Discussions

Problem 1:

The APM .log files contain CAM messages based on when the autopilot commanded the camera to be triggered. It doesn't know when or if the camera actually triggered. This can result in CAM records that don't have corresponding photos or latency issues, both can result in difficulty in the Geotag process.

Problem 2:

I'm using a Sony NEX in a roll gimbal. The .log file contains the IMU attitude data for the aircraft, not for the camera. I would like to be able to feed the camera's IMU data into the image processing software.

The Solution:

These problems were solved by the Field Of View GeoSnap http://fieldofviewllc.com/true-color-imaging-payloads/

However they want $10,000 for it, and it is big and heavy. How can we DIY this?

We could use a separate APM mounted directly on the back of the camera. The new breed of mini APMs would fit nicely and can be found for $40 online (no 3DR mini option).We would need to feed this with the GPS data which could be simply tapped with a splice off the aircraft's GPS receiver. The same could be done with the magnometer.

This APM could be used as a stand alone triggering device if desired. If triggering by distance, it wouldn't even need a flight plan, unless you wanted a couple waypoints to start/stop the triggering with DO_SET_ CAM_TRIGG_DIST. You could use a very large WP Radius to make sure they are not missed.

Here is the part that gets more difficult and requires some code modification...

How do we tell this APM that the camera has actually fired so it can record that event along with the GPS and IMU data at that moment?  For the Sony NEX the iISO Hot Shoe could provide the signal that the camera has fired. This is the solution that the GeoSnap uses. There are a number of cheap eBay hot shoe adapters for around $8 that could be hacked to provide an easy slide in connection without soldering to the contacts. Cameras without a hotshoe could be hacked to provide a trigger signal from other sources, like perhaps the speaker. We may need a voltage divider or multiplier.

So now the question is, how will the APM read this trigger signal, and how can we have each event recorded in the logs? This is where I need help from the community as it exceeds my knowledge base. Could we simply use the voltage pin to detect the spike from the hot shoe, or would it be better to write new code for a new sensor pin, or I2C perhaps? Is there already any code in place that can provide a sort of reverse relay? Like for a proximity switch or a another sensor that provides a simple on/off switch?

Then the next issue is getting the trigger signals recorded in the DF log. Should it replace the CAM message, or be recorded in addition to it? If we had a CAM2 log that recorded the actual trigger moment, and the old CAM log that measured when the trigger was commanded by the APM, we would be able to measure the latency and troubleshoot issues.

So what do you guys think? Would others be interested in this? Who could help write the code modifications?

Looking forward to some brainstorming.