Nearly every time we fly an enhanced 3D mission, the crosshatch flight ends at the opposite end of the site as the perimeter flight begins. The drone flys across the site at 6mph doing nothing but burning up battery life. Today it cost us 6% of battery life which would have been enough to finish the mission.
Is there a reason for this behavior? If not can you please update the map planning to set the perimeter start point as close as possible to the end point of the grid flight?
I did take a video of this behavior, will add a link later this afternoon.
5 Likes
I see that most of the time the plan just adjusts to whatever perimeter you have and likes to start on the north. You can usually rotate the path to mitigate this as much as possible. The are usually a couple of angles you can input that can be run that will essentially be in the same alignment but you can watch the time estimate to get it as short of a crossover as possible. You have to turn off Automatic Settings in the Advanced menu.
DD Defaulted to this.
I aligned for the longest run.
I changed the angle so the length of the change in direction of the crosshatch and the transition to the perimeter path are as short as possible. We picked up 2 minutes but that’s about all I could get since we are unable to change the start point otherwise.
The tip is that if you can plan on a computer to highlight the Flight Direction and with the slider still up you can use your arrow keys to quickly find that lowest flight duration.
Hey Michael, yes we do take advantage of the work arounds and adjusting the direction to try and minimize the flight time. The logic in the planning just doesn’t make sense. Why would DD default to north? Maybe it’s more complex than I’m giving credit but changing the logic to start the perimeter at the nearest point to the end of the grid would inevitably save us all battery life right? Even if the logic is more complex, at least increase the speed from end of grid to start of perimeter since there are no images being captured.
2 Likes
Yeah I don’t get it either. Even when you do photos or video it seems to want to start at the northwest. I wonder if a simple reverse flight like on the linear app would help counteract? I also find it odd that you can’t do a perimeter by itself.
Why can we not have a photo report with multiple points of view and not limited to 16 photos? I guess I could do 5 different photo flights… meh. I have been asking for it for years and I guess it is too hard to implement.
It seems like we have been experiencing a decline in practical engineering for flight as the solution continues to build new project management functionality. I am starting to think we now need two separate apps. One for flight and the other for analysis/project management.
2 Likes
I also mentioned this to DD at least a year ago and still no update. Please up-vote this thread so DD understands how much of an issue this really is. On small sites it’s not huge but on large sites (like most of mine) I burn anywhere from 8-15% just between the end of the “lawn mower pattern” and the beginning of the perimeter flight - it is very inefficient.
2 Likes
Here is the video evidence… almost 2 minutes of 6 mph for absolutely no reason.
2 Likes
Oh yeah, there’s no doubt. I don’t know if you’ve ever used a linear flight app but just imagine having to start and end all the way at the end of a run. Probably weighs 6 to 7 minutes on a mile of roadway. I’m still doing those with the H520E RTK until drone deploy releases their native linear flight. I Hope they’ve gotten some user input while building it. I gave them a ton of information at the beginning so hopefully it all made sense. Only time will tell.
This happens on every flight path change from parallel to perpendicular and from either to oblique.
I’ve been complaining about this forever.
Really, how difficult is it to have DD do simple math to choose the starting waypoint of prependicular/oblique flight the closest to the last waypoint of parallel/perpendicular flight?
Usually one of the transitions is on the direct opposite waypoint.
I have had responses from DD with the lame excuse “it’s not that easy to calculate…”, but my college does it on an excel spreadsheet, so how hard can it be?!
The mentioned workarounds take a lot of tinkering time and aren’t usually possible when you plan a parallel+perpendicular+oblique flight. Besides, it’s just that, a WORKAROUND that shouldn’t even be needed, just to spear DD a few minutes of programming.
The entire DD team should feel really ashamed about this lack of the simplest optimization math.
1 Like
I think the most complicated thing about it is to have it wrap around on itself. If there are 100 waypoints and you want to start on 25 then it flies 75 and goes back to do the first 25. The only issue with that is pilot awareness and safety in my opinion.
I think the logic for that sequence is pretty straight forward. The only time the perimeter flight is in play is after a grid. Seems like you would start the perimeter waypoint numbering at the last grid waypoint so that if you change the parameters of the mission, the perimeter waypoints always start closest to the last grid waypoint, eliminating the 25 through 100 then back to 1.
**Not a programmer
Part of the problem is when the start and stop of the individual headings are on opposite side of the site and then the perimeter starts in a different place which is caused by the forced N/NW position there often is no way to get them closer to each other due to the required settings for the plan. This is where we adjust the overlaps by percentage points in order to align the start/turn/perimeter are as close to each other as possible. This at least get them all on the same end of the location instead of across from. The coding of calling waypoint 1 as 25 is the unknown.
Isn’t this exactly what happens when you map a grid and choose no perimeter?
1 Like
Well it of course does have a perimeter waypoint then. This is where you can adjust the overlaps to get everything on the same side.
I guess what I’m saying is the logic to solve this issue is simple enough that we shouldn’t have to manipulate the map to avoid wasting 5-10% of battery life. You could build out this logic in a simple flight app like Litchi in 20 minutes.
1 Like
Litchi is always the fallback here as well. I’ve made some pretty crazy maps with elevation change and strangely shaped sites. If it did mapping calculations I probably wouldn’t use anything else. That’s the way ours look after simple direction and overlap adjustments. If you know how to make it happen tell support! 
1 Like
The highest priced consumer drone software on the market ought to be able to figure this one out without some fool like me providing input.
1 Like
What would be really nice is to have a high-level view of the Engineering queue. I can’t even imagine what they have on the plate right now and it sure would help us focus on the most important issues. They have their take on it but obviously not what the users here are experiencing like our need for Linear flight which is supposed to be very soon. Maybe DDC…
1 Like
Ha! Pretty sure they are all dialed into 360 camera integration at the moment.
2 Likes
That’s one of the items but communications have been ghost lately. Linear flight is there but more likely are API integrations like BIM360 and Procore. Also there is allot of traffic on Live Map expansion of functionality.
1 Like
thanks for the info here!
3 Likes
