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.

Code-Specific Issues
Following are some possible bugs in the demo software (canpoll.cpp) that, if actual bugs, might be responsible for some odd behaviors:

• line 300, currAtik should probably reference hdrmsg[] not hdrmsg2[], see comparable construction for currBtik at line 236.
• line 321, noBreakA set to 0 (it's ALWAYS 0, rendering it useless), it should probably be set to 1 as is its counterpart noBreakB at line 237.

Following are unexplained protocol issues:

• undocumented CANbus msg 0x405
• undocumented CANbus msg 0x681
• What is the "0x5a5a signifies droped[sic] frame" at line 313? Is this a special value a user application would need to look for that signifies "invalid data"?
• In assembling frame at line 310, only 16 "gpdata" elements are used, but 20 elements were retrieved from the CANbus msgs, what about the other 4 values (from undocumented CANbus msg 0x405)
• What is the CANbus msg sequence? E.g., does 0x400 mark the beginning of a frame, or the end of a frame, etc. The assembly of a frame is done after receiving 0x400, but the data array indices and the setting of currBtik imply 0x400 is the start of a frame.
• How does the frame counter (as supplied as one of the 16 data values) relate to the 0x400-0x405 msgs, so that a block of data can be properly assigned a 'timestamp' without skewing? Is all the data in one frame actually from the same moment in time, or is there some non-zero duration of a frame, during which data are stored at various times?
• Canpoll returns data from both buses. Is there some preferred way to look at both sets, or should only one or the other be used?

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:

line 172,

data[6] = (param) & 0x0ff;

should be

data[6] = (param >> 8) & 0x0ff;

General Issues to be Considered
The RMP contains frame fault detection for the CANbus. This means that if the frame of the RMP comes into contact with the shielding (frame) of the CANbus card or cables, the RMP will consider it a system fault and immediately shut off all power. This poses a problem because such a connection is easy (if not obvious) to make with an attached computer and sensors. Typically, the CAN card frame will make electrical contact with the computer chassis into which it is inserted. The computer chassis ground and is tied to the signal ground for the serial port. A sensor connected to the serial port (such as a SICK laser rangefinder) will tie the signal ground to its frame. Finally, the sensor frame is bolted to the RMP chassis, completing the connection and causing the RMP to shut down. To avoid this problem at NRL, the SICK rangefinder is mounted on a wooden plate to insulate it from the RMP top plate.

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 servo frame counter, which serves as the clock for aligning data in time, is a short integer and rolls over every 10 minutes. We have added a check to the counter such that rollover is detected (when subsequent value is below the prior value), and the counter adjusted so that it continues counting upward. The modified counter is stored as a long integer, and the rollover period has been extended to 497 days, which is reasonably longer than the expected "up" time (particulary as the RMP must be turned off to recharge every 6 or so hours).

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
The table below maps native counts to real units: