We also address this problem in a similar manner to TUDelft option #2. Our setup is as follows:
- Payload consists of a sparkfun logomatic board with logger software on it, a Ocean Optics USB spectrometer connected over RS232, a GoPro Hero 2, and an arduino mini with software to generate DTMF tones only one of the stereo audio tracks of the GoPro. The camera and spectrometer are fixed to a very stiff mount together, which is fixed to the aircraft. This allows the two devices to be mounted and calibrated against each other, and later attached to the aircraft. No gimbal due to size/weight constraints at this point.
- Logger software is slightly modified to handle logging of spectrometer data and initialization of spectrometer
- We use the dc camera module and photogrammetry module in paparazzi to trigger a gpio line, which links up to both the spectrometer sample trigger line and also the arduino, coding a dtmf tone onto the audio track of the video
- During flight, we trigger the sampling using the regular time interval method, use the LINE_START_FUNCTION and LINE_STOP_FUNCTION macros in the survey flightplan blocks, with the macro defined in the flightplan file appropriately
- The logger sniffs only the ap->gcs data (in addition to the spectrometer tx data), and all of this is logged on the sd card
- Postflight, we download the .tlm files off the sd card with a card reader, then we run it through a cleaning script to separate out the spectrometer data, after which we run it through sd2log to get a log/data file out.
- This log/data file (with supposedly no missed DC_SHOT messages) gets run through a python script to format it into an xml file appropriate for Photoscan software. The python script also does some magic and takes the video file from the gopro and extracts frames/images based on the dtmf tone locations on the audio track using ffmpeg and a python dtmf decoder. All this gets run into Photoscan.
This method is decent but still not ideal. If you can trigger your camera using the modules, it probably simplifies things. I know a number of people have had success with CHDK if you have a Canon. The key part is to have the datalogger onboard with will eliminate any dropped packets for the DC_SHOT messages. Very useful. In addition, the software probably needs good bundle adjustment to handle to the errors in all measurements, not the least of which is due to the time delays everywhere. Most have this I think. Extracting DC_SHOT messages from the logs is generally very easy, and reformatting into say xml or similar is also easy.
Hope that helps.
Thanks,
-Stephen Dwyer