Header file defining the interface between the low- and high-level parts of the Robolocust controller. More...
Go to the source code of this file.
Enumerations | |
| enum | { LOBOT_ACK_READY = ':', LOBOT_ACK_BUMPS = 'B', LOBOT_ACK_WHEEL_DROPS = 'W', LOBOT_ACK_CLIFFS = 'C', LOBOT_ACK_REMOTE = '.', LOBOT_ACK_SENSORS = '$' } |
| enum | { LOBOT_CMD_NOP = '@', LOBOT_CMD_FORWARD = 'F', LOBOT_CMD_REVERSE = 'R', LOBOT_CMD_STOP = 'S', LOBOT_CMD_LEFT = '<', LOBOT_CMD_RIGHT = '>', LOBOT_CMD_STRAIGHT = '!', LOBOT_CMD_SPIN = '*', LOBOT_CMD_ENABLE_REAR_BUMPS = 'e', LOBOT_CMD_DISABLE_REAR_BUMPS = 'd' } |
| enum | { LOBOT_CMD_SIZE = 4, LOBOT_BUMPS_SIZE = 5, LOBOT_WHEEL_DROPS_SIZE = 1, LOBOT_CLIFFS_SIZE = 5, LOBOT_REMOTE_SIZE = 1, LOBOT_SENSORS_SIZE = 53 } |
| enum | { LOBOT_BUMPS_FLAGS, LOBOT_BUMPS_DISTANCE_HI, LOBOT_BUMPS_DISTANCE_LO, LOBOT_BUMPS_ANGLE_HI, LOBOT_BUMPS_ANGLE_LO } |
| enum | { LOBOT_CLIFFS_FLAGS, LOBOT_CLIFFS_DISTANCE_HI, LOBOT_CLIFFS_DISTANCE_LO, LOBOT_CLIFFS_ANGLE_HI, LOBOT_CLIFFS_ANGLE_LO } |
| enum | { LOBOT_SENSORS_BUMPS = 0, LOBOT_SENSORS_WHEEL_DROPS = LOBOT_SENSORS_BUMPS, LOBOT_SENSORS_WALL, LOBOT_SENSORS_CLIFF_LEFT, LOBOT_SENSORS_CLIFF_FRONT_LEFT, LOBOT_SENSORS_CLIFF_FRONT_RIGHT, LOBOT_SENSORS_CLIFF_RIGHT, LOBOT_SENSORS_VIRTUAL_WALL, LOBOT_SENSORS_LSD_WHEEL_OC, LOBOT_UNUSED1, LOBOT_UNUSED2, LOBOT_SENSORS_INFRARED_BYTE, LOBOT_SENSORS_BUTTONS, LOBOT_SENSORS_DISTANCE_HI, LOBOT_SENSORS_DISTANCE_LO, LOBOT_SENSORS_ANGLE_HI, LOBOT_SENSORS_ANGLE_LO, LOBOT_SENSORS_CHARGING_STATE, LOBOT_SENSORS_VOLTAGE_HI, LOBOT_SENSORS_VOLTAGE_LO, LOBOT_SENSORS_CURRENT_HI, LOBOT_SENSORS_CURRENT_LO, LOBOT_SENSORS_BATTERY_TEMP, LOBOT_SENSORS_BATTERY_CHARGE_HI, LOBOT_SENSORS_BATTERY_CHARGE_LO, LOBOT_SENSORS_BATTERY_CAPACITY_HI, LOBOT_SENSORS_BATTERY_CAPACITY_LO, LOBOT_SENSORS_WALL_SIGNAL_HI, LOBOT_SENSORS_WALL_SIGNAL_LO, LOBOT_SENSORS_CLIFF_LEFT_SIGNAL_HI, LOBOT_SENSORS_CLIFF_LEFT_SIGNAL_LO, LOBOT_SENSORS_CLIFF_FRONT_LEFT_SIGNAL_HI, LOBOT_SENSORS_CLIFF_FRONT_LEFT_SIGNAL_LO, LOBOT_SENSORS_CLIFF_FRONT_RIGHT_SIGNAL_HI, LOBOT_SENSORS_CLIFF_FRONT_RIGHT_SIGNAL_LO, LOBOT_SENSORS_CLIFF_RIGHT_SIGNAL_HI, LOBOT_SENSORS_CLIFF_RIGHT_SIGNAL_LO, LOBOT_SENSORS_CARGO_BAY_DIGITAL_INPUTS, LOBOT_SENSORS_CARGO_BAY_ANALOG_SIGNAL_HI, LOBOT_SENSORS_CARGO_BAY_ANALOG_SIGNAL_LO, LOBOT_SENSORS_CHARGING_SOURCES, LOBOT_SENSORS_OI_MODE, LOBOT_SENSORS_SONG_NUMBER, LOBOT_SENSORS_SONG_PLAYING, LOBOT_SENSORS_NUM_STREAM_PACKETS, LOBOT_SENSORS_REQUESTED_SPEED_HI, LOBOT_SENSORS_REQUESTED_SPEED_LO, LOBOT_SENSORS_REQUESTED_RADIUS_HI, LOBOT_SENSORS_REQUESTED_RADIUS_LO, LOBOT_SENSORS_REQUESTED_RIGHT_SPEED_HI, LOBOT_SENSORS_REQUESTED_RIGHT_SPEED_LO, LOBOT_SENSORS_REQUESTED_LEFT_SPEED_HI, LOBOT_SENSORS_REQUESTED_LEFT_SPEED_LO, LOBOT_SENSORS_SPIN_FLAG } |
| enum | { LOBOT_BUMP_REAR_LEFT = 0x40, LOBOT_BUMP_REAR_RIGHT = 0x20, LOBOT_BUMP_REAR_BOTH = 0x60, LOBOT_BUMP_REAR_EITHER = 0x60, LOBOT_BUMP_ACK_REAR_LEFT = 0x08, LOBOT_BUMP_ACK_REAR_RIGHT = 0x04, LOBOT_BUMP_ACK_REAR_BOTH = 0x0C, LOBOT_BUMP_ACK_REAR_EITHER = 0x0C } |
These enumerations define bit masks for the rear bumpers. More... | |
Header file defining the interface between the low- and high-level parts of the Robolocust controller.
The Robolocust controller consists of two major parts:
1. The high-level C++ layers that run different behaviours, LGMD models, integration algorithms, etc.
2. The low-level layer that runs on the microcontroller that interfaces with the electromechanical systems on the physical robot platform.
The two parts communicate with each other by exchanging messages (commands and data) over a serial port. This file defines the interface between the higher layers and the low-level control program when the "roomba_cm" robot platform is being used. This platform identifies an iRobot Create with a Command Module in place.
This header file specifies the symbolic IDs and the values of the different messages that are to go back and forth between the high-level C++ part of lobot and the low-level Command Module part. It also defines other relevant things such as the size of command messages sent by the high-level to the low-level and the number of bytes of sensor data sent from the low-level to the high-level.
This file will have to be included by the high-level C++ codebase as well as the Command Module's low-level C codebase.
Definition in file LoCMInterface.h.
| anonymous enum |
These enumerations are for acknowledgement (ACK) messages sent from the low-level control program to the higher (C++) layers of the lobot controller.
DEVNOTE: We use printable ASCII characters as the command codes to ensure that we can easily identify the messages going back and forth (when these message IDs are printed out during debugging).
| LOBOT_ACK_READY |
The Command Module sends the READY message to the high level to let it know that the low-level control program is ready to accept high-level commands. The high level must wait to receive this acknowledgement from the low level before sending a motor or sensor query command. Once the low level has executed the high-level command, it will again send a READY message to indicate that it is ready to accept the next command; so on and so forth. The high level cannot send commands willy-nilly and must wait for READY ACKs because the Command Module has only one USART that can either talk to the (external) USB port or the (internal) serial port to which the robot is connected. If the high level were to send commands at its whim, they may never be received by the Command Module because it may well have redirected its USART to the internal serial port and not be listening to whatever the high level has to say. Then, when the Command Module redirects its USART to the USB port, it may not receive any commands because the high level has fallen silent in the mean time. Needless to say, the above situation will, very quickly, make the robot quite schizophrenic. Therefore, the high and low level controllers need to coordinate their activities so as to elicit coherent behaviour on the part of the robot. When the low level sends ACK_READY, the high level can be assured that its command, if sent within a predefined timeout window (usually, 1.5 seconds), will be received and executed by the robot. |
| LOBOT_ACK_BUMPS |
The low level sends the BUMPS acknowledgement after reacting to the robot's bump sensors. The low level always reacts to the bump sensors by backing up a little and then spinning around a little bit. In case one or both of the rear bumpers is hit, the low level will respond by moving forward a little and the spinning. Thus, this message is accompanied by five bytes of data. The first byte indicates the sensor flags. Bit #0 is for the right bump sensor and bit #1 for the left bump sensor. The bit masks defined in LoOpenInterface.h may be used to test these bits. Bit #2 is for the rear right bumper and bit #3 for the rear left bumper. This file defines appropriate constants that can be used to test for the states of the rear bump sensors. The second and third data bytes make up a signed 16-bit integer (high byte first) indicating the distance backed up. Since the robot always backs up in response to a bump sensor, this number will always be negative. The fourth and fifth data bytes make up a signed 16-bit integer (high byte first) indicating the number of degrees turned in-place after the back-up. Positive values indicate counterclockwise turns and negative values are for clockwise turns. DEVNOTE: As mentioned above, the ACK_BUMPS message is followed by several data bytes containing bump sensor information as well as information about the actions the robot took in response to the bump sensors. This file defines a symbolic constant specifying how many such bytes the high level may expect to receive. Furthermore, this file also defines symbolic constants that can be used as indices into the data byte array sent as part of the acknowledgement. |
| LOBOT_ACK_WHEEL_DROPS |
When the robot's wheel drop sensors are activated, the low-level controller will immediately shut off the motors and then send this message to the high level to let it know what has happened. This acknowledgement is accompanied by one data byte containing bit flags indicating which wheel drops are active. Bit #2 is for the right wheel, bit #3 for the left wheel and bit #4 for the front caster wheel. LoOpenInterface.h defines bit masks that can be used to test these bits. |
| LOBOT_ACK_CLIFFS |
When the robot's cliff sensors fire, the low-level controller backs up and then spins the robot to avoid falling down the stairs or something like that. To let the high level know what just happened, it sends this acknowledgement message accompanied by five data bytes. The first data byte contains the flags for the cliff sensors. Bit #3 of this data byte specifies whether the left cliff sensor is on or off; bit #2 is for the front left cliff sensor; bit #1 for front right; and bit #0 for the right cliff sensor. The second and third data bytes make up a signed 16-bit integer (high byte first) indicating the distance backed up. Since the robot always backs up in response to a cliff sensor, this number will always be negative. The fourth and fifth data bytes make up a signed 16-bit integer (high byte first) indicating the number of degrees turned in-place after the back-up. Positive values indicate counterclockwise turns and negative values are for clockwise turns. DEVNOTE: As mentioned above, the ACK_BUMPS message is followed by several data bytes containing bump sensor information as well as information about the actions the robot took in response to the bump sensors. This file defines a symbolic constant specifying how many such bytes the high level may expect to receive. Furthermore, this file also defines symbolic constants that can be used as indices into the data byte array sent as part of the acknowledgement. However, there are no symbolic bit mask constants for testing the bit flags in the first data byte. |
| LOBOT_ACK_REMOTE |
When the robot is being remote controlled by the user, the low level will handle the requested command and then inform the high level with an ACK_REMOTE. This message is accompanied by a single data byte, which simply specifies the remote control command the low level handled. LoOpenInterface.h defines symbolic constants for the Roomba Remote's infrared byte. |
| LOBOT_ACK_SENSORS |
The low level regularly polls the iRobot Create for all its sensor data and streams this data to the high level using the SENSORS acknowledgement. This message is followed by several bytes of sensor data sent from the low level to the high level. It is the high level controller's responsibility to buffer the sensor data being streamed by the low-level. DEVNOTE: As mentioned above, the ACK_SENSORS message is followed by several data bytes containing the current sensor values. This file defines a symbolic constant specifying how many such bytes the high level may expect to receive. Furthermore, this file also defines symbolic constants that can be used as indices into the sensor data byte array. |
Definition at line 86 of file LoCMInterface.h.
| anonymous enum |
The following enumerations are for command (CMD) messages sent from the high-level controller to the low-level control program running on the Command Module. These commands indicate the actions the high level would like the robot to perform. The low-level control program will respond to these commands by talking in Open Interface to the iRobot Create. Thus, the high level need not worry about the low-level minutiae required to get the robot to actually execute such actions as "drive left at 200mm/s" or "veer right while backing up at 100mm/s," etc.
NOTE: All commands sent by the high level must consist of exactly four bytes. The first byte holds the command ID (one of the CMD enums defined below), the second and third bytes are for a 16-bit parameter (e.g., the drive speed or turn radius), and the fourth byte must be a parity checksum byte computed by taking the bitwise XOR of the other three bytes.
The low level will execute the command only if the parity byte checks out okay. If not, the low-level controller will stop the robot. It will also stop the robot if it gets an unknown command ID.
As a matter of good form, the high level should set the two parameter bytes to zero if the command doesn't require a parameter (e.g., CMD_STOP). If a command does require a parameter, it should be sent high byte first followed by the low byte.
DEVNOTE: We use printable ASCII characters as the command codes to ensure that we can easily identify the messages going back and forth (when these message IDs are printed out during debugging).
Definition at line 251 of file LoCMInterface.h.
| anonymous enum |
These enumerations specify the sizes of different message or data packets exchanged between the high- and low-level controllers.
| LOBOT_CMD_SIZE |
This symbolic constant specifies the number of bytes that each command sent by the high level to the low level must be. As described earlier, all high-level commands are expected to be four bytes long. The first byte holds the command ID, the next two bytes are for a 16-bit parameter (sent high byte first) and the fourth byte is an XOR parity byte. DEVNOTE: If the format of a high-level command ever changes, be sure to update this number to follow suit. Otherwise, expect Bad Things to happen. |
| LOBOT_BUMPS_SIZE |
The number of data bytes sent back with the ACK_BUMPS message. DEVNOTE: If the format and/or size of the ACK_BUMPS message ever changes, be sure to update this number to follow suit. Otherwise, expect Bad Things to happen. |
| LOBOT_WHEEL_DROPS_SIZE |
The number of data bytes sent back with the ACK_WHEEL_DROPS message. Only the state of the wheel drops as returned by the Open Interface is sent as part of this message. Thus, there is only one data byte. It contains 3 bits indicating the status of the wheel drops. Bit #2 is for the right wheel, bit #3 for the left wheel, and bit #4 for the front caster wheel. LoOpenInterface.h defines bit masks for testing these bit flags. DEVNOTE: If the format and/or size of the ACK_WHEEL_DROPS message ever changes, be sure to update this number to follow suit. Otherwise, expect Bad Things to happen. |
| LOBOT_CLIFFS_SIZE |
The number of data bytes sent back with the ACK_CLIFFS message. DEVNOTE: If the format and/or size of the ACK_CLIFFS message ever changes, be sure to update this number to follow suit. Otherwise, expect Bad Things to happen. |
| LOBOT_REMOTE_SIZE |
The number of data bytes sent back with the ACK_REMOTE message. Only the infrared byte received and processed by the low level is sent as part of this message. LoOpenInterface.h defines symbolic constants for the IR byte's different values. DEVNOTE: If the format and/or size of the ACK_REMOTE message ever changes, be sure to update this number to follow suit. Otherwise, expect Bad Things to happen. |
| LOBOT_SENSORS_SIZE |
This symbol specifies the number of data bytes that will be sent back to the high level along with the ACK_SENSORS acknowledgement message. DEVNOTE: At present, we send back all of the Create's sensor packets plus one extra byte to the high level and let it decide what data it wants/needs and what it doesn't want/need. Therefore, the number of data bytes sent back will be one more than the size of the sensor data buffer for group 6 sensor packets as defined in the Open Interface. We could simply use the LOBOT_OI_SENSOR_SIZE_GROUP_6 symbol defined in irccm/LoOpenInterface.h over here. However, we choose to "hard-code" the number 53 (i.e., 52 + 1) instead. This allows us to avoid having to include LoOpenInterface.h in this file, a consideration that seems to make sense because LoOpenInterface.h defines things that are pertinent to the Open Interface whereas this header defines things specifically pertinent to the lobot controller. The fact that LoOpenInterface.h defines a symbol that happens to match the number of sensor data bytes the low-level lobot controller sends to the high level is somewhat (though not entirely) coincidental. In the future, we may decide to send a subset of the available sensor packets or to preprocess/combine the sensor data returned by the robot before sending it off to the high level. In that case, LoOpenInterface.h may not define a convenient symbol specifying the number of data bytes sent to the high-level lobot controller. This is why it makes sense to decouple this header file from LoOpenInterface.h. DEVNOTE 2: If, as alluded to above, we do decide to change the sensor data that is to be sent back to the high level, be sure to update this number here! Otherwise, Bad Things *will* happen. |
Definition at line 338 of file LoCMInterface.h.
| anonymous enum |
These enumerations specify the indices for the data byte array sent from the low level to the high level as part of the ACK_BUMPS message.
| LOBOT_BUMPS_FLAGS |
The first data byte indicates the sensor flags. Bit #0 is for the right bump sensor and bit #1 for the left bump sensor. The bit masks defined in LoOpenInterface.h may be used to test these bits. Additionally, lobot sports two rear bump sensors. Their bit flags are in bits 3 (rear right) and 4 (rear left). Since these bump sensors are not built into the iRobot Create, they do not have predefined masks as part of the Open Interface. Instead, this file defines appropriate masks that can be used to test the status of the rear bumpers. |
| LOBOT_BUMPS_DISTANCE_HI |
The second and third data bytes make up a signed 16-bit integer (high byte first) indicating the distance backed up or moved forward in response to the front or rear bumpers. |
| LOBOT_BUMPS_ANGLE_HI |
The fourth and fifth data bytes make up a signed 16-bit integer (high byte first) indicating the number of degrees turned in-place as part of the bump sensor response. Positive values indicate counterclockwise turns and negative values are for clockwise turns. |
Definition at line 432 of file LoCMInterface.h.
| anonymous enum |
These enumerations specify the indices for the data byte array sent from the low level to the high level as part of the ACK_CLIFFS message.
Definition at line 463 of file LoCMInterface.h.
| anonymous enum |
These enumerations specify the indices for the sensor data byte array sent from the low level to the high level as part of the ACK_SENSORS message.
DEVNOTE: At present, we simply send back all of the Create's sensor packets to the high level plus one extra byte. Thus, the order of sensor data bytes matches exactly the order specified in the Open Interface specs for sensor packet #6. The last byte, however, is the extra byte alluded to above; it is not part of the Open Interface specs.
| LOBOT_SENSORS_BUMPS |
The first byte of the sensor data contains the bits for the bump sensors and the wheel drop sensors. Bits 0 and 1 are for the right and left bump sensors respectively. Bits 2, 3 and 4 are for the right, left and caster wheel drops respectively. Bits 5 and 6 are for the right and left bump sensors added to the rear of the robot. DEVNOTE: LoOpenInterface.h defines symbolic constants for bit masks that can be used to access these individual bits. This file defines bit masks for bits 5 and 6, which are for the added rear bumpers. |
| LOBOT_SENSORS_WALL |
The second byte of sensor data contains a flag indicating whether the Create/Roomba's wall sensor is active (1) or not (0). |
| LOBOT_SENSORS_CLIFF_LEFT |
Bytes 3 through 6 are flags indicating whether the cliff sensors are active (1) or not (0). |
| LOBOT_SENSORS_VIRTUAL_WALL |
The seventh byte of sensor data returned by the low level specifies whether the virtual wall sensor is active (1) or not (0). |
| LOBOT_SENSORS_LSD_WHEEL_OC |
Byte #8 specifies the state of the low side driver and wheel overcurrents. DEVNOTE: As of now, LoOpenInterface.h does not provide any convenient means of making sense of this particular value. Refer to the Open Interface specs for the gory details. |
| LOBOT_UNUSED1 |
After the wheel overcurrents, come two unused bytes (always zero). |
| LOBOT_SENSORS_INFRARED_BYTE |
The 11th byte contains the IR command received by the robot's omnidirectional IR sensor located in the front of the robot on top of the bumper assembly. This sensor value lies in the range [0, 255]. DEVNOTE: LoOpenInterface.h defines symbolic constants for the different values sent by the Roomba Remote and the Home Base. |
| LOBOT_SENSORS_BUTTONS |
The 12th byte specifies the states of the Play and Advance buttons. Bit #0 is for the Play button and bit #2 is for the Advance button. If these bits are 1, it means the corresponding button is currently being pressed; zero means the button is not being pressed. DEVNOTE: LoOpenInterface.h defines symbolic constants for bit masks that can be used to access the above-mentioned two bits. |
| LOBOT_SENSORS_DISTANCE_HI |
Bytes 13 and 14 are a two byte value (high byte first) specifying the distance (in mm) traveled by the robot since the last time its encoders were queried. Positive values indicate forward motion, negative values indicate backward motion. This sensor's value will lie in the range [-500, 500]. |
| LOBOT_SENSORS_ANGLE_HI |
Bytes 15 and 16 are a two byte value (high byte first) specifying the angle (in degrees) turned by the robot since the last time its encoders were queried. Positive value indicate counterclockwise turns, negative values indicate clockwise turns. |
| LOBOT_SENSORS_CHARGING_STATE |
Byte #17 specifies the robot's charging state. DEVNOTE: LoOpenInterface.h provides symbolic constants for the different values this sensor can take on. |
| LOBOT_SENSORS_VOLTAGE_HI |
Bytes 18 and 19 specify the voltage (in mV; high byte first) across the robot's batteries. |
| LOBOT_SENSORS_CURRENT_HI |
Bytes 20 and 21 specify the current (in mA; high byte first) flowing into or out of the robot's batteries. Negative values indicate current being drawn from the batteries (as would happen when the robot is being used); positive values indicate current flowing into the battery (as during charging). |
| LOBOT_SENSORS_BATTERY_TEMP |
Byte #22 is the battery temperature in degrees Celcius. This is a signed 8-bit integer that can take on values in the range -128 to +127. |
| LOBOT_SENSORS_BATTERY_CHARGE_HI |
Bytes 23 and 24 specify the battery charge (in mAh; high byte first) of the robot's batteries. The charge value will decrease when the robot is in use and its batteries get depleted; it will increase when the robot is being recharged. |
| LOBOT_SENSORS_BATTERY_CAPACITY_HI |
Bytes 25 and 26 specify the estimated charge capacity of the Create's battery (in mAh; high byte first) of the robot's batteries. |
| LOBOT_SENSORS_WALL_SIGNAL_HI |
The 27th and 28th bytes of sensor data contain a two-byte value indicating the strength of the wall sensor's signal. The high byte is sent first, then the low byte. The range of this sensor value is from zero to 4095. |
| LOBOT_SENSORS_CLIFF_LEFT_SIGNAL_HI |
Bytes 29 through 36 contain byte pairs (high byte first) specifying the signal strengths of the cliff sensors. The range of each of these signals is from zero to 4095. |
| LOBOT_SENSORS_CARGO_BAY_DIGITAL_INPUTS |
Byte #37 specifies the state of the digital inputs on the 25-pin Cargo Bay Connector sent as individual bits (0 = low, 1 = high, i.e., 5V). DEVNOTE: LoOpenInterface.h does not yet provide symbolic bit masks for accessing these bits. Refer to the Open Interface documentation for the gory details. |
| LOBOT_SENSORS_CARGO_BAY_ANALOG_SIGNAL_HI |
Bytes 38 and 39 specify the 10-bit vaue of the analog signal on the 25-pin cargo Bay Connector. The high byte is returned first. A value of zero stands for 0V; a value of 1023 is for 5V; intermediate values are for intermediate voltages. NOTE: The analog input is on pin #4 of the Cargo Bay Connector. |
| LOBOT_SENSORS_CHARGING_SOURCES |
Byte #40 specifies the robot's connection to the different charging sources. Bit #0 is for the internal charger and bit #1 for the Home Base. DEVNOTE: LoOpenInterface.h provides symbolic bit masks for accessing these bits. |
| LOBOT_SENSORS_OI_MODE |
Byte #41 specifies the Open Interface operating mode, which can be either Off, Passive, Safe or Full. DEVNOTE: LoOpenInterface.h provides symbolic constants for these modes. |
| LOBOT_SENSORS_SONG_NUMBER |
Byte #42 specifies the currently selected song number. |
| LOBOT_SENSORS_SONG_PLAYING |
Byte #43 is flag indicating whether the robot is currently playing a song or not. |
| LOBOT_SENSORS_NUM_STREAM_PACKETS |
Byte #44 specifies the number of stream packets. |
| LOBOT_SENSORS_REQUESTED_SPEED_HI |
Bytes 45 and 46 are a two byte value (high byte first) indicating the most recent drive speed requested by the high level. This is a signed 16-bit integer that can range from -500 to +500. |
| LOBOT_SENSORS_REQUESTED_RADIUS_HI |
Bytes 47 and 48 are a two byte value (high byte first) indicating the most recent turn radius requested by the high level. This sensor's value will be in the range [-2000, 2000] or one of the special case values for in-place turns or driving straight. DEVNOTE: LoOpenInterface.h provides symbolic constants for the special case values mentioned above. |
| LOBOT_SENSORS_REQUESTED_RIGHT_SPEED_HI |
Bytes 49 and 50 are a two byte value (high byte first) indicating the drive speed requested by the high level for the right wheel. This sensor's value will be in the range [-500, 500]. |
| LOBOT_SENSORS_REQUESTED_LEFT_SPEED_HI |
Bytes 51 and 52 are a two byte value (high byte first) indicating the drive speed requested by the high level for the left wheel. This sensor's value will be in the range [-500, 500]. |
| LOBOT_SENSORS_SPIN_FLAG |
Byte 53 is an extra byte not part of the Open Interface. This byte holds a flag indicating whether or not the distance and angle packets include the actual amount spun and any unintentional translation in response to the most recent SPIN command sent by the high-level controller. DEVNOTE: The reason we need this extra byte is as follows. When the high level sends a SPIN command to have the robot turn in-place, the robot may actually end up spinning by an amount that differs slightly from the requested cw/ccw turn due to actuation errors and timing limitations in the low-level controller. Additionally, the robot may also experience a small amount of translation while rotating in-place due to wheel slippage and other such effects. Ideally, the low-level controller would then report the actual amount of rotation and any unintended translation via a SPIN acknowledgement. Unfortunately, the low-level controller's current design makes it hard to implement such an acknowledgement message because the drive module implements the response to the SPIN command but has no means of initiating an acknowledgement. Therefore, it requests the sensors module to record the actual amount of rotation and translation and tack these amounts on to the distance and angle reported by the encoders the next time the main loop requests a full sensor sweep. This extra byte in the sensors packet lets the high level know that the encoder packet it has just received includes the response to a recent SPIN command sent by it to the low level, in effect, acting as a crude sort of ACK_SPIN. DEVNOTE 2: Even if the low-level controller were able to send an ACK_SPIN in response to a CMD_SPIN, the high-level controller at present (circa August 2010) ignores all ACKs except for ACK_READY and ACK_SENSORS. Consequently, it does make some sense for the low level to tack on the effects of a CMD_SPIN to an ACK_SENSORS to ensure that the high level sees the actual amount of rotational and translational motion caused by a SPIN command. If we were to avoid this bit of hackery, it would become necessary instead to respond to all low-level ACKs and setup some sort of callback mechanism to report odometry updates to all interested high level modules (e.g., localization). Needless to say, implementing an extra flag sent as part of the low-level sensor packet is a lot less work and, therefore, we adopt this solution now in the interests of minimizing development time. DEVNOTE 3: Eventually, when we redesign the low-level controller and the interface to it in the high level, it would be a good idea to have the main module act as a general communication buffer that queues incoming commands from the high level and outgoing acknowledgements from the low level and to then allow all low-level modules to queue relevant acknowledgements. Thus, when a SPIN command comes in, the drive module could handle it and queue an ACK_SPIN in response without any trouble. Of course, the high-level thread/module interfacing with the low-level controller will also have to be redesigned to accept all low-level ACKs and implement a proper observer pattern to inform interested parties about the latest odometry updates, etc. |
Definition at line 495 of file LoCMInterface.h.
| anonymous enum |
These enumerations define bit masks for the rear bumpers.
| LOBOT_BUMP_REAR_LEFT |
Instead of adding a new sensor data byte for the rear bumpers to be sent as part of the SENSORS_ACK message, we simply use the unused bits of the bumps + wheel drops data byte. These bit masks can be used to access the states of the rear bumpers when the bumps data byte of the SENSORS_ACK message is being used. |
| LOBOT_BUMP_ACK_REAR_LEFT |
When the low-level controller sends the BUMPS_ACK message to the high level, it packages the states of the front and rear bump sensors into lower four bits of the first data byte. LoOpenInterface.h defines bit masks for the (built-in) front bumpers. These bit masks specify the locations of the rear left and right bump sensors for the BUMPS_ACK message. |
Definition at line 792 of file LoCMInterface.h.
1.6.3