NCARAI ~ Intelligent Systems
|NRL / Systems / ITD / NCARAI / ISS / Segway RMP / Development||NRL Resources|
Segway RMP Development Issues
In working with the RMP and the provided example interface code, we have found a few errors and quirks that must be considered.
Following are unexplained protocol issues:
The following is a known coding error in miranda/rmi_demo/mirandalink.cpp. This bug causes command parameter values to be garbled. Given the limited range of parameters for most commands, this currently exhibits incorrect behavior only for setting the motor torque, but it should be fixed to prevent problems with any future additions to the command set:
General Issues to be Considered
The "max velocity scale factor" command is truly a scale factor, not a maximum limit of speed as has been seen on other robotic platforms. This has the effect of scaling your velocity units, such that a single, specific speed command issued with one factor value will have a different resulting wheel speed than the same command issued after changing the factor. Thus, if a top speed limit is what is really desired, the software needs to maintain it's own inverse factor to cancel out the velocity factor (to preserve the units), or better yet, leave the velocity factor alone and just implement a speed limit in the code sending the commands.
The CANbus hardware itself may be buffering CANbus messages, such that slow reading can result in a time skew. Each frame of information should have its timestamp (servo frame number) consulted for the time the message was generated. It should be possible to issue a library call to clear the hardware buffer, but this has not been explored at NRL.
Apart from hardware buffering of CANbus messages, messages are also buffered in miranda/common/canpoll.cpp. The function "read_thread()" queues completed frames (messages) for later retrieval by "fp_available()". Calling the higher level "fp_available()" function at a faster or slower rate therefore has NO effect on the CANbus traffic. Calling it slower than the rate of incoming messages will only cause the queue to grow in length, and the returned data to grow more stale the longer the system is running. At NRL, this queue has been replaced by a single message buffer (effectively a queue length of one but with less overhead), such that unread messages are overwritten, and only the most recently received message is ever returned by "fp_available()". The client program can call "fp_available at any rate (or intermittently) without having to clear out stale messages and without risk of running out of memory.
The reported wheel position counts are not absolute, because of the platform's ability to tilt. For example, if the wheels don't move (and report 0 counts of wheel motion), the robot may still be moving because as it tilts the net effect is to roll and the robot moves. Also, not all reported wheel motion results in net motion, but rather goes into tilting the body. Note that these are both small errors, likely below the integration error, and NRL has not tried to measure or correct them. If necessary, they might be compensated by using the reported robot tilt as a correcting factor.
The argument for the turn command is intepreted in one of two ways (rotational speed or lateral acceleration), depending on the forward speed of the robot. To predictably control the robot's turning, it is therefore necessary to always consider the forward velocity and adjust the turn value depending on how it will be interpreted. The speed at which the transition occurs, and the mapping from raw counts to each of these two ranges is not well specified.
State Variable Rollover
The integrated travel state variable will roll over at +/-64654 meters. The integrated yaw variable will roll over at +/- 19064 revolutions.
Considering reverse motion will cause these counters to reverse, it is possible to run continuously and never roll over. But even with steady motion, these variables are unlikely to roll over in a normal run, and we have not added any rollover protection to them.
State Variable and Command Units