Pixhawk + Reach + Sony QX1 : Camera Trigger Sync

Howdy, I have just order a Reach GPS to use with my Pixhawk 1 for mapping. I’d like to use my Sony QX-1, but gather that getting the camera trigger synced with the Reach in not straight forward. I have read all I can find on this issue and so far it seems that the only solution is from Event38. I have sent them a email asking about cost (sigh…). I’m just wondering if there are other solutions out there?

Currently I use a camera trigger from Seagull UAV : Seagull #Map2 (Seagull #MAP2 - UAV / Drone Camera Trigger) to interface with my Pixhawk. Works well, but I don’t have a clue whether it will work with the Reach GPS…

Any ideas?


1 Like

Check out this forum post

I have been in contact with Event38 and yes to get my camera modified is $400. It seems to be the only solution, at this time, that does a precise timing sync between camera trigger and raw gps data. Ya, is it worth $400? I’m thinking on that. The trouble is that for taking high quality photos, in landscape orientation, in my Skywalker or Skyhunter the QX1 is the only solution that I know of. The other option is to switch to a plane like the monster Skywalker X-8 and then use my NEX-5 with the hot shoe shoe trigger cable from Tuffwing.

1 Like

Hi Peter,

Yes, unfortunately there are no companies manufacturing large sensor cameras that meet our needs.

Are you aware of the QX1 automatic image rotation issue? I’m not aware of anyway to automatically rotate the images back to landscape orientation after downloading. If you are flying large areas or many flights in a row where you are generating lots of pictures, this can be somewhat of a pain.



You can use your Nex or RX100 on your Skywalker.
First I did a rectangle hole on a side so the camera can stay inside in landscape position. Very few of the cam is outside and its easy to protect.
Secondly I fixed the camera under one wing, Approx 10 cm away from fuselage. I found this solution better as there is no need to have extra hole on bottom, and the relative high position is protecting the camera from dust and debris during landing.
Just put some 50g weight on other wing extremity for balance.

1 Like

Hi Steve,

Ya, this summer I have some REALLY big areas to fly. I’d like to use the QX-1 and right now I am experimenting with the Seagull #map2 trigger with Pixhawk. When I get my Reach GPS I’m going to experiment with this trigger and see how far off sync is between trigger event and GPS time stamp.

What I’m also wondering about if all this worry about sync is justified. I might be thinking wrong, but having a precise time stamp capable of giving a few centimeters accuracy, would only be valid if one’s camera is near perfect nadir angle when acquiring photos. For example, at 100m if the camera nadir is off by 1 degree then the camera center point would be offset 1+ meter from the DGPS position. So it seems to me – to get say 10cm overall horizontal accuracy in a final orthomosiac – one would need to use a really well tuned 2-axis brushless gimbal. On my big hexacopter I have a 2-axis gimbal that gives me a few tenths of degree accuracy. So now I am using my 3d printer to design a 2-axis gimbal for my qx-1 for plane use.

This is my first attempt at DGPS in a drone so lots of experimenting and testing ahead! I plan on using some existing high accuracy 10cm orthophotos (from a Lidar survey), as well as surveying in a bunch of ground targets, for doing a series of flybys using the Reach GPS to determine what the reality really is. I’m realistically hoping that for large areas that an overall orthomosaic accuracy of sub-metre, without the use of ground control, is attainable. We’ll see. But I’m thinking that where the dgps potential will shine is with small site mapping using my hexacopter. Heck, I could always just hover over each photo point for a couple seconds to avoid the sync issue. That’s easier than laying out ground targets.

In regards to the auto-rotation of images in the QX-1 I haven’t done enough flying with that camera to see how much of a problem it is. If it is a problem then I will crank out a C++ program to automatically batch rotate portrait images. Not a big deal.

Sort of went off topic here…


From my previous post I think it will be necessary to use a gimbal to take advantage of the potential of the reach gps for high accuracy mapping without using ground control. So the camera must reside in the plane and have room for a small gimbal. This is my journey! The QX-1 is perfect for this. I am also experimenting with the really nice and small 1st generation Canon EOS. The problem with this camera is that it can only be triggered using the tragic lantern hack and then triggering via the mic port on the camera. I still haven’t got this to work with Pixhawk.

Now I’m wondering if a plane like the UAV Talon might have the room I need. I’m amazed no one has yet designed a plane with a wider body to help us mappers!

So have a look on new Skywalker Eve. Very wide.

1 Like

