Cam1 and Cam2 Triggering with Pixhawk 6c

Hey guys,

I’ve got a hexacopter with a Pixhawk 6c onboard. I’m currently running Copter 4.5 (dev) as I need bidirectional dshot for harmonic notch filtering (the copter does get high vibrations, but they are manageable).

I’m trying to trigger two cameras I have onboard - a MicaSense Rededge-P, and a FLIR Vue Pro -R.
I have Mavlink communication to both of them successfully. I can trigger a capture via their respective mobile device apps, and those captures are getting geotagged.

However, I’d like to trigger both of them. I can’t tell what Cam1 and Cam2 trigger - I don’t know the corresponding physical ports. I have connected an aux cable to Servo1 (IO PWM Out) on the Pixhawk, and I’ll get occasional captures with the Rededge-P. But I can’t get the FLIR to capture, despite following the Ardupilot docs on it. Does this have something to do with the Dev firmware I’m using?
Here’s my params:

Both cameras are wired up in parallel, and they share the same Aux and Telem port for Mavlink and PWM communication. I’d like to trigger both at 0.6s capture interval.



I think it would be good to split the problem into two and test each camera separately and ensure they’re working before trying them together.

I guess that neither camera has a built in GPS? If they don’t have GPS then because the images are being geotagged the autopilot->camera mavlink communication must be working (I’m sure you already realise this but just to state the obvious).

You mention that they share the same telem port which will work for the autopilot->camera mavlink communication (aka autopilot’s TX pin, aka RXD, aka device receive) but it may not work for the camera->autopilot’s communication (aka, autopilot’s RX pin, aka TXD, aka device transmit) because two cameras can’t both send on the same serial pin. I don’t know if either or both cameras actually send mavlink data to the autopilot but if they both do and try to send at the same time then you could end up with corrupted data. This is not dangerous (the vehicle won’t crash or anything) but the messages might not get through. The most likely mavlink data they would send is a message saying they’ve successfully taken a picture.

The next question is how are the take-picture commands accepted by the camera?. The AP FLIR Vue Pro wiki page (that I wrote a few years ago) says that a PWM input is used but it is also possible that the camera can be triggered using a mavlink message. I don’t know if there’s anyway to figure out which method is used for each camera…

Re the AP 4.5 camera and gimbal setup. If a PWM signal is used to trigger the camera then CAMx_TYPE = 1 is the correct choice. If MAVLink is used to trigger the camera then either CAMx_TYPE = 5 (older style mavlink message) or CAMx_TYPE=6 (newer style mavlink messages) could work. You’d probably have to try both to see. Remember that a reboot is required after changing CAMx_TYPE.

By the way, if a PWM signal is used to trigger both cameras then I think you’ll only need to set CAM1_TYPE = 1 (Servo). No need to set CAM2_TYPE.

Feel free to include a log file and/or parameter file if you’d like me to look into this further.

Txs for reporting this!

1 Like

I have used this camera setup for years. Micasense next to a FLIR Vue Pro.

I wired both cameras in parallel and connected the to the servo of choice out of the camera trigger output of the Cube.

I send the trigger to the FLIR using the Aux PWM input and set it to take a picture using the app.

I send the PWM trigger to the RedEdge , set up external trigger to short PWM, GPIO 1 to External trigger input. PWM Threshold to 1.5ms.

In mission planner I set the trigger PWM Push to 1900ms and Not pushed for 1000ms. The duration is 15 for 1.5 sec push. The FLIR needs a longer duration trigger to take a picture where the RedEdge does not, 1 second for the RedEdge is enough.

This has worked for years.

However just recently and currently I have a problem where I CAN trigger the FLIR camera just fine but not the Micasense camera. Normally the micasesne rededge sets up easy and quick, just a few settings to make and never an issue with triggering.

I have checked my wiring and its checks good. The other reason I know it works is as I trouble shoot this problem I changed the PWM type on the Rededge camera and app to Falling/rising edge PWM and I get triggers from the camera, I set it back to short pwm and the triggers stop. So somehow there is a valid trigger making its way from the autopilot to the camera, I just cant control the triggers. While in falling edge on the camera with the camera triggering I try to change settings in Mission planner to try and reverse or match the PWM Push/Not Push to try and get the triggers to stop, they don’t. Nothing I change in mission planner camera settings stops the triggers, I have to go back to Short PWM on the camera app to stop the camera from triggering.

I feel like this is a camera setting issue and not an autopilot issue. However just as I need to setup another drone with this trigger setup, mission planner can’t support the new firmware setup on the autopilot and the camera settings page is not working right…


Small update.

Spoke with Micasense, the sent me a new firmware version that is not posted. Currently firmware is 1.3.2, they gave me 1.3.3. The trigger works in short PWM however its opposite the FLIR camera. FLIR Triggers around 1900ms, the RedEdge camera triggers at 1100 ms and stops over 1500ms. I can’t find a way to reverse either the rededge camera or the FLIR trigger inputs… You’d think this would be standard now days but…

1 Like

Thank you all for the help!

I tried various settings, but now I have the two cameras triggering as they should. I will detail my complete setup in case someone else is attempting to do this.

I have a Pixhawk 6c flight controller. The FMU output is connected to a PM07 power management board, and is split out to the 6 motors (hex), and outputs 7-8 are connected to the two PWM inputs to the FLIR. Output 8 corresponds with PWM 3 on the FLIR. This output is also connected to the GPIO1 input on the Rededge-P. Both cameras are also connected to Telem3 for Mavlink communication. There are no important messages being sent back as far as I know, the important thing is that they receive geotags from my RTK setup on board.

Both cameras are connected to a buck converter that’s connected directly to the batteries. They receive 10v, which is in range for both cameras (the FLIR has the plug in converter attached). Grounds are carefully managed to ensure no loops are made, and triggering works consistently.

Arducopter (MP parameters):
4.5 (dev) firmware

Leave cam2 with defaults (disabled).
Servo outputs:

Telem 3 port uses Mavlink 1 at 57600 baud. Use the following params to allow system passthrough for geotagging: (

I use “CAM_TRIG_DISTANCE” when planning survey missions. I make sure to plan around the FLIR, as the PWM trigger still has a maximum capture rate of 1/sec. We tested this by walking around in the parking lot at different speeds.

FLIR Settings:
This has mainly been taken from @rmackay9 and their FLIR page: FLIR Vue Pro — Copter documentation

Other FLIR settings are by use case/desired image filters. We are using ours for agricultural photogrammetry.

Micasense Rededge-P settings:
Taken from the previously linked Micasense guide, and these two -
RedEdge Serial API

@Lawrence_Dennis I too contacted Micasense and am running on 1.3.3 firmware. If you try these settings I wonder if it might work for you?

That’s everything I’ve learned so far! We have gotten a successful orthomosaic using these settings. Now off to tune our copter better so that speed is consistent, RTL lands exactly on the pad, vibrations go down…

1 Like

I did get it working. It was the threshold in ms that needed to be adjusted. Once I did that and set the trigger to long PWM then both the REP and FLIR triggered at the same time.

1 Like

Thanks for the detailed write-up.

I have a Flir Vue (an old one) arriving within a few days and I hope to give it a test and update this wiki page if necessary.

If you think of any particular changes we should make the wiki to help users get the setup working more easily feel free to ping me here and/or raise an issue here… or if you’re feeling really ambitious you can raise a PR to change the wiki directly. No pressure though especially on this last one.

Hi @peterscache12,

I finally retrieved my Flir Vue Pro and attempted to set it up as described on the wiki but I found that the MAVLink interface does not appear to be working. At least the camera didn’t appear in Mission Planner’s connection drop-down meaning the camera is not sending heartbeats. I also found that pictures do not contain the vehicle’s location in the EXIF data.

I see from the screenshots you’ve very helpfully provided that you’re using the same version as I am, ver 3.3.2.

Can you double check that the FLIR is definitely recording the Location in the EXIF data?

By the way, there is another similar discussion here.

Hi Randy,

thank you for the info. I also contacted FLIR for their support but the only answer I got was this:

Hi Konrad,

I would suggest making sure that you are sending the right information to the camera via MAVLINK on the new Ardupilot firmware. Duo Pro R and Vue Pro R both have not changed in the past few years. The settings on the UAS App also should not have changed.

I can not help you with the correct settings for Ardupilot’s firmware as we do not work on that, I would contact them for that. On the camera side nothing should have changed.

You can also try using the antenna for the Vue Pro R and send data to that directly.

Best regards,

It worked years before so something must have changed. Either AP or FLIR firmware.

Hi @KadaverJoe,

Thanks for that extra info.

The suggestions to “try using the antenna” is interesting because ArduPilot supports NMEA output by setting SERIALx_PROTOCOL = 20 (NMEA Output).

Sadly I’ve got the Flir Vue not the Flir Vue R so there is no input for the GPS and the serial input conifguration options only list PWM and MAVLink.

I’ll probably give up on this old camera soon because there are new alternatives including the ViewPro and Xacti which actively support the ArduPilot interface.