(Note: for a quick overview of some of the Critterbot's orientation-dependent sensors, see the Critterbot's Sensorimotor layout.) Critterbot observation labels in RLParkPowerSource, 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). ActionsActions 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 ControlThere 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.
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 ControlThere 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
ObservationsObservations 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.
|
Hardware > The Critterbot Robot >