On January 9 my partner, Gus Calderon and I, completed a successful aerial survey mission that covered abut 900 Meters by 650 Meters.  The results was a very high resolution picture of the area.

The aircraft:  Graupner Kadett

Motor:          Extreem Flight 2814T/820

Prop:            APC 13 x 6.5

ESC:            Hacker X-55

BEC:            Castle Creations 10 Amp

Servos:         4 ea.  Hitec HS65MG

GPS:            MediaTek

Telem:          XBee 

Battery:         Turnigy 3300 mAh nano-tech 25-50c

Autopilot:      APM1 Version 2.27 (Loaded via Mission Planner)

GCS:             Mission Planner Version 1.1.17

                     Mission Planner's 'Draw Polygon' and 'Grid' were used to generate the waypoint file. 

Camera:        Canon SD1100is with CHDK control (via relay through the camera's USB port)

Shutter:         1/1000 sec.

Aperture:        f/2.8

Focal Length: 6.2 mm

ISO:              320 

Stitch software:   ICE  (Microsoft Image Composite Editor)  PTGui was also used but it requires a lot of manual intervention.  It can give better picture placement than ICE.

Some stats:

The plane flew at 100M AGL, 10M/sec ground speed.

The flight lasted 17 min. and used 65% of the battery capacity.

There were 13 passes, 25 Meters apart.  The camera was turned on at takeoff an took a picture every 2 sec. for about 24 exposures per row.  556 exposures total.

The really good results:

APM did a very good job of controlling the aircraft.  (Look at the .kml flight path.)

The Kadett performed flawlessly.  Great payload capacity, strong, spacious structure, good endurance, has a short turn radius, and it is a very pretty airplane.

Resolution of the pictures is so good that the placement of irrigation valve covers (1.5 foot square or less) could be identified.

The not so good (but fixable) results:

The spacing of the rows was too close, we got too many pictures.  A lot of hand picking of the images was required to render the final stitched picture.

The camera took pictures every 2 seconds (set by the internal capability of the camera).  That was too many.  A bit too much overlap.  We used every other row for the stitch.  That was 7 rows of 24 pix or 168 images.

The big problem:

The APM directed the Kadett very well.  The Mission Planner provided a very easy way generate the waypoint file.  The XBees kept us informed about critical aspects of the flight.  Log files were generated and saved.  Thanks to all members of the development team. A job very well done.


There is little or no payload management capability with the current APM/Mission Planner system.

I have managed to turn the relay on and off in the past but it doesn't work with APM V2.27. (I submitted issue 479)  


In March, I submitted issue 292   'Add a command TRIGGER'

To trigger a camera shutter or any other event driven payload (water drop, parachute, etc.) please add a TRIGGER command.
It should have these characteristics:

Use either the relay or a servo
Configurable active state (relay on or off to trigger - servo on pulse width and off pulse width)
If servo - assignable channel
Assign time the trigger event is active (in ms.)
Choose if trigger is to be repeatable
Choose and set the repeat interval (every x seconds or every y meters)

The TRIGGER event should be logged for both the onboard log file and the GCS stream
The TRIGGER event should be able to be fired from the GCS

In October there was this reply:

Comment 4 by project member amilcar....@gmail.com, Oct 11, 2011
Part of it has now been implemented in the "APM_Camera" git branch:
-Use either the relay or a servo
-Configurable active state (relay on or off to trigger - servo on pulse width and off pulse width)
-Assignable servo channel
-Assign time the trigger event is active (in ms.) (via define only)
-The TRIGGER event should be able to be fired from the GCS

What is not implemented yet:
-Choose if trigger is to be repeatable
-Choose and set the repeat interval (every x seconds or every y meters)
-The TRIGGER event should be logged for both the onboard log file and the GCS stream

Please note:

APM_Camera is not in the git directory and is not in the latest arduino sketch file set.


The existing DO_RELAY and DO_SERVO commands do not work if instantiated through the Mission Planner. 


Even with no APM control of the camera we were able the get these results.

The waypoint file generated by the Mission Planner

The flight path as captured via the Mission Planner .tlog and converted to .klm

The survey picture stitched with ICE.

Again,  a big thanks to the development team. 

Views: 8464


Reply to This

Replies to This Discussion

nice presentation.. marvelous job done

very cool! i would love to implement the trigger control for the camera, right now we are using CHDK w/ interval scripts. your idea is much better. awesome flight platform! i've found with a large enough image overlap and enough computing power you can build mosaics automated

awesome i like the idea of the trigger function i hope they do that soon

Hi all,

I am also looking for the best way to send trigger commands to my camera (and configure and aim it). 

I noticed that the MAVLink commands for camera control and mount control are actually implemented in the mission planner. I am however unable to find/identify whether (and if so; how) this works (sending cam / mount commands from the mission planner). Would filling in the parameters in these commands arrive in the Ardu code?

Can anyone (Michael Oborne? :)) explain more about this?

Thanks a lot!

I sent in 2 enhancement requests today.

Issue 574:   Please add camera stabilization to ArduPlane.


Issue 575:   Please add a command set to trigger a camera. See issue 292.

Very well done. I am also building up a mapping UAV using the Ardupilot Mega. I have used some more expensive AP stuff in the past, and am really enjoying the capabilities of this AP for aerial mapping purposes... so far.


I have been searching the forum for successful mapping configurations and you appear to have done an excellent job!!


Some triggering elements would be very great additions. along with automating the camera trigger GPS location in the grid calculations. I might be missing something, but this seems like a natural addition to the Mission planning tool. That way you could plan camera shots per GPS waypoint vs camera triggering every X seconds.


Again, well done and Cheers!



Great job! 

I am curious if you have made any improvements in your stitching.  I am getting ready to do the same type of mission and am trying to find the best way to stitch the photos together.  I noticed in your picture the lines from the ball fields were quite off and the road in one spot.  Did the other program work better? 

Don't misunderstand me I think it is great, just wondering if you found a way around that.


I used some  manual intervention with PTGui and got this result:

I also submitted the database to the dronemapper as part of the beta testing of the service and got this false color result:

I have a question which although unrelated is certainly implied by this thread and others. 

My understanding of current FAA policy (http://www.faa.gov/about/initiatives/uas/reg/) is that the FAA currently doesn't allow any commercial UAS applications without getting an airworthiness certificate. 

And that if you claim to be operating under 91-57 (hobbyist, <400 ft agl, line of sight) that you really can't sell your services (or even the pictures that you yourself took) commercially.

Of course FAA policy doesn't really matter if you've just got the mojo to go out and build an excellent aerial photography and surveillance system, which it looks to me like you are doing a great job of!

But if you're planning on making a real business out of it, won't you eventually run into the slight problem of it being against the law?  At least until the FAA changes the laws?

Thanks for any insight.

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service