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.
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.
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.
As mentioned by the other people, the camera "hot shoe" approach mentioned here sounds really good, and would like to implement it... Something like RTK GPS would not really be that great if it isn't represented in the photo's geo-coding.
The problem now, the sony A5000 (which I have) does not have a hot shoe connector on. Anyone have an idea how I could DIY myself around this?
It's ready to go: http://www.tuffwing.com/support/Install_a_canon_precision_geotag_ca...
Hi Brian, any guide anywhere to make that phototransistor and install it on the pixhawk?
Brian Christal said:
For Canon Powershots...
I've been working with working with the KAPUAV script guy. http://chdk.setepontos.com/index.php?topic=12398.0
He has modified the script so it flashes the Assist focus LED on on shutter open. I'm in the process of modifying my (Tuffwing) trigger cable with a phototransistor so it will create a feedback loop to the autopilot - precisely when and if the picture was taken.
Anxiously waiting on this update: https://github.com/diydrones/ardupilot/issues/2289
"Anxiously waiting on this update: https://github.com/diydrones/ardupilot/issues/2289"
Do you have a date for when this will be implemented in official code?
I tested the script kap_uav3.6 beta and works perfectly on my Canon SX260. Solid flashes every shot. My camera can take a maximum of one photo every 3 seconds. What is the minimum time between shots in the Canon Power Shot elph 115? I also manufacture my triggers cables. I will start working on the phototransistor cable tomorrow. I will share with you the cable development, so we can compare.
As far as the tagging aspect goes and without modifying the autopilot, we have released a free standalone photo tagger that works with the autopilots log, and uses a script with Mission Planner. Using this method we can handle missing arbitrary photos within, and have shown good results with tagging photos that were taken more often then once a second. (Although our typical times between photos are usually roughly 1-2 seconds rather then sub one second). It's available here: http://swiftradioplanes.com/swifttag/
It primarily been tested with APM:Plane with great success, but we have also used it with copter as well. Feedback will be a great refinement to camera accuracy.
There is already a solution on the works for this issue, is probably coming out soon.
I see there hasn't been any discussions for a while. How is this project going? I would love to see this. Did the script from Gerard solve the problem?
I also have another questions. I'm running a Flytron sLED v2 IR trigger from the PIXHAWK RC10 to trigger a sony nex 7. I get it to trigger, but it wont' stop triggering. Anyone have any ideas?
I've bought a NEX-5R a week ago and use the gentLED-SHUTTER cable.
Not yet in the air with this cam but interested in the issue as well.
Just did a quick test on the ground.
- missing shots
Triggering via the mission planner manually shows that the cam
is not awaiting the disk write but engaging the somehow 10 pictures
deep buffer. That means missed pictures indicates to run out of
buffer. Is this correct? If yes then it indicates that the scenario
mentioned above is beyond the capacity of the NEX-7.
I've used my video cam to record a stop watch on the monitor and the manual trigger
seen in the mission planner. The stop watch is taken in the NEX pictures as well.
Not a very precise measurement but to the single frame (25fps) of the video cam.
After 10 pictures taken I've got
average delay: 360ms
max deviation: 31ms
These values are in a range where my test setup is insufficient. May be
in reality even better figures.
Compared to the GPS precision mentioned above these values seems quite good
to me. No need to have a backward channel for better values.