Litchi Point of Interest Not Centering Properly
- Thread starter VernCook
- Start date
Strange! My Litchi missions always complete perfectly. Camera settings, POI, flight path, gimbal angle, etc. all work even though the drone frequently flies out of controller range due to low altitude or trees blocking part of the signal. This was correct on my original Phantom 4 and now my Phantom 4 Pro V 2.0.
Thanks
Jim
WA5TEF
Thanks
Jim
WA5TEF
- Joined
- Jul 22, 2016
- Messages
- 30
- Reaction score
- 6
- Age
- 66
Here's an observation that might shed some light on the issue... The statement that speed and gimbal angle don't get adjusted if signal is lost means (to me) that those parameters are being handled by the Litchi software running on the mobile device/smart controller in "real time" and not by the aircraft's processor (using the set of instructions uploaded to the aircraft before the mission starts). Adjustments needed to maintain gimbal angle and at least make changes to the over-the-ground speed are being sent from Litchi on the phone/ipad/SmartController to the aircraft constantly during the mission. So the mobile device/ipad/smart controller CPU is doing the gimbal angle calculations and sending any needed speed adjustments while the aircraft's CPU is doing the rest as it processes the uploaded commands (the ones uploaded from Litchi to the aircraft at the start of the mission).
What I've noticed doesn't have so much to do with speed or gimbal angle. It has to do with what appears to be the rate of change in aircraft yaw needed to keep the current POI in the center of the frame.
I never noticed this as a problem when I run Litchi on my P4-Pro and iPad combination. I've made some pretty tight moves in waypoint missions on the P4/iPad and they've all been rock solid. But I just tried Litchi for the first time on my Mavic 2 Pro and Android-based smart controller. On that setup, it seems to me that f the "slew" rate is too high - meaning the aircraft needs to yaw at a high rate to keep the POI framed - the yaw gets hopelessly "behind"... letting the POI drift out of frame.
I just uploaded a short video HERE of two nearly identical waypoint missions. One "close and fast" where the POIs drift from center-frame and a second one a but further away and slower where the POIs stay centered. The P4/iPad would have done either of these missions flawlessly. My working theory is either the Mavic 2's CPU or the Smart Controller's CPU is too under-powered to keep up when values are changing quickly... where on the Phantom/iPad setup, the CPU responsible for maintaining yaw correctly is fast enough to do the job.
One other bit of information that might be relevant... I was filming in 30 FPS, H.265, 10-bit DLOG-M on the Mavic. Perhaps if I chose a less stressful codec the first mission in the video would have worked better? However, I'd assumed (hoped) that the new 10-bit video capability relied on an internal GPU for image processing and not the same CPU the aircraft uses to control flight. If that's not true, then that really sucks!
I'd welcome comments from anyone who has knowledge of Litchi's "workload assignment" (between controller/mobile device and aircraft) during a waypoint mission with POIs... or from anyone else who might have additional insight.
Thanks!
Tim
What I've noticed doesn't have so much to do with speed or gimbal angle. It has to do with what appears to be the rate of change in aircraft yaw needed to keep the current POI in the center of the frame.
I never noticed this as a problem when I run Litchi on my P4-Pro and iPad combination. I've made some pretty tight moves in waypoint missions on the P4/iPad and they've all been rock solid. But I just tried Litchi for the first time on my Mavic 2 Pro and Android-based smart controller. On that setup, it seems to me that f the "slew" rate is too high - meaning the aircraft needs to yaw at a high rate to keep the POI framed - the yaw gets hopelessly "behind"... letting the POI drift out of frame.
I just uploaded a short video HERE of two nearly identical waypoint missions. One "close and fast" where the POIs drift from center-frame and a second one a but further away and slower where the POIs stay centered. The P4/iPad would have done either of these missions flawlessly. My working theory is either the Mavic 2's CPU or the Smart Controller's CPU is too under-powered to keep up when values are changing quickly... where on the Phantom/iPad setup, the CPU responsible for maintaining yaw correctly is fast enough to do the job.
One other bit of information that might be relevant... I was filming in 30 FPS, H.265, 10-bit DLOG-M on the Mavic. Perhaps if I chose a less stressful codec the first mission in the video would have worked better? However, I'd assumed (hoped) that the new 10-bit video capability relied on an internal GPU for image processing and not the same CPU the aircraft uses to control flight. If that's not true, then that really sucks!
I'd welcome comments from anyone who has knowledge of Litchi's "workload assignment" (between controller/mobile device and aircraft) during a waypoint mission with POIs... or from anyone else who might have additional insight.
Thanks!
Tim
Something to keep in mind - which may not apply here anyway - is that it doesn’t know where the POI is in between waypoints. It calculates the angle and heading for waypoints only and in between is interpolated. So if you have waypoints spaced very far apart, you can’t guarantee to be aimed at the POI between them. It just knows that it wants to end at a certain heading at the next WPHere's an observation that might shed some light on the issue... The statement that speed and gimbal angle don't get adjusted if signal is lost means (to me) that those parameters are being handled by the Litchi software running on the mobile device/smart controller in "real time" and not by the aircraft's processor (using the set of instructions uploaded to the aircraft before the mission starts). Adjustments needed to maintain gimbal angle and at least make changes to the over-the-ground speed are being sent from Litchi on the phone/ipad/SmartController to the aircraft constantly during the mission. So the mobile device/ipad/smart controller CPU is doing the gimbal angle calculations and sending any needed speed adjustments while the aircraft's CPU is doing the rest as it processes the uploaded commands (the ones uploaded from Litchi to the aircraft at the start of the mission).
What I've noticed doesn't have so much to do with speed or gimbal angle. It has to do with what appears to be the rate of change in aircraft yaw needed to keep the current POI in the center of the frame.
I never noticed this as a problem when I run Litchi on my P4-Pro and iPad combination. I've made some pretty tight moves in waypoint missions on the P4/iPad and they've all been rock solid. But I just tried Litchi for the first time on my Mavic 2 Pro and Android-based smart controller. On that setup, it seems to me that f the "slew" rate is too high - meaning the aircraft needs to yaw at a high rate to keep the POI framed - the yaw gets hopelessly "behind"... letting the POI drift out of frame.
I just uploaded a short video HERE of two nearly identical waypoint missions. One "close and fast" where the POIs drift from center-frame and a second one a but further away and slower where the POIs stay centered. The P4/iPad would have done either of these missions flawlessly. My working theory is either the Mavic 2's CPU or the Smart Controller's CPU is too under-powered to keep up when values are changing quickly... where on the Phantom/iPad setup, the CPU responsible for maintaining yaw correctly is fast enough to do the job.
One other bit of information that might be relevant... I was filming in 30 FPS, H.265, 10-bit DLOG-M on the Mavic. Perhaps if I chose a less stressful codec the first mission in the video would have worked better? However, I'd assumed (hoped) that the new 10-bit video capability relied on an internal GPU for image processing and not the same CPU the aircraft uses to control flight. If that's not true, then that really sucks!
I'd welcome comments from anyone who has knowledge of Litchi's "workload assignment" (between controller/mobile device and aircraft) during a waypoint mission with POIs... or from anyone else who might have additional insight.
Thanks!
Tim
- Joined
- Jul 22, 2016
- Messages
- 30
- Reaction score
- 6
- Age
- 66
The issue here seems to be one related to rate-of-change rather than interpolation error... but I can't say that for sure because I changed two variables between the first and second attempt.... I moved the waypoints further from the POI and I slowed down the crusing speed. Both actions slowed the rate of change - but moving the waypoints further away from the POIs also changed the geometry slightly. I should have just slowed the cruising speed and left the waypoints where they were.
I just don't recall reading multiple posts about POI/Framing issues with Litchi until the Mavic arrived. I certainly never experienced it on the P4P/iPad before - ever. So that makes me suspect something about the hardware as the culprit... and CPU horsepower seemed to be one likely candidate. I suppose sensor sampling rate could also be an issue... but the Mavic seems to be quite stable and very responsive in manual flight - it seems to be able to keep up with and react quickly to its environment.
The frustration I am having with the Mavic stems from the fact that when you use any of the (now improved) DJI Go Intelligent Flight Modes, you're forced out of 10-Bit DLOG for the video format. So if you want automated flight on the Mavic with DJI Go, you give up the video mode that gives you the best data to work with in post.... and one of the main reasons you might want a Mavic (10 Bit Video). So my "solution" was... Litchi on the Mavic... I can automate flight and still use DLOG.... except it seems there may be a **hidden, unspoken reason** that DJI forces the video mode out of 10-bit DLOG when automation is engaged in DJI Go. That could be because they DO use the "flight CPU" when working with 10 Bit DLOG... and it taxes the thing to the point that automation doesn't have the horsepower it needs to work well. So to save the cost of a more powerful CPU, they disable the CPU-stressing video mode when the CPU needs to perform other tasks in a timely fashion.
Reminds me of the old Doctor joke: "Doctor, it hurts when I raise my arm. Doctor: Then don't raise your arm."
Boy I hope I'm wrong about this... because if I'm not, my Mavic 2 Pro has a huge drawback I wasn't aware of when I bought it.
I just don't recall reading multiple posts about POI/Framing issues with Litchi until the Mavic arrived. I certainly never experienced it on the P4P/iPad before - ever. So that makes me suspect something about the hardware as the culprit... and CPU horsepower seemed to be one likely candidate. I suppose sensor sampling rate could also be an issue... but the Mavic seems to be quite stable and very responsive in manual flight - it seems to be able to keep up with and react quickly to its environment.
The frustration I am having with the Mavic stems from the fact that when you use any of the (now improved) DJI Go Intelligent Flight Modes, you're forced out of 10-Bit DLOG for the video format. So if you want automated flight on the Mavic with DJI Go, you give up the video mode that gives you the best data to work with in post.... and one of the main reasons you might want a Mavic (10 Bit Video). So my "solution" was... Litchi on the Mavic... I can automate flight and still use DLOG.... except it seems there may be a **hidden, unspoken reason** that DJI forces the video mode out of 10-bit DLOG when automation is engaged in DJI Go. That could be because they DO use the "flight CPU" when working with 10 Bit DLOG... and it taxes the thing to the point that automation doesn't have the horsepower it needs to work well. So to save the cost of a more powerful CPU, they disable the CPU-stressing video mode when the CPU needs to perform other tasks in a timely fashion.
Reminds me of the old Doctor joke: "Doctor, it hurts when I raise my arm. Doctor: Then don't raise your arm."
Boy I hope I'm wrong about this... because if I'm not, my Mavic 2 Pro has a huge drawback I wasn't aware of when I bought it.
Separate and aside from what I describe above (which *has* happened to me), I have had, on occasion, POI tracking issues with my P4P that may or may not be attributable to that. I’m thinking those cases were something else entirely because my waypoints were close and it was tracking *ahead* of the POI IIRC. If I don’t remember correctly and it, in fact, tracked behind then I like your theory.
- Joined
- Jul 22, 2016
- Messages
- 30
- Reaction score
- 6
- Age
- 66
Well, depending on what you mean by "ahead"... we may be talking about the same thing. In my case, the aircraft is moving horizontally to the East with the POI to the left (North) of the course line... meaning that it needs to yaw counterclockwise (viewed from the top down) and look further and further "behind" to the West to keep the POI in frame. What happened instead is that the center of the frame went "ahead" of the POI... in the direction of travel. It wasn't turning "behind" fast enough so the center of the frame moved "ahead" of where it should have been. Should have stayed pointed at the little grey house in the video... and instead it drifted "ahead" indicating an insufficient rate of yaw to look sufficiently "behind" the aircraft (related to it's course line).
Look at the first flight here and you'll see what I mean:
Does that make sense?
I see what you are saying. Yes I may have been seeing the same thing. Possibly complicating things a little it that the drone was making a turn at around the same time.
