My first orthomosaic surveys

[franknitty69]

I used Pix4d a while back to chug on a bunch of photos I took of a property down in Costa Rica. It is mostly jungle so I am sort of surprised the Pix4d software was able to put everything together (see attached image). For this, I just used the Tower app on the phone to take the shots and it worked reasonably well.

Perhaps this has been discussed previously but is there a recommended workflow to properly geotag the images using Mission Planner (if I don't have use of Pix4d) and then place the image back into a google map? Is it best to build a survey scan of a site in Mission Planner or in Tower?

Thanks for any ideas/suggestions.

to geotag the images you need the flight log and then you can use mission planner. or better yet use geosetter.

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

 

[Mike Bohlmann]

What preprocessing did you do with your images? I'm trying to figure out what I'm doing wrong with DroneDeploy. I'm using a Solo, Tower, stock GP4B, and Mission Planner to geotag.

Based on these results, I was thinking it has to be one of 3 problems:

• GPS data has the wrong long/lat (the frame lines make me think this is possible).
• GPS data has the wrong altitude (images are too zoomed in)
• Fisheye causing stitching problems

Other than the fisheye, the images are great. They were shot on the zig zag pattern that Tower automatically generated. I randomly picked an image to look at the exif data. The position was within the acceptable accuracy of GPS, off by maybe 10 feet or so. The altitude it showed was 285m. Google Earth claimed 225m elevation at the same location which puts the altitude at the altitude I flew the mission.

I'm left with either user error for DroneDeploy or the fisheye causing problems. Any ideas?

 

[Pedals2Paddles]

I cant' see the images at work (firewalled).

What did you have the overlap and sidelap set for? I had mine set to 70/70, which I believe took care of the fisheye distortion.

 

[Ed Beck]

What was your sidelap and overlap? I use 80% for both and get good results.

I have a Peau Production lens with no distortion but from what I've heard Drone Deploy can handle the distortion.

Use Geosetter. I know it looks difficult but after you've done a few of them it's pretty easy. The key is to find the image that's easy to know where it is and match it up with the log. It's always a turn for me because it's easy to see the before and after turn. I like to have a road or structure near my turn points to make it easier.

 

[Pedals2Paddles]

When I've done surveys I've put my GoPro in medium FOV and then told Tower I was using a GoPro 3 with a medium FOV.

@Ed Beck Where did you see a medium FOV for photo modes? I didn't think that was an option.

 

[Ed Beck]

@Ed Beck Where did you see a medium FOV for photo modes? I didn't think that was an option.

It's one of the options for the Hero 3.

 

[Mike Bohlmann]

I cant' see the images at work (firewalled).

What did you have the overlap and sidelap set for? I had mine set to 70/70, which I believe took care of the fisheye distortion.

I did 50% overlap and 80% overlap since it's such a small area. I looked at some more random images, and the GPS does seem kind of flaky. What makes Geosetter work better than Mission Planner?

 

[Ed Beck]

I did 50% overlap and 80% overlap since it's such a small area. I looked at some more random images, and the GPS does seem kind of flaky. What makes Geosetter work better than Mission Planner?

With Geosetter you manually link an image with a point in the log, then all the other images are associated with log points. With Mission Planner you're relying on the timestamp on the log and the image to be in sync.

After you tag the photos in Geosetter you should then go back through the log and make sure that the log and images match up.

It's all in the video that Frank posted. I think the first 7 minutes talk about Mission Planner, then the rest talks about Geosetter.

 

[Mike Bohlmann]

Cool, thanks. I'll give that a shot and run it through DroneDeploy again to see if maybe it's just a geotagging issue.

 

[Ron380]

Other than the fisheye, the images are great. They were shot on the zig zag pattern that Tower automatically generated. I randomly picked an image to look at the exif data. The position was within the acceptable accuracy of GPS, off by maybe 10 feet or so. The altitude it showed was 285m. Google Earth claimed 225m elevation at the same location which puts the altitude at the altitude I flew the mission.

I'm left with either user error for DroneDeploy or the fisheye causing problems. Any ideas?

Altitude 285 Meters? MSL, or were you flying at over 850 feet? Seems a bit excessive?

Noob here < Sorry if I'm reading that wrong.

 

[Mike Bohlmann]

Altitude 285 Meters? MSL, or were you flying at over 850 feet? Seems a bit excessive?

Noob here < Sorry if I'm reading that wrong.

GPS altitude in the logs is MSL. The altitude that the apps tell you is typically AGL (above ground level). In this case, MSL of the Solo was 285, and the MSL of the ground was 225. 285-225=60m AGL. Even though you tell Tower to use an AGL altitude, it clearly maintains an MSL flight plan since otherwise you'd see variable altitudes over variable elevation terrani.

 

[Mike Bohlmann]

My second test from last night finished processing, and I think I can blame Mission Planner's attempt at geotagging. While the orthomosaic at least looks like the site I surveyed (aka it is stitched correctly), it is not scaled properly.

 

[Ed Beck]

I think the altitude might have something to do with the scaling. When Geosetter asks me about altitude I just hit cancel, which I think tell Geosetter to use the starting altitude as 0.

I might be confusing Geosetter with Drone Deploy, whichever one it is, when it comes up with the altitude question I hit cancel.

 

[Mike Bohlmann]

When Mission Planner exports the GPX file, it asks about an altitude to use or whether to use an absolute altitude (by click cancel). I'm guessing that refers to MSL since the GPX file had altitudes that were MSL when I used absolute.

After following that video from Mapir, the issue appears to have been purely due to Mission Planner doing a horrible job of geotagging the images. Here's the results I got after following the steps. As an FYI, I used an interval of 4 seconds since that's what appeared to be the trigger time from Tower. I don't know if that ever changes.

 

[Pedals2Paddles]

When I used MP to geotag, it worked perfectly. I dont' recall it using time stamps. I think it just did it in numerical order. You need to feed it only the images from the survey, it does them in order. If there is mismatch in image count, it will tell you and not work. So the time stamps of the images were irrelevant.

 

[Mike Bohlmann]

When I used MP to geotag, it worked perfectly. I dont' recall it using time stamps. I think it just did it in numerical order. You need to feed it only the images from the survey, it does them in order. If there is mismatch in image count, it will tell you and not work. So the time stamps of the images were irrelevant.

MP only works by using time stamps. It uses the timestamp of the image and looks for a tlog entry of the same time. With a four second picture interval, there looked to be about 10 to 20 GPS coordinates in the tlog file per photo. You can see it try to align tlog GPS coordinate timestamps with image timestamps when you tell it to estimate offset or pre-process; it's looking for tlog entries with the same time stamp as the image. When it is estimating offset, it is trying to figure out just how much different the two times are.

From what I understand of what you and others have posted, Pix4D uses geotags to assist in stitching, but GPS metadata isn't required. I'm using DroneDeploy at the moment, and geotagging is required by them.

 

[Pedals2Paddles]

OK. I see why now. There are two methods of geotagging with Mission Planner. You're using the "less accurate" way, which you can see is indeed as described. You need to use the CAM MESSAGE method that require the dataflash logs, not the tlogs. You need to download the dataflash log, convert it from .bin to .log, then use the cam message tagging.
Geotagging Images with Mission Planner — Copter documentation

 

[Mike Bohlmann]

Ahh, ok. I'm still glad I learned the method I used since it doesn't rely on the Solo triggering the photo. Some of the camera solutions don't allow camera control by the Solo and so Geosetter might be the only way to geotag the photos.

 

[Jubalr]

Ahh, ok. I'm still glad I learned the method I used since it doesn't rely on the Solo triggering the photo. Some of the camera solutions don't allow camera control by the Solo and so Geosetter might be the only way to geotag the photos.

I used MP for tagging briefly, but once I got the flow down for GeoSetter it has been the only one I use. Very accurate and fast once you get used to it.

 

[Jubalr]

Here is an Ortho of a construction site I did last May. 216 images and used Geosetter for geotagging the images. GP4 BK triggered by Tower..
http://drdp.ly/AhkwJj