All: Precise Camera Feedback messages #2383
Conversation
Added _feedback_pin; Added _camera_triggered; Included FEEDBACK_PIN parameter and his default definition
DataFlash.h: added support for Trigger MSG, supressed TAB separations and file reorganized LogFile.cpp: included Trigger packet
Message DISABLE by default. Can be ENABLED trough CLI
Message DISABLE by default. Can be ENABLED trough CLI Log.cpp: corrected according to defines.h
Message DISABLE by default. Can be ENABLED trough CLI Log.cpp: corrected according to defines.h
system.cpp: included support for digital pin. Already included in APMrover2.
system.cpp: included support for digital pin. Already included in APMrover2.
Corrected comments and functions added
Added update_trigger and check_digital_pin functions
Added update_trigger and check_digital_pin functions
|
Based on my conversation with @tridge when discussing the initial issue #2309 it makes more sense to do this using interrupts much the same way that the PulsedLight can input information (timers triggered on rising edge). And it makes more sense to simply extend this aspect that is currently hardcoded. The goal here is to avoid polling for the pin state, as that requires external circuitry in the flash hot shoe adapter, meaning that only some hot shoe adapters will work. (as well as being a slightly less accurate method). My benchmarking in the past has shown a very short signal here for the flash, that could easily be missed. I'm willing to do the rework for it, but I think it's going to take at least two weeks to a month before I get to sit down and look at this aspect of it. This should also still log the standard cam message as well as the trigger feedback message (allows tagging software to handle a photo where the feedback was missed, as well as diagnose if commands were simply sent to rapidly to trigger the camera). |
|
Hello everyone, @rmackay9 @WickedShell @tridge
Seriously, we need to isolate wires between camera an controller with an aditional optocoupled electronic board. So we can not connect directly the camera hot shoe to the Pixhawk. The measurements that we have realized with several cameras (Olympus, Sony Nex series, Ricoh, Canon) show that the hot shoe trigger duration varies between the camera brands, for example, Ricoh outputs a signal of 1ms, as opposed, 12 ms for Canon. Ricoh hot shoe in action: We have made an electronic that solves this problem and universalizes the use of this pull request. So Universal Hot Shoe adapter is no more needed. The different between using this pull request or not is that the camera shutter lag causes a mean deviation of photographs of about 2 meters from their ideal coordinates. We are using a RTK GPS system, so achieving the best georreferenced photos is crucial for simplify postprocessing work. Some users have already asked me about when this code could be included due to the high accuracy it grants. I can provide logs and software jobs that support the difference in time, effort and result that means the use of this pull request. So please consider merging this new code. Thanks for your time and effort, |
|
Hi Dario, I just wanted to say thanks for this great addition (whenever that happens to be merged). Also thanks for the awesome explanation and time you have taken to investigate signal timings etc. Efforts are beeing made in L1 and L1/L2 GPS raw recording with Ublox and others and this is the missing part. Does anyone knows if this is going to be merged? A+ |
|
I thought I had replied to this awhile ago, but it apparently got lost in my email as a draft instead... Yeah the optoisolater is an expected requirement to do this. Would you mind sharing the circuit you used? Have you had any cases of having photos but not having a feedback time for them? This is still my biggest fear about polling as opposed to using a hardware capture timer. |
|
Hello everyone, @WickedShell, we are working on developing a final circuit. It will be integrated on an universal hot shoe, so any camera with an universal hot shoe rail will be able to work perfectly. It has a Camera Trigger integrated too, so you just need to use one hardware to trigger the camera and give the feedback to the Pixhawk. Our plans is to make it open source, but maybe would be a good idea to have the support of 3DR or anyone that could make several pcbs. I have several flights with more than a thousand of photos, and always I have been having the same number of photos as CAM messages (and of course my new TRIG messages). I have a Microsoft Excel macro for verify the messages and photos reference numbers plus the GeoTool on Mission Planner. Yeah! It works like a charm! The key is to standarize the hot shoe trigger duration, and this is made by our circuit. The results on photogrametry software are impressive... less than 1 meter of absolute error in Photoscan without an RTK system... Give me some hours and I will be able to post here an example (I am on holidays). Here you can see one of our prototypes:
I need to make in this Pull Request a Little change to adjust the frequency of the function before it can be merged... Regards from Spain. |
|
Hello everyone, @WickedShell @rmackay9 @tridge : *Always working on WGS84 coordinates. See and compare photo data between both images. As you can see, same flight, same photos (34), but different coordinates and therefore different result. With normal CAM msgs (here is called TRIG):
With custom CAM msgs:
The difference is obvious. ;) Cheers, |
|
This needs a rebase on master due to the namespace change of HAL to access hal.* |
|
Closing due to working being required and rebase request ignored. Please reopen if you are able to rebase. |
|
Hello everyone, Regards from Spain, |
|
Created a new pull request with the rebase for this pull request #3446 |
|
closed, replaced by #3446 |
Hello everyone,
Well, I think this is the ultimate for make affordable this thing...
I want to achieve the exact time and precise coordinates where the pictures are taken. It not depends on PixHawk, as it sends the order to trigger, but is the camera itself who actually decides when to make the shot.
Some miliseconds are wasted between Pixhawk triggering and camera shooting. This time is variable and depends on multiple factors: light, focus, shutter,... so the best solution is to use a synchronized flag or a signal, i.e, the camera flash (best solution that I found).
Well, this is not the best solution and sure this is the worst code you've ever seen, but... it works!
Please give me time to complete here the explanation of how to add the hardware necesary for this and how the code works.
Here you are:
Firstly you need an universal Hot Shoe adapter. Not all Hot Shoes will work. You need one that supports Preflash and Flash Ready emulation. I have tried 5 adapters and just one has worked...
Connecting it to the PixHawk is very easy, as you can see below, but be careful: BE SURE THAT YOUR CAMERA OUTPUTS A MAXIMUM OF 5,7 VOLTS THROUGH HOT SHOE FLASH PINS or you will burn your PixHawk.
Secondly, you need to configure CAMERA_FEEDBACK_PIN through Mission Planner.
Then, when the function do_take_picture will be called, for example with "Trigger camera now", the code will generate a flag for wait to the Hot Shoe response.
If the Pixhawk detects an input from the Hot Shoe pin, i.e, camera has been truely triggered, a CAM message will be saved to the Dataflash log.
Finally, code will reset the cicle, waiting for a new do_take_picture.
With all, we have a consistent Log, with the same number of CAM messages and pictures, and the best... precise coordinates and time marks for each picture.
I have included an option for log a "TRIGGER" message that corresponds with the "normal" CAM messages. So now we have two signals or logs for the trigger process: when you require to the camera to shot a picture, the "TRIGGER" (TRIG) message is generated, and then, when the camera really takes the picture, the "CAMERA_FEEDBACK" (CAM) message will be saved.
This is highly useful for compare the time and conditions we have between we order the trigger with the autopilot board and when camera really takes the picture.
For configure the "TRIGGER" message, you need to enable it trough CLI, i.e, Enable CLI in the full parameter list and reset the board. Go to Mission Planner/Terminal and connect with the controller. Then activate (enable) the TRIGGER msg typing "ENABLE TRIGGER" inside logs menu (for Rover #2381 has to be merged).
Tested with ArduPlane, ArduCopter and APMrover2 on APM1/APM2 and PixHawk.
Fully compatible with Sony NEX series and Olympus E-PMx series (both with universal hot shoe adapters).
I can provide log files to confirm the operation of this pull request if necessary.
Regards,
Dario.