Here’s a couple of items that would help with camera integration on the Reach. For the short term, could we add the ability to trigger a camera based on distance travelled as an option? The current period based trigger is ok, but being able to specify distances would be useful.
Ultimately, I’d like to be able to connect to a Solo (or any pixhawk) via Mavlink so we can capture the camera trigger command and fire off a shot (and use ground control planning software to setup the survey). This could be accomplished by either using a serial connection to the accessory bay connector on Solo or by connection to the Solo’s wifi network. Since I’m powering Reach with the accessory bay connector, that would be my preference as wifi problems wouldn’t cause an issue. Ultimately, if Reach was able to integrate USB communications with the camera, we could put the positions in the images if we’re doing RTK or write the exact time stamp in EXIF, making post-processing a little easier. Perhaps if we could integrate storage, images and logs could be copied to external storage.
Anyone have a better idea to integrate Reach with Solo for surveying? Others have used companion computers to interface, but since we’ve already got a Reach, why not use it?
You request is noted. We will not add the distance based, or mission based trigger to Reach as it is the work of autopilot to trigger the camera. A lot of work will be required on our side to complete that, while something like a Pixhawk can already do it better. Time-based trigger is for DJI users that have no other option to do precise mapping.
USB communication is something that we are exploring.
I would also be happy to see a distance based camera trigger. I am using a Reach M+ hooked up to a Sony A6000 to capture aerial images from a tethered balloon that is walked across the landscape. This has to be done in an area where no radio signals and no drones are allowed. Naturally, the time based trigger works but we must capture much many more images than we need to make sure we get what we need.
I had thought to create a distance based camera trigger using an Arduino and feeding it the position information from the Reach M+. This seemed quite silly though considering everything I need is in the Reach M+. It is really just a matter of calculating the distance from the last camera trigger and triggering again if this distance has been exceeded. I would be happy to help if I had access to the code
Doesn’t the Reach M+ trigger cameras? I am working on integration on manned airplane. No autopilot. If Reach M+ could trigger by distance I could drop the onboard computer required to trigger the camera. Of course I can use time but speed will vary, need distance. I could write small script on the Reach itself.
@wlcable Stay tuned! You are not alone and am working through this same issue right now.
I am glad to hear someone else would find this useful. I would also be interested in writing a script but I don’t see how that is possible. In the past, for an Arduino project, I did some distance calculations from GPS coordinates that worked out quite well.
How do you plan to run a script on the Reach itself?
However, Reach M+ support only the photo shooting on evenly-spaced time spans, and we don’t plan to implement the remote triggering. I believe AutoPilot is a better tool for it.
@tatiana.andreeva Thank you. However, for my project there is no autopilot. Just a camera, Reach M+, and a RPi. Can I get some guidance on the function and data structure for a logged event onboard the Reach M+? I can easily see the last timemark in Reachview but does not give you last position. I know its in raw file but is this best place to pull last event?
My Reach M+ is sending raw data over serial to the RPi of which it is being logged. Is there way to get an event of the Reach without postprocessing and generating an events file? Is it possible to push just an _events file through data stream?
I am not clear yet to my approach if I use the Reach only, I will have a little time to look around today. My thought was to to piggyback off the trigger command already in there but run some background math from the raw logs last event. I need to understand more of how an event is generated and saved from my questions above.
Else, I will run all commands from my Pi but would need the timestamp from the hotshoe at minimum. I can extrapolate position from just the timestamp.
At the moment, post-processing is the only way to get events data.
To calculate the time mark position, you need to calculate the position of the 2 measurements: one taken before and one taken after time mark recording. So, as it’s not implemented in RTK, you can get the time mark position with PPK only.
If you use a companion computer you could write a script which saves a interpolated position for the moment a pin was pulled down. Then you only need the RTK position from the Reach serial port and maybe a timesync (with the help of the time pulse pin and some magic, which might be the hard part you have to solve in any case)…
Plan is to trigger camera over USB from Reach from another application. The application will ingest location and time from the Reach itself. That application will use the Reach GPST as its masterclock. Camera will still be put on hotshoe to drive timemark for PPK.
The application will know when and where that picture was triggered. With a little background math it should then also know when to take the next picture. Time has not been on my side. Hope to return to these projects next few weeks.
