We need a TRIGGER command for fixed wing aerial photography/survey work.

Why?

The current method of camera shutter control is start/stop only. (DO_REPEAT_RELAY, DO_REPEAT_SERVO don't work.)
Start/stop control only works if the camera has an intervalometer mode.

Start/stop shutter control makes geo referencing hit or miss at best.
There is no feedback during the flight that the shutter has been operated.

For fixed wing aerial photography/survey work we also need a stabile platform to assure the proper orthographic pointing of the camera. Joystick control could point the camera off axis if needed.

A camera platform capability is available with the released ArduCopter firmware but not for the ArduPlane.  ArduCopter also needs a TRIGGER command.

The trigger event should be recorded by the internal log file so it can be directly associated with the GPS position, time, and airframe attitude for accurate geopositioning.

The Mission Planner should log the event and the event should be downloaded as part of the data stream. There could be a flash or marker on the Flight Data path display and a verbal announcement of the occurrence.

A trigger could be used to snap a camera shutter, start/stop a movie recording, drop a water bottle or marker, pop a parachute in an emergency, etc.

The trigger should be able to be fired from the ground by the user (via the Mission Planner) or by the APM's WP file at timed or distance intervals between designated waypoints.

Here are some suggested programmable attributes of the TRIGGER:

1) Trigger mechanism:
   If actuation is by a servo - set the servo port number.
   If actuation is by a relay - set relay reference.
   If actuation is by a logic level - set output reference.
2) Duration:
   The duration of the trigger in milliseconds.
3) Interval:
   Choose time in sec. or distance in Meters

The TRIGGER and Stable Platform attributes could be defined by the Mission Planner on the Configuration page. Maybe added selections after Antenna Tracker.

The trigger actuation could be set by the Mission Planner - Flight Planner on the Waypoints Command Line.

I have more specific suggestions for the trigger parameters and command line definitions.

Views: 3946

Reply to This

Replies to This Discussion

This is absolutely critical and is the key to unlocking the real potential to doing some serious mapping with the AruPlane.

In addition to the above requirements, I would add that the trigger routine, would be very useful to have multiple routines available (Trigger for Camera and Trigger for Parachute/item deployment). Both would be around a selected GPS coordinate.

Regarding the generation of GPS camera trigger positions, it would appear that the GCS is almost there. Having the camera calculator tied to the Grid calculations should make it straight forward to automatically generate the waypoints for camera trigger locations only. In otherwards, the plane flies between the two existing waypoints that form the photo line and the camera triggers at the closest point that it gets to the camera trigger GPS coordinate.

 

This is certainly one of the holdbacks that I see to doing some real useful things with te AP and GCS.

This seems like such a fantastic system so far, and just a little more to go to really turn things up!!

I too would like to see this implemented. I just purchased a GentLED to trigger the shutter on a Canon DSLR. While it works, it is hardly cost effective when all we need is a contact closure. As nearly as I can determine, the GentLED has a very small 555 timer configured as a pulse width detector that can be connected to one of our channels. Since the Arduino is already decoding specific pulse widths, this should be relatively easy (for a knowledgable programmer) to do.

Irvin,

Ideally, I'd love to be able to have a control panel that would allow me to associate trigger points with PWM... Something like trigger 1700 at WP1, trigger 1400 on arrival at loiter point, home, or fly-to point.

I'd also like an interactive panel that allows me to do this in-flight when I wanted... Right now I am planning on adding a parachute recovery system - that would make this easy.

Best case would be a GUI control panel, not as good but acceptable would be a segment of code (normally commented out), perhaps nested in the medium loop, that could be enabled and modified to provide the functionality on a conditional basis.

Even a "Ardupilot Servo Control for Idiots" guide would go a long ways...

Any takers?? If my wife wasn't constantly bringing up how expensive this activity is I'd consider offering a bounty...

+ 1 for me, Great idea, I am also waiting for Arduplane to integrate camera features like Pitch and Roll stabilization. I am currently building a slimline Pitch/Roll gimbal for a Canon P and S camera for Ortho work.

It has been mentioned that you can download the AP_Camera branch from the GIT repository to add it to Arduplane, has anyone had any success with this? I downloaded GIT, tried to make the code, but didnt get very far with mt limited programming skills! 

Following this thread closely.. 

Richard, and all interested in getting a TRIGGER Comand,

I could not get the AP_Camera branch properly installed either.  I even tried to manually transfer the ArduCopter sketches that had camera references to ArduPlane.  I just don't know c++ well enough to set all the global and local variable declarations properly or recognize the error messages when the compile fails.

The proper implementation of TRIGGER will require Michael Oborne's efforts to provide the needed Mission Planner interaction.  Even if we could get some of the AP_Camera code working (basic "start  clicking the relay/servo now - every 2.7 seconds"  "now stop".) we would not have the ability to fire the shutter from the ground or, most importantly, not have the event captured in the log files.

We need the developers to sign on for this very important, but missing, capability of a very good system.

 

