One of the most hazardous duties on the modern battlefield is the clearing of land mines. Many vehicles have been developed to detect and / or clear land mines. Operating such a vehicle in a mine field is a high risk operation for a soldier. Anti-vehicle mines typically severely damage the vehicle and often wound or kill the operator of the vehicle. One solution is to equip existing mine clearing vehicles with robotic teleoperation capabilities so that the vehicle operator can control the vehicle from a safe distance.
The Standardized Robotics System is a kit which, when installed on a vehicle, allows the vehicle to be operated from a safe distance. The Standardized Robotic System was designed in accordance with the Joint Architecture for Unmanned Ground Systems (JAUGS). JAUGS defines an application programmatic interface and a high level architecture that allows robotic systems and subsystems to cooperate and grow over time.
JAUGS defines vehicle operation and control from the point of view of the War Fighter. As such, it defines concepts such as command responsibilities, command hierarchies, and fundamental communication structures. JAUGS compliant robotics systems may be directly controlled by a human operator, or may exhibit any level of autonomous operational capability.
Goals of the Joint Architecture are
|
|
|
| Obstacle Avoider | Identify and avoid obstacles in the vehicle�s path |
| Obstacle Detector | Identify obstacles in the vehicle�s path |
| Waypoint Driver | Drive the vehicle through a series of map waypoints within a specified tolerance of time and path deviation. |
| Vehicle-Centered Driver | Follow a current path, or follow a current leader |
| Vector Driver | Establish a vehicle heading and speed |
| Teloperated Driver | Follow explicit vehicle mobility commands such as steering, throttle, brake, etc. |
JAUGS also defines a set of messages to facilitate communication at each of the autonomous levels defined in the above table. JAUGS messages are defined such that each message is a class inherited from JAUGS_Message Class.
Each autonomous level is implemented using a set of independent components. Components for the Teleoperated Driver level include Primitive_Driver, Mechanical_Payload, Vehicle_Parameters, and Visual_Component. The Primitive_Driver component acts on all vehicle mobility messages and communicates the status of vehicle mobility hardware components. The Mechanical_Payload compponent acts on all vehicle payload messages and communicates payload status. The Vehicle_Parameters component acts on all vehicle sensor messages and communicates sensor status. The Visual_Component acts on all messages controlling imaging devices and communicates imaging device status.
All JAUGS messages are distributed on each subsystem by a message routing system. Messages are communicated between the message routing system and JAUGS components using message queues. Message queues may be either First-in, First-out or Priority queues.
In addition to the JAUGS requirements, the SRS has the additional requirements to be portable across a wide range of vehicles including various bulldozers, HMMWVs, tanks, and special purpose mine detection systems. This portability requirement includes the ability to reconfigure the SRS system in a maintenance depot from one vehicle to another.
The SRS software implements the JAUGS system at the Teleoperated Driver level. This requires two basic subsystems per controlled vehicle; the Operator Control Unit (OCU) and the Vehicle Control Unit (VCU). The OCU and VCU communicate via a radio link. The software on the OCU and the VCU is written in Ada 95 using the Object Ada compiler. The Ada code runs on the ETS real time operating system from Phar Lap. The computers in the OCU and VCU are PC104 format single board computers with 133 MHz Pentium(tm) class processors.
The Ada code on the OCU and the VCU is over 85% reused without change. Ada 95 features used include tasks, protected types, streams, and tagged types. The SRS design is highly distributed and highly parallel, using over 50 asynchronous tasks. Each device controlled on the vehicle has two or more tasks directly associated with control. One task handles low level, device specific communications, and another task handles JAUGS level communications. Additional tasks handle built-in test, autonomous safety behavior, message routing, and communication between the OCU and the VCU. Communication between tasks within a subsystem (OCU or VCU) is handled by message queues implemented as protected objects.
Low level communication to vehicle devices and control surfaces is isolated from JAUGS level communication to allow for future changes in device communication technology. The SRS currently uses the CANOpen protocol to communicate with devices on the vehicle and the OCU.
The OCU hardware is designed to be configurable for many different vehicles. Drop-in hardware panels provide vehicle-specific controls, such as a steering wheel for a HMMWV, or a joystick for blade control on a D7 bulldozer. The OCU software recognizes each hardware panel and automatically configures itself for the vehicle corresponding to that hardware panel. OCU capabilities include: