Reconstructing models from multiple levels (aerial and ground), initial findings

I worry less about ODM finding the ground plane in cases where there isn’t good GPS. I worry more that with good GPS, but lots of non-nadir shots, that we might not find the correct model orientation.

2 Likes

Hi Gordon,

The tilt is just because I hadn’t refined the orientation in the 3D settings after viewer upload, but only done a ‘crude’ X-axis set. I have now done that and WebODM performed admirably given the task and settings. I certainly found that using one hand to focus entirely on the viewpoint instead of that and the shutter, made the capture process smoother.

Over time I am building up a set of parameters for different numbers of photos dealing with various m2 of the site or with land-based items. Doing my neighbour’s field for his biodiversity project covered an area of 12,100 m2 and 2,224 images so the result was not that good having to use Medium for Feature Quality and PC Quality to avoid running out of memory. So I’m redoing it in two halves as my Mac Mini can manage about 1,000 images with good reconstruction quality. Compare these two results with the latter being the ‘half’ area:

I can’t recall if I have previously posted the one of Carn Kenidjack (with animation movie on a link in the description). This was 806 images over an area of 4,300m2. I went there again to get some more orbitals of specific areas that were in ‘shadow’ and so not well defined. In case I didn’t post it here it is: Carn Kenidjack - Download Free 3D model by Kerrowman [3c1b485] - Sketchfab

2 Likes

PS. I still haven’t figured out what causes the bright spots at random positions; or how to edit them out in Blender for example. I have never found a distortion in the original photos so it must be an ‘algorithm artifact’. Sometimes they can be bright green like someone left some Kryptonite lying around :slight_smile:

2 Likes

An interesting area of concern. So far I have never used more than -80 degrees down for mapping shots. I read somewhere that -90 could cause ‘Doming’ but I’m not clear yet what that is. I reason to myself that a slightly forward gimbal will see more of the vertical surfaces coming up and together with a max speed of 4mph, seems to work well.

3 Likes

I thought I sent the problematic images over to Piero, but it doesn’t show up in my history. That said, I found a few more datasets that I can confirm were correctly oriented with earlier versions of ODM/OpenSfM, and they are all ones I feel comfortable sharing publically, so I will do that shortly.

2 Likes

I phrased my last reply quite misleading.
I just wonder if you can share the reconstruction file or a screenshot of the camera errors in opensfm viewer, that might be helpful to understand how the model is aligned with camera location.

1 Like

I like the Carn Kenidjack animation, quite a spectacular feature on the landscape!

What are the sausage shapes running diagonally across Survey 1 animation, and are those depressions natural features?

Those bright spots are something I’ve seen appear a few times too, but I also do not know why they appear.

I’ve had good results with imaging at a range of camera tilt angles in a single project, anything from nadir to -50°, so long as the horizon is kept out of view. It certainly improves the coverage under trees and overhangs etc.

1 Like

Not sure which features you are referring to, the little pits or the brown patches of plants.

The small scraping pits have been dug to provide bees with sun-facing homes (social housing for bees :slight_smile: ) and the brown ‘things’ are clumps of a certain type of vegetation.

The survey was complicated by being on a pronounced slope so a regular mapping flight plan (using takeoff height for reference) was not possible with my subscription level as the drone would have hit the hillside. So I had to build an AGL waypoint plan to mimic it. Tedious but can use it again next year for the follow on.

2 Likes

Yes, them.
And the vaguely loaf of bread shaped hollow on the left of the top image.

I use Litchi for final flight planning, after exporting from DJIFlight Planner, it allows pretty easy adjustment of way point altitude- really useful when there is over 100m of local relief in a flight plan! I generally try to fly approximately along contours, rather than up and down slopes, so the battery lasts longer.

1 Like

That’s also my guess : if the GPS between aerial and ground has some shift/bias, then the alignment will be messed up. Two fixes I’m seeing :

  • (In case of GCPs, this wouldn’t an issue since we would use GCPs to align and then compute a global bias per device)
  • Run the alignment per device (i.e. ground shot and aerial separately) and pick the “best” one (with least variance). The other devices/images will be bias-compensated.

@ smathermather I’ll give it a try if you can DM me the dataset.

ALso you mentioned that this ground + aerial dataset was working before ?

3 Likes

Yup, I just DM’d it. As far as what I said about stuff working before, that was a different dataset, and as I went through the old datasets I’m seeing something else happening probably related to GPS parsing and not this.

I actually suspect that the reason I haven’t seen this before is that the matching of datasets have gotten better and it is now possible to match the ground level stuff with the aerial stuff, which might be exposing an older issue. But, that’s pretty high-level supposition… .:smiley:

1 Like

So the GPS altitude is really off for the ground images AND aerial as well, that totally explains why the alignment is off, this is expected since the alignment isn’t robust :

I’ve modified the global alignment so that it is robust (by using good old LMedS), still not perfect, as the biggest consistent GPS set is 145 images over 254 (in Meshlab) :

I will test a bit more since this change can affect many datasets.

Yann

4 Likes

Playing a bit more shows it’s quite tricky : we don’t have any robust term for the GPS in the bundle, and even in such case, the hypothesis is that bad GPS (outliers) are drawn from uniform distribution, which isn’t even the case here (since there was some jump in GPS).

The GPS data is just too messy here to get a good alignment. I’ll the fix on the side if we get other issue like this, but for now I would prefer to have more cases in order to take a decision.

1 Like

I wonder if this is a case where any available relative altitude might be more beneficial, or instigate when there are wild inconsistencies in GPS.

1 Like

Just an observation, the normal GPS errors are not uniformly distributed. The relative horizontal error seems correlated with moving direction. The relative vertical error tends to be sensitive to actual elevation change. I’m not sure if it’s also related to the drone’s flying speed. I always observe to errors tend to have the same directions per row like the image below.
The errors can still be compensated with enough samples though, but if the survey is biased, it could possibly cause a bad orientation of the model.


2 Likes

I’m not sure if it will work, maybe you can try to specify different GPSDOP for different sets of images? For drone images, use GPSDOP 10, for others, use GPSDOP 150(or even larger).
geolocation file could do this.

2 Likes

There’s more things to try in that space, but GPSDOP is where I started in troubleshooting this. That said, it appears there more GPS variance in the flights than I expected, and my GPSDOP fiddling was only with the ground images.

1 Like

I’ll try grabbing relative altitude and stuffing it into GPS Z (plus an offset) to tamp down the vertical error and see if that yields an acceptable result. Thanks for looking at it!

I’ve got upcoming projects that may have wide variance in GPS quality, so this was an accidentally good test case.

1 Like

Pretty much every dataset I collect from my phone reconstructs at some crazy (not at all real) alignment. I always assumed it was the camera lens profile, but it might be poor GPS consistency instead.

Would you like these datasets to test like you did with Stephen?

2 Likes

I’ve got a couple of other datasets that exhibit this too – at least one from Dar and one from Zanzibar. I chalked them up to something else as well, but I’m guessing it’s the same issue.

BTW, copied over RelativeAltitude to GPSAltitude and reran. exiftool "-GPSAltitude<RelativeAltitude" . It ran faster than stripping elevation (no need for BOW), and completed nicely, but it is still rotated:

I’ll run it with a straight install of OpenSfM tomorrow and dig deeper, but that was surprising.

1 Like