Issue when mapping video footage with mavlink data

ODM
1

I’m trying to create a map with a drone feed, and separate provided geo data through MAVLINK which I supply to webodm though a geo.txt file. However, when I try to create a map, the image is blurry and offset ± 5 meters to the west, while the coordinates are correct (checked with google maps). What could be the issue? When making a map without the geo data, the image looks way better.

The mavlink data looks like this:

{“ATTITUDE”: {“mavpackettype”: “ATTITUDE”, “time_boot_ms”: 0, “roll”: -0.017000000923871994, “pitch”: 0.04699999839067459, “yaw”: -0.028999999165534973, “rollspeed”: 0.0, “pitchspeed”: 0.0, “yawspeed”: 0.0}, “POSITION”: {“mavpackettype”: “GLOBAL_POSITION_INT”, “time_boot_ms”: 0, “lat”: 303179016, “lon”: 780397796, “alt”: 759799, “relative_alt”: 74700, “vx”: 0, “vy”: 0, “vz”: 0, “hdg”: 0}, “CAMERA”: {“mavpackettype”: “CAMERA_FOV_STATUS”, “time_boot_ms”: 0, “lat_camera”: 0, “lon_camera”: 0, “alt_camera”: 0, “lat_image”: 303186259, “lon_image”: 780397469, “alt_image”: 665000, “q”: [0.9999783635139465, -1.3762515891357907e-06, -0.006571117322891951, -0.0002094349911203608], “hfov”: 6.489999771118164, “vfov”: 0.0}, “Time”: 1685701212.122587}
Which comes with a mp4 file, and a start time of the video. Right now I take a specific frame and supply it with the geo coordinates.

The geo.txt flie looks like this:
0.5800011157989502.PNG 78.0397644 30.3179016 74.8 1.576170669573772e-15 -0.01473057932977135 -0.00012217304569326373
Where I translated the q into yaw pitch roll.

2

Pictures of the result are in this github issue:
Issue when mapping video footage with mavlink data. · Issue #1352 · OpenDroneMap/WebODM (github.com)

3

Welcome!

When you map the mavlink position data does it match known truth data?

Be mindful that Google Maps is not truth data, and can be quite off in certain regions.

What ODM version and processing parameters are you using?

4

Thanks for your reply!

I’m using WebODM 1.9.12, and in terms of processing parameters, I tried a lot, but nothing seemed to improve the quality of the result. The result I posted was without any additional parameters.
Lowering the gps accuracy which I thought would be a logical solution, gives an even worse result.

I checked the gps data with the folium package on python. Which uses the same projection as I parsed in the geo.txt file (EPSG:4326), and the results are what they should be. What other method could I use to check this?

5

Can you please re-try on a current release?

6

I tried with 2.0.3, the image looks different, but is still deformed, and offset about 5 meters. Are there any specific parameters I should try?

7

Can you share your Task options and console log?

8

Sure, the options are: skip-3dmodel: true, gps-accuracy: 1

And the logs are here

https://raw.githubusercontent.com/0578Tex/webodmlogs/main/console.log

9

Are you using RTK? You are confident your man GPS error isn’t more than 1m?

If not, you should try setting that to 2x your mean GPS error.

Also, how are you extracting the frames from the video?

10

I’m using RTK and a DJI drone.
Not sure what the absolute GPS error is, but adjusting this has the most positive impact on the image. Setting the gps accuracy at 2x the GPS error does not give a significant improvement.

I’m extracting the frames using cv2, by syncing the mavlink data with the video, and using this function:

def getframe(timestamp,cap):
    ind = int(timestamp * cap.get(cv2.CAP_PROP_FPS))
    cap.set(cv2.CAP_PROP_POS_FRAMES, ind)
    success, frame = cap.read()

    if success:
        return frame
11

Can you try using our implementation? You’ll need to setup a SRT file to hold the geolocation information.

12

Could you direct me to your impelementation? I tried this, but it didn’t work.

Also, I have a feeling that the bad quality of the stream is causing a lot of my problems. As I’m not flying the drone myself, what are best practices to improve the result of a shaky video?

13

That’s the correct one.

Video should be stabilized, either externally via a gimbal or internally via IMU and 360deg camera coverage.

You ideally want 4k at a bare minimum, with a high enough bitrate that the compression artifacts don’t interfere with feature extraction.

Frame rate is a bit inconsequential. ISO should be kept as low as possible without causing underexposure and motion blur.

What this translates to in settings depends upon the platform, so you will definitely have trial and error.