DD has two ways (that I know of) to change the starting point for a mission. The first is helpful if a mission has started and something interrupts it and the program doesn’t automatically pick up where I left off. By advancing the start point from 1 to something higher, the first part of the route is not repeated. I’m not trying to address this need. The second is to change the direction of the flight and hope that you can luck into getting the start point to be where you want it. This is a frustrating game that I think could be addressed a couple of ways.
I propose two additional ways to change the start point, that is, where waypoint 1 is on the flight path. The first would be a choice (checkbox?) that causes the current path to be reversed. Essentially the final waypoint becomes the first waypoint. Presumably, this would maximize the benefit of whatever path the program thought would make sense since the route would be unchanged, but would allow the drone to essentially advance in the opposite direction. Several benefits of this to be explained in a moment.
The second would be the ability to touch the route on the screen, probably on the perimeter of the area, identifying where I want the start point to be. The program from that point would create a logical route while maintaining my start point.
Why is so important to be able to pick a start point? When I fly, I want to start at a point farthest from my takeoff/landing location so that the drone is constantly getting closer to me. When I’m flying and DD is deciding out how much battery it needs to return, it adds a factor that appears to be proportionally longer as the pathway back to the landing pad increases. So extra margins are reserved than might be needed if we’re flying in the direction of “home” as part of the mission. The flight out to the farthest point (which only happens once) is flown about as fast and efficiently as possible and has a nearly 0 impact on the battery life (of course depending on the size of the mission).
What else might drive where the start point might be? Wind. If there’s a meaningful wind, I will move my takeoff/landing spot to as close to a downwind spot as I can so that the drone is doing the mission with the wind “pushing” it toward the landing spot, not away from it. Good for battery life. Good for safety.
One way to implement all this might be by a radio button. The first choice is to let the program choose the start point as it does today and allowing the course to be adjusted. The second choice would take whatever the current course is and reverse it. If you then went back to the first choice after reversing the course, the starting point for any course changes would be whatever the reversed course was. You could still change the course from that point. The third choice would be to select a starting point on the screen. (This would end up being my preferred method most of the time.) After selecting the start point, the path would be drawn by the program and the course would (as always) be set by the program. I’d still be able to adjust the course, but the start point would remain static unless I were to choose the first radio button choice again.
I welcome any thoughts on any of this from DroneDeploy developers or from other users who may have a different way of thinking about this.
@dburk I can definitely see the benefit in the efficiency of operation and the need for altering flight plans to work backward as opposed to away from the pilot. Do you feel this feature would be easier to use as a reversed mirror of the flight plan, that could be accessed with just a click? Or do you feel this would be better as a more customizable addition in the advanced settings?
@Rob_Corbett some of the time reversing the course would solve the entire problem, but more of the time it likely wouldn’t by itself. Course changes (already possible in DroneDeploy) might correct the natural path but it can be tricky getting the end point to be where I want it to be just by changing the course. The ideal (as one of several choices) would be to specify the starting point or the ending point and let the path be generated from there. I hope that’s making sense.Since I don’t have to program it and I have no idea what kind of an interface or implementation problems I’m creating, it’s easy for me to say “I want it all!” But I get it, it may be hard to implement “all” of my idea.
@Jamespipe @dburk has presented some really great ideas recently. Some I feel could be very beneficial, moving forward.
Thanks for the input! We did actually set the current model (start at the nearest corner) thanks to the opposite feedback from others.
The reasoning was:
- that if there was a problem with the camera for some reason, you would find out sooner if it flew to the first capture location.
- we don’t know how long the drone will be able to fly exactly, so the most efficient way to use the battery is to start capturing as soon as possible,
I admit it would be nice to be able to control this, but we don’t have any plans to add that to the roadmap.
Thanks for your response. Two thoughts:
When you say you set the start to the “nearest corner”, how does the program know where I’ll be taking-off/landing? More often than not, I’ll create the flight at my desk and then tweak it on site. When did the “start” point get defined? Is it based on actual take-off location? That hasn’t been my experience, but I’m often wrong.
From a safety standpoint, I really want/need the drone to fly so the wind is blowing toward me and the landing spot. For me, that’s the safest. I see the benefit of knowing I’ve got a camera problem before I fly to the farthest end of the site, but can’t that be solved by taking a picture or two at altitude before heading to the start point? Maybe one picture at the horizon, one nadir, and one at the horizon so the block of 3 can be treated as what I call “bookends” for the rest of the shots that are really part of the data collection. I also wonder if starting away from me and flying towards me is more eficient with the battery for 2 reasons:
a) I would think we’d want to reduce the number of times we fly the “wasted legs” of the mission. By “wasted legs”, I mean the ones to/from the flight area. After the first battery, all my “wasted legs” get shorter rather than increasing with each battery. Maybe I’m naive to think that I’m reducing the “wasted legs” by shortening them with each battery. For a one-battery flight, it doesn’t matter. But for a 2+ battery flight, I imagine (maybe incorrectly) that my direction reduces the length of the “wasted legs”.
b) But even if a) isn’t right, I would think that as the drione is closer to me when the battery is getting low, the amount of extra/unused battery that needs to be reserved for the return flight is lessened. If there’s a “fudge” factor based on an estimate of what’s needed to return home, the fudge factor is multiplying by a smaller number as the drone is closer to me. Maybe there is no “fudge” safety factor.
In any event, if we can’t place the start point, perhaps we can at least be able to reverse the flight path so that we can choose which way we think is safest and most efficient? Just an idea.
It’s easier to show you how I change the start/end point than tell you. Change the start/end position
That is a really neat workaround. Does it work with mapping missions too?