I am having a weird problem with writing my own pymavlink code. I have tried MAVProxy and that works ever time so I know that pymavlink, my PixHawk, etc, are all functional. The problem is that when I use my own pymavlink code it only works sometimes. Here is a fragment of what doesn't (always) work.
pCon = mavutil.mavserial(device=”/dev/ttyACM0”) #or whatver tty it shows up on
pCon.mav.param_request_read_send(1, 250, "RC1_MIN", -1)
rc1MIN = pCon.recv_match(type='PARAM_VALUE', blocking=True).param_value
This *does* work, sometimes, when it doesn't work, it hangs on the 3rdline. My question is why this doesn't work every time and how to fix it. It would be one thing if it never worked, but since it works sometimes I know it isn't the wrong component ID or something like that. Also, I can use MAVProxy just fine even after this fails. Any ideas? Thanks!
Replies
Don't use blocking code to communicate over an unreliable data link. It will always break! Add code to not block, and retry sending the parameter you are trying to set, if at first it does not succeed.
Thanks for the advice! However, I should have specified that when I was testing this I was doing it over USB which I would have thought would be reliable. Is it unreliable? Either way, I will try non-blocking.
Anything over a wire is unreliable. And even with lower protocol layers checking for corrupted packets, doing resends and all manner of things to make it like your streaming Netflix video feed is 'awesome' With a blocking socket, after a lower layer failure, it will just sit there. You won't receive a bad packet or any packet, and so be blocked.
Physical cables are more reliable than radio links, but they don't do what you want reliably :( As you have found.
The art is detecting when something fails, and issue a retry if that makes sense, not if it doesn't or just throwing the bad result away and moving on. or just giving up! :-o ( i mean in the protocol sense ;) )