The old Flyer, I completely agree, this functionality would be a great addition to Arduplane, I did post a few days ago on another thread to see if there was any sort of release date for this, as I know they have a beta in the testing phase. that was back in December. I know a someone who is familiar with the C language, so may ask him to help. The instructions on this page seem to relate to Arduplane, so i don't quite get why the instructions are on the wiki, but are so difficult to get installed. 

Fingers crossed it won't be long to wait!

Richard, and others,

Here are some ideas I had about a way to implement the TRIGGER:

These TRIGGER attributes could be defined by the Mission Planner on the Configuration page.
Maybe an added selection after Antenna Tracker.

Parameter: Values
TRIGGER_SERVO 8 Port number of trigger servo
TRIGGER_RELAY 1 Relay reference (0 if no relay)
TRIGGER_LOGIC 2 Logic level port or reference number (0 if none)

TRIGGER_DURATION 25 active time in msec.
TRIGGER_REPEAT 1 0=single trigger 1=distance in Meters 2=interval in time (sec.)

Trigger actuation could be set by the Mission Planner on the Flight Planner Waypoints Command Line:

Command                V1   V2   V3   V4   Lat   Long   Alt.
DO_SET_TRIGGER  0      0     25    -      -       -       -    V1 1=Servo, 2=relay, 3=logic level
                                                                                  V2 if servo - 1900 servo on ms
                                                                                   if relay - 1=on triggers 0=off triggers
                                                                                   if logic - 1=high triggers 0=low triggers
                                                                                  V3 =repeat interval in Meters or seconds

The stable platform attributes could be defined by the Mission Planner on the Configuration page.
Maybe after the Trigger.

Parameter Values
Command Value
PITCH_PORT 6 Port number of pitch camera servo 0=none
TILT_PORT 7 Port number of tilt (roll) camera servo 0=none

PITCH_DIRECTION 1 0=reverse rotation 1=normal rotation
TILT_DIRECTION 1 0=reverse rotation 1=normal rotation

PITCH_GAIN 500 1000 0=no rotation 1000=max rotation
TILT_GAIN 500 1000 0=no rotation 1000=max rotation

PITCH_MAX 1900 Max PWM
PITCH_MIN 1100 Min PWM
PITCH_CTR 1500 Center PWM

TILT_MAX 1900 Max PWM
TILT_MIN 1100 Min PWM
TILT_CTR 1500 Center PWM

PIDs may be needed for precise control of the stabile platform.
Joystick control should be available for other than nadir pointing.

I will be on vacation 'till May 23.  Hope you can make some constructive headway on this issue.

Thanks,

Irv

http://code.google.com/p/ardupilot/wiki/SpecialEvents

 

Is this what tou are looking for?

 

or this http://code.google.com/p/ardupilot-mega/wiki/Python

 

not sure how they work - i need to sit down for hours and work things like that out! just thought they may be useful

I spent 5 hours testing the Mission Planner 'Take Off', 'Do_Repeat_Servo' and 'Land'.

I managed to get them all working quite nicely' though watching a plane land by itself is scary.

The 'Do_Repeat_Servo' is the second line in the Plan and I set it to Servo 5, PWM 1990, Repeats 900, Delay 2 sec.

This has the effect of triggering the camera every 2 seconds for the whole of the flight.

My only problem is I can't turn the 'Do_Repeat_Servo' off at all.

Has anybody done this?

I'm interested in making a very light camera design optimized for ortho photo acqusition. My interest is sub-centimeter resolution in urban areas. Ideas include:

  • Using a real time optical flow algorithm to provide adaptive image capture. The constraint could then be e.g. 60% overlap independant of altitude, FoV and speed over ground. This would eliminate the need for an external trigger.
  • Close integration with a WAAS capable GNSS reciever for accurate georeferencing to be included in compressed image meta data.
  • I'm considering to use a secondary synchronized upward looking camera with >180 degree FoV for detecting the position of the sun. Together with the GPS time, this could be used for very accurate estimation of the direction of gravity. Maybe IMU precision is precise enough (?) Just an idea....that of course will not work when there is no sun...

I'm currently exploring different CCD and CMOS image sensor options. This is a tough trade-off between price, availability, engineering time, sensitivity, dynamic range, colour separation, near infrared capability, sensor area, power requirements.....

My goal is to have a robust a fully automated image rectification software pipeline that outputs mosaics with a suitable (?) georeference accuracy.

If any of you are interested in joining this specification work, then I'll be more than happy to hear from you.

It would of course also be interesting for me to know if anyone would be interested in this kind of hardware product?

You don't need all that.  Take your pics, stitch together, align one point with google earth, and you're done.  It's not all that difficult.

Accurate (cm level) georeferencing is essential to my application and I also need a fully automated image rectification pipeline.

It's an interesting idea to use image features found in e.g. public online orthophoto as a pseudo ground reference. The obvious disadvantage is that you don't know what the accuracy will be, but if you dont care about accuracy, then you are clearly less troubled man :-)

Reply to Discussion

RSS

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service