Pr camera capture driver

[DanielePettenuzzo]

This pr replaces #10295 because support was added also for the av-x board that currently doesn't have timer input capture available, therefore we are using gpio captures. This is not ideal but the goal is to get this merged and then do a second iteration where we add timer capture support for the av-x board.

[DanielePettenuzzo]

From previous pr:

This PR adds the camera capture driver. This can be used to receive a feedback from a camera after it is triggered (eg. sony hot shoe feedback). In this case we don't publish the camera_trigger message in the camera_trigger driver when we trigger the camera, but we publish when we receive the feedback from the camera. When geotagging images this will increase the presision in the geotag.

This can be also used to sync CV cameras with the IMU data for VIO or similar applications.

Currently only channel 5 on the FMU PWM outputs can be used for this driver. I still need to check on which outputs we can actually run this.

Some more tests will be done in the next days.

Params for testing:
CAM_CAP_FBACK = 1 (enable camera capture)

CAM_CAP_MODE =
0 (get edge timestamp)
1 (get pulse midpoint timestamp for active high triggers)
2 (get pulse midpoint timestamp for active low triggers)

CAM_CAP_EDGE =
0 (trigger on falling edge)
1 (trigger on rising edge)

CAM_CAP_DELAY --> delay between image integration start and strobe firing (default to 0)

[DanielePettenuzzo]

@dagar this was tested yesterday on the av-x board and on a pixhawk 4.

[dagar]

I need to better understand the overall design, but reaching into other modules params is something I'd like to avoid.

[DanielePettenuzzo]

@dagar I agree. The reason for this is because when the camera_capture driver is active I rename the topic name of the camera_trigger driver so that the camera_capture can publish the camera_trigger message (which is the one that goes to the geotagging and to mavlink). Do you have any idea how this could be cleaned up? In any case, even if we want to keep this structure I think the parameter should be defined in the camera_trigger driver because otherwise this will cause issues on the targets that won't have the camera_capture driver in their cmake.

[dagar]

There are some minor things, but this looks safe to merge and we've been sitting on it for way too long. I'll merge now and we can continue from master.

[jasonbeach]

@DanielePettenuzzo I'm looking at this again--so for I've built what's on master and completed a basic test it seems to work. It looks like the autopilot should publish a camera_capture message in response to the pulse. How do you access that message? If I run mavros the only related message I see published is the cam_imu_stamp message. I will also try to help out with the docs so this can get pushed into a release.

[jasonbeach]

I guess just to be clear, it looks like the camera_capture driver publishes the camera_trigger message which the camera_feedback module subscribes to and then looks like it should publish the camera_capture message. Couple things I see:

1. the camera_feedback module doesn't run by default.
2. from the mavlink console in qgroundcontrol I can start it but even when I do the camera_capture message doesn't appear to be getting published. (It doesn't show up on uorb top)

[AlexandreBorowczyk]

I have a quick question and it seems like the most likely place to get the answer.
Why in the following section, only one input capture is defined? what happens of the otherone?

https://github.com/PX4/Firmware/blob/dcfe226638c8d50a42f30c1c50f8c5ca4a000060/src/drivers/px4fmu/fmu.cpp#L358-L370

[davids5]

@AlexandreBorowczyk - It is a mistake. There needs to be a

`up_input_capture_set(6, Rising, 0, NULL, NULL);`

added.

[AlexandreBorowczyk]

Alright Thanks for clearing things up!

[bys1123]

Will this have a document? @hamishwillee

[hamishwillee]

@bys1123 One can only hope that @DanielePettenuzzo will find time. I've got a placeholder for it: PX4/PX4-user_guide#604