Wrong orientation in SiteScan model created in free flight

[HalgeirDahle]

Sometimes my models have wrong orientation. One example is this model.  The road cut seems to be overtopped by 10 degrees, but the real situation is the opposite. 

The pictures are taken in a free flight with DJI mini 3 PRO. Out of approx 100 road cut models, 5-10 models have wrong orientation, all of them are tilted towards the road. 

I have computed the same pictures in PIX4D matic, and there the model is perfect. What can be done to solve this?

[Pål_Herman_Sund]

@HalgeirDahle has rasied this issue as a supportcase with the Norwegian support team with me as consultant. Adding details

• 181 images in total
• They all seem to be oblique or close to horisontal shots of the cut, som are partially covering the road to the west.
• No GCP's and a code-GNSS

I did process the imagery in Drone2Map which seems to produce a "correct" result. With Drone2Map I digitized 4 points which was imported to Site Scan as GCP's. Registering the "GCP's" in Site Scan and reprocessing seems to produce a better result (see https://sitescan.arcgis.com/share/8a0be250-a240-4452-92a3-31d6a37fb1ff). The cut may also be looked at with Google Street View (https://shorturl.at/hrAZ3).

My guess, the current processing engine in Site Scan require more "consistent" flight planning.

Heavy trafficked road, therefor a light drone (max 250 grams) and no GCP's to avoid blocking the road for traffic.

Attachements:

• flight_part.png displays a part of the images location. 
• typicalimage.png is one example of imagery captured. The other images are similar to this sample

best
Pål Herman 

[NicoBonnafoux]

Thanks for bringing this. Without looking at the actual images, it's challenging to diagnose why 5-10 models out 100 show this tilt. @Pål_Herman_Sund could you please escalate this to Esri Inc Tech Support so they can work with you and @HalgeirDahle to review the actual data? 

The upcoming Reality Engine Beta v2 may help here especially if you've already seen good results in Drone2Map where it's already implemented. Support will be able to try that out for you now as well. 

[Pål_Herman_Sund]

Thanks @NicoBonnafoux I escalated yesterday and got excellent (as usual) help from @NikolasDingus. Two proposals both seemed to solved the issue (though I have not yet compared the DSM's).

1. The Beta Reality Engine in Site Scan
2. Restricting XY and Z shifts in the "legacy engine" (PIX4D) to 1 respective 2 dm's for the photopositions

I can make an update when DSM's are compared. 

[Pål_Herman_Sund]

@NicoBonnafoux @HalgeirDahle @NikolasDingus I have compared the DSM's. They have an offset (no big surprice). Part of the offset accounted for with use of raster arithmetic's. They both now have similar slope for the cut's. I would say "case closed"

[Pål_Herman_Sund]

It ain't over till it's over @NicoBonnafoux . Found a feature today which I m not able to explain. @HalgeirDahle had another problem in his Site Scan organization with the results. He had Output Settings to EPSG:32632/EGM96 (WGS84) resulting in model again being heavily tilted. I changed Output Settings to EPSG:25832/EGM96 (ETRS89) -  re-processed and everything is fine. 

Due to "bad" flight-altitudes I have to offset the mesh with 110 meters in the WGS84 results and approx 70 meters for the ETRS89 results for the results not to intersect the underlaying DRM in the "mesh viewer". The difference between the two being approximate the geoid height in this area. Both processed with the Beta Engine. So - I have some questions here 🙂