Say I would like to handle a mavlink command that requires long computational / IO time, also I only know if the command succeeded after the long computation / IO.
I suppose the first step is to return MAV_RESULT_IN_PROGRESS and then invoke my custom handle_msg() from GCS_Mavlink.
But I’m quite lost as to how to proceed.
Where do I put and invoke the computationally / IO intensive code? (obviously it can’t be in handle_msg since it would block the entire message handling)
How do I follow up with the correct MAV_RESULT (ACCEPTED / FAILED)?
Say I would like to handle a mavlink command that requires long
computational / IO time, also I only know if the command succeeded after the
long computation / IO.
I’m also interested in answers to such questions; in particular, things
like formatting SD cards or even the arming sequence can require
asynchronous ressponses.
I suppose the first step is to return MAV_RESULT_IN_PROGRESS and then invoke
my custom handle_msg() from GCS_Mavlink.
We don’t even have that in our common.xml yet
Any idea how that’s all supposed to work? When you attempt the command it
returns an in-progress and if you repeat the command it returns you a new
percentage? How about if a command isn’t idempotent? Do you volunteer a
mav-result-accepted when you’ve completed the task? What happens if
you’ve just finished the task and the user tries to poll the progress - do
you start it again immediately?
Where do I put and invoke the computationally / IO intensive code?
(obviously it can¢t be in handle_msg since it would block the entire message
handling)
That depends on what you’re trying to do. It might deserve its own
thread, or it might want to work like several of our libraries with a
::update() which does some of the work and then returns.
How do I follow up with the correct MAV_RESULT (ACCEPTED / FAILED)?
Those are all interesting questions. Maybe there’s some documentation
around somewhere about how in-progress is supposed to work…
I am dealing with an idempotent commands currently
My naive implementation is on receiving the command, I return IN_PROGRESS.
If the command succeeds, all subsequent commands will return ACCEPTED
If the command fails, since my system only allows me to retry every X seconds, subsequent commands within X seconds will return FAILED, commands that come after X seconds will trigger a retry and return IN_PROGRESS
I thought of adding an internal “is_read” flag to track whether the current ACCEPTED / FAILED status has been read or not and trigger retry using that, but I haven’t implemented that yet.
Another solution I thought of is have the command status come in as a data stream which should be a cleaner and more robust (though potentially overkill) approach
Obviously lacking, but I hope this can help trigger discussion
