Hover and capture: trigger image when vehicle is at rest

[Stifael]

The current implementation of hover-and-capture together with QGC is somewhat unfortunate because the camera trigger command is sent just before the vehicle continues to accelerate towards the next waypoint.

During survey (hover-and-capture), MAV_CMD_NAV_WAYPOINT(16) and MAV_CMD_IMAGE_START_CAPTURE (2000 ) are extracted from dataman as mission-items, where MAV_CMD_IMAGE_START_CAPTURE is consumed and sent out by the Firmware immediately after the mission-item that corresponds to MAV_CMD_NAV_WAYPOINT is reached. MAV_CMD_NAV_WAYPOINT is considered reached if the vehicle spent a certain amount of time within the acceptance radius (NAV_ACC_RAD), where the time is defined by the corresponding mission-item of MAV_CMD_NAV_WAYPOINT. Once the waypoint is reached, the mission will proceed with the next MAV_CMD, which is
MAV_CMD_IMAGE_START_CAPTURE that is just passed to the camera. The cycle repeats itself by moving on to the next MAV_CMD, which is the next MAV_CMD_NAV_WAYPOINT. Consequently, independent of how long the vehicle hovers at the desired waypoint, the trigger command and the acceleration to the next waypoint happens pretty much at the same time.

Especially for RTK solution, the current hover-and-capture implementation defeats the purpose of having accurate GPS information.

Desired behavior

The vehicle flies to a given waypoint. Once the vehicle reaches the waypoint and is at rest, the camera image capture will be sent out. The vehicle will not accelerate towards the next waypoint until it receives an acknowledgment from the camera.

Intermediate solution

1. tighten the criteria about when a waypoint is considered reached. This requires a simple change within the mission_block.cpp.
2. Either QGC or PX4 should inject another MAV_CMD_NAV_WAYPOINT after MAV_CMD_IMAGE_START_CAPTURE with the same settings as the MAV_CMD_IMAGE_START_CAPTURE that was set before MAV_CMD_IMAGE_START_CAPTURE. The hover-time would need to be split between the two MAV_CMD_NAV_WAYPOINTs.

Similar issues:
mavlink/qgroundcontrol#7486

[julianoes]

Notes from devcall:

Possible options:

• Wait for the camera ack before moving on. This would require quite some changes in the way commands and acks flow through the system.
• Add some sort of timer in navigator which leads to a delay (configurable by param) after a capture command has been sent. Probably the easiest but might be a bit hacky.
• Move functionality from navigator to a flight task. This would be more a longer term thing.
• Insert loiter/pause mission items in QGC survey generation -> let's get @DonLakeFlyer's opinion.

[DonLakeFlyer]

None of this can be done without new mavlink message. You want two things to make hover and capture work for real:

1. Wait until the vehicle stops moving before executing next command
2. Take picture, don't execute next command until the camera report image capture complete

Both of which are not doable with the current command set.

[Stifael]

@DonLakeFlyer

1. Wait until the vehicle stops moving before executing next command

Why should that not be possible? To my knowledge that is how most MAV_CMDs are excecuted, and certainly any kind of waypoint types. In fact, for hover and capture that is already implemented, the criteria are just very lose, but can easily be tighten.

The real issue with hover and capture is 2.

Take picture, don't execute next command until the camera report image capture complete

That is currently not implemented and is basically what I was asking. Julian just listed a few possible soultion, where some of them are obviosuly intermediate solutions.

Insert loiter/pause mission items in QGC survey generation -> let's get @DonLakeFlyer's opinion

Probably it is not exactly clear what is meant with that. Currently, the order of hover-capture is the following:
MAV_CMD_NAV_WAYPOINT__0 -> MAV_CMD_IMAGE_START_CAPTURE__0 -> MAV_CMD_NAV_WAYPOINT__1 -> MAV_CMD_IMAGE_START_CAPTURE__1 -> ...

To force the vehicle to stay at the curent location after image capture was triggered, one possiblity could be the following:
MAV_CMD_NAV_WAYPOINT__0 -> MAV_CMD_IMAGE_START_CAPTURE__0 -> MAV_CMD_NAV_WAYPOINT__0(or loiter) ->
MAV_CMD_NAV_WAYPOINT__1 -> MAV_CMD_IMAGE_START_CAPTURE__1 -> MAV_CMD_NAV_WAYPOINT__1(or loiter) -> ...

That is how I would do it as an intermediate solution if I were using MAVSDK. Can you explain why that would be a bad idea to do that in QGC?

Both of which are not doable with the current command set.

What kind of command set would you propose?

In the mean time I will implement the real hacky solution and add just a delay after MAV_CMD_IMAGE_START_CAPTURE since it is urgent on our side at least.

[DonLakeFlyer]

Why should that not be possible?

Is totally possible with a new command. I don't think you can change the behavior of the existing waypoint command to get that.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.