Once you have a terminal in the main ODM folder, run
this command to start the processing of the images:
docker run -it —user root -v
If you are on an older machine or just can’t wait, I
suggest selecting a subset of the images — about 150
works well. Processing the entire set took overnight on a
relatively modern machine, but I didn’t mind waiting once
the process was ironed out.
While ODM is running, lots of messages will fly by, but
you’ll notice that in this case the program terminates
unsuccessfully. What’s the problem? Our Faux Pro doesn’t
have any GPS information in the EXIF data of the photos,
and we haven’t told the program where the photos are by
providing any reference points. This means that the
reconstruction has no way of knowing the proper zenith
Figure 7: A well constrained textured mesh represents the
mapping area pretty well. The top of one of the buildings did not
render well, but the elevation changes are very close to actual
(up) direction, and fails when trying to generate the
orthophoto. Luckily for us, the meshing process should be
complete and we can start by looking at that result.
Without GPS data, we can constrain the location of the
images with ground control points (GCPs). These are points
visible in multiple photos whose location is very well known.
To view the textured mesh results of our run, navigate
to the odm_texturing directory in the main OpenDroneMap
directory. Just like last month, using a program like
By picking multiple ground control points that are visible in
multiple photos, ODM can determine the zenith direction
and geo-locate the images.
MeshLab, open the odm_textured_model.obj file and
explore. Depending on which photos you used, the
reconstruction could be pretty good (Figure 7) or rather
warped (Figure 8). Already we can see a lot of information
about the farm. The biggest thing I noticed was the
splotchy patches in the field — probably something that
should be looked at.
The ideal GCP has a sharp feature that can be well
located. Corners of buildings, painted markings on the
street, even utility poles could be good “natural” GCPs.
When making my first flights, I did not add any specific
GCPs, so I had to find some suitable points.
Already the advantages of technology like this for
agriculture and industry are obvious. There certainly are
some places that the reconstruction did not do as well;
namely, the sides of buildings. That makes sense as the
camera was pointed nearly straight down and at a relatively
high altitude when compared to the height of the buildings.
To create a geo-referenced image, ODM requires a
minimum of five GCPs that are each visible in a minimum of
three photos. In my experience, the minimum was never
enough. I chose seven points — each visible in three photos.
If you look near the intersection of the three gravel roads,
you can see me flying the quad, but my height information
was not well captured.
These points were easy to identify and in an area of the
flight in which I knew there were many passes. To tell ODM
about our newly discovered GCPs, we need to create a file
containing the image coordinates and real world
coordinates. To do that, we need to understand a few
things about coordinate systems.
All coordinate systems need to have a coordinate origin
— where zero is for the system. While we commonly talk
Ground Control Points
To get a true geo-referenced orthophoto, we
need to provide some information to ODM about
where the photos were taken. The easiest way would
be with GPS, but as I mentioned, this inexpensive
camera does not have that capability. Using a GPS, Pi
Camera, and Raspberry Pi would be an interesting
solution though. Using the OpenCV library, the
camera could be instructed to only save images when
needed to maintain the desired overlap, but that’s
Figure 8: An early attempt using less data resulted in grossly flawed
topography towards the edges of the map.
SERVO 05.2017 15