I have a problem with accuracy. I made a mission for electric pole inspection, actually is to feed Ai with photos. Did Python script to creating CSV file. Imported it into Litchi Hub, and it looks ok for me:
While there is some inherent error in consumer GPS, if your second photo is supposed to be 180 degrees from your first photo, that does appear to be too far off. Is this repeatable? If it were me, I would examine the EXIF data in your photos (heading/yaw is captured) to see how well it corresponds to what was configured in your mission.
Yes, second photo was supposed to be 180 degrees from first photo
Coordinates in waypoint:
51.97560815199425, 15.515266
Coordinates in file:
51.97569, 15.51514
The two sets of GPS coordinates you provided are 12.5m (41 feet) apart. I don’t know what those two sets of coordinates refer to but if one is from a Litchi waypoint and the other is from the corresponding photo, that distance is too great.
While there is some lack of accuracy in consumer GPS, 12.5m is significantly more than I would expect.
Your two photos are taken from almost opposite sides of an electric pole. The difference in orientation of the drone to take those photos looks like either around 170 or 190 degrees. While GPS is used to position the drone, the compass and IMU are used to orient the yaw/heading of the drone.
If those two photos are from opposite side of the mission with the heading/yaw configured to be 180 degrees apart, something is wrong.
If it were me I would:
Examine the mission to make sure it is configured as expected.
Examine the EXIF/XMP data of each image and compare that data to each corresponding waypoint.
Tools I would use include Google Earth Pro, ExifTool (to examine the image metadata), and my AirData to Litchi Mission converter. I would convert the flight log from AirData into a Litchi mission and then load both the original Litchi mission and the converted AirData mission into Google Earth Pro. Once overlayed, it will be easy to see any differences.
And in CSV file I imported, whis W.P. is like this:
|latitude|longitude|altitude(m)|heading(deg)|curvesize(m)|rotationdir|gimbalmode|gimbalpitchangle|actiontype1|actionparam1|actiontype2|actionparam2|altitudemode|speed(m/s)|poi_latitude|poi_longitude|poi_altitude(m)|poi_altitudemode|photo_timeinterval|photo_distinterval|
|51.975689|15.51513475168293|15.5|0|0|0|2|-45|1|0|0|500|1|2|51.975689|15.515266|15.5|1|0|0|
I find it curious that all of the GPS coordinates you show have repeating digits. I’m not sure I would trust whatever software you are using that is showing those values. What did you use to get those coordinates?
The coordinates in your Mission Hub snapshot match those extracted from the photo.
Your calculated longitude values have much more precision than your calculated latitude values. Not that it matters. It’s just a bit of a curiosity.
I don’t see any significant problem with the data you are showing here. I would closely examine the coordinates and heading values from the photo you previously showed. Are you sure that the second photo was taken 180 degrees from the first photo? It sure does not look like it. The EXIF/XMP data in the photos should confirm either way.
Looking at the 2nd photo (532) the drone is off to the left by about 1.5 times the distance between the 2 outer cables, guessing this is about 1.5m.
104 waypoints within a Ø12m area borders the SDK limits for the minimum 3d distance between 2 waypoints.
This mission is more suitable for a drone with RTK (Real-time kinematic positioning).
Also I wonder if the number of photos actually taken equals the number of photos that should be taken according to the mission (most likely 104 when each waypoint has a “Take Photo” Action).
If it does not, than it could well be that the second photo for instance belongs to WP88 instead of WP90.
Assuming the inner circel has a diameter of 6m, then the distance between the 16 waypoints on that circel (22.5° apart) is only 1.2m, and on the outer circel (Ø12m) 2.3m.
This (to me) seems a more logical explanation of what’s realy happening.
A plot of the list of chronological photos you provided in Google Earth seems to confirm this.
Also it seems that photo 533 is opposite of photo 516, not photo 532.
These values are directly from pictures. But I obtained them using exifread Python library.
And that’s why I’m curious.
It’s because of rounding. There are 4 photos from 8 sides, so there is
I’m sure. Anyway, You can see it in mission hub.
I needed this number of waypoints, because If there were only ones with photos, drone wasn’t able to head into POI. I needed to add some additional WP, even in the same coordinates, to make drone head into POI.
But anyway, even with good accuracy it won’t feed my client needs. They want to have photosin with parallel lines, like it is on the first photo. So I would need dynamic POI with dynamic direction. Without this I need to do it manually.
I looked at your flight log. It has data corresponding to 363 photos. My guess is that this flight log contains several attempts at this mission. Or, are you really capturing 363 photos?
In order for me to access your Litchi mission, you would have to copy the URL and post it here.
Here is a top-down view of the AirData data with the mission clamped to ground. Each red dot represents a photo location.
Your flight log did indeed have multiple missions in it. I converted your flight log to a Litchi mission taking data points only where a photo was captured. I then only extracted data to match the number of photos taken and the headings in the original, programmed Litchi mission you provided.
I then overlayed the flight paths of these two missions in Google Earth Pro. This way I can compare in 3D the original flight design and the actual flight path. The result is shown below:
In the above screen capture, the yellow line represents your programmed Litchi mission. The orange line represents the actual, flown mission from your flight log taken from AirData.
After comparing these two, my conclusion is that your drone successfully flew this mission with the expected accuracy. In my opinion, the drone faithfully executed this mission with great accuracy.
Things to note:
The orange line (AirData flight path) contains some diagonal lines that don’t seem to match the computed/yellow path. This is because the original, computed path, contained a number of waypoints where no photo was taken. I only extracted GPS coordinates where a photo was taken so the AirData (orange) path skipped the non-photo waypoints of the original, computed mission.
There are some slight deviations in the radial portions of the flight path. The waypoints along the radial yellow lines are computed to be completely straight. The actual flown path along the radial orange lines are slightly crooked, which is expected.
The only major error I see in this mission is in its placement. See the image below:
As you can see, the POI (and the entire mission) is centered on the upper tip of the electrical pole. Because of parallax, this mission is not actually centered on the pole. When trying to place a POI (or any type of point) directly on top of a tall object shown in Google Maps, the base of that object should be used as the reference. This mission should have been placed roughly 3m to the south and slightly to the east.
From this data I can tell that the two images posted earlier in this thread were not captured 180 degrees from each other. The metadata in those images could be used to confirm that.
Thank You, this is reasonable explanation for me. The first photo confused me and I thought I had set the PIO correctly.
Here is the whole set: https://photos.app.goo.gl/qR1vL2AcGdSacCzi8
I have moved this discussion to its own thread since it was not directly related to Litchi Pilot.
I extracted the yaw angles (headings) from the 16 photos around the outer rim of your mission. They correspond pretty closely with the programmed values.
