Many intermittent failures with serial packet
Posted: Mon Mar 04, 2019 12:05 pm
Reading encoders values fails intermittently.
I am using the ROS roboclaw_node Python node which makes calls to the python roboclaw driver. Specifically, it calls roboclaw.ReadEncM2() and roboclaw.ReadEncM1() 10 times per second. The Roboclaw is connected to a Raspberry Pi3b with a USB cable
I noticed that many times encoder values of "0" where being detected so I looked carefully at the code and see that the encoder value was initialized to zero then roboclaw.ReadEncMx() is called. If the function fails the value remains zero.
I changed this. with a "hack" Now I init the value to "1234567" and if after roboclaw.ReadEncM1() returns the value is 1234567 I log a warning and do not publish the bad data.
By experiment, I found that roboclaw.ReadEncMx() fails after big changes in roboclaw.SpeedM1M2(). roboclaw.SpeedM1M2 is called 20 times per second and works fine if every call passes the same speed values but when I make big changes (such as reversing the motors) I see a string of failed roboclaw.ReadEncMx() When it gets to failing, I see from 1 to 5 failed reads per second for a few seconds and then some tens of seconds of not failing
The diagnostic reads also fail and return error statuses.
But eventually, it gets worse...
After a while, the roboclaw become unresponsive to commands but recovers after I close the serial port, wait and then re-open it. Some time two cycles or close /open are required. (A power cycle always fixes the problem but mostly close-wait-open the port fixes it.)
EDIT: I've just determined that serial reads can hang "forever". This pretty much puts the roboclaw off-line
QUESTION: Is the roboclaw not able to process packet serial commands at the fill "wire speed" of the USB cable?
Could I be overloading the processor inside the Roboclaw. Have I uncovered a firmware bug?
Even if I write 10 bytes of data 20times per second that is only about 2Kbit per second
My next step is to write the simplest possible Python script that causes this same kind of failure.
Is there a software-reset command that I missed.
(BTW, roboclaw_node.py makes calls to the driver library but does not check status. I'll fix that and eventually a pull request.
I am using the ROS roboclaw_node Python node which makes calls to the python roboclaw driver. Specifically, it calls roboclaw.ReadEncM2() and roboclaw.ReadEncM1() 10 times per second. The Roboclaw is connected to a Raspberry Pi3b with a USB cable
I noticed that many times encoder values of "0" where being detected so I looked carefully at the code and see that the encoder value was initialized to zero then roboclaw.ReadEncMx() is called. If the function fails the value remains zero.
I changed this. with a "hack" Now I init the value to "1234567" and if after roboclaw.ReadEncM1() returns the value is 1234567 I log a warning and do not publish the bad data.
By experiment, I found that roboclaw.ReadEncMx() fails after big changes in roboclaw.SpeedM1M2(). roboclaw.SpeedM1M2 is called 20 times per second and works fine if every call passes the same speed values but when I make big changes (such as reversing the motors) I see a string of failed roboclaw.ReadEncMx() When it gets to failing, I see from 1 to 5 failed reads per second for a few seconds and then some tens of seconds of not failing
The diagnostic reads also fail and return error statuses.
But eventually, it gets worse...
After a while, the roboclaw become unresponsive to commands but recovers after I close the serial port, wait and then re-open it. Some time two cycles or close /open are required. (A power cycle always fixes the problem but mostly close-wait-open the port fixes it.)
EDIT: I've just determined that serial reads can hang "forever". This pretty much puts the roboclaw off-line
QUESTION: Is the roboclaw not able to process packet serial commands at the fill "wire speed" of the USB cable?
Could I be overloading the processor inside the Roboclaw. Have I uncovered a firmware bug?
Even if I write 10 bytes of data 20times per second that is only about 2Kbit per second
My next step is to write the simplest possible Python script that causes this same kind of failure.
Is there a software-reset command that I missed.
(BTW, roboclaw_node.py makes calls to the driver library but does not check status. I'll fix that and eventually a pull request.