trigger_control command not working

[maciejmatuszak]

In short: I am trying to access px4 (stock v1.4.4) running on Pixhawk(original hardware) via mavros to enable/disable the camera trigger it looks like the call fails on px4 side.

My setup: PX4 Firmware (v1.4.4) running on original (not a clone) Pixhawk. 2x USB to serial converters one for Telem2 (MAVROS) and other on Serial 4/5 for System console Initially I was running mavros on odroid but I move it to PC for debugging, same symptoms on odroid. System console works ok. The Mavros works ok as well I can connect QGroundcontrol (v3.0.0). there is number of warnings in the mavros log, not sure if those are related: [ WARN] [1474506787.825324587]: init: message from ASLUAV, MSG-ID 201 ignored! Table has different entry. - about 40 of those and then once QgroundControl is started there is endless stream of those: [ WARN] [1474506803.305721024]: PR: request param #11 timeout, retries left 2, and 440 params still missing logs attached. mavros_console.log.txt mavros-roslaunch-miner-gc-27467.log.txt

Originally the trigger failed when called from within ueye_cam package but it is easily reproducible with mavros commands: rosservice call -v /mavros/cmd/trigger_control 1 0 - to enable the trigger rosservice call -v /mavros/cmd/trigger_control 0 0 - to disable the trigger

I know the command message reaches the px4 stack, every time I try the command I can see the following in nsh shell: nsh> WARN [navigator] navigator: global position timeout

I traced the calls in mavros stepping trough the code. The message is sent to Pixhawk but the ack callback is never triggered and it times out after 5 seconds.

Here is example session from NSH: nsh_console_log.txt

My Conclusion:

• The DO_TRIGGER_CONTROL reaches the px4 but it fails without ACK
• the enabled/disabled status is correctly toggled
• the CAMERA_TRIGGER message (mavros_msgs::CamIMUStamp) is send or not depending on the enabled/disabled state
• the physical trigger line is not influenced by enabled/disabled status. once the RC is on the trigger is on all the time even if I switch off the RC. Should the trigger line be influenced by RC signal present or not?

my PX4 config: SUAV_01.params.txt

Maciej

[maciejmatuszak]

I decided to dive into PX4 code myself and here is what found. The VEHICLE_CMD_DO_DIGICAM_CONTROL message is handled outside the commander, so there is no easy way to send back the ACK message. I think proper solution would be to introduce new message for ACK between camera_trigger driver and commander. any opinions?

As for the dependency on RC controller I found solution by digging in the @mhkabir version of repository see this change to ROMFS/px4fmu_common/init.d/rcS file. It does the trick but I would like to understand the implications. If someone can point me into some doco or discussion what are the FMU_MODE and AUX_MODE ?

Maciej

[mhkabir]

If you're using pins 5 or 6, you shouldn't run into that issue, because rcS on master sets it to pwm4 (see below).

FMU_MODE and AUX_MODE set the operation mode of the auxiliary (AUX) pins. They need to be set to mode_none (trigger can use 1-6) or mode_pwm4 (trigger can use 5,6).

Regarding the ACK, you can simply ignore the return value of the ROS service call. It always succeeds anyway.

[mhkabir]

Also, here's our upstream ueye_cam driver which will ignore the ACK requirement (for now). There is also a lot of other stuff there, which you can rebase to remove : https://github.com/ProjectArtemis/ueye_cam

Commit from mavros which you'll need for completeness : https://github.com/ProjectArtemis/mavros/commit/31591da94492b85d5030c3db2d66b8cc2dda5a6b

Also, use this commit if you will be manually killing the camera driver and restarting it without a pixhawk reboot : https://github.com/mhkabir/Firmware/commit/bd7874df0fc37eeb07d936ea2dd14574baa6889c

This will reset the sequence to zero when a new enable command is received.

[AndreasAntener]

@maciejmatuszak there is an easy way to send ACKs. Have a look how the commander does it. It's done via uORB, nothing commander specific.

[mhkabir]

Clsoing in favour of https://github.com/PX4/Firmware/issues/6961.