All: Precise Camera Feedback messages

[taedla01]

Hello everyone,

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.

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.

Tested with ArduPlane, ArduCopter (should work with ArduRover) on APM1/APM2 and PixHawk.

Regards,
Dario.

[WickedShell]

I really like the idea but I have a couple of questions about the implementation.

A) Have you tested this, and had good luck with always detecting the sync pulse? Past testing with the camera's I've had on hand have needed to use an oscilloscope sampling at 200MHz to briefly show the waveform, or using an interrupt, my testing showed poor accuracy in actually detecting the hot shoe when polling the pin. (And if you've tested, what cameras where used? It's going to take me a couple of days to dig out my hot shoe adapters and preform testing here).

B) I'm open to other ideas here, but I would like to see us log both when we commanded taking the picture as well as when it was actually taken. This is primarily related to my concern with point A) that we might not detect every actual photo, and I need to be able to resolve the data after the flight as best I can, even if that means some of my photos will have a larger delay and thus inaccuracy in their position.

C) The check_digital_pin helper function reapplies the pin mode/writes to it every time its called, is this truly desired/needed? (I haven't done enough with the HAL to know the answer, or if this helps with some platform).

[taedla01]

Hello @WickedShell ,

A)Yes, I've tried. I've been flying with this improvement past three years, always with APM1 (not exact same code) and now with PixHawk. As you said, usually modern cameras take a digital signal for activating the flash running too fast for be readed. For that reason, you need an universal Hot Shoe adapter which converts the digital signal into an analog signal (like a relay but all electronics). My camera is custom made, but I confirm you that code works with Sony Nex5.

B)If you look at the code, you see that only if the full cicle is true, can be return to rerun the log_picture function. Both are reciprocal.
Thus, the do_take_picture function can be being called, but if the camera does not return a signal that the photo has been taken, the CAM message is not stored.
My idea is to also store two messages in the log, the actual CAM message indicating when we made the call to do_take_picture, and a new one to which I have called TRIG and is the result of this Pull Request, which indicates when the camera is truly triggered and therefore when the log_picture function is executed.

C)I am not a programmer so I am not sure if is needed... Best would be that an official project programmer revise the above code.

Regards,
Dario.

[magicrub]

Would be nice if the commit was cleaned up a bit. Needs an interactive rebase to consolidate and remove the revert.

[jmachuca77]

In general using "Magic numbers" is not very clear. I would add a define for what -1 and 0 mean (triggered, nottirggered). Also I think this should have its own loop, This loop seems to be for the camera mount (gimbal). And do a call into a function from the camera library, so that we don't have to duplicate code on Plane, copter and rover.

[jmachuca77]

Is this function missing from Rover? I only see it for plane and copter.

[taedla01]

Hi @jmachuca77 ,
This function already was in Rover, indeed is a copy-paste from it. Originally was used for AUTO_TRIGGER_PIN.

[taedla01]

@magicrub, Sorry to interrupt you... Windows GitHub client is giving me headaches ... I made an interactive rebase but I do not known why I can not clean PR commits... Is there an option to change the entire remote branch of a pull request? Sorry for the inconveniences... I am rookie with GitHub.
Please feel free to make any change that you want. As I wrote above, I am sure this is the worst code you've ever seen...

[taedla01]

Reorganized and updated according to new format (C++) with #2383 so will close...

Sorry for the inconvenients...
Dario.