The interfaces for the critterbot and the simulator are identical, however there is some variation on the data each provides. There are three main sets of data, actions, observations, and world state. Actions are the commands the agent sends to the robot, observations are the local state information from the robot's sensors, and world state is anything the robot is not directly aware of, such as time of day and global position. Currently there is no world state information reported, we are still defining the boundary between observations and world state, as well as the relationship between world state from the robot and the simulator.

(Note: for a quick overview of some of the Critterbot's orientation-dependent sensors, see the Critterbot's Sensorimotor layout.)

Critterbot observation labels in RLPark

PowerSource, ChargeState, BusVoltage, Bat0, Bat1, Bat2, MotorCommand0, MotorSpeed0, MotorCurrent0, MotorTemperature0, MotorCommand1, MotorSpeed1, MotorCurrent1, MotorTemperature1, MotorCommand2, MotorSpeed2, MotorCurrent2, MotorTemperature2, AccelX, AccelY, AccelZ, MagX, MagY, MagZ, RotationVel, IRDistance0, IRDistance1, IRDistance2, IRDistance3, IRDistance4, IRDistance5, IRDistance6, IRDistance7, IRDistance8, IRDistance9, IRLight0, IRLight1, IRLight2, IRLight3, IRLight4, IRLight5, IRLight6, IRLight7, Light0, Light1, Light2, Light3, Thermal0, Thermal1, Thermal2, Thermal3, Thermal4, Thermal5, Thermal6, Thermal7, ErrorFlags, CycleTime, MonitorState

Bump sensors are not seen in RLPark by default and are not yet provided by the robot.  Datasource is similarly dropped.  Some semantics for the internal state variables.  PowerSource is 0/1 for Unattached/Attached. ChargeState is 0 when not charging, 1-10 when charging, and 11 when charging is complete. Numbers above 200 indicate an error state.  The low bits of ErrorFlags indicate low-level system errors, the high byte is used to store ChargeState again (this enables diagnosing faults which cause fast power failures).  MonitorState is a bit-vector for internal state (bit 7 = ChargingEnabled, bit 6= DriveEnabled, bit 0=Motors disabled for overheating protection).

Actions

Actions are the agent's tool for effecting change to its state and the world. The critterbot has three types of effectors: motors, lights, and a speaker. The speaker is a special case (and not currently functional) so it won't be covered here. A single action can contain commands for the motor, the lights, or both. Actions can be sent at any time, however the hardware is only checking for new commands at 100Hz, so sending actions faster than this is meaningless. Additionally, the motors cannot respond instantly to new commands, it takes several 100Hz cycles for a new action to actually have an effect on the state of a motor, and several more (possibly hundreds) of cycles for the motor to reach a steady state due to a single action. The lights respond quickly to new actions, and no damage can be done by sending wildly varying data so they are an excellent testbed.

Motor Control

There are a few special cases regarding the motors that will cause the robot to modify the actions you send. For safety reasons there is a timeout, if no new action is received within 500ms of the previous action the action will be reset to 0. To give a motor a constant command for longer than 500ms, send the same action repeatedly, never waiting longer than the timeout between actions.

The second special case is also for safety reasons and involves speed and power limiting. Putting current through the windings of a motor causes it to heat up. If too much current passes through the windings for a long enough period of time the motor can be permanently damaged; to prevent this the motor controllers will start to decrease the magnitude of a commanded action if it is causing prolonged large currents in a motor. The robot is capable of moving very quickly, and at full speed could easily cause damage to itself, or more likely to things around it. The controllers also monitor the speed of the robot and provide an artificial ceiling; in velocity control mode this just means that actions are simply capped, however in voltage mode the controllers will start to decrease the action's magnitude once the robot reaches the speed threshold.

Motor commands are the first 4 values of an action. The first value represents the type of command, and the next three values are the magnitudes for that command. Wheel-specific commands are ordered according the diagram above. The motor index indicates the order of the wheel in the command packet, the wheel value is the angle of the wheel relative to the positive X axis.

Mode 0	Wheel Velocity Control
Each of the three value fields represent the velocity of one of the robot's three wheels, in the range -100 to 100. Set motor_mode to WHEEL_SPACE in CritterControlDrop, set values for m100_vel, m220_vel, and m340_vel.
Mode 1	Robot Velocity Control
The first value is the robot's forward or x velocity, the second value the robot's sidways or y velocity, and the third is the robot's rotational velocity. Again in the range -100 to 100. Set motor_mode to XYTHETA_SPACE in CritterControlDrop, set values for x_vel, y_vel, and theta_vel.
Mode 2	Wheel Voltage Control
Each value represents the relative voltage sent to each wheel. This can roughly be viewed as the force exerted by the wheel, in the range of -127 to 127. This is the lowest level of control possible. Unimplemented at this time.

