[Elphel-support] UAV photogrammetry application

Richard Antecki richard at clearboxsystems.com.au
Mon Oct 18 20:51:12 PDT 2010


We have mounted an Elphel 353 (8.0.8.41) on an unmanned helicopter for use
in aerial mapping research applications.  For accurate positioning of the
images, time synchronisation is very important as we need to correlate the
time the photo was taken with the navigation solution of the helicopter at
that particular instant (raw GPS data providing only one input to the
navigation solution).  Even with the ntp sync at bootup, the timestamps on
the captured photos have been seen to be up to 10 seconds out.  We require
time accuracy of less than 1ms for this research application.

 

We're now investigating use of external triggering and/or serial NMEA
timestamp data to help with this issue.  I have a couple of questions
around this area.

 

We have a U-Blox 5 GPS receiver which spits out NMEA GPS time information
at 1 second intervals.  I understand that the camera can take an external
GPS serial input and embed the location in the EXIF data.  Am I correct in
assuming that by default, the camera will include this data in the EXIF
header of all future images captured, until a new NMEA update is received?
So with this alone, the GPS time in the EXIF data will be accurate to +/-
1 sec?

 

I've found a nmea2exif.c file in the source.  Does this need to be started
manually or is it run automatically somehow?

 

The U-Blox can also spit out a timing pulse at exactly 1 sec intervals,
which correlates to 1 sec GPS time increments.  We could potentially use
this pulse to trigger the camera on 1 sec boundaries.  Is the sensor
triggered on the rising edge of the trigger pulse or the falling edge?

 

The NMEA timestamps are received after the timing pulse to which they
relate, so the EXIF timestamp data in the image captured by the timing
pulse trigger should be accurate, but exactly 1 second behind.  This is a
potential solution.  The drawback with this method would be that we can
only take photos at fixed 1 second intervals.

 

We tested a method using an external trigger at a known time, using camogm
to capture images, and noted some strange behaviour when the camera is in
trigger mode (such as Apache freezing).  The internal clock also seems to
be affected whilst in trigger mode.  Just prior to enabling trigger mode,
an image was captured using camogm with the filename
"1287443109_363240.jpeg", which is the correct time.  After trigger mode
was enabled, the next set of images captured were named as follows: 

 

-268435456_1048575.jpeg

-1610612736_1048575.jpeg

-000000008_1048575.jpeg

-000000001_1048575.jpeg

-134217728_1048575.jpeg

 

The timestamps captured in the EXIF data were also highly incorrect, e.g.
"EXIF_DateTime=2106:02:06 06:28:15"

 

>From what I've read so far, the external trigger method has some
negatives, such as the auto-exposure, white balancing etc not being able
to function correctly, requiring all these parameters to be set manually
beforehand.  Can anybody see any other potential issues with this
application?

 

Thoughts/suggestions on any of the above would be appreciated.


Regards,

 

Richard

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20101019/d7c5d6de/attachment-0002.html>


More information about the Support-list mailing list