Vehicle: keep commands in list if in progress #10850
Conversation
Signed-off-by: Julian Oes <[email protected]>
We should not remove commands from the command list when we receive an IN_PROGRESS ack because we should eventually receive a final ack. Signed-off-by: Julian Oes <[email protected]>
|
Ah, glad you're doing this; I was looking at changing the ArduPilot-specific calibration stuff to use this mechanism.... |
| @@ -3254,7 +3254,10 @@ void Vehicle::_handleCommandAck(mavlink_message_t& message) | |||
| int entryIndex = _findMavCommandListEntryIndex(message.compid, static_cast<MAV_CMD>(ack.command)); | |||
| bool commandInList = false; | |||
| if (entryIndex != -1) { | |||
| MavCommandListEntry_t commandEntry = _mavCommandList.takeAt(entryIndex); | |||
| // We remove the command from the list unless it's still in progress. | |||
There was a problem hiding this comment.
While in progress, are retries handled correctly?
|
Beat is correct. Supporting this is more involved than just the list management. I'll take a look. |
|
There are also big problems with how MAV_RESULT_IN_PROGRESS and progress values were plumbed through Vehicle::sendMavCommandWithHandler. Given the fact that any command can start to send IN_PROGRESS before sending an ack, all callbacks from Vehicle::sendMavCommandWithHandler as currently implemented need to handle IN_PROGRESS specifically otherwise they will break if the command ever sends that. |
|
I should have a pull which cleans this all up in a day or so... |
|
Closing this. Thanks @DonLakeFlyer for #10852. |
We should not remove commands from the command list when we receive an IN_PROGRESS ack because we should eventually receive a final ack.