7.33 reb

Authors

John Sweeney sweeney(at)cs.umass.edu

Synopsis

The reb_* family of drivers are used to control robots using the K-Team Kameleon 376SBC with Robotics Extension Board (REB). The Kameleon, (or Kam), has a Motorola MC68376 microcontroller that can perform velocity and position control and odometry for up to four motors, using the REB. It can also access a number of A/D inputs, which we have connected to Sharp GP2D12 IR proximity detectors.

In its default setting, a host computer can communicate with the Kam using the K-Team SerCom program, which uses a simple protocol to send commands and read data back. At UMass, we found that the default SerCom did not offer enough performance, so we developed our own, LPRSerCom, which uses the same protocol, but with some enhancements, such as letting the Kam do the odometry updates and IR synchronization. The bottom line is that you need to modifiy these drivers to work with the K-Team SerCom, which is not very difficult (mainly removing the LPRSerCom specific code). We can also send you a copy of LPRSerCom if you'd like. Email John Sweeney (sweeney@cs.umass.edu) for information.

Interfaces / Configuration requests

Like the P2OS device, one thread handles 3 separate devices: position, IR, and power.

• reb_position
  • Interface: position (see Section 6.19)
  • Configurations: GET_GEOM, MOTOR_POWER, VELOCITY_MODE, RESET_ODOM, POSITION_MODE, SPEED_PID, POSITION_PID, SPEED_PROF, SET_ODOM
  • Notes: Provides access to differential wheelbase. Position mode is supported, but experimental. Velocity mode has two operating modes: direct and heading-based. In direct mode, the translational and rotational desired velocities are given as commands. In heading-based, a desired heading an limits on translation and rotational velocities are given.

• reb_ir
  • Interface: ir (see Section 6.15)
  • Configurations: POSE, POWER
  • Notes: Accesses an array of IR proximity detectors. The device returns voltages from the detector, which the client must decode into ranges (usually done in IRProxy). The 8 sensors are arranged in a counterclockwise octagon around the robot, with sensor 0 oriented with the robocentric positive $\hat{{x}}$ axis, and sensor 2 oriented robocentrically at positive $\hat{{y}}$.

• reb_power
  • Interface: power (see Section 6.21)
  • Configurations: none
  • Notes: Accesses the current battery voltage information, from the REB.

Configuration file options

Table 7.3 lists the available configuration file options for the REB device. In an option is specified more than once in the config file, then only the last value will be used. Note that the ``subclass'' option is very UMass specific, since are using two different chassis with different gear ratios.

Table: Configuration file options for the reb_* drivers.

Name Type Default Supported by Values Meaning

port string /dev/ttySA1 reb_* This port connects to the REB.

subclass string slow reb_position fast, slow The type of robot.

Notes

• The reb_position driver sets some default PID parameters and resets the odometry to (0, 0, 0) when the first client subscribes. Likewise, the IR sensors are only turned on when an IR client has subscribed.
• Position mode is very finicky. This seems to be a problem with the REB itself, which may lose bytes on the serial port while performing position mode actions. This causes the driver to time out, and quite possibly lose a connection to the REB.
• The LPRSerCom protocol running on the REB will sometimes lose a byte over the port, which can cause the driver to time out on a read call to the port. The driver will attempt to retry the call, but there is no guarantee that the REB will be able to handle it. The best solution is to reset the REB. Hopefully this should be a relatively rare occurrence.
• As mentioned above, for this driver to function properly, the REB needs to be running the LPRSerCom program.
• Much of the code for this driver was originally adapted from the p2os driver, which we have appreciated.