Litchi - Creating Missions by flying them first

[Logger]

(Warning Long Rambling post)

I have had good experiences creating Litchi missions around a farm in the mobile apps and Mission hub. These have been 9km long and have tended to be fairly course in their navigation requirements. Any potential obstacle issues have been dealt with by flying above them.

Recently I tried to create much shorter, more precise missions by recording the waypoints with the aircraft using the C buttons. The plan was to have the Mavic fly well below tree top height, so that it can inspect Water Troughs on a farm. Flying above obstacle height does not provide a close enough inspection to fulfil the task. A typical mission may be 2km in length starting with a 500m transit, then a slower observation section viewing scattered water troughs over undulating terrain along a 1km section near to trees. Finishing with a 500m transit home. The aircraft goes beyond line of sight.

To do this, I carefully flew the Mavic along the route in Waypoint mode adding Waypoints to build the route in a similar manner to DJIGo4. Logic being that actual physical locations will provide more accurate positions than anything derived from a map.

However regardless of GPS accuracy, I have struck issues with Litchi that make what I am trying to do unworkable. Litchi does not seem quite up to the task.

+++++++++++++++++++++++++++++++++++++

Early attempt led to a crash

I carefully marked out a route recording WPTs, heights and orientations. I did this by flying the aircraft to the positions and using the C1 button to record the WPTs.

I then flew the mission as curved turns. At the first target the aircraft was visibly a few metres south of a WPT, where it was set to slow up to 3mph and look at a target. At the second target the aircraft also passed a few metres south of where I had physically programmed it to be and a couple of seconds after toggling sports mode to abort, it crashed into a tree. It was only doing 3mph and I had very carefully set the WPT to be clear of the tree. Fortunately, only prop damage.

I cannot be certain this was a GPS accuracy issue as logs show it was receiving 16 GPS/Glonass satellites at the time. It was more likely related to an overshoot in the curved turns. Had I used Straight legs the aircraft would have come to a complete stop at each WPT and then reversed away to next WPT back in the direction it came from. Instead the curve took it beyond the WPT it flew by.

++++++++++++++++++++++++++++++++++

(Some of the stuff below is not mentioned in the Litchi manuals so may useful to know. I observed the behaviour by flying over test routes. )


SPEED when flying Waypoints

Litchi HELP says this about Waypoint speed:

Speed: The speed at which the aircraft will travel from this waypoint to the next. By default the aircraft will use the mission's cruising speed setting, but the cruising speed can be overriden for each waypoint using this setting.
Warning This setting is only in effect when the aircraft is in range of the remote controller. If signal is lost during the mission, the aircraft will continue the mission at the speed it was travelling at when it lost signal.

However this needs further clarification. What I have observed from testing is as follows:

Straight line - WPT Speed means “Commence speed leaving this WPT until approaching Next WPT, slowing in time to a STOP at next WPT.”

With straight lines the aircraft always stops at ALL the Waypoints and will never actually be at programmed speed at any WPT. Flying high speed (30mph) at a Straight Lines WPT, aircraft will commence deceleration before arrival and stop over head.

Curved Turns - WPT Speed means .. “Commence speed passing this WPT until passing Next WPT. Once PAST next WPT commence new speed. So a speed of 30mph will be maintained all the way to next WPT, then speed changes, if programmed to do so”.

With a programmed reduction to low speed - a large overshoot will occur. Same route as before but curved turns, aircraft will arrive overhead at 30mph then commence speed change. If it is a large reduction like 30 to 5 mph this can take 100’ or more beyond the WPT before Mavic slows.

So you can see, Curved Turns and Straight Lines deal with Speed settings very differently.


A Loss of signal (LOS) means the rest of route will be flown at Signal Loss speed (Not Mission Speed). A/C will still stop at WPTs if Straight lines in use.

Turning remote off to create LOS while Flying full speed at a Straight Lines WPT, aircraft will commence deceleration before arrival and stop over head. More importantly it will then depart waypoint and attempt to fly subsequent legs at the 30mph LOS speed and NOT at programmed speeds.

This could be problematic if mission commences with a high speed transit at 30mph, a signal loss occurs and then progresses to a slow speed manoeuvre section in a confined space. Close in turns programmed to occur at 2 or 3 mph will now be attempted at 30mph almost guaranteeing a collision.


Curved Turns

Curved turns and confined spaces do not work so well. Because the aircraft never comes to a complete slop (as is does with straight legs) it seems more prone to flying wide or overshooting turns.

Waypoint actions do not occur on Curved Turns. Caveat - They do still occur on first and last WPT of a Curved Turn mission because there is no curve at these WPTs!

+++++++++++++++++++++++++++++++++++++++++++++++++++++++



Creating WPTs and POIs with aircraft and tablet using screen tap or C buttons.

Observations and Issues so far:


