Once I fixed the
ticks_per_meter error, I could drive Phoebe around by sending movement command messages to the
/cmd_vel topic. However, I could not do this for very long (sometimes minutes, sometimes mere seconds) before the Roboclaw ROS driver would crash with the following error:
File "roboclaw_node.py", line 232, in run
rospy.logdebug(" Encoders %d %d" % (enc1, enc2))
TypeError: %d format: a number is required, not NoneType
Once crashed, Phoebe no longer responds to movement commands, and that is bad. What’s going on here? The instance of
TypeError that brought the whole thing crashing down gives us a place to start: one of its
%d parameters (which could have been either
enc2) has a value of
None instead of a number representing encoder count.
Looking through the source code file, I could see that the encoder values were initialized to
None then replaced with an encoder count by a call to Roboclaw API
ReadEncM2. If this call should fail, there’s a
except block to catch the error, but that leaves the encoder value at
None, causing the crash I’ve experienced.
There exists an
if statement whose intention might be to avoid this crash by checking for existence of the variable, but I don’t understand how it would help. Encoder count variables would always exist since they were declared and initialized to
There are two parts to this problem:
- Why is the Roboclaw API call failing?
- If it fails, how can we avoid crashing on
Part 2 is easier so let’s address that first.
TypeError complains when the variables are not numbers, so let’s explicitly check for numbers. Looking through trusty StackOverflow found this method of checking for numeric values in Python, so let’s use that to guard against
This change would not address the root cause of API call failing, it’s just a band-aid to avoid fatally crashing and burning. When we fail to retrieve encoder count using Roboclaw API, our internal information become stale which causes more problems down the line. Problems like bad odometry calculations, which will cascade to more problems.
What we really need to do is to address the failing API call, which I’ll work on next. In the meantime this band-aid has been submitted via a pull request.