High-level API for driving and steering the robot and keeping track of its sensors. More...
#include <Robots/LoBot/io/LoRobot.H>
Classes | |
| class | Sensors |
Public Types | |
| typedef void(* | SensorUpdateCB )(const Sensors &, unsigned long client_data) |
|
typedef std::pair < SensorUpdateCB, unsigned long > | SensorHook |
Public Member Functions | |
| const Sensors & | sensors () const |
| void | add_hook (const SensorHook &) |
| virtual void | drive (float speed, int pwm)=0 |
| virtual void | turn (float direction)=0 |
| virtual void | spin (float angle)=0 |
| void | update () |
| virtual bool | stopped () const |
| virtual void | off () |
| virtual | ~Robot () |
| Clean-up. | |
| float | current_speed () const |
| Retrieving the robot's current speed and heading. | |
| float | current_heading () const |
Protected Member Functions | |
| Robot (const ModelManager &, const std::string &device, int baud_rate) | |
| void | time_stamp (long long ts) |
| void | speed (float s) |
| void | heading (float h) |
| void | motor_pwm (int p) |
| void | servo_pwm (int p) |
| void | rpm (float r) |
| void | bump_left (bool b) |
| void | bump_right (bool b) |
| void | bump_rear_left (bool b) |
| void | bump_rear_right (bool b) |
| void | wheel_drop_left (bool b) |
| void | wheel_drop_right (bool b) |
| void | wheel_drop_caster (bool b) |
| void | wall (bool b) |
| void | virtual_wall (bool b) |
| void | wall_signal (int s) |
| void | cliff_left (bool b) |
| void | cliff_right (bool b) |
| void | cliff_front_left (bool b) |
| void | cliff_front_right (bool b) |
| void | cliff_left_signal (int s) |
| void | cliff_right_signal (int s) |
| void | cliff_front_left_signal (int s) |
| void | cliff_front_right_signal (int s) |
| void | infrared (int i) |
| void | distance (int d) |
| void | angle (int a) |
| void | spin_flag (bool f) |
| void | battery_charge (int c) |
| void | requested_speed (int s) |
| void | requested_radius (int r) |
Protected Attributes | |
| lobot::Serial | m_serial |
| Sensors | m_sensors |
High-level API for driving and steering the robot and keeping track of its sensors.
The Robolocust controller may run on different kinds of robots (e.g., a hacked R/C car or a Roomba). All these robots are expected to be driven and queried for their sensors using a common interface as specified by this abstract base class. Derived classes will implement the actual innards of the interface for the different robots they are written for. These derived classes will be instantiated using a polymorphic factory and a config file setting.
Definition at line 86 of file LoRobot.H.
| typedef void(* lobot::Robot::SensorUpdateCB)(const Sensors &, unsigned long client_data) |
Usually, when a behaviour or other client module wants to know the current sensor state, it can simply query the robot interface object (via lobot::App) for the desired data. However, in certain situations, a behaviour might want to be informed about low-level sensor updates as soon as they come in. For example, if a behaviour is performing odometry-based localization, it cannot afford to miss low-level sensor updates by querying in its action method because it could well get incorrect odometric info by the time the behaviour's main loop's next iteration kicks in.
The robot interface object, therefore, maintains a list of callback functions, which it calls one-by-one right after the main thread updates the robot's sensor state. These types define the sensor hook functions.
NOTE: The sensor hooks are executed in the context of the main thread. So, clients should take appropriate measures to protect any shared data structures that are used in the hook functions. Furthermore, to avoid delaying the main thread, clients should keep the processing within these hook functions to a minimum.
| lobot::Robot::Robot | ( | const ModelManager & | mgr, | |
| const std::string & | device, | |||
| int | baud_rate | |||
| ) | [protected] |
| void lobot::Robot::add_hook | ( | const SensorHook & | H | ) |
| float lobot::Robot::current_speed | ( | ) | const [inline] |
| virtual void lobot::Robot::drive | ( | float | speed, | |
| int | pwm | |||
| ) | [pure virtual] |
Clients must issue drive commands using both a speed expressed in m/s and a PWM value.
The reason we require clients to supply both is because some robot platforms will support a speed command whereas others only provide for PWM commands. Robot platforms that support both can choose one type of command over the other based on config file settings, sensor readings, etc. Either ways, this decision is up to individual derived classes.
DEVNOTE: Since this method will change the internal state of the motor system (which is shared by many behaviours/modules), clients should protect calls to it using lobot::UpdateLock.
Referenced by off().
| void lobot::Robot::off | ( | ) | [virtual] |
A convenience function for stopping the robot and straightening its wheels.
NOTE: The default implementation of this function simply issues drive and turn commands with zero as the parameters. However, derived classes may want to override this implementation if their particular robot platforms provide different or better ways to turn the motor system off.
Definition at line 126 of file LoRobot.C.
References drive(), and turn().
Referenced by lobot::App::run().
| const Sensors& lobot::Robot::sensors | ( | ) | const [inline] |
| virtual void lobot::Robot::spin | ( | float | angle | ) | [pure virtual] |
Command the robot to spin in-place by the specified angle (expressed in degrees). Positive angles result in counterclockwise in-place turns and negative angles in clockwise in-place turns.
DEVNOTE: Since this method will change the internal state of the motor system (which is shared by many behaviours/modules), clients should protect calls to it using lobot::UpdateLock.
| bool lobot::Robot::stopped | ( | ) | const [virtual] |
Query the motor subsystem to see if the robot is currently moving or stationary.
NOTE: Derived classes may override this method if they wish to implement it in a different way from the default, which is to simply check if the speed is zero.
Definition at line 134 of file LoRobot.C.
References current_speed().
| void lobot::Robot::time_stamp | ( | long long | ts | ) | [inline, protected] |
| virtual void lobot::Robot::turn | ( | float | direction | ) | [pure virtual] |
Command the robot to steer towards the specified direction (expressed in degrees). Zero degrees is for driving straight ahead; positive (ccw) angles are for heading left and negative (cw) angles for heading right.
DEVNOTE: Since this method will change the internal state of the motor system (which is shared by many behaviours/modules), clients should protect calls to it using lobot::UpdateLock.
Referenced by off().
| void lobot::Robot::update | ( | ) |
This method is meant to be called by the Robolocust main thread as part of the sensorimotor update loop. It should not be called by any other modules. The idea here is that the main thread updates all the sensors and motor systems while all other behaviours and modules simply read the latest measurements or motor states.
DEVNOTE: Since this method will change the internal state of the motor system (which is shared by many behaviours/modules), clients should protect calls to it using lobot::UpdateLock.
Definition at line 115 of file LoRobot.C.
References m_sensors.
Referenced by lobot::App::run().
Sensors lobot::Robot::m_sensors [protected] |
The robot's current sensor values are all maintained in an instance of the Sensors inner class defined above. Derived classes are expected to update this object and client modules may retrieve a reference to it to examine the robot's current state.
Definition at line 342 of file LoRobot.H.
Referenced by current_speed(), sensors(), time_stamp(), and update().
lobot::Serial lobot::Robot::m_serial [protected] |
The low-level serial device interface.
DEVNOTE: We need to qualify the Serial class name with the namespace because LoSerial.H may use either libserial's SerialPort class or INVT's Serial class. If it is using INVT's serial support, then that class name will clash with the Robolocust Serial class encapsulating serial communications.
1.6.3