Sfm-algorithm: triangulation

WebODM
#6

Is it useful for a consumer drone or is it more for a rtk-drone?

#7

Tested on very high-end manned capture (similar to Ultracam) and also on a DJI Phantom 4.

1 Like
#8

I have Mavic 2 Pro, I’m running a small test now.

#9

The process completed but the result is horrible.
Might be that triangulation isn’t working for Mavic2Pro.

#10

Images to share ?

1 Like
#11

Hello!

I have obtained similarly poor results using smf triangulation with Mavic 2 Pro images. For a comparison of incremental versus triangulation smf algorithms please see https://community.opendronemap.org/t/geolocation-files-versus-exif-and-omega-phi-kappa-versus-pitch-roll-yaw/9905/4 and https://app.box.com/s/6kngeyemqv02c2ytt5ydmuiv1o4co4rz

Any suggestions would be greatly appreciated.

2 Likes
#12

The result I got wasn’t usable at all.

#13

Could you share more original images ? There’s only one in the Box folder.

1 Like
#14

It´s a small set, about 3 hours for computation.

My settings:
[{“name”: “auto-boundary”, “value”: true}, {“name”: “build-overviews”, “value”: true}, {“name”: “crop”, “value”: “3”}, {“name”: “debug”, “value”: true}, {“name”: “dem-resolution”, “value”: “2”}, {“name”: “dsm”, “value”: true}, {“name”: “feature-quality”, “value”: “ultra”}, {“name”: “feature-type”, “value”: “orb”}, {“name”: “gps-accuracy”, “value”: “10”}, {“name”: “matcher-neighbors”, “value”: “38”}, {“name”: “min-num-features”, “value”: “24000”}, {“name”: “orthophoto-resolution”, “value”: “2”}, {“name”: “pc-filter”, “value”: “5”}, {“name”: “pc-geometric”, “value”: true}, {“name”: “pc-quality”, “value”: “ultra”}, {“name”: “pc-sample”, “value”: “0,02”}, {“name”: “resize-to”, “value”: “-1”}, {“name”: “sfm-algorithm”, “value”: “triangulation”}, {“name”: “texturing-tone-mapping”, “value”: “gamma”}, {“name”: “use-hybrid-bundle-adjustment”, “value”: true}, {“name”: “verbose”, “value”: true}]

3 Likes
#15

There’s clearly a conversion issue between the Mavic YPR → OPK that we didn’t have when trying with Phantom 4 data.

Summoning @pierotofy here.

3 Likes
#16

Thanks for the quick reply.

I have uploaded 12 additional images in images.zip to the same Box folder.

Please let me know if I can help with anything else at this stage.

3 Likes
#17

Make an announcement when you figured it out so we can try it.

1 Like
#18

Based on my observations, it seems that DJI products do not have consistent conventions when it comes to yaw values. Yesterday for example I noticed that my Mavic Mini uses a different value to indicate north compared to a dataset I captured with a Phantom 3 Adv.

This will require sample datasets and a database to get the correct orientation for all models right. Ugh… DJI…

2 Likes
#19

Starting a repository to collect sample images here: DJI OPK - Google Drive

If you have a DJI drone, please help?

3 Likes
WebODM Now Taking Much Longer to Process Datasets With Matcher Process in Latest Version
Problems with output from Parrot Sequoia RGB
#20

Good idea @pierotofy. The conventions may be different for any and all 3 YPR angles.

Looking at the comments in your code at https://github.com/mapillary/OpenSfM/pull/838/files the following occurs to me.

            # YPR conventions (assuming nadir camera)
            # Yaw: 0 --> top of image points north
            # Yaw: 90 --> top of image points east
            # Yaw: 270 --> top of image points west
            # Pitch: 0 --> nadir camera**
            # Pitch: 90 --> camera is looking forward
            # Roll: 0 (assuming gimbal)

For the Mavic 2 Pro, Pitch 0 is a forward facing camera, Pitch -90 is a nadir camera. For example:

         Gimbal Pitch Degree             : -85.30

is the EXIF entry for my images taken with a pitch 5 degrees off nadir.

2 Likes
#21

I haven’t seen differences in the pitch/roll between DJI models (yet).

We already normalize DJI pitch values:

if self.has_ypr():
                        if self.camera_make.lower() == 'dji':
                            self.pitch = 90 + self.pitch
2 Likes
#22

Thanks @pierotofy. It must be the yaw then.

I will post a sample image to the DJI OPK repository ASAP.

3 Likes
#23

If I may, could you post a small set of maybe 6-10? It’d be great to test reconstruction with each set.

Regardless, thanks for helping us look into all these different cameras!

1 Like
#24

I found the following “DJI definitions” in my files, as provided by Litchi customer support in 2020:

Aircraft YPR:
“The attitude of the aircraft, where the pitch, roll, and yaw values
will be in the range of [-180, 180] degrees. If its pitch, roll, and yaw
values are 0, the aircraft will be hovering level with a True North heading.”

Gimbal YPR:
“The current gimbal attitude in degrees. Roll, pitch and yaw are 0 if
the gimbal is level with the aircraft and points in the forward direction of
North Pole.”

Unfortunately, as you point out, these definitions may not be consistent with EXIF data generated by different DJI models (and firmware?), creating plenty of scope for ambiguity and confusion. Under the circumstances, do you think the following approach might help simplify matters?

Divide YPR to OPK conversion into two explicit steps:

  1. Convert YPR as given by the EXIF of each model into your clearly defined conventions.

         # YPR conventions (assuming nadir camera)
     # Yaw: 0 --> top of image points north
     # Yaw: 90 --> top of image points east
     # Yaw: 270 --> top of image points west
     # Pitch: 0 --> nadir camera**
     # Pitch: 90 --> camera is looking forward
     # Roll: 0 (assuming gimbal)

  2. Convert YPR as defined above to OPK as per Baumaker & Heimes and your existing code.

3 Likes
#25

I uploaded a image for DJI Mavic 2 Pro and Phantom 4 Pro V2 for you I will add a Mavic 3 later.

3 Likes