That makes sense. I have some myself.
I have no idea. Thatās a feedback solution. You want to know if the camera fired. It seems they use the flash signal (off the hot shoe) to know if the trigger happened. I have never had a need for that. I guess itās a necessity for some unreliable triggering system?
The camera feedback is critical for accurate mapping. The camera trigger has lag so with a standard PWM trigger cable the geotagged location vs actual camera trigger location varies up to 10m. It is critical this be very accurate otherwise even if you use RTK all you images are still out up to 10m making onboard RTK effectively useless for mapping. Tridge was referring to that function being specific to PX4, so I am safe assuming it is supported in the current beta?
Looking at TTL triggers it looks like that is a standard way for pro photographers to trigger the camera through the hotshoe, but each manufacturer has there own protocol that would have to be supported. If the TTL trigger works it should be much better than PWM based triggers from what I can tell but legacy support for PWM trigger plus camera feedback would still be important.
Cameras like a Sony A5000 or wx500 can only be triggered through The multi terminal port, so from what I am understanding TTL would not work for these popular mapping cameras since they do not have a hot shoe.
Triggering the camera and feedback from a hot shoe are two different things.
To take a picture you press a button. The button closes a contact and the camera reacts to this contact closure by running whatever circuit it has to take a picture. A remote trigger is just an extension of this contact closure. Instead of pressing the button on top of the camera, you attach a cable with a button at the end of it. When you strap a camera to the bottom end of a flying thing, you want to be able to press that button from far away (manually or automatically). For that, you build a circuit that does the button pressing for you. Contact closure is a binary state. Itās open or closed. When itās open nothing happens, when you close it, the camera shoots. TTL is a binary state. Itās on or off. All you need is to adapt the signal so they are compatible. Thatās what I explained above.
This page lists all the different cameras and their weird connectors providing virtually the same set of ābutton extensionsā. They all do the same. You close a contact to shoot. The only difference are the obnoxiously weird plugs these manufacturers invent so you have to pay extra to get it from them.
Thatās all there is to tell the camera to shoot a picture.
Now, as you explained above, some cameras have a lag between button closure and and actual shutter action. Coincidentally, I experimented with my camera and the lag was within 400ns (the setup was simpleāboth trigger and flash terminal connected to a logical analyzer.) A 10m error between trigger and image capture would mean the camera would have to be moving at around 90,000km/h.
If some of these cameras have some horrendous lag (orders of magnitude greater than mine), you will then need a way to tell when the image was actually captured. Thatās the whole thing about capturing the shutter time using the camera hot shoe trick discussed in that page. This is completely unrelated to how to trigger the camera and even less related to TTL.
Trigger ā Output signal to camera.
Capture time ā Input signal from camera.
Different functions, circuits, GPIO ports, and software.
That is a lot of good information there and a very fast trigger you have. Iāll have to do some testing and figure this out.p, really looking forward to the wiki page. The only question is what to do in the intern until the cables are sorted out.
What camera are you using? Any chance you have a pix4d quality report you could share?
That was quick, fixed and testable within 2 hours - issue is fixed in beta and master, thanks guys 
I had never heard of Pix4D. I had to Google it to find out. What that software does is rather simple. Itās one of the things I do quite a bit for my āday jobā, though completely unrelated to mapping. They seem to have released a Mac version so I might try it later and see what this āquality reportā is all about. Iām not at all involved in mapping. I just work with computer software and imaging. Been doing that for, crap, over 25 years now! Getting oldā¦ Iāve been strapping cameras to be bottom of flying things for quite a long time. Thatās what got me into drones to begin with. āSlightly" more stable than kites and a bit more manageable than helium balloons. Iām now transitioning to Fujifilm (XPro2 and XT-1) having been a Cannon user since the 90s (tired of the bulk). The camera I used above was a 1Ds, only because it was simpler for me to wire its remote trigger and flash terminal. I had it setup in the way I would imagine mapping is done. Fully manual, mirror locked and using only the electronic shutter. As I mentioned earlier, lag time has never been an issue for me so I had never put any thought to it.
I tried looking up the specs for the Sony A5000 you mentioned and it seems shutter lag is not something normally listed. The times I found are in the 20ms range but I assume thatās not having the camera in full manual. Even that timing would only give you 140mm error at 25km/h, which I assume (guess) itās an order of magnitude smaller than the margin of error of the rest of the system (GPS, pixel resolution, etc.) In other words, unless Iām missing something, there must be another factor messing up the timing.
@Andreas_Hoffmann @Sn0west @gervais I just pushed a change to beta which enables RSSI for Pixracer. I believe that was one of the longer-standing feature requests.
I also fixed the AUX1-2 output for Pixracer, which will allow you now to control a gimbal or similar through the manual pass-through on channels 5 & 6.
To give you some background I map proffessional and @bchristal manufacturers mapping plans. We are trying to figure out if we can switch over to PX4 permanently because it looks like you guys are making some great software.
Attached is a quality reports screenshots that show blue and green dots which is the difference between geotagged shutter location and calculated shutter location. These dots need to be overtop each other as much as possible as you can see there is a lot of space between them without camera feedback. This kills overall accuracy of the system and can easily render RTK useless for mapping because the shutter error as seen in the pic below which is out 3-5m. I do not know if the lag is from the camera or on the signal conversion from analof to digital with PWM triggers. Either way a proffessional system canot have that error because even DJI with integrated cameras on phantoms gets the correct location and both dots line up. Shutter correction is critical and I hope the feedback methods will be supported in PX4 as part of the legacy PWM supp
ort.QR report.pdf (2.0 MB)What is odd about this plot is that the error is not constant. It varies quite a bit. Assuming the software measuring it is accurate, that would indicate there is a variance in the shutter release timing. Is the camera set to manual focus and exposure? If yes, what system did you use to take these photographs? That is, what hardware triggered the camera and what software issued the trigger commands? Iām also assuming the plot deviation was computed based on geographic features rather than some timing metadata?
Heres the difference on a phantom 3 which is much better results since DJI knows when there cameras trigger.
Here the error is virtually constant, as I would expect from a digital system.
That was using APM flying about 16 m/s with a seagull trigger cable and sony wx500. This is the issue we get with these PWM trigger systems on APM and the we eliminate it using the camera feedback system. When mapping we use auto exposure mode on bright days and shutter priority on cloudy days for best results. The camera feedback system eliminates all of the issues and the dots line up correctly.
My guess is that if you use manual focus and manual exposure, you would have zero errors and no need for a feedback system. The variance in error is caused by the camera focusing and computing exposure. I donāt see a reason to have automatic anything on these. Turn off all āautoā anything. Just have the lens set to infinity, the aperture down a few stops to minimize edge distortion and calibrate the sensor sensitivity (ISO) accordingly. Unless you are shooting during a solar eclipse, there canāt be enough light variation to require adjustments.
@Justin_Cooper @dogmaphobic Letās move the camera discussion here: Camera Interfacing & Triggering
There have been plenty of studies on this topic and the results are always the same. If your not shooting in one of these two modes your results generally turn out visually very bad when compared. We always want focus set to infinity when mapping. Thatās why APM had such a big push for the feedback systems.
For all non-camera people: Iām not aware of big open issues or significant missing features for the 1.3.0 release. If you think something is still wrong, please raise it. Otherwise please help us test as much as possible and share your experience and log files.
I did some flying yesterday which ended in a Fly Away I had to terminate using the Kill-Switch. No major damage to the copter. I assume this was caused due to improper mounting/calibration of the Flight Controller combined with a loss of GPS Signal Quality. Iāll maybe have the chance to test again tomorrow.
@LorenzMeier Iāll send you the link to the UAVentures Log file, just in case.
