Overview
Figure overview-1: Monstro, an outdoor mobile ground robot.
Monstro is a custom, rugged, cost effective, unmanned ground vehicle (UGV) hardware and software platform for use indoors and outdoors. Our final design consists of a 4 wheel drive, 2 axis steering, carbon fiber chassis capable of supporting a 30 pound payload. The robot was equipped with high precision differential GPS, 802.11 WiFi networking, a 1.6 GHz PentiumM Linux-based mobile computer, a programmable motor controller, and a Telos wireless sensor mote. A client-server software platform was developed to facilitate quick interaction and testing of control concepts. Interfacing with a wireless sensor network (WSN) is provided by an onboard Telos mote and supporting software interface. Additionally, the onboard computer is interfaced with the motor controller (running the TinyOS operating system) which provides control of wheel steering and speed while ensuring safety by disabling the motors during communication disruption. Additional onboard software utilizes a client-server model allowing a remote client (such as a desktop or laptop) to employ all the robot resources such as the motor control, the GPS, and the WSN.
Hardware Architecture
Figure hardware-1: Hardware architecture for the mobile robot.
The final hardware design, built on a model monster truck chassis, consisted of several systems (see Figure hardware-1):
- a power system
- a D-GPS system
- a networking system
- a actuation system
- a general sensor system
- a computation system
The power system was driven by two sets of batteries: one set provided 7.2VDC to the onboard actuators, and the other set provided a stable 12VDC for the rest of the electronics. Utilizing two independent battery sets allowed us to isolate the power used to drive the motors (which under load is often very noisy) from the power required by the sensitive electronic components. The motor controllers further converted the 7.2VDC to 5VDC for use by the steering servos. The 12VDC was additionally converted to both 5VDC (via a discrete DC to DC converter) and 3.3VDC (via the TelosB mote onboard power system). These signals (12VDC, 5VDC, and 3.3VDC) were used to drive all other electronics: the onboard computer required 12VDC, the D-GPS system required both 12VDC and 5VDC, and the general sensor system required 5VDC and 3.3VDC. Finally, the remaining components where powered through their interface to the onboard computer: the wireless adapter (part of the networking system) was connected via a PC Card slot, and the two TelosB motes (part of the networking, actuation, and general sensor systems) were connected via available USB ports.
The D-GPS system consisted of a GPS measurement unit, a GPS satellite antenna, an Ethernet converter system (ECS), and a 2.4GHz antenna. The GPS unit uses the satellite antenna to provided a good estimate (within about 1-2 meters) of the robot's position. This information is provided to the onboard computer over a serial link (utilizing a proprietary format). To improve the accuracy, we further allowed our GPS unit to communicate with an on-site D-GPS base station. To this end, our system utilized an Ethernet converter system (ECS) to convert the serial communication link of the GPS system to a wireless 802.11b compatible signal that is connected to a 2.4GHz antenna. With the D-GPS system configured, we were able to estimate the robot's position to within 2cm with updates every 0.1 seconds.
The networking system is design to allow the robot to communicate with motes in a nearby sensor network and to communicate with other 802.11 enabled devices, such as a base station or another robot. To interact with a sensor network, we attached a TelosB mote to the onboard computer using the USB port. To network with other wifi devices, with use a standard off-the-shelf 802.11b wireless adapter that connects to the onboard computer using another USB port. Since, the TelosB, the wireless adapter, and the ECS operate at 2.4GHz, we connect them to the same 2.4GHz antenna using a discrete radio coupler. The mote is connected with a SMA cable, whereas the ECS and the PC wireless adapter utilize a MC Card cable. In order to avoid frequency collision on the radio, we ensure that each system is operating in a different frequency band.
The actuation system consists of the motors, motor controllers, steering servos, and an actuation controller. Our robot is equipped with 4 wheel drive and 2 axis steering: we have an independent driving motor and steering servo on both the front and back wheel sets. The driving motors are controlled with standard off-the-shelf RC motor controllers, and both the motor controllers and the steering servos are controlled by an actuation controller. The actuation controller is a TelosB mote programmed to act as an overall interface to the actuators and to act as a safety system (disengaging the motors in the absence of a signal). The mote controls the actuation via 4 PWM signals: 2 driving motors and 2 steering servos. Finally, the mote is connected to the onboard computer using a USB port.
The general sensor system is distinguished from the D-GPS system. It allows an end user to interface many of the standard robotic sensors that support I2C. The same TelosB mote used as an actuation controller is used to interface I2C sensors to the onboard computer. This is accomplished by using a discrete I2C level translator to convert the I2C bus onboard the TelosB mote (operating at 3.3VDC) to a more typical I2C bus level (operating at 5VDC). Then an end user's I2C sensors (such as sonar) can be directly connected to the I2C level translator and accessed from the onboard computer via a software interface that spans the onboard computer and the TelosB mote.
Finally, the robot's onboard computation system provides the end user with the computing power to meet their application requirements. The onboard computer is running Linux on a 1.6GHz Pentium M mobile computer. This computer is connected to a wireless adapter for networking, to a TelosB mote for interacting with a sensor network, to a D-GPS system for self-localization, and to a sensor/actuator controller for interfacing with the robot's onboard sensor and actuators.
Software Architecture
The software architecture consists of 4 components (see the orange ovals in Figure hardware-1): TOSBase, RoboMote, RoboServ, and one or more RoboServ clients. TOSBase is a TinyOS application that runs on one of the two onboard TelosB motes. TOSBase allows the mote to act as a conduit for sensor network messages. This application never needs to be modified by the end user; software installed on the robot's onboard computer will provide all the access that is necessary.
RoboMote is a TinyOS application written in NesC. RoboMote is responsible for providing a uniform interface to the sensors and actuators. To this end, RoboMote sends and receives TinyOS messages that allow another system to set and read the state of the sensors and actuators. Additionally, it is tasked with disengaging the actuators during an interruption in communication with application level software. RoboMote's message API accomplishes this by requiring the communicating application to engage the motors with a finite timeout value. After which, RoboMote must receive messages from the application at least this often to keep the motors engaged. This feature is useful when the robot was remote controlled from a joystick; when the robot left the range of communication, it would stop moving rather than continuing to drive away.
RoboServ is an (set of) Linux applications that are designed to isolate the end-user from directly interacting with TOSBase and RoboMote, to provide a clean easy-to-use interface to the robot, and to provide for resource sharing to distributed applications. To this end, RoboServ provides an interface for sending and receiving TinyOS messages via the mote running TOSBase. It also provides an interface for sensing and actuation that conceals the passing of TinyOS messages between RoboServ and RoboMote. The sensing interface also exposes access to the D-GPS system while hiding the details of the underlying D-GPS message format that is received over the serial port. To allow for resource sharing, RoboServ's application API is exposed as both a custom, high-speed client-server interface and a standard XML-RPC interface. This allows multiple onboard and remote clients to connect to and share the resources available on the robot, such as D-GPS, actuation, and sensor network interaction.
The last piece of the software architecture is the end-user's application, written as a RoboServ client. This client may choose to use either of RoboServ's interfaces: an XML-RPC API or a high-speed, custom message over socket protocol. Developing for either interface is simple by using the provided RoboServ client libraries. We focused on client's written in Java, C++, or Python. We provide an example Python client application that demonstrates simple control of the robot. We provide a more extensive example Java application that allows a remote laptop to open a GUI dashboard and control center for the robot -- allowing remote monitoring of the robot's state and control of the robot using either the keyboard or a connected joystick.
Our software architecture allows for extremely fast prototyping of control software. End-users can develop and debug applications on their laptops and desktops. They can stream sensor and actuation information from the robot to monitor their progress. An application can be made totally autonomous by simple uploading the same application to the robot's onboard computer. For high-speed applications, end-users can take advantage of the custom socket protocol and the C++ client library.
Acknowledgments
Special thanks to Dr. Khalid Al-Ali's team at Carnegie Mellon West who developed the chassis for their MAX platform and graciously allowed us to use it for our project. Special thanks to John Breneman for obtaining, modifying, and assembling the chassis. Thanks to Cory Sharp for code debugging assistance.