New MP behavior running Litchi Waypoint mission

[modbuilder]

I've been photo'ing construction projects monthly for almost a year using Litchi waypoint missions on my iPad mini-4. Very recently (perhaps after the recent Litchi App update?) my Mavic Pro has started halting at waypoints on well-established successful Litchi missions. I have over a dozen Litchi missions that I run monthly, and I'm seeing the new problem on some missions but not all missions.

All the missions are set to go to a WP with specified GPS coordinates, heading, altitude, and camera pitch (no POI's), wait for 2 seconds, take a photo, move on to the next WP, and RTH after the last waypoint. Yesterday during the 4th of 5 missions run during the day, it got to WP#2, and hovered for about 2 minutes, then it took the picture and moved on without incident through the rest of the mission. In the final (5th) mission of the day, it got to WP #2 and again hovered taking no action until I got tired of waiting (probably 2-3 minutes), then I took control of the craft and hand flew the photos that I needed. Both missions were the first time flown this year. The prior flights from last year all ran fine, and the first 3 missions yesterday ran normally until this problem on both the 4th and 5th missions.

I was using a 16GB micro SD re-formated in the MP before the first flight of the day (yesterday). I used the same memory card for all 5 missions, and the card was only 8% full at the end of the day.

I've kept the MP on an older Go4 release back before the heavy restrictions on NFZ's were implemented, and it seems like all this started when I gave in to a iOS update on the ipad. About that same time Litchi came out with an update, and i went with it, but I've not updated the GO4 app for obvious reasons. So... what do you think? an emerging equipment problem? An incompatibility among the apps that all contribute to the performance? Suggestions?

BTW -- I do have a backup MP, and I'll start using it where I can, but it's currently on a newer GO4 release with DJI restrictions. Before I hear a storm of rants about flying in NFZ's, everywhere I fly in restricted airspace is with FAA and local ATC authorization. I just don't recognize DJI's authority to regulate my legal actions. So..... back to the ranch -- your suggestions are welcome. Thanks............... R

 

[sar104]

What does the flight log say?

 

[modbuilder]

Dang! Why didn't I think of that!!. Haven't looked. Thanks.

Haven't had to do that before, so I'll go chase it down. Probably won't have more until tomorrow. 'Preciate it. More later......... R

 

[modbuilder]

Well, I've extracted the Litchi flight log, reviewed the entries with the on-line flight log viewer, and have attached the log file. It shows exactly what I observed for one of the missions that had the temporary "stall out" at a WP, but it doesn't provide event or interrupt info to let me know what's going on. It doesn't even record having taken a photo at any of the waypoints, which I know that it did at all eight WP's.

What you'll find in this simple eight WP fly-stop-take photo-move on mission with no POI's:

WP# Time My comment
1 1:20 Normal movement (photo was taken as scheduled)
2 1:35 Normal movement (photo was taken as scheduled)
3 2:10 Normal movement (photo was taken as scheduled)
4 2:35 Normal movement (photo was taken as scheduled)
5 3:00 Normal movement, but took photo after 42-second wait (scheduled wait is 2sec); mission continued without my intervention
6 4:00 Normal movement (photo was taken as scheduled)
7 4:30 Normal movement (photo was taken as scheduled)
8 5:00 Normal movement (photo was taken as scheduled)
began Go Home
- 6:17 Arrive Home

Looking at the flight log was a great notion and I should have thought of it myself. In this case with a Litchi log, I'm not finding clues to the problem.

Other ideas?

Thanks........... R

 

[modbuilder]

Well Snap. The formatting got hosed up in the above post, but I think you can sort out what I'm saying.

 

[sar104]

Well, I've extracted the Litchi flight log, reviewed the entries with the on-line flight log viewer, and have attached the log file. It shows exactly what I observed for one of the missions that had the temporary "stall out" at a WP, but it doesn't provide event or interrupt info to let me know what's going on. It doesn't even record having taken a photo at any of the waypoints, which I know that it did at all eight WP's.

What you'll find in this simple eight WP fly-stop-take photo-move on mission with no POI's:

WP# Time My comment
1 1:20 Normal movement (photo was taken as scheduled)
2 1:35 Normal movement (photo was taken as scheduled)
3 2:10 Normal movement (photo was taken as scheduled)
4 2:35 Normal movement (photo was taken as scheduled)
5 3:00 Normal movement, but took photo after 42-second wait (scheduled wait is 2sec); mission continued without my intervention
6 4:00 Normal movement (photo was taken as scheduled)
7 4:30 Normal movement (photo was taken as scheduled)
8 5:00 Normal movement (photo was taken as scheduled)
began Go Home
- 6:17 Arrive Home

Looking at the flight log was a great notion and I should have thought of it myself. In this case with a Litchi log, I'm not finding clues to the problem.

Other ideas?

Thanks........... R

I'm not sure what you are looking at in those data - the photos are all recorded. However, there are nine of them, not eight.



If you look at the waypoint with the extended wait period, the aircraft stops at 180 s, waits 16 s, takes a photo at 196 s, waits, and takes another photo at 220 s, and then immediately moves on.

I would check the mission profile again - save it as a csv and look at it line by line.

 

[modbuilder]

What are you using to view the file? You're seeing stuff that I'm not seeing using the DJI Flight Log Viewer. My screen looks like this

 

[sar104]

What are you using to view the file? You're seeing stuff that I'm not seeing using the DJI Flight Log Viewer. My screen looks like this
View attachment 60366

I'm converting the txt log to a csv file using TXTlogToCSVtool.

 

[modbuilder]

I'm not sure what you are looking at in those data - the photos are all recorded. However, there are nine of them, not eight.

View attachment 60340

If you look at the waypoint with the extended wait period, the aircraft stops at 180 s, waits 16 s, takes a photo at 196 s, waits, and takes another photo at 220 s, and then immediately moves on.

I would check the mission profile again - save it as a csv and look at it line by line.

 

[modbuilder]

I'm not sure what you are looking at in those data - the photos are all recorded. However, there are nine of them, not eight.

View attachment 60340

If you look at the waypoint with the extended wait period, the aircraft stops at 180 s, waits 16 s, takes a photo at 196 s, waits, and takes another photo at 220 s, and then immediately moves on.

I would check the mission profile again - save it as a csv and look at it line by line.

There are nine photos instead of eight because at the 5th WP, after 16 seconds of the MP continuing to wait when it was supposed to take a photo after 2 seconds, I triggered the photo manually at 196 sec without leaving the Litchi mission. It continued to wait at the same WP until 220 seconds, then the MP finally took the mission photo at that WP and starts to move on to WP #6.

A possibility -- I can see in the above chart is that all the "normal" WP photos were taken when the indicated speed dropped to zero, including the mission photo for WP#5 (the 6th photo shown on the chart). The MP arrived at WP#5 at 180 sec, but the speed didn't actually drop to an indicated zero. When the indicated speed achieved zero at 220 sec, the MP took the mission photo and moved on.

So........... I don't know if the indicated speed is a GPS-derived speed or an IMU-derived speed. But I'm thinking that the indicated speed may be the source of what I've called the "stalling out" behavior. I'm going to calibrate the IMU's, and if the problem continues I'll have Rob at Thunderdrones take a look at it with an eye toward speed measurement.

I'll also take the flight logs from other problem flights, see if I can construct the same kind of display that SAR104 created on this one, and look for the zero speed deal. Guess I'll also take the backup MP and downgrade the FW to get it to where I can use it.

SAR104 -- I did take your advice, downloaded the mission profile in csv, and looked it over carefully. There were no problems apparent. You got me on a path with possibilities when I didn't have a place to start. Thanks a ton. Best regards................ R

 

[sar104]

There are nine photos instead of eight because at the 5th WP, after 16 seconds of the MP continuing to wait when it was supposed to take a photo after 2 seconds, I triggered the photo manually at 196 sec without leaving the Litchi mission. It continued to wait at the same WP until 220 seconds, then the MP finally took the mission photo at that WP and starts to move on to WP #6.

A possibility -- I can see in the above chart is that all the "normal" WP photos were taken when the indicated speed dropped to zero, including the mission photo for WP#5 (the 6th photo shown on the chart). The MP arrived at WP#5 at 180 sec, but the speed didn't actually drop to an indicated zero. When the indicated speed achieved zero at 220 sec, the MP took the mission photo and moved on.

So........... I don't know if the indicated speed is a GPS-derived speed or an IMU-derived speed. But I'm thinking that the indicated speed may be the source of what I've called the "stalling out" behavior. I'm going to calibrate the IMU's, and if the problem continues I'll have Rob at Thunderdrones take a look at it with an eye toward speed measurement.

I'll also take the flight logs from other problem flights, see if I can construct the same kind of display that SAR104 created on this one, and look for the zero speed deal. Guess I'll also take the backup MP and downgrade the FW to get it to where I can use it.

SAR104 -- I did take your advice, downloaded the mission profile in csv, and looked it over carefully. There were no problems apparent. You got me on a path with possibilities when I didn't have a place to start. Thanks a ton. Best regards................ R

I also wondered about whether the aircraft was having problems achieving a satisfactory position hold, but the pitch and roll data don't indicate strong enough wind speeds to have been a problem. It might be interesting to try the same mission again to see if the issue is repeatable.

 

[modbuilder]

Wind speeds were definitely not a problem that day. When I first started having this happen on a different mission near my house earlier this month, I tried to see what was repeatable and couldn't find anything that I could reproduce. It was just an intermittent (but highly disruptive) problem.

This Mavic Pro has lots of time on it and some early rough treatment and repairs when I first got it about 18 months ago. I'm guessing I have some drift in the sensors that shows up in reduced position hold accuracy. I also think it's significant that the problem only emerged after the most recent LItchi upgrade. It's possible that the threshold for accepting a steady position hold got tweaked. I plan to check in with them and share the observations. At least now I have something to look for when the problem reappears.

Thanks for all the help. If I learn anything conclusive, I'll come back here and update the thread. Best regards.......... R

 

[modbuilder]

This isn't definitive yet, but I seem to have eliminated the intermittent problem of not achieving a zero-speed position hold at a waypoint (delaying taking the picture at a WP) by re-calibrating the IMU.

But I'm now having new issues with soft focus on the same bird, so I'm suspicious that I'm dealing with a main processor issue. Reinforces the need to have backup equipment when you have client work on the line. Planning to reach out to Thunderdrones and see if he works on this type of potential CPU problem also.

Otherwise this may become my excuse for jumping on the Mavic 2 bandwagon. "Sorry dear, but I just have to replace that old bird"