Chat: reliability enhancements #1289
Conversation
rmackay9
force-pushed
the
chat-reliability-enhancements
branch
from
4ca1aef to
8365e5b
Compare
| @@ -26,6 +28,11 @@ def __init__(self, mpstate): | |||
| # keep reference to mpstate | |||
| self.mpstate = mpstate | |||
|
|
|||
| # a dictionary of command_ack mavcmds we are waiting for | |||
| # key is the mavcmd, value is -1 or the MAV_RESULT (e.g. 0 to 9) | |||
| # we assume we will never be waiting for two of the same mavcmds at the same time | |||
There was a problem hiding this comment.
You can't dis-ambiguate the results anyway! I've pushed for the addition of an "opaque ID" supplied in the COMMAND_INT message and returned in a COMMAND_ACK to fix that problem, but didn't ever get traction on it...
You can ensure you never send a second command of a specific type while one is outstanding based on your dictionary, 'though. You would then need a timeout as the ACK may get lost.
There was a problem hiding this comment.
ok thanks. The way the chat module works at the moment, the commands are only sent one-by-one and after sending it immediately waits for the ACK so there's actually no way for it to be waiting for two command_acks. It could still pickup the wrong ACK though if that ACK is in response to a similar command from some other sender... and your proposed change would help with that so I'm all for it.
BTW I could have simplified the dictionary down to just a single name-value pair but in python a dictionary is so easy to use I went with it.
rmackay9
force-pushed
the
chat-reliability-enhancements
branch
from
8365e5b to
316be97
Compare
rmackay9
dismissed
peterbarker’s stale review
I think I've addressed PeterB's requests.
|
Merged, thanks! |
|
Thanks!! |
This improves the reliability in a few ways:
I could squash down the assistant instructions to a single commit if this is preferred.
I've tested this and it certain improves reliability. Below is a typical test where the user asked it to takeoff before the arming checks cleared and it still managed to do it.