No need to do c++ coding, rotation is just an information on exif. Write a batch script with exiftool embeded and you solve your problem !

1 Like

When you are doing stitching in Pix4D/Photoscan, software is able to determine the parameters of the orientation with great precision. Much better than any commercial IMU or gimbal.

Time stamp is crucial bit to achieve centimeter-accurate results.

1 Like

Sync is extremely critical if you are planning to map without ground control and want horizontal accuracy. No need for a nadir camera, it is just a waste of weight to add a camera gimbal. Unless you are doing video or oblique pictures.
Many people, including us, have already achieved a few cm error without ground control targets.

Yes, auto-rotating images is very simple with some simple coding. The hard part is know which way to rotate the image so you get it back to correct. There is no way to “read” in the EXIF data how the QX1 rotated the images from landscape. It assumes you wanted to rotate the images based on the camera pitching/rolling with the aircraft. I suppose a gimbal could fix that issue with a multirotor… but with a plane, the bank will exceed a gimbal in turns…

If you want a plane with lots of room, check out the Drak from Ritewing. Or, any of the airframes from Ritewing.

Good luck!

@igor.vereninov and @cczeets
Very interesting! Oh, I like this! So you are saying that when the orientation of the a single frame is determined, that these programs in essence are able to reproject the images to nadir, thereby making that time stamp critical. I guess I am suffering from self inflicted bias from years of working with satellite and traditional aerial frame imagery. Never to late to change!.

So now you have me thinking that a simple 1-axis roll gimbal, for a plane, might be a nice compromise. Or as you suggest, no gimbal at all.

So it’s looking like my best use of money and time will be to spend $400 to get my QX-1 modified.

I’m getting excited at the prospects. My Reach GPS is in the mail, so hope to start test soon.

Thanks, I’ll take a look. I am not familiar with the exiftool. I suppose that there is a tag to indicate Landscape or portrait orientation?

Thanks for the info!

The programs are not necessarily able to reproject the images to nadir… but, they are able to determine the attitude of the aircraft with similar precision to the expensive imu in traditional aerial frame imagery. Also, the SfM software is far superior to traditional aerial frame imagery software when it comes to ties points between images. This helps with the attitude determination and overall accuracy.
If you are using a multicopter, I would suggest not using a gimbal.
If you are using a fixed-wing, you could use a roll gimbal. Although, we don’t use a gimbal with our fixed-wing. It depends on the fixed-wing you choose and how much it’s susceptible to the wind.
If you are set on using the QX-1, then you definitely need the modification to get accurate data. Let me know if you find a way to determine which way the image needs rotated back to the correct position.
Yes, the EXIF will tell you which way the image is rotated (i.e. landscape or portrait). But, it won’t tell you how that rotation is related to the original orientation of your camera (i.e. it doesn’t say -90 or +90).


Thanks for the interesting info on gimbals. I obviously have to do some testing. On my large hexacopter I have a nice 2-axis gimbal so I can conduct some tests both with it on and off. I’m also flying more with my 3dr Solos (love these things!!), so nice to know I don’t have make a gimbal for that (although I still have no GPS solution for PPK), In regards to planes I have a mess of them. Currently experimenting with my trusted Skywalker 1900 and Skyhunter, although I just ordered a X-UAV Talon.

In regards to camera I am working with the Canon 5d2 (for big hexacopter), QX-1, Nex-5n and first generation Canon EOS (trigger not figured out yet), Mapir 2 rgb and gopro. I have to admit that I was amazed at the good results I got last fall using my Solo + gopro (blew me away).

Sounds like I need to start experimenting with the auto rotation issue with the QX-1…

I personally think a gimbal is quite a good thing for mapping. I started without and I have serious problems to mosaic all flights with a little bit more then no wind. The gimbal helped a lot to get next to nadir pictures even with wind and a uniform coverage over the hole area. Now mosaicing with Photoscan works great. I really wonder if I could skip the gimbal with my larger hexacopter but I think that is hard to imagine.

With precise time stamps and no gimbal, we can achieve a few cm accuracy without ground control. We have flown in 20mph winds and still get this accuracy. I’m not sure how a gimbal can improve on that?

1 Like

That is a very interesting information, I will try that. I actually would be very happy if I do not have to carry the very heavy gimbal around, that would save 700g… .
How do you avoid missing coverage when several images are “looking into the sky”? How much overlapping are you using when planning the missions?

We remove the images which have roll angles above what is typical.
The overlap depends on what you’re mapping and what you are trying to extract for data.

1 Like