Actual Waypoint Positions Differ Greatly from Waypoint Positions in the Plan
Doing identical missions with Air2s. Same waypoints from Litchi imported to DL. Gimbal -90'. Planned positions for each waypoint are identical "Center of Roof". Attached comparison shows Litchi taking accurate photos above center of each roof. DL mission is showing photos not centered on each roof but somehow offset by 12-15 feet form their designated waypoints in the DL plan. DL seems to have become inaccurate lately. (20+ Satellites for GPS in both cases). See attached comparison show DL taking photos between roofs, not at the center of each roof.
Also, the Litchi and DroneLink Lat-Longs are identical for each Waypoint.
Comments
11 comments
Can you please share your mission plan?
Done, link sent via email to Dronelink Support.
Also I did all Compass & IMU calibrations before and after - no difference there. I've noticed this on flights up to 35 miles away too ( in South Florida). It's almost as if the map Datum has changed recently. DL Maps are quite old. Litchi uses a version of Google Maps and is much more current. One more aspect. The Missions File view does show the actual locations of the shots between the roofs - which in not what is in the plan but at least it matches with the actual photos themselves.
Does Litchi come to a complete stop at the waypoints to take the photos?
Re-ran Mission again today with Mavic 2 Pro - same 15 ft offsets seen - pictures are happening between the roofs - just like the Air2s. Here they are:
I don't believe this is an issue with the base layer as you are using the same coordinates in both apps. If that were the case, I would recommend georectification.
Instead, I believe it is due to a misunderstanding of how the waypoint actions in Dronelink work. You have selected to add a photo action while allowing the drone to continue moving through the waypoint, which means Dronelink will send the command to take a photo once it reaches the waypoint, but in the time period between sending the command, and when the drone actually receives and executes the command (usually 100-200ms), the drone has since moved on. The resulting photo will necessarily always be beyond the waypoint if you choose this type of action.
If Litchi does come to a complete stop, that is why it is not having similar issues.
The solutions are:
Litchi and DL both slow down for each waypoint similarly. Both test missions are completed in 2 minutes for 18 pictures - so average speed is same. (Maybe there is excessive latency in the DL code when triggering the Photo command? ) I just re-ran the test Litchi mission today and got this comparison between the DL vs Litchi for the Mavic 2 Pro:
Not so much excessive latency, but rather extraneous commands. When you click the add photo button to a waypoint, it assumes the worse case scenario, that the camera is already recording video and is in the wrong photo mode, so it adds these commands:
If you know that your camera will not be capturing video and instead already be in the right mode (single photo), then you can just add a camera start capture command. You can do this by clicking add photo, and then removing all the extra commands, or just click component instead and choose camera start capture.
Of course, this still will not solve the underlying issue, which is the the drone moving through the waypoint, so the more accuracy you want, the slower you need to go. For maximum accuracy, you need to georectify and come to a complete stop.
Thank you Jim for the explanation. After more testing, there do seem to be 2 systemic inaccuracies. The "latency" issue from these "extra" Single Photo commands and also a map offset by several feet to the south of the planned waypoints (in my geography). Even with the drone stopping, photos are being captured 3 ft south and west of the planned Waypoint location. (Litchi map seems immune from this BTW). Also to correct my last statement, DL does fly through the waypoint before taking a picture about 1.5 seconds later becase of the extra Single Photo commands. Is there anyway to compensate for the "fly through" SINGLE PHOTO delays? The "extra" components from the "Single Photo" camera action are from an assumption being made that video is being record. This seems to be a bad assumption and introduces the excess photo delays. It might be better to just assume "Photo" is the right Camera action rather than a "Single Photo" composite set of commands applied at each Waypoint.
So these extra Commands are from the Import from Litchi (CSV) create mission option. Could those be eliminated from the Litchi Import CSV? (and each Waypoint just get a Photo command assigned instead?).As you know its now a real effort to go and change the Camera Command for each individual Waypoint since there is not yet a mass update function for all Waypoints.(Enhancement request submitted for this key functionality).
I can't really explain the difference since I don't know Litchi's code, but if it is consistently off in one direction by the same magnitude, then georectification is all I can offer you. If it is off randomly, then this is because of the inaccuracies of the underlying sensors, which are typically +/- 3-4m for the GPS (assuming no RTK).
Even if we assume photo (meaning don't waste the time on the photo type command), it will still be wasting time on stop capture and camera mode.
I will move this thread over to feature requests, and to remind the team, the feature is to make the Litchi importer smarter when adding waypoint actions. In other words, look at the previous actions to see if the camera is already in the correct mode and photo type to avoid adding the additional commands. This won't really help the first waypoint (if implemented this way), but it would at least be a start. This will also not help the case where the operator changes the camera to video and starts capturing in between waypoints (from the UI), but I think that case doesn't really matter.
Thank you Jim. Appreciate the considerations. BTW I went through and changed all the camera actions for every Waypoint to "Photo". Immediately there was a 50% accuracy improvement and the Photos now are at least somewhere on each roof. So it is better, but not good enough for commercial use cases. I will say the Missions are being flown the same for all the drones, and are Repeatable each flight - so you have Repeatability, just not accuracy. Last thought.... It really is a bear to have to adjust each Waypoint manually. A mass update function for all Waypoint values really would reduce the pain and effort. Thanks Again.
Also, could I suggest Triggering the Photo command in advance of arriving at the Waypoint to compensate for the speed delay. Empirically the preemptive timing could be worked out a a function of speed so that the photo command would trigger when the drone actually reaches the Waypoint rather than a second after it departs the waypoint. That would make a lot of sense and be more accurate.
Please sign in to leave a comment.