1. Manually dropping a WPT with C1 button will record A/C location, height above TO point and heading including gimbal angle.

2. Subsequently dropping a POI and assigning it to this WPT will overwrite heading and gimbal angle. So it is easy to inadvertently lose hard gathered positioning data and aircraft recorded alignments. ** very annoying

3. Works best if you take off at intended home point, so that recorded WPT heights are correctly referenced. This becomes a problem if home point and observation area are a long way apart as you need to walk there.

4. If you walk a route carrying the aircraft in hand with aircraft powered on at proposed take off point and use it to record WPTS or POIs it will set altitudes at 0. No Take Off occurred so there is no Take Off reference height.

5. Home point is recorded though, so when you walk back home it is interesting to see how many feet the aircraft remote thinks it is from home when you place it back at the known home point. Gives a good idea as to how far out the GPS can get.

6. If you walk a route with the aircraft flying alongside you can use it to carefully record WPTS and orientation. Correct WPT altitudes referenced to take off point will be set.

7. If your survey area is distant from your take off point this process can become impractical as the battery will be flat by the time you walk there. Instead fly aircraft from take off point to survey area and land noting height difference. Walk the route from within the survey area with aircraft flying alongside marking waypoints. Then later adjust the WPT altitudes by the height offset between your proposed TO point and the height where you landed/took off again in the survey area.

8. You cannot return the aircraft to a location mid route and add another WPT at the aircraft. If you do it will be added to the end of the route.

9. You cannot re order waypoints. Instead you have to use the standard process of adding a WPT between two existing WPTs then drag it to where you want it to be on the map which is less accurate.

10. Aircraft speed has to be extremely slow at flyby WPTs to prevent overshoot and collision with close in obstacles. ie 1 or 2 mph

11. To this end multiple wpts, some with enroute speed for the transit leading to others at inspection points with much slower speeds could provide solution.

12. Aircraft heading will not necessarily be course aligned enroute and this has obstacle avoidance implications

13. Having obstacle avoidance ON precludes fast transits above ~ 22mph

14. In winter when sun remains low in sky obstacle avoidance may need to be off for mission to proceed. In this case positioning accuracy and accurate height is paramount.

15. Pausing a mission at a WPT only stops the trajectory. WPT actions like rotate and “take photo” continue regardless.

16. WPT action “Rotate Aircraft – x degrees” does not mean rotate aircraft x degrees. It actually means rotate aircraft onto a bearing of x degrees in relation to North.

17. Straight leg WPTs that are purely intended to cause a change in altitude or a slight bend in route still result in a complete stop. Annoying if trying to place a bend on a high speed transit leg or a climb to avoid an obstacle.

18. Consider creating and overflying a reference Keyhole WPT at start of route to check GPS positioning accuracy. Abort mission if no good. This could be as simple as programming it to fly along a fence line and stopping over a fence post. If actual flight is offset don’t continue

19. Consider a 10m (30 ft) buffer. Take 10 Steps back from obstacles. If WPT is within 10m of an obstacle, Fly aircraft to desired WPT position then move the WPT 10 steps away from the obstacle. On future flights GPS variance could place the aircraft on the obstacle even though it is well clear when marking the point.

20. Consider programming curve sizes to 100% if there is any chance of the mission getting flown faster than programmed due to LOS. Otherwise it more likely to fly wide on sharp corners.

21. Consider Setting Signal loss action to RTH if signal loss could possibly occur in high speed section of route.

22. Use Straight Legs to guarantee dead stop at all waypoints. Downside is this leads to much longer mission time.

23. The inability of Litchi to create a mission with a combination of straight legs and curved turns means the farm observation flights I envisage will invariably have undesired stops at WPTs, that were merely intended to place a bend in the route.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Some questions:

Q In Litchi WPT mission - how do I cancel out of impending low battery RTH mid mission in the 10 sec warning phase? I cannot see how to do this as there is no cancel prompt in WPT.


Q What does the aircraft know in terms of autonomous flight plan after signal loss? Waypoints = Yes, Speeds changes = No, Heights changes = Yes?


CONCLUSION

Litchi does not appear well suited to flying Waypoint mission that encompass a transit beyond line of site into obstacle effected confined areas.

Signal loss in transit could lead to overspeed and collisions in subsequent slow sections.
The necessity to use straight legs to confine the route will lead to numerous unnecessary enroute stops.
This in turn will reduce usable observation time and the practicality of programming these mission for Farm use.

These shortcomings may well effect the other WPT capable apps using the DJI SDK too.

Will be interesting to see if new offerings like Drone Harmony can do a better job of this.

 

[Oglo]