For instance, the command ['1', '25', '0', '-10'] tells the robot to move forward at 1/4 velocity and turn slowly to the right. Actions sent in Modes 0 and 2 are not as intuitive as the cartesean velocities sent in Mode 1. Most combinations of wheel velocities in Mode 0 will result in the robot spinning in eccentric circles. Linear motion occurs with a small subset of commands, the simplest of which are any ordering of 0, X, and -X. Actions in Mode 2 produce similar results, due to the lack of feedback in the low-level control the resulting motion will be less precise.

LED Control

There are 16 LED's in a circle on top of the robot, each with controllable RGB values. They can be programed to display certain canned routines or individually controlled by the agent. Continuous actions keep the display updated, either with a fixed animation or reacting to various inputs. One-time actions update the display to a static look until the next action is sent. Set led_mode in CritterControlDrop to your preference

NONE	No action
No change to the state of the LED's
CLEAR	One-time Action
Turn off all the LED's
BATTERY	Continuous Action
Displays the live battery voltage as a pie graph, from 11.5 to 16.5 volts
BALL	Continuous Action
A simulation of a ball in a track using the accelerometer
ERROR	Continuous Action
Error state, indicated by strobing orange lights
EMERGENCY	Continuous Action
Blinking red and blue lights
BUSY	Continuous Action
Waiting or busy display, indicated by spinning green circle
CUSTOM	One-time Action
Lets the agent specifically set each LED value. The led_val array lets you set values for each LED's red, green, and blue element individually, within the range 0 (off) to 255 (full brightness).

Observations

Observations are information the robot can gather itself about the state of the world, this includes both internal and external state. New observations are provided nominally every 10ms, and each observation contains the entire state of the robot at a single moment in time.

Individual observations change at varying rates; acceleration can change drastically from one time step to the next, but system voltage might be constant for an hour or more. Observations may also be offset in time from the actual event. An action causing sudden acceleration will first register as a spike in current, then as an increase in velocity, and at some point in the future may appear as an increase in motor temperature.

Due to certain hardware restrictions, be aware that some of the following sensor readings may be compressed. This limit will eventually be addressed, but for now the precision of most readings will be limited to 8 bits. This can been seen in the log files as artificially quantized readings, for instance the light sensors have no data in the 2 lowest bits.

Here is a list of all the sensor data provided by the Critterbot. The robot and the simulator have a slightly different set of sensors, so the Robot and Sim columns indicate if the sensor is present respectively.

Sensor	Num	Range	Sim	Robot
Motor Command	3	(-127,127)	Y	Y
This the instantanious command issued to the motor. For both wheel and robot velocity control this is the speed issued to the motor, from -100 to 100. For voltage control this the voltage command, from -127 to 127.
Motor Speed	3	(-100,100)	Y	Y
This is the actual speed of the motor, and corresponds directly to the Motor Command when in a velocity mode.
Motor Current	3	(0,255)	Y	Y
Increasing value is higher current. Expect values from 0-50 peaking around 100 when robot is moving.
Motor Temperature	3	(0,255)	N	Y
Decreasing value is higher temp. Expected values around 165 when the motors are at ambient (~20 degrees C), leveling off to around 70 after extended driving.
System Voltage	1	(100,255)	Y	Y
Voltage is reported in 1/10ths of a Volt, so 124 is 12.4V. Battery range is 12.0-16.8V; charging voltage is 24V, however due to non-linearity at this end of the sensor it should measure approximately 220. This is the raw system bus voltage, there is no monitoring on the 5V and 3.3V busses. Under heavy current draw conditions from the motors, expect the value to sag a little, especially as the batteries near empty.
Accelerometer	3	(-2048,2048)	Y (no Z axis)	Y
In 1/1024th of a G (roughly milli-G's). Expect lots and lots of noise when moving partially due to the roughness of the wheel surface, even on the Z axis.
Gyroscope	1	(-410,410)	Y	Y
This is a sensed value of rotation, not a calculated one. Saturates at maximum value at a rotational velocity command of about 28. This is probably the most accurate exteroceptive sensor on the robot.
Light Sensor	4	(0,700)	Y	Y
Orientations. Higher values are brighter. Expect 20-200 in dim light, 400+ in sunlight.
IR Distance Sensor	10	(0,255)	Y	Y
Orientations. See response curves for value/distance relationship. Sensitive only in a very narrow field of view, reflective and dark objects are not detected as well as matte white ones. Important real-word considerations: With no detectable object in range these have a value of 2-3, not 0; noise is in no way gaussian, when an object is just on the edge of detection values will jump wildly between 2-3 and ~50; when an IR sensor on the robot is pressed against an obstacle it will likely read greater than 100 but less than 255, see response curves.
Thermal Sensors	4	(11748,19908)	N	N
Orientations. Each sensor provides two values, the first is the ambient temperature (Ta) of the sensor itself, the second is the average temperature in it's field of view (To). Kelvin temperatures are value / 50.
Magnetic Field Sensor	3	(-512,511)	N	N
Three axis value of the local magnetic field, ordered X, Y, Z.
Bump Sensors	32?	(0,255)	Y	N
Provided in the simulator for now as a function of collision force, the value is not instantanious but decays from a maximum value for several observations after the impact.