Mate! You've just saved me about 10 hours of testing!
Definitely not a long and rambling post as far as I'm concerned - valuable and greatly appreciated.
I had started doing a complex Litchi WP mission and had unexplainable things happening when I was running them - thankfully they have a pause button. Very disconcerting watching the MP come close to trees when I had left plenty of room between WP''s.
I was trying to do a complex flight path along the side of a hill with close rocks & trees to go between plus have very accurate POI points. Intended use was for a 'cinematic' style one shot following a mountain bike. For the life of me I couldn't work out what was going on as I was just trying to do the shot, not test if Litchi was capable of doing the shot.

As an aside I also have been working on looking at doing farm inspections exactly as you outlined. My hope is to be able to do extremely long distance farm inspections (even if it's only working out the tools and logic for now, waiting for when affordable quads/fixed wings can stay airborne for much longer).

I'm looking closely at Drone Harmony(DHM) and fingers crossed with where that may lead. Love their approach and logic. I am finding that my phone/tablet bogs down doing computing projections in the current beta version of DHM when I get a lot objects in their scene (time for an upgrade to the latest phone/tablet?!) or hopefully they can code it to compute more efficiently on Android. Exciting times.....

Thanks again for what would have taken you a lot of time to "put pen to paper". Greatly appreciated.

 

[dwallersv]

Some comments:

Pt 2: This is exactly what I expect Litchi to do when I assign a POI to a waypoint. After all, what did you think the point of assigning a POI to a WP was other than to have Litchi automatically calculate heading and gimbal angle to frame the POI? A POI serves no other purpose in connection to a WP, so if you've already (painstakingly) determined heading and gimbal for a WP, a POI near by has no connection to it at all.

In fact, in the use case you're talking about the option to assign a POI you've placed on the map shouldn't even be available in the type of waypoints you're discussing; the gimbal should be set to "Interpolate", not "Focus POI".

Pts 3-7: You are making this much harder than it needs to be for managing altitude. There is a batch edit feature in Litchi that allows editing certain waypoint characteristics for a selected set of waypoints. One of the available features in batch edit mode is ground-relative altitude.

So, you can use any of the methods you've described to locate waypoints, and then edit them all as a batch and set their altitude to some fixed elevation above the ground. Litchi uses Google Earth elevation data to determine ground elevation at the waypoint.

After that, you can refine your altitudes by editing individual, or subsets of waypoints. For example, if you wanted to fly 100' above the ground, but in one section of 7 waypoints you want to fly 150', first select all waypoints in the batch editor, set altitude to 100' ground relative. Then, select the 7 you want higher, and set their altitude to a delta of +50' (another option in the batch edit dialog -- adjust all selected waypoints by a fixed amount).

Pt 10: Have you done much manual flying at speed? Put it in sport mode, send it off to your left far enough to get it up to 30mph as it passes in front of you, then let go of the stick as it passes and see how far it has to go to stop as fast as it can. It's quite a distance. This is not a Litchi issue, its a flight dynamics issue. Other variables like wind, GPS accuracy, etc. make it impossible for Litchi to be precise to within a few feet for things like speed changes at specific locations. Pt 11 is spot-on, and is the technique often used.

Pt 12: This is deliberate -- that's how you point the camera. In fact, if using POIs in a Litchi mission, the heading and course will often be different, perhaps most of the flight.

Pt 18: When absolute best possible GPS accuracy is important, as is the case with the sort of mission you're discussing in the OP, getting a good understanding of GPS Dilution of Precision (DOP) and its "sub" variants (HDOP/VDOP/PDOP/TDOP), and how to use tools to forecast DOP for planning is very important.

DOP directly affects the accuracy of GPS at any given time of day and location on the earth's surface. It's a calculated value based on the geometry of visible satellites that affects the error margin in the calculated position. Without explanation (google this stuff for more info), the configuration of GPS birds can be bad for accuracy, occasionally but rarely really bad, and therefore not suitable for applications that depend on +/- 10-15ft accuracy. A high DOP of 6-8 can result in position errors as bad as 40-50'.

You want a DOP as close to 1 as possible. Finding a date/time that meets this criteria should be a part of mission planning. We can forecast future DOP because we know where the satellites will be in the future, hence we can calculate the geometry at a point on the earth.

Various pts about speed changes, overshoot, stopping, etc.:
A great deal of this can be completely controlled and worked around by using control waypoints (CWP) before and after the working waypoint (WWP).

With Curved turns enabled, you can reduce the Curve Size at the WWP to 0ft, and the speed to 0.2mph. Then, put one or more CWP before and after the WWP far enough away to fully absorb any overshoot. Use several if you want to ramp speed at a certain rate. Or, calculate distances based on the Mavic braking performance and place CWP(s) on that basis.

In any case, you can then control what happens precisely at the WWP. The entire survey is shot in 4K, so any hires stills you need are simply frame-grabbed from the video. Doing it this way also gives you an easy way to use POIs to manage image framing at WWPs.

Often you won't need anything more than a properly placed CWP in front to get speed down in time, and then one after to loiter as long as you want. All the things you want to do with changing where the camera points and taking pictures can be simulated by a bunch close together waypoints changing heading and gimbal, transitioning at 0.2mph.

Limitations of automation when disconnected: Look at how you might break the mission up into several missions with different RC locations and home points, so the connection isn't lost. This is pretty easy to do with the batch editor -- a bunch of WPs can be easily selected by tapping on them, then deleted all at once. Make copies of the original mission for as many segments as you are going to break it into, then edit each and quickly just delete the waypoints not a part of the segment. Add a new HP, and you're ready to go.

 

[Oglo]

Excellent reply, thanks for the huge effort you've put into your detailed post.

You seem to have considerable knowledge and experience of the app, just be aware many of us don't, so the original post is quite justified in its observations even if in your mind things are obvious. BTW My normal gripe with apps is that they are usually written by people with highly technical & vast knowledge, but aimed at people with experience in other fields. It's almost a catch 22 situation - we want it powerful, but we want it simple.
Luv the app!

Some comments:

 

[Logger]

Thank for the suggestions.

Some comments:

Pt 2: This is exactly what I expect Litchi to do when I assign a POI to a waypoint. After all, what did you think the point of assigning a POI to a WP was other than to have Litchi automatically calculate heading and gimbal angle to frame the POI? A POI serves no other purpose in connection to a WP, so if you've already (painstakingly) determined heading and gimbal for a WP, a POI near by has no connection to it at all.

In fact, in the use case you're talking about the option to assign a POI you've placed on the map shouldn't even be available in the type of waypoints you're discussing; the gimbal should be set to "Interpolate", not "Focus POI".

Correct. Assigning a POI to WPT is irreversible with Litchi in the sense that you cannot recover the previously recorded alignments that may have taken considerable effort to record. It is a shame Litchi is unable to store two alignments per WPT. One associated with user settings and a second for POIs. One could then toggle between them without fear of loss..

Pts 3-7: You are making this much harder than it needs to be for managing altitude. There is a batch edit feature in Litchi that allows editing certain waypoint characteristics for a selected set of waypoints. One of the available features in batch edit mode is ground-relative altitude.

So, you can use any of the methods you've described to locate waypoints, and then edit them all as a batch and set their altitude to some fixed elevation above the ground. Litchi uses Google Earth elevation data to determine ground elevation at the waypoint.

After that, you can refine your altitudes by editing individual, or subsets of waypoints. For example, if you wanted to fly 100' above the ground, but in one section of 7 waypoints you want to fly 150', first select all waypoints in the batch editor, set altitude to 100' ground relative. Then, select the 7 you want higher, and set their altitude to a delta of +50' (another option in the batch edit dialog -- adjust all selected waypoints by a fixed amount).

I disagree. Well aware of the batch edit feature and I use it all the time. There is no way I am going to rely on Google Earth ground-relative altitude to get the drone in beneath overhanging trees and so on. I simply set the the transit sections above known terrain. Then for the inspection points it is far more accurate to set known baro altitudes by flying the aircraft to the exact position and altitude I require. This is the very reason to pre-fly the mission. So I can have the drone sitting 5 or 10 feet a above ground level between tall trees observing a target.

Pt 10: Have you done much manual flying at speed? Put it in sport mode, send it off to your left far enough to get it up to 30mph as it passes in front of you, then let go of the stick as it passes and see how far it has to go to stop as fast as it can. It's quite a distance. This is not a Litchi issue, its a flight dynamics issue. Other variables like wind, GPS accuracy, etc. make it impossible for Litchi to be precise to within a few feet for things like speed changes at specific locations. Pt 11 is spot-on, and is the technique often used.

Well lets see - 700 flights and 1200km on my Mavic. YES, I have done my fair share. How do you think I tested all this in the first place? I flew it over Waypoints at 30mph and observed the results while standing underneath . It is a DJI SDK Curved Turns issue that can be mitigated by using Straight Lines

Pt 12: This is deliberate -- that's how you point the camera. In fact, if using POIs in a Litchi mission, the heading and course will often be different, perhaps most of the flight.

I think you missed the point - I was advising people that having the heading out of alignment with the course has obstacle avoidance implications. I tend to fly my missions with OA off though.

Pt 18: When absolute best possible GPS accuracy is important, as is the case with the sort of mission you're discussing in the OP, getting a good understanding of GPS Dilution of Precision (DOP) and its "sub" variants (HDOP/VDOP/PDOP/TDOP), and how to use tools to forecast DOP for planning is very important.

DOP directly affects the accuracy of GPS at any given time of day and location on the earth's surface. It's a calculated value based on the geometry of visible satellites that affects the error margin in the calculated position. Without explanation (google this stuff for more info), the configuration of GPS birds can be bad for accuracy, occasionally but rarely really bad, and therefore not suitable for applications that depend on +/- 10-15ft accuracy. A high DOP of 6-8 can result in position errors as bad as 40-50'.

You want a DOP as close to 1 as possible. Finding a date/time that meets this criteria should be a part of mission planning. We can forecast future DOP because we know where the satellites will be in the future, hence we can calculate the geometry at a point on the earth.

Indeed it does, I should also point out that there are around ~ 50 satellites available for use and not just the 24 GPS you mentioned elsewhere. This explains why it is very common see GPS fix 15 or 16 Sats.

Various pts about speed changes, overshoot, stopping, etc.:
A great deal of this can be completely controlled and worked around by using control waypoints (CWP) before and after the working waypoint (WWP).

With Curved turns enabled, you can reduce the Curve Size at the WWP to 0ft, and the speed to 0.2mph. Then, put one or more CWP before and after the WWP far enough away to fully absorb any overshoot. Use several if you want to ramp speed at a certain rate. Or, calculate distances based on the Mavic braking performance and place CWP(s) on that basis.

In any case, you can then control what happens precisely at the WWP. The entire survey is shot in 4K, so any hires stills you need are simply frame-grabbed from the video. Doing it this way also gives you an easy way to use POIs to manage image framing at WWPs.

Often you won't need anything more than a properly placed CWP in front to get speed down in time, and then one after to loiter as long as you want. All the things you want to do with changing where the camera points and taking pictures can be simulated by a bunch close together waypoints changing heading and gimbal, transitioning at 0.2mph.

In theory it might work.Using speeds like you suggest of 0.2mph will probably lead to much more time being spent at each water trough than is desired. I envisage flying between troughs at 10 to 20 mph and then slowing up and looking at each one for around 15 seconds .Then on to the next with slow speed segments extricating the aircraft from each Water trough as well. If I persist with Litchi for the task I wont be using Curved Turns though. I see too much risk due to the way they deal with speeds. Straight Lines will be better especially given I am not chasing cinematic footage. Just checking to see status of trough. Fly to abeam trough to a straight line WPT clear of obstacles, stop because I have no choice. Position in to observation point STOP and observer. Reverse out to safe spot STOP, Climb away and on the next water trough. Lots of stops but no over shoot.

Limitations of automation when disconnected: Look at how you might break the mission up into several missions with different RC locations and home points, so the connection isn't lost. This is pretty easy to do with the batch editor -- a bunch of WPs can be easily selected by tapping on them, then deleted all at once. Make copies of the original mission for as many segments as you are going to break it into, then edit each and quickly just delete the waypoints not a part of the segment. Add a new HP, and you're ready to go.

I see your methodology but at the point I break it up into multiple mission like this I might as well simply hand fly each one. I am not going to use multiple missions due to the limitations of Litchi or the SDK.
With careful straight line programming I think it can be done in a way to allow for disconnects and proceeding successfully after signal loss. It will be tedious to program though and there may be better tools for the tasks.

Think of a farmer wanting to use his drone to do this job. He wants to press play and have it check 15 water troughs saving him an hour of opening gates and driving about the place. An ideal software package might allow you to set it all up by driving to each water trough in you farm truck. Pop the drone into the air and record 3 WPTs. One to arrive at, a second in the confined space for the observation and a third in a safe position to allow departure to next site. Record this for each of the sites then have it compile into a route that can be safely flown in one go with all the altitudes referenced to the take off point.. Litchi is not the tool for this.

Anyway interesting to hear your thoughts.

 

[Logger]

Mate! You've just saved me about 10 hours of testing!
Definitely not a long and rambling post as far as I'm concerned - valuable and greatly appreciated.
I had started doing a complex Litchi WP mission and had unexplainable things happening when I was running them - thankfully they have a pause button. Very disconcerting watching the MP come close to trees when I had left plenty of room between WP''s.
I was trying to do a complex flight path along the side of a hill with close rocks & trees to go between plus have very accurate POI points. Intended use was for a 'cinematic' style one shot following a mountain bike. For the life of me I couldn't work out what was going on as I was just trying to do the shot, not test if Litchi was capable of doing the shot.

As an aside I also have been working on looking at doing farm inspections exactly as you outlined. My hope is to be able to do extremely long distance farm inspections (even if it's only working out the tools and logic for now, waiting for when affordable quads/fixed wings can stay airborne for much longer).

I'm looking closely at Drone Harmony(DHM) and fingers crossed with where that may lead. Love their approach and logic. I am finding that my phone/tablet bogs down doing computing projections in the current beta version of DHM when I get a lot objects in their scene (time for an upgrade to the latest phone/tablet?!) or hopefully they can code it to compute more efficiently on Android. Exciting times.....

Thanks again for what would have taken you a lot of time to "put pen to paper". Greatly appreciated.

Your Welcome. There is a lot of stuff in there derived from months of fiddling about with Litchi and lots of hand written notes. Is is a shame the Litchi manuals do not document it all a bit better. Lots of little gotchas in there. The Speed handling difference between Curve turns and Straight Lines is a clanger.

I still believe the Fly and Record C key methodology is good way create a Litchi route, if accuracy is primary goal. As you can see my experiences with it so far have been mixed. Good to discuss this method though, as most people do it the other way with Mission hub or the mobile apps.

Like you I have high hopes for Drone Harmony for farm inspections. Be great if they develop a module suited to this sort of thing.

 

[dwallersv]

Excellent reply, thanks for the huge effort you've put into your detailed post.

You seem to have considerable knowledge and experience of the app, just be aware many of us don't, so the original post is quite justified in its observations even if in your mind things are obvious. BTW My normal gripe with apps is that they are usually written by people with highly technical & vast knowledge, but aimed at people with experience in other fields. It's almost a catch 22 situation - we want it powerful, but we want it simple.
Luv the app!

The internet is such a poor communication medium, as so much non-verbal essential to communicating "mood" or attitude just isn't there.

I meant no criticism of the OP, and agree 100% that posts like his are extremely valuable -- if only so that others with more experience can clear things up, in an open discussion, and benefit many.

I often have the problem of people misinterpreting my somewhat clinical tone online to be critical or abrasive. I try not to sound like this, but I'm hopelessly crippled in this regard

 

[Logger]

One trap with pre flying routes and recording WPTs is it is very easy to overlook the drones flight path between WPTs. It only records WPTs and POIs and not the path that you fly.

So if you put a WPT at a tree you want to look at beside a building , then fly around the building to another tree and drop a second WPT, the mavic will fly directly across or into the building instead of following your flown path around it. Fine if you consider this and place appropriate WPTs. Not fine if you forget!

 

[guest112]

One trap with pre flying routes and recording WPTs is it is very easy to overlook the drones flight path between WPTs. It only records WPTs and POIs and not the path that you fly.

So if you put a WPT at a tree you want to look at beside a building , then fly around the building to another tree and drop a second WPT, the mavic will fly directly across or into the building instead of following your flown path around it. Fine if you consider this and place appropriate WPTs. Not fine if you forget!

Hello pilots,

We love your interesting discussion! Hope you don't mind us joining in and learn from your experiences so that we can further improve the Drone Harmony Mission Planner. We certainly will put efforts into providing a better solution for farm scans and your feedback will help us tremendously in doing so. Thanks for that!

Logger, in your post you mention the problem of recording a flight path between WPTs for which we offer a solution:

1. Record the manual flight (for explicit WP's take a picture at each WP location)
2. Transform the recorded flight with the magic wand tool (appears on the left side once you select your recorded flight) - it provides you with three options for the flight plan creation:
   • Use only the pictures (WP's): DH will create a smooth path that goes through your recorded WP's. On that smooth path DH will create new WPs and it will also include your recorded WPs.
   • Use the recorded path: DH will distribute new WPs on your recorded path.
     
   • Use the recorded path and WP's: DH will distribute new WPs on your recorded path and make sure that your recorded WPs are included.

If you have questions on the process, we're here to help.

Thanks again and happy flying!

DH Team

 

[dwallersv]

@droneharmony, nice! By recorded path, do you mean the .TXT log file data, or the more detailed .DAT logs taken from the drone via DJI Assistant 2?

I was unaware of this feature, and as soon as I understand how to get the recorded path and import it into DH, I'm heading out to give it a shot.

 

[Logger]

...

Logger, in your post you mention the problem of recording a flight path between WPTs for which we offer a solution:

1. Record the manual flight (for explicit WP's take a picture at each WP location)
2. Transform the recorded flight with the magic wand tool (appears on the left side once you select your recorded flight) - it provides you with three options for the flight plan creation:
   • Use only the pictures (WP's): DH will create a smooth path that goes through your recorded WP's. On that smooth path DH will create new WPs and it will also include your recorded WPs.
   • Use the recorded path: DH will distribute new WPs on your recorded path.
     
   • Use the recorded path and WP's: DH will distribute new WPs on your recorded path and make sure that your recorded WPs are included...

Thats sounds like an excellent feature to have and one that is well and truly missing from Litchi. So create the flight plan path using your REC module (The last option in your planner.) I assume it records the flight by taking note of position at a high sample rate like every half second or so. Then choose the option from the three you list to create the plan to save.

Will you system ultimately allow for mission continuation after signal loss and disconnect?

 

[Logger]

Lets continue in an app specific thread shall we .

Drone Harmony - Creating Missions by flying them first

 

[CivilizedSteve]

Thank you for doing and posting this detailed information. I have also been wondering about using waypoints for technical missions and wondering several things, including how much leeway/variance one should expect from the plan. Thanks!

 

[Jim Dow]

Why should you have to create curved flight lines by flying them first. Take a look at the following curved flight lines.

 

[MaverickMavicMark]

(Warning Long Rambling post)

I have had good experiences creating Litchi missions around a farm in the mobile apps and Mission hub. These have been 9km long and have tended to be fairly course in their navigation requirements. Any potential obstacle issues have been dealt with by flying above them.

Recently I tried to create much shorter, more precise missions by recording the waypoints with the aircraft using the C buttons. The plan was to have the Mavic fly well below tree top height, so that it can inspect Water Troughs on a farm. Flying above obstacle height does not provide a close enough inspection to fulfil the task. A typical mission may be 2km in length starting with a 500m transit, then a slower observation section viewing scattered water troughs over undulating terrain along a 1km section near to trees. Finishing with a 500m transit home. The aircraft goes beyond line of sight.

To do this, I carefully flew the Mavic along the route in Waypoint mode adding Waypoints to build the route in a similar manner to DJIGo4. Logic being that actual physical locations will provide more accurate positions than anything derived from a map.

However regardless of GPS accuracy, I have struck issues with Litchi that make what I am trying to do unworkable. Litchi does not seem quite up to the task.

+++++++++++++++++++++++++++++++++++++

Early attempt led to a crash

I carefully marked out a route recording WPTs, heights and orientations. I did this by flying the aircraft to the positions and using the C1 button to record the WPTs.

I then flew the mission as curved turns. At the first target the aircraft was visibly a few metres south of a WPT, where it was set to slow up to 3mph and look at a target. At the second target the aircraft also passed a few metres south of where I had physically programmed it to be and a couple of seconds after toggling sports mode to abort, it crashed into a tree. It was only doing 3mph and I had very carefully set the WPT to be clear of the tree. Fortunately, only prop damage.

I cannot be certain this was a GPS accuracy issue as logs show it was receiving 16 GPS/Glonass satellites at the time. It was more likely related to an overshoot in the curved turns. Had I used Straight legs the aircraft would have come to a complete stop at each WPT and then reversed away to next WPT back in the direction it came from. Instead the curve took it beyond the WPT it flew by.

++++++++++++++++++++++++++++++++++

(Some of the stuff below is not mentioned in the Litchi manuals so may useful to know. I observed the behaviour by flying over test routes. )


SPEED when flying Waypoints

Litchi HELP says this about Waypoint speed:

Speed: The speed at which the aircraft will travel from this waypoint to the next. By default the aircraft will use the mission's cruising speed setting, but the cruising speed can be overriden for each waypoint using this setting.
Warning This setting is only in effect when the aircraft is in range of the remote controller. If signal is lost during the mission, the aircraft will continue the mission at the speed it was travelling at when it lost signal.

However this needs further clarification. What I have observed from testing is as follows:

Straight line - WPT Speed means “Commence speed leaving this WPT until approaching Next WPT, slowing in time to a STOP at next WPT.”

With straight lines the aircraft always stops at ALL the Waypoints and will never actually be at programmed speed at any WPT. Flying high speed (30mph) at a Straight Lines WPT, aircraft will commence deceleration before arrival and stop over head.

Curved Turns - WPT Speed means .. “Commence speed passing this WPT until passing Next WPT. Once PAST next WPT commence new speed. So a speed of 30mph will be maintained all the way to next WPT, then speed changes, if programmed to do so”.

With a programmed reduction to low speed - a large overshoot will occur. Same route as before but curved turns, aircraft will arrive overhead at 30mph then commence speed change. If it is a large reduction like 30 to 5 mph this can take 100’ or more beyond the WPT before Mavic slows.

So you can see, Curved Turns and Straight Lines deal with Speed settings very differently.


A Loss of signal (LOS) means the rest of route will be flown at Signal Loss speed (Not Mission Speed). A/C will still stop at WPTs if Straight lines in use.

Turning remote off to create LOS while Flying full speed at a Straight Lines WPT, aircraft will commence deceleration before arrival and stop over head. More importantly it will then depart waypoint and attempt to fly subsequent legs at the 30mph LOS speed and NOT at programmed speeds.

This could be problematic if mission commences with a high speed transit at 30mph, a signal loss occurs and then progresses to a slow speed manoeuvre section in a confined space. Close in turns programmed to occur at 2 or 3 mph will now be attempted at 30mph almost guaranteeing a collision.


Curved Turns

Curved turns and confined spaces do not work so well. Because the aircraft never comes to a complete slop (as is does with straight legs) it seems more prone to flying wide or overshooting turns.

Waypoint actions do not occur on Curved Turns. Caveat - They do still occur on first and last WPT of a Curved Turn mission because there is no curve at these WPTs!

+++++++++++++++++++++++++++++++++++++++++++++++++++++++



Creating WPTs and POIs with aircraft and tablet using screen tap or C buttons.

Observations and Issues so far:


1. Manually dropping a WPT with C1 button will record A/C location, height above TO point and heading including gimbal angle.

2. Subsequently dropping a POI and assigning it to this WPT will overwrite heading and gimbal angle. So it is easy to inadvertently lose hard gathered positioning data and aircraft recorded alignments. ** very annoying

3. Works best if you take off at intended home point, so that recorded WPT heights are correctly referenced. This becomes a problem if home point and observation area are a long way apart as you need to walk there.

4. If you walk a route carrying the aircraft in hand with aircraft powered on at proposed take off point and use it to record WPTS or POIs it will set altitudes at 0. No Take Off occurred so there is no Take Off reference height.

5. Home point is recorded though, so when you walk back home it is interesting to see how many feet the aircraft remote thinks it is from home when you place it back at the known home point. Gives a good idea as to how far out the GPS can get.

6. If you walk a route with the aircraft flying alongside you can use it to carefully record WPTS and orientation. Correct WPT altitudes referenced to take off point will be set.

7. If your survey area is distant from your take off point this process can become impractical as the battery will be flat by the time you walk there. Instead fly aircraft from take off point to survey area and land noting height difference. Walk the route from within the survey area with aircraft flying alongside marking waypoints. Then later adjust the WPT altitudes by the height offset between your proposed TO point and the height where you landed/took off again in the survey area.

8. You cannot return the aircraft to a location mid route and add another WPT at the aircraft. If you do it will be added to the end of the route.

9. You cannot re order waypoints. Instead you have to use the standard process of adding a WPT between two existing WPTs then drag it to where you want it to be on the map which is less accurate.

10. Aircraft speed has to be extremely slow at flyby WPTs to prevent overshoot and collision with close in obstacles. ie 1 or 2 mph

11. To this end multiple wpts, some with enroute speed for the transit leading to others at inspection points with much slower speeds could provide solution.

12. Aircraft heading will not necessarily be course aligned enroute and this has obstacle avoidance implications

13. Having obstacle avoidance ON precludes fast transits above ~ 22mph

14. In winter when sun remains low in sky obstacle avoidance may need to be off for mission to proceed. In this case positioning accuracy and accurate height is paramount.

15. Pausing a mission at a WPT only stops the trajectory. WPT actions like rotate and “take photo” continue regardless.

16. WPT action “Rotate Aircraft – x degrees” does not mean rotate aircraft x degrees. It actually means rotate aircraft onto a bearing of x degrees in relation to North.

17. Straight leg WPTs that are purely intended to cause a change in altitude or a slight bend in route still result in a complete stop. Annoying if trying to place a bend on a high speed transit leg or a climb to avoid an obstacle.

18. Consider creating and overflying a reference Keyhole WPT at start of route to check GPS positioning accuracy. Abort mission if no good. This could be as simple as programming it to fly along a fence line and stopping over a fence post. If actual flight is offset don’t continue

19. Consider a 10m (30 ft) buffer. Take 10 Steps back from obstacles. If WPT is within 10m of an obstacle, Fly aircraft to desired WPT position then move the WPT 10 steps away from the obstacle. On future flights GPS variance could place the aircraft on the obstacle even though it is well clear when marking the point.

20. Consider programming curve sizes to 100% if there is any chance of the mission getting flown faster than programmed due to LOS. Otherwise it more likely to fly wide on sharp corners.

21. Consider Setting Signal loss action to RTH if signal loss could possibly occur in high speed section of route.

22. Use Straight Legs to guarantee dead stop at all waypoints. Downside is this leads to much longer mission time.

23. The inability of Litchi to create a mission with a combination of straight legs and curved turns means the farm observation flights I envisage will invariably have undesired stops at WPTs, that were merely intended to place a bend in the route.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Some questions:

Q In Litchi WPT mission - how do I cancel out of impending low battery RTH mid mission in the 10 sec warning phase? I cannot see how to do this as there is no cancel prompt in WPT.


Q What does the aircraft know in terms of autonomous flight plan after signal loss? Waypoints = Yes, Speeds changes = No, Heights changes = Yes?


CONCLUSION

Litchi does not appear well suited to flying Waypoint mission that encompass a transit beyond line of site into obstacle effected confined areas.

Signal loss in transit could lead to overspeed and collisions in subsequent slow sections.
The necessity to use straight legs to confine the route will lead to numerous unnecessary enroute stops.
This in turn will reduce usable observation time and the practicality of programming these mission for Farm use.

These shortcomings may well effect the other WPT capable apps using the DJI SDK too.

Will be interesting to see if new offerings like Drone Harmony can do a better job of this.

OMGosh, DJI n Litchi - hire this person and another video expert to publish such detailed and accurate information.

DJI n Litchi - please join forces to finish squashing the rest of the supposed competition. Wait, don't, competition's good, eh?