Attachment: Technical Description of CLARAty

An overview of the CLARAty software packages in the Functional and
Decision Layers are illustrated in Figure 1. In the Function Layer,
there are about 20 packages, of which four of them are rover
adaptations, currently consisting of several wheeled rover prototypes
that include the Rocky8, FIDO, K9, and Rocky7 rovers. The Decision Layer
has 5 modules.

**Figure 1**: CLARAty Software Packages

#  {#section .unnumbered}

**Table 1. Detailed listing of the CLARAty Software items**

+---+-----------+-------------------+----------+----------+----------+
|   | Package   | Des               | Inputs & | Use      | Notes/\  |
|   |           | cription/Features | Outputs  |          | Comments |
|   |           | &                 |          |          |          |
|   |           |                   |          |          |          |
|   |           | Performance       |          |          |          |
|   |           | Limitations       |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Base      |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Share     | -   Common        |          | General  | Basic    |
| . |           |     definitions   |          | use      | Infras   |
| 1 |           |                   |          |          | tructure |
|   |           | -   Math          |          | (co      |          |
|   |           |     constants     |          | mmercial |          |
|   |           |                   |          | example: |          |
|   |           | -   Function      |          | MATLAB)  |          |
|   |           |     operators     |          |          |          |
|   |           |                   |          |          |          |
|   |           | -   Display       |          |          |          |
|   |           |     functions     |          |          |          |
|   |           |                   |          |          |          |
|   |           | A few basic       |          |          |          |
|   |           | common parameters |          |          |          |
|   |           | and functions     |          |          |          |
|   |           | defined in header |          |          |          |
|   |           | files for CLARAty |          |          |          |
|   |           | software packages |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Array     | -   1D arrays     | Inputs:  | General  | Basic    |
| . |           |                   | matrix   | Use;     | Infras   |
| 2 |           | -   2D arrays     | array    |          | tructure |
|   |           |                   | data     | MATLAB   |          |
|   |           | -   Sub arrays    |          |          |          |
|   |           |                   | Outputs: |          |          |
|   |           | Array data and    | r        |          |          |
|   |           | memory            | esulting |          |          |
|   |           | management.       | array,   |          |          |
|   |           | Creation and      | Boolean, |          |          |
|   |           | manipulation of   | display  |          |          |
|   |           | 2-D and 1-D       |          |          |          |
|   |           | arrays of numeric |          |          |          |
|   |           | and non-numeric   |          |          |          |
|   |           | template          |          |          |          |
|   |           | elements.         |          |          |          |
|   |           |                   |          |          |          |
|   |           | Performance: very |          |          |          |
|   |           | generic class,    |          |          |          |
|   |           | not specialized   |          |          |          |
|   |           | for efficiency    |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Matrix    | -   2D matrices   | Inputs:  | General  | Basic    |
| . |           |                   | matrix   | Use;     | Infras   |
| 3 |           | -   1D matrices   | array    |          | tructure |
|   |           |     (Vectors)     | data or  | MATLAB   |          |
|   |           |                   | Euler    |          |          |
|   |           | -   Fixed size    | angles   |          |          |
|   |           |     matrices      |          |          |          |
|   |           |                   | Outputs: |          |          |
|   |           | -   Rotation      |          |          |          |
|   |           |     matrices      | Results  |          |          |
|   |           |                   | after    |          |          |
|   |           | Standard matrix   | matrix   |          |          |
|   |           | arithmetic.       | op       |          |          |
|   |           | Inherited or      | erations |          |          |
|   |           | derived template  |          |          |          |
|   |           | class of          |          |          |          |
|   |           | Array_2D. It      |          |          |          |
|   |           | supports          |          |          |          |
|   |           | mathematical      |          |          |          |
|   |           | matrix operations |          |          |          |
|   |           | such as +, -, \*, |          |          |          |
|   |           | /, transpose, and |          |          |          |
|   |           | inverse. For      |          |          |          |
|   |           | efficiency it     |          |          |          |
|   |           | also supports     |          |          |          |
|   |           | special-case      |          |          |          |
|   |           | matrices such as  |          |          |          |
|   |           | vectors,          |          |          |          |
|   |           | fixed-size        |          |          |          |
|   |           | matrices, and     |          |          |          |
|   |           | rotation          |          |          |          |
|   |           | matrices. The     |          |          |          |
|   |           | rotation matrix   |          |          |          |
|   |           | can be specified  |          |          |          |
|   |           | by three Euler    |          |          |          |
|   |           | angles.           |          |          |          |
|   |           |                   |          |          |          |
|   |           | Performance: Its  |          |          |          |
|   |           | elements must be  |          |          |          |
|   |           | numerical. For    |          |          |          |
|   |           | computational     |          |          |          |
|   |           | efficiency,       |          |          |          |
|   |           | special classes   |          |          |          |
|   |           | are also defined. |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Point     | -   2-D points    | Inputs:  | General  | Basic    |
| . |           |                   |          | Use;     | Infrast  |
| 4 |           | -   3-D points    | 2-D or   |          | ructure; |
|   |           |                   | 3-D      | MATLAB   |          |
|   |           | Standard 2-D and  | point    |          | Re       |
|   |           | 3-D vector        | data     |          | ference: |
|   |           | arithmetic and    |          |          |          |
|   |           | algebra. Supports | Outputs: |          | \[Paul,  |
|   |           | 3-D or 2-D vector |          |          | 1981;    |
|   |           | operations such   | Results  |          | Brad,    |
|   |           | as scaling,       | after    |          | 1982;    |
|   |           | addition,         | point    |          | Craig,   |
|   |           | subtraction, dot  | vector   |          | 1986;    |
|   |           | product, cross    | op       |          | M        |
|   |           | product,          | erations |          | cKerrow, |
|   |           | magnitude         |          |          | 1991\]   |
|   |           |                   |          |          |          |
|   |           | Performance: Its  |          |          |          |
|   |           | elements must be  |          |          |          |
|   |           | numerical.        |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | T         | -   Homogeneous   | Inputs:  | Co       | Basic    |
| . | ransforms |     transforms    | 3-D      | mmercial | Infras   |
| 5 |           |                   | point &  | example: | tructure |
|   |           | -   Quaternions   | 3 angles |          |          |
|   |           |                   | for      | Adept    |          |
|   |           | Efficient         | HTrans;  | Tec      |          |
|   |           | homogeneous       | 4        | hnology, |          |
|   |           | transform and     | elements | V+       |          |
|   |           | quaternion        | for      | pro      |          |
|   |           | classes           | qu       | gramming |          |
|   |           | templatized by    | aternion | l        |          |
|   |           | element type.     |          | anguage; |          |
|   |           |                   | Outputs: |          |          |
|   |           | Location is       | r        | Matlab   |          |
|   |           | HTrans\<double\>. | esulting |          |          |
|   |           |                   | t        |          |          |
|   |           | Performance: For  | ransform |          |          |
|   |           | computational     |          |          |          |
|   |           | efficiency, the   |          |          |          |
|   |           | 4x4 Homogeneous   |          |          |          |
|   |           | Transform uses a  |          |          |          |
|   |           | 3-D Point and a   |          |          |          |
|   |           | 3x3 rotation      |          |          |          |
|   |           | matrix            |          |          |          |
|   |           | internally.       |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Frame     | -   Coordinate    | Inputs:  | General  |          |
| . |           |     frames        | parent   | use      |          |
| 6 |           |                   | frame,   |          |          |
|   |           | Multi-thread-safe | location |          |          |
|   |           | relational data   |          |          |          |
|   |           | structure that    | Outputs: |          |          |
|   |           | connects          |          |          |          |
|   |           | homogeneous       | Status   |          |          |
|   |           | transforms in a   | or       |          |          |
|   |           | coherent tree.    | r        |          |          |
|   |           | Efficient         | esulting |          |          |
|   |           | coordinate        | frame    |          |          |
|   |           | transformation    |          |          |          |
|   |           | that can be       |          |          |          |
|   |           | represented by    |          |          |          |
|   |           | either            |          |          |          |
|   |           | Homogeneous       |          |          |          |
|   |           | Transforms or     |          |          |          |
|   |           | Quaternion/Point  |          |          |          |
|   |           | Pair.             |          |          |          |
|   |           |                   |          |          |          |
|   |           | It establishes    |          |          |          |
|   |           | tree relationship |          |          |          |
|   |           | between frames.   |          |          |          |
|   |           |                   |          |          |          |
|   |           | Performance:      |          |          |          |
|   |           | supports          |          |          |          |
|   |           | systematic        |          |          |          |
|   |           | generation and    |          |          |          |
|   |           | retrieval of      |          |          |          |
|   |           | relations between |          |          |          |
|   |           | frames            |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Device    | -   Device        |          |          |          |
| . |           |                   |          |          |          |
| 7 |           | ```{=html}        |          |          |          |
|   |           | <!-- -->          |          |          |          |
|   |           | ```               |          |          |          |
|   |           | -   Facility for  |          |          |          |
|   |           |     device        |          |          |          |
|   |           |     operations    |          |          |          |
|   |           |     such as power |          |          |          |
|   |           |     switching,    |          |          |          |
|   |           |     generic       |          |          |          |
|   |           |     status        |          |          |          |
|   |           |     reporting,    |          |          |          |
|   |           |     and mounting  |          |          |          |
|   |           |     configuration |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Resource  | -   Timers        | Output:  | Basic    | Re       |
| . |           |                   | time     | classes  | ference: |
| 8 |           | -   System        | elapsed  | such as  | \[       |
|   |           |     Threads       |          | in ACE,  | Schmidt, |
|   |           |                   |          | which is | 2002\]   |
|   |           | System support    |          | a        |          |
|   |           | for timing and    |          | co       | P        |
|   |           | multi-threaded    |          | mmercial | artially |
|   |           | applications;     |          | toolkit  | impl     |
|   |           |                   |          | for      | emented. |
|   |           | get_time_elapsed. |          | de       |          |
|   |           |                   |          | veloping |          |
|   |           |                   |          | portable |          |
|   |           |                   |          | appli    |          |
|   |           |                   |          | cations. |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | C         | -   Linked lists  |          | Similar  | P        |
| . | ontainers |                   |          | to C++   | artially |
| 9 |           | -   Maps          |          | Standard | imp      |
|   |           |                   |          | Template | lemented |
|   |           | -   Hash Table    |          | Library  |          |
|   |           |                   |          |          |          |
|   |           | -   etc.          |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | State &   | -   State data    |          |          | P        |
| . | Telemetry |     logging       |          |          | artially |
| 1 |           |                   |          |          | imp      |
| 0 |           | -   Generic       |          |          | lemented |
|   |           |     interface for |          |          |          |
|   |           |     device        |          |          |          |
|   |           |     telemetry     |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Qt        | -   Qt_util       | Outputs: | Tro      | Re       |
| . | Display   |                   | Qt       | llTech's | ference: |
| 1 | Interface | -   Qt_frame      | displays | Qt is a  | \[Da     |
| 1 |           |                   |          | co       | lheimer, |
|   |           | -                 |          | mmercial | 2002\]   |
|   |           |    Qt_manipulator |          | software |          |
|   |           |                   |          | toolkit  |          |
|   |           | -   Qt_locomotor  |          | for      |          |
|   |           |                   |          | multi-   |          |
|   |           | -   Qt_rover      |          | platform |          |
|   |           |                   |          | C++ GUI  |          |
|   |           | -   Qt_camera     |          | (g       |          |
|   |           |                   |          | raphical |          |
|   |           | Display           |          | user     |          |
|   |           | interfaces using  |          | in       |          |
|   |           | Qt for            |          | terface) |          |
|   |           | visualization and |          |          |          |
|   |           | control of        |          |          |          |
|   |           | various           |          |          |          |
|   |           | components        |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 2 | Motion    |                   |          |          |          |
|   | Control   |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 2 | Motor     | -   Open-loop     | Inputs:  | Basic    |          |
| . |           |     motors        | desired  | motion   |          |
| 1 |           |                   | motor    | control  |          |
|   |           | -   Controlled    | p        | software |          |
|   |           |     motors        | osition, |          |          |
|   |           |                   | v        | (co      |          |
|   |           | -   Coordinated   | elocity, | mmercial |          |
|   |           |     motion        | accel    | e        |          |
|   |           |                   | eration, | xamples: |          |
|   |           | Basic single-axis | filter   |          |          |
|   |           | motor control. It | par      | An       |          |
|   |           | controls the      | ameters, | imatics, |          |
|   |           | operation and     | etc.     | Galil,   |          |
|   |           | functionality of  |          | etc.)    |          |
|   |           | a motor. Motor    | Outputs: |          |          |
|   |           | coordination      | co       |          |          |
|   |           | synchronizes the  | ntrolled |          |          |
|   |           | motions of        | motion   |          |          |
|   |           | multiple motors.  | and      |          |          |
|   |           | Methods specific  | report   |          |          |
|   |           | to different      | status   |          |          |
|   |           | motor             |          |          |          |
|   |           | implementations   |          |          |          |
|   |           | are defined in    |          |          |          |
|   |           | Motor_Impl.       |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 2 | T         | -   Trajectories  | Inputs:  | Co       |          |
| . | rajectory |                   | final    | mmercial |          |
| 2 |           | -   Trajectory    | p        | e        |          |
|   |           |     generators    | osition, | xamples: |          |
|   |           |                   | max_vel, |          |          |
|   |           | Generates a       | &        | Adept V+ |          |
|   |           | trapezoidal       | acce     | o        |          |
|   |           | profile           | leration | perating |          |
|   |           |                   |          | system,  |          |
|   |           |                   | Outputs: | Seiko    |          |
|   |           |                   | tr       | Robotics |          |
|   |           |                   | ajectory | OS (each |          |
|   |           |                   | profile  | in       |          |
|   |           |                   |          | dustrial |          |
|   |           |                   |          | robotic  |          |
|   |           |                   |          | platform |          |
|   |           |                   |          | has one) |          |
+---+-----------+-------------------+----------+----------+----------+
| 2 | Co        | -   Motor         |          |          | P        |
| . | ordinated |     coordinators  |          |          | artially |
| 3 | Systems   |                   |          |          | imp      |
|   |           |                   |          |          | lemented |
+---+-----------+-------------------+----------+----------+----------+
| 3 | Hardware  |                   |          |          |          |
|   | Drivers   |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 3 | Motion    | -   HCTL 1100     | Inputs:  | HP       |          |
| . | Co        |     motor         | motor    | /Agilant |          |
| 1 | ntrollers |     controller    | control  | HCTL     |          |
|   |           |                   | pa       | 1100     |          |
|   |           | -   LM629 motor   | rameters | spec.    |          |
|   |           |     controller    |          | sheet;   |          |
|   |           |                   | Outputs: |          |          |
|   |           | Supports          | control  | National |          |
|   |           | functions for     | motor    | Semic    |          |
|   |           | motor controller  | and      | onductor |          |
|   |           | chips             | report   |          |          |
|   |           |                   | status   | LM629    |          |
|   |           |                   |          | spec.    |          |
|   |           |                   |          | sheet    |          |
+---+-----------+-------------------+----------+----------+----------+
| 3 | Frame     | -   Imagenation   | Inputs:  | Ima      |          |
| . | Grabbers  |     CX100 frame   | frame    | genation |          |
| 2 | & Drivers |     grabber       | grabber  | frame    |          |
|   |           |                   | control  | grabber  |          |
|   |           | -   Imagenation   | pa       | manuals  |          |
|   |           |     PX610 frame   | rameters |          |          |
|   |           |     grabber       |          |          |          |
|   |           |                   | Outputs: |          |          |
|   |           | -   1394 camera   | grab     |          |          |
|   |           |     driver        | camera   |          |          |
|   |           |                   | image    |          |          |
|   |           | Interface         | and      |          |          |
|   |           | functions for     | report   |          |          |
|   |           | various frame     | status   |          |          |
|   |           | grabbers          |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 3 | I/O       | -   VPAR10        | Inputs:  | Manuals  |          |
| . | Boards &  |     digital I/O   | DIO or   | for      |          |
| 3 | Chips     |     board         | AIO      | various  |          |
|   |           |                   | related  | I/O      |          |
|   |           | -   Sensoray S720 | pa       | boards;  |          |
|   |           |     digital I/O   | rameters |          |          |
|   |           |     board         | and/or   | Maxum    |          |
|   |           |                   | data     | A/D and  |          |
|   |           | -   VADC20 analog |          | D/A      |          |
|   |           |     input board   | Outputs: | spec.    |          |
|   |           |                   | status   | sheets   |          |
|   |           | -   MAX186 analog | or data  |          |          |
|   |           |     to digital    | read     |          |          |
|   |           |     converter     |          |          |          |
|   |           |                   |          |          |          |
|   |           | -   MAX528        |          |          |          |
|   |           |     digital to    |          |          |          |
|   |           |     analog        |          |          |          |
|   |           |     converter     |          |          |          |
|   |           |                   |          |          |          |
|   |           | Interface         |          |          |          |
|   |           | functions for     |          |          |          |
|   |           | various DIO and   |          |          |          |
|   |           | AIO boards        |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 3 | Custom    | -   Widget board  | Inputs:  | See 3.1  | J        |
| . | Boards    |     motion        | widget   | and 3.3  | PL-built |
| 4 |           |     control       | board    | above    | board    |
|   |           |                   | related  |          | using    |
|   |           | -   Widget board  | pa       |          | readily  |
|   |           |     firmware      | rameters |          | a        |
|   |           |                   |          |          | vailable |
|   |           | Interface         | Outputs: |          | co       |
|   |           | functions for the | status   |          | mmercial |
|   |           | custom widget     | or data  |          | chips    |
|   |           | board with I2C    | read     |          |          |
|   |           | bus, DIO, AI, AO, |          |          |          |
|   |           | and motor         |          |          |          |
|   |           | controller; it    |          |          |          |
|   |           | uses HCTL 1100,   |          |          |          |
|   |           | MAX186/528        |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 3 | Other     | -   VISA VME to   | Inputs:  |          |          |
| . |           |     ISA converter | hardware |          |          |
| 5 |           |                   | related  |          |          |
|   |           | -   I2C master    | pa       |          |          |
|   |           |     controller    | rameters |          |          |
|   |           |                   |          |          |          |
|   |           | -   PCI           | Outputs: |          |          |
|   |           |     controller    | status   |          |          |
|   |           |                   | or data  |          |          |
|   |           | -   Crossbow DMU  |          |          |          |
|   |           |     inertial      |          |          |          |
|   |           |     measurement   |          |          |          |
|   |           |     unit          |          |          |          |
|   |           |                   |          |          |          |
|   |           | Supports          |          |          |          |
|   |           | interface         |          |          |          |
|   |           | functions for the |          |          |          |
|   |           | hardware listed   |          |          |          |
|   |           | above             |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 4 | Sensor    |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 4 | IMUs      | -   Generic       | Outputs: |          |          |
| . |           |     inertial      | IMU      |          |          |
| 1 |           |     measurement   | meas     |          |          |
|   |           |     unit          | urements |          |          |
|   |           |                   | data     |          |          |
|   |           |    infrastructure | such as  |          |          |
|   |           |                   | roll/p   |          |          |
|   |           | Get IMU           | itch/yaw |          |          |
|   |           | measurements data | angle,   |          |          |
|   |           |                   | rate,    |          |          |
|   |           |                   | acce     |          |          |
|   |           |                   | leration |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 4 | Specific  | -   Crossbow DMU  |          | Crossbow |          |
| . | IMUs      |     driver        |          | DMU is a |          |
| 2 | implem    |                   |          | co       |          |
|   | entations |                   |          | mmercial |          |
|   |           |                   |          | motion   |          |
|   |           |                   |          | and      |          |
|   |           |                   |          | attitude |          |
|   |           |                   |          | sensing  |          |
|   |           |                   |          | unit.    |          |
+---+-----------+-------------------+----------+----------+----------+
| 4 | Or        | -   Generic       |          |          | P        |
| . | ientation |     electronic    |          |          | artially |
| 3 | Sensors   |     tilt sensors  |          |          | imp      |
|   |           |                   |          |          | lemented |
|   |           | -   Compasses     |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 4 | Rate      | -   Generic gyros |          |          | P        |
| . | Sensors   |     structure     |          |          | artially |
| 4 |           |                   |          |          | imp      |
|   |           |                   |          |          | lemented |
+---+-----------+-------------------+----------+----------+----------+
| 4 | Te        | -   Generic       |          |          | P        |
| . | mperature |     temperature   |          |          | artially |
| 5 | Sensors   |     sensor        |          |          | imp      |
|   |           |                   |          |          | lemented |
+---+-----------+-------------------+----------+----------+----------+
| 4 | Voltage & | -   Generic       |          |          | P        |
| . | Current   |     voltage and   |          |          | artially |
| 6 | Sensors   |     current       |          |          | imp      |
|   |           |     sensors       |          |          | lemented |
+---+-----------+-------------------+----------+----------+----------+
| 4 | Power     | -   Power system  |          |          | P        |
| . | System    |     manager       |          |          | artially |
| 7 | Manager   |                   |          |          | imp      |
|   |           |                   |          |          | lemented |
+---+-----------+-------------------+----------+----------+----------+
| 5 | Inp       |                   |          |          |          |
|   | ut/Output |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 5 | DIO       | -   Digital       | Inputs:  | All      |          |
| . |           |     input/output  | desired  | robotic  |          |
| 1 |           |                   | bit      | OS's     |          |
|   |           | DIO is used to    | pattern  | have I/O |          |
|   |           | control a single  |          | control  |          |
|   |           | port, several     | Outputs: | and      |          |
|   |           | ports, or a       | actual   | ma       |          |
|   |           | combination of    | bit      | nagement |          |
|   |           | parts of certain  | pattern  |          |          |
|   |           | ports.            |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 6 | AIO       | -   Analog        |          |          |          |
| . |           |     input/output  |          |          |          |
| 2 |           |                   |          |          |          |
|   |           | AI reads data     |          |          |          |
|   |           | from              |          |          |          |
|   |           | analog-to-digital |          |          |          |
|   |           | converter, while  |          |          |          |
|   |           | AO writes data to |          |          |          |
|   |           | digital-to-analog |          |          |          |
|   |           | converter.        |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 6 | Comm      |                   |          |          |          |
|   | unication |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 6 | Socket    | -   Socket        | Inputs:  |          | Example  |
| . |           |     UDP/TCP       | input    |          | source   |
| 1 |           |     protocols     | message  |          | codes    |
|   |           |                   |          |          | widely   |
|   |           | Send and receive  | Outputs: |          | a        |
|   |           | messages through  | output   |          | vailable |
|   |           | sockets; Uses     | message  |          | (e.g.,   |
|   |           | standard network  |          |          | Sun      |
|   |           | protocol          |          |          | manual)  |
+---+-----------+-------------------+----------+----------+----------+
| 6 | I2C       | -   I2C bus       | Inputs:  |          |          |
| . |           |     interface     | input    |          |          |
| 2 |           |                   | message  |          |          |
|   |           | Send and receive  |          |          |          |
|   |           | messages through  | Outputs: |          |          |
|   |           | I2C bus           | output   |          |          |
|   |           |                   | message  |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 6 | Serial    | -   Serial        | Inputs:  |          |          |
| . | driver    |     interface     | input    |          |          |
| 3 |           |     driver        | message  |          |          |
|   |           |                   |          |          |          |
|   |           | Send and receive  | Outputs: |          |          |
|   |           | messages through  | output   |          |          |
|   |           | serial I/O lines  | message  |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 7 | Man       |                   |          |          |          |
|   | ipulation |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 7 | Man       | -   Limited DOF   | Inputs:  | Basic    | Re       |
| . | ipulators |     manipulators  | man      | man      | ference: |
| 1 |           |                   | ipulator | ipulator | \[Paul,  |
|   |           | -                 | control  | control  | 1981;    |
|   |           |  Manipulator_Impl | pa       | s        | Brad,    |
|   |           |                   | rameters | oftware; | 1982;    |
|   |           | -   Redundant     |          |          | Craig,   |
|   |           |     manipulators  | Outputs: | Co       | 1986;    |
|   |           |                   | control  | mmercial | M        |
|   |           | -   End effectors | the      | e        | cKerrow, |
|   |           |                   | man      | xamples: | 1991\];  |
|   |           | Serail link       | ipulator |          |          |
|   |           | manipulator       | and      | Adept,   | R        |
|   |           | operation.        | report   | Fanuc,   | edundant |
|   |           | Includes stow and | status   | Yamaha,  | man      |
|   |           | unstow of a       |          | Seiko,   | ipulator |
|   |           | manipulator as    |          | Kuka     | not      |
|   |           | well as joint and |          |          | imp      |
|   |           | Cartesian motions |          |          | lemented |
|   |           | using forward/    |          |          |          |
|   |           | inverse           |          |          |          |
|   |           | kinematics;       |          |          |          |
|   |           | Methods specific  |          |          |          |
|   |           | to different      |          |          |          |
|   |           | manipulator       |          |          |          |
|   |           | implementations   |          |          |          |
|   |           | defined in        |          |          |          |
|   |           | Manipulator_Impl  |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 7 | Sen       | -   Stereovision  |          |          | Vision   |
| . | sor-based |     based         |          |          | /tactile |
| 2 | Man       |     manipulation  |          |          | mani     |
|   | ipulation |                   |          |          | pulation |
|   |           | -                 |          |          | p        |
|   |           |    Vision/tactile |          |          | artially |
|   |           |     manipulation  |          |          | imp      |
|   |           |                   |          |          | lemented |
+---+-----------+-------------------+----------+----------+----------+
| 8 | L         |                   |          |          |          |
|   | ocomotion |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 8 | Wheel     | -   2-D wheel     | Inputs:  |          | Re       |
| . | L         |     locomotion    | desired  |          | ference: |
| 1 | ocomotion |                   | vehicle  |          |          |
|   |           | -   3-D Rocker    | p        |          | \        |
|   |           |     Bogie         | osition, |          | [Nesnas, |
|   |           |     Locomotion    | heading, |          | 2000\]   |
|   |           |                   | or       |          |          |
|   |           | -   Continuous    | velocity |          |          |
|   |           |     driving       |          |          |          |
|   |           |     modules       | Outputs: |          |          |
|   |           |                   | drive    |          |          |
|   |           | -   Motion        | the      |          |          |
|   |           |     sequences     | vehicle  |          |          |
|   |           |                   | and      |          |          |
|   |           | Wheel based       | report   |          |          |
|   |           | locomotion and    | status   |          |          |
|   |           | driving. It       |          |          |          |
|   |           | supports position |          |          |          |
|   |           | driving (crab and |          |          |          |
|   |           | arc motion) and   |          |          |          |
|   |           | velocity driving  |          |          |          |
|   |           | of a rover        |          |          |          |
|   |           | vehicle that can  |          |          |          |
|   |           | be fully,         |          |          |          |
|   |           | partially, or     |          |          |          |
|   |           | skid steered.     |          |          |          |
|   |           |                   |          |          |          |
|   |           | Performance: It   |          |          |          |
|   |           | either steers or  |          |          |          |
|   |           | drives wheel      |          |          |          |
|   |           | motors. Currently |          |          |          |
|   |           | it does not steer |          |          |          |
|   |           | or change heading |          |          |          |
|   |           | while driving.    |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 8 | Legged    | -   Legged        |          |          | P        |
| . | L         |     Locomotors    |          |          | artially |
| 2 | ocomotion |                   |          |          | Imp      |
|   |           |                   |          |          | lemented |
+---+-----------+-------------------+----------+----------+----------+
| 8 | Hybrid    | -   Wheel/Legged  |          |          | P        |
| . | L         |     Locomotion    |          |          | artially |
| 3 | ocomotion |                   |          |          | imp      |
|   |           |                   |          |          | lemented |
+---+-----------+-------------------+----------+----------+----------+
| 9 | Vision    |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 9 | Image     | -   Image         | Inputs:  | Basic    | Image    |
| . | Related   |                   | images   | image    | sets and |
| 1 | Data      | -   Color Image   | or image | pr       | pyramid  |
|   | S         |                   | pa       | ocessing | p        |
|   | tructures | -   Camera Image  | rameters | functi   | artially |
|   |           |                   |          | onality; | imp      |
|   |           | -   Image Sets    | Outputs: | a        | lemented |
|   |           |                   | images,  | vailable |          |
|   |           | -   Image Pyramid | data,    | in       |          |
|   |           |                   | par      | MATLAB   |          |
|   |           | -   Point Cloud   | ameters, |          |          |
|   |           |     for 3D points | or       |          |          |
|   |           |                   | status   |          |          |
|   |           | Image inherits    |          |          |          |
|   |           | data structure    |          |          |          |
|   |           | from Array_2D and |          |          |          |
|   |           | math operations   |          |          |          |
|   |           | from Matrix. It   |          |          |          |
|   |           | adds concept of   |          |          |          |
|   |           | pixel and         |          |          |          |
|   |           | sub-pixel         |          |          |          |
|   |           | sampling. Image   |          |          |          |
|   |           | Sets and Pyramid  |          |          |          |
|   |           | are image         |          |          |          |
|   |           | containers.       |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 9 | Cameras & | -   Camera        | Inputs:  |          | Camera   |
| . | Image     |     (single)      | camera   |          | Pair     |
| 2 | Ac        |                   | control  |          | p        |
|   | quisition | -   Multi Cameras | or model |          | artially |
|   |           |                   | pa       |          | imp      |
|   |           |    (synchronized) | rameters |          | lemented |
|   |           |                   |          |          |          |
|   |           | -   Camera Impl's | Outputs: |          |          |
|   |           |                   | images,  |          |          |
|   |           | -   Camera Pair   | data,    |          |          |
|   |           |                   | par      |          |          |
|   |           | -   Camera Models | ameters, |          |          |
|   |           |                   | or       |          |          |
|   |           | Wrappers around   | status   |          |          |
|   |           | existing drivers; |          |          |          |
|   |           | no new            |          |          |          |
|   |           | functionality     |          |          |          |
|   |           | added.            |          |          |          |
|   |           | Multi-Cameras     |          |          |          |
|   |           | enables           |          |          |          |
|   |           | synchronized      |          |          |          |
|   |           | image             |          |          |          |
|   |           | acquisition.      |          |          |          |
|   |           | Camera Impls are  |          |          |          |
|   |           | hardware-specific |          |          |          |
|   |           | implementations   |          |          |          |
|   |           | such as           |          |          |          |
|   |           | Came              |          |          |          |
|   |           | ra_Impl_Linux1394 |          |          |          |
|   |           | and               |          |          |          |
|   |           | Mult              |          |          |          |
|   |           | i_Impl_Linux1394. |          |          |          |
|   |           | Camera Image is   |          |          |          |
|   |           | an Image with the |          |          |          |
|   |           | Camera Model and  |          |          |          |
|   |           | the frame number. |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 9 | Camera    | -   Camera        | Inputs:  | Intel's  | P        |
| . | Ca        |     calibration   | camera   | OpenCV   | artially |
| 3 | libration |                   | model    |          | imp      |
|   |           | Camera            | selected |          | lemented |
|   |           | calibration using |          |          |          |
|   |           | CAHVOR \[JPL\] or | Outputs: |          | Re       |
|   |           | Tsai/matrix       | camera   |          | ference: |
|   |           | \[OpenCV, SRI\]   | model    |          | \[Intel, |
|   |           | model. All        | pa       |          | 1999\]   |
|   |           | implementations   | rameters |          |          |
|   |           | are published     | after    |          |          |
|   |           | and/or            | cal      |          |          |
|   |           | distributed as a  | ibration |          |          |
|   |           | library           |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 9 | Image     | -   Image_Op      | Inputs:  | Basic;   |          |
| . | O         |     Interface     | images   | all      |          |
| 4 | perations |                   | and      | a        |          |
|   | and       | -   Convolve_Op   | pa       | vailable |          |
|   | P         |                   | rameters | in       |          |
|   | rocessing | -   Gradient_Op   | for      | MATLAB   |          |
|   |           |                   | o        | vision   |          |
|   |           | -   2-D image     | peration | pr       |          |
|   |           |     processing    |          | ocessing |          |
|   |           |                   | Outputs: | package  |          |
|   |           | -   Filtering &   | images   |          |          |
|   |           |     smoothing     | after    |          |          |
|   |           |                   | the      |          |          |
|   |           | -   Edge          | o        |          |          |
|   |           |     detection     | peration |          |          |
|   |           |                   |          |          |          |
|   |           | -   Blob          |          |          |          |
|   |           |     detection     |          |          |          |
|   |           |                   |          |          |          |
|   |           | -   Corner        |          |          |          |
|   |           |     feature       |          |          |          |
|   |           |     detection     |          |          |          |
|   |           |                   |          |          |          |
|   |           | Image_Op          |          |          |          |
|   |           | Interface         |          |          |          |
|   |           | supports image    |          |          |          |
|   |           | filtering &       |          |          |          |
|   |           | smoothing.        |          |          |          |
|   |           | Examples include  |          |          |          |
|   |           | convolution and   |          |          |          |
|   |           | gradient          |          |          |          |
|   |           | operations, which |          |          |          |
|   |           | can be used for   |          |          |          |
|   |           | edge, blob, or    |          |          |          |
|   |           | corner detection. |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 9 | Image     | -   Image IO      | Inputs:  | Basic    |          |
| . | related   |     loads and     | images   | image    |          |
| 5 | file      |     saves images  | or image | I/O and  |          |
|   | o         |     to various    | pa       | display  |          |
|   | perations |     formats.      | rameters | functi   |          |
|   | and       |                   |          | onality; |          |
|   | display   | -   Image         | Outputs: | a        |          |
|   |           |     Converter     | images,  | vailable |          |
|   |           |     converts to   | data,    | in       |          |
|   |           |     other library | par      | MATLAB   |          |
|   |           |                   | ameters, |          |          |
|   |           |   implementations | or       |          |          |
|   |           |     (OpenCv,      | status   |          |          |
|   |           |     JPLPic).      |          |          |          |
|   |           |                   |          |          |          |
|   |           | -   Image         |          |          |          |
|   |           |     Displayer     |          |          |          |
|   |           |     displays the  |          |          |          |
|   |           |     image.        |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 9 | Machine   | -   Stereovision  |          |          |          |
| . | Vision    |     Interface     |          |          |          |
| 6 | Interface |                   |          |          |          |
|   |           | -   Visual        |          |          |          |
|   |           |     Tracking      |          |          |          |
|   |           |     Interface     |          |          |          |
|   |           |                   |          |          |          |
|   |           | -   Visual        |          |          |          |
|   |           |     Odometry      |          |          |          |
|   |           |     Interface     |          |          |          |
|   |           |                   |          |          |          |
|   |           | -   Image         |          |          |          |
|   |           |     matching      |          |          |          |
|   |           |     interface     |          |          |          |
|   |           |                   |          |          |          |
|   |           | An interface to   |          |          |          |
|   |           | support various   |          |          |          |
|   |           | implementations   |          |          |          |
|   |           | of stereo vision  |          |          |          |
|   |           | algorithms        |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 9 | Stereo    | -   JPL stereo    | Inputs:  | SRI      |          |
| . | Vision    |     engine        | stereo   | provides |          |
| 7 | Imple     |                   | image    | co       |          |
|   | mentation | -   SRI stereo    | pair and | mmercial |          |
|   |           |     engine        | ca       | product  |          |
|   |           |     (commercial)  | librated | SVS      |          |
|   |           |                   | camera   | stereo   |          |
|   |           | -   Ames stereo   | model    | vision   |          |
|   |           |     engine        |          |          |          |
|   |           |                   | Outputs: |          |          |
|   |           | Specific          | d        |          |          |
|   |           | implementations   | isparity |          |          |
|   |           | of stereo vision  | map      |          |          |
|   |           | algorithms.       | after    |          |          |
|   |           | Stereo algorithms | stereo   |          |          |
|   |           | do stereo         | matching |          |          |
|   |           | matching between  | and      |          |          |
|   |           | left and right    | range    |          |          |
|   |           | images, and then  | map      |          |          |
|   |           | computes the      |          |          |          |
|   |           | range for a given |          |          |          |
|   |           | calibrated camera |          |          |          |
|   |           | model.            |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 9 | Visual    | -   2-D feature   |          |          | Re       |
| . | Tracking  |     detection &   |          |          | ference: |
| 8 | Imple     |     tracking      |          |          |          |
|   | mentation |                   |          |          | \[Shi,   |
|   |           | -   3-D feature   |          |          | 1994\];  |
|   |           |     detection &   |          |          |          |
|   |           |     tracking      |          |          | P        |
|   |           |                   |          |          | artially |
|   |           | -   Combined 2-D  |          |          | imp      |
|   |           |     & 3-D         |          |          | lemented |
|   |           |     tracking      |          |          |          |
|   |           |                   |          |          |          |
|   |           | Basic feature     |          |          |          |
|   |           | extractions       |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 9 | Visual    | -   Visual        | Inputs:  |          | Re       |
| . | Odometry  |     odometry      | image    |          | ference: |
| 9 | Imple     |                   | s        |          | \[Olson, |
|   | mentation | Estimation of     | equences |          | 2000\];  |
|   |           | rover motion from |          |          |          |
|   |           | tracking rock     | Outputs: |          | P        |
|   |           | features and 3-D  | es       |          | artially |
|   |           | range data using  | timation |          | imp      |
|   |           | vision            | of 2-D   |          | lemented |
|   |           |                   | motion   |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Science   |                   |          |          |          |
| 0 |           |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Spec      | -   Generic       |          |          |          |
| 0 | trometers |     Spectra       |          |          |          |
| . |           |     classes       |          |          |          |
| 1 |           |                   |          |          |          |
|   |           | -   Generic       |          |          |          |
|   |           |     Spectrometer  |          |          |          |
|   |           |     classes       |          |          |          |
|   |           |                   |          |          |          |
|   |           | Generic glue code |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Science   | -   Edge          |          |          | P        |
| 0 | Image     |     detection     |          |          | artially |
| . | Analysis  |                   |          |          | imp      |
| 2 |           | -   Horizon       |          |          | lemented |
|   |           |     detection     |          |          |          |
|   |           |                   |          |          |          |
|   |           | -   Finding       |          |          |          |
|   |           |     solids        |          |          |          |
|   |           |                   |          |          |          |
|   |           | -   Finding       |          |          |          |
|   |           |     layers        |          |          |          |
|   |           |                   |          |          |          |
|   |           | -   Ellipse       |          |          |          |
|   |           |     Summary       |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Science   | -   Carbonate     |          |          |          |
| 0 | Spectrum  |     identifier    |          |          |          |
| . | Analysis  |                   |          |          |          |
| 3 |           |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Science   | -   Special       |          |          |          |
| 0 | Cameras   |     science       |          |          |          |
| . |           |     cameras       |          |          |          |
| 4 |           |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | E         |                   |          |          |          |
| 1 | stimation |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Kalman    | -   Kalman filter |          |          | Re       |
| 1 | Filter    |                   |          |          | ference: |
| . |           |    implementation |          |          | \[       |
| 1 |           |                   |          |          | Balaram, |
|   |           |                   |          |          | 2000\]   |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Pose      | -   Pose          |          |          |          |
| 1 | Estimator |     estimator     |          |          |          |
| . | Interface |     interface     |          |          |          |
| 2 |           |                   |          |          |          |
|   |           | An interface to   |          |          |          |
|   |           | support various   |          |          |          |
|   |           | implementations   |          |          |          |
|   |           | of pose           |          |          |          |
|   |           | estimators        |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Pose      | -   Wheel-based   | Inputs:  |          | Re       |
| 1 | Estimator |     Pose          | various  |          | ference: |
| . | Imple     |     estimator     | sensor   |          |          |
| 3 | mentation |                   | readings |          | \[       |
|   |           | -   Legged-based  |          |          | Balaram, |
|   |           |     Pose          | Outputs: |          | 2000\]   |
|   |           |     Estimator     | vehicle  |          |          |
|   |           |                   | pose     |          | Legg     |
|   |           | Estimates the     | estimate |          | ed-based |
|   |           | vehicle pose      |          |          | P        |
|   |           | (position and     |          |          | artially |
|   |           | orientation)      |          |          | imp      |
|   |           | using multiple    |          |          | lemented |
|   |           | sensors such as   |          |          |          |
|   |           | IMU, wheel        |          |          |          |
|   |           | odometry. Basic   |          |          |          |
|   |           | estimation: work  |          |          |          |
|   |           | done by FIDO and  |          |          |          |
|   |           | Rocky 7 rovers    |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | N         |                   |          |          |          |
| 2 | avigation |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Local     | -   Generic local | Inputs:  | Co       |          |
| 2 | navigator |     navigator     | desired  | mmercial |          |
| . |           |     structure     | path,    | example: |          |
| 1 |           |                   | goal to  |          |          |
|   |           | Generic interface | achieve  | MOBILITY |          |
|   |           | for specific      |          | software |          |
|   |           | implementations   | Outputs: | from     |          |
|   |           |                   | motion   | IROBOT   |          |
|   |           |                   | sequence |          |          |
|   |           |                   | to a     |          |          |
|   |           |                   | l        |          |          |
|   |           |                   | ocomotor |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Local     | -   Generic local |          | Co       |          |
| 2 | Path      |     path planner  |          | mmercial |          |
| . | planner   |     structure     |          | example: |          |
| 2 |           |                   |          |          |          |
|   |           | Generic interface |          | MOBILITY |          |
|   |           | for specific      |          | software |          |
|   |           | implementations   |          | from     |          |
|   |           |                   |          | IROBOT   |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | N         | -   MER/GESTALT   | Inputs:  |          | Re       |
| 2 | avigation |     navigator     | waypoint |          | ference: |
| . | Implem    |                   | goal,    |          |          |
| 3 | entations | -   Morphin       | stereo   |          | \[G      |
|   |           |     Navigator     | image or |          | oldberg, |
|   |           |     (CMU)         | range    |          | 2002\];  |
|   |           |                   | map      |          |          |
|   |           | -   Fuzzy         |          |          | Fuzzy    |
|   |           |     Navigator     | Outputs: |          | N        |
|   |           |                   | d        |          | avigator |
|   |           | Gestalt Navigator | etermine |          | p        |
|   |           | does the          | the path |          | artially |
|   |           | following         | to the   |          | imp      |
|   |           | steps: 1)         | goal     |          | lemented |
|   |           | generate planes   | waypoint |          |          |
|   |           | for all cells     |          |          |          |
|   |           | using range map,  |          |          |          |
|   |           | 2) evaluate cells |          |          |          |
|   |           | to map obstacles, |          |          |          |
|   |           | 3) generate path  |          |          |          |
|   |           | votes, 4) merge   |          |          |          |
|   |           | votes, and 5)     |          |          |          |
|   |           | select best arc   |          |          |          |
|   |           | path              |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Path      |                   |          |          |          |
| 3 | Planning  |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Global    | -   Generic path  |          |          |          |
| 3 | Path      |     planner       |          |          |          |
| . | Planners  |     structure     |          |          |          |
| 1 |           |                   |          |          |          |
|   |           | Generic interface |          |          |          |
|   |           | for specific      |          |          |          |
|   |           | implementations   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Global    | -   D\* path      |          |          | D\* and  |
| 3 | Path      |     planner (CMU) |          |          | ISE path |
| . | Planner   |                   |          |          | planner  |
| 2 | Imple     | -   Tangent graph |          |          | p        |
|   | mentation |     path planner  |          |          | artially |
|   |           |     (JPL)         |          |          | impl     |
|   |           |                   |          |          | emented; |
|   |           | -   ISE path      |          |          |          |
|   |           |     planner (CMU) |          |          | Ref      |
|   |           |                   |          |          | erences: |
|   |           | D\* path planner  |          |          | \        |
|   |           | accumulates       |          |          | [Stentz, |
|   |           | global obstacle   |          |          | 1995;    |
|   |           | map.              |          |          | Laubach, |
|   |           |                   |          |          | 1999,    |
|   |           |                   |          |          | T        |
|   |           |                   |          |          | ompkins, |
|   |           |                   |          |          | 2002\]   |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Behaviors |                   |          |          |          |
| 4 |           |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Behaviors | -   Basic rover   |          |          |          |
| 4 |           |     behaviors     |          |          |          |
| . |           |                   |          |          |          |
| 1 |           |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Behavior  | -   Arbiters      |          |          |          |
| 4 | Coo       |                   |          |          |          |
| . | rdination | -   Behavior      |          |          |          |
| 2 |           |     combinators   |          |          |          |
|   |           |                   |          |          |          |
|   |           | General mechanism |          |          |          |
|   |           | for data fusion   |          |          |          |
|   |           | from different    |          |          |          |
|   |           | sensors.          |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | S         |                   |          |          |          |
| 5 | imulation |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Simulator | -   Interface to  |          |          |          |
| 5 | C         |     ROAMS (Rover  |          |          |          |
| . | onnectors |     Analysis      |          |          |          |
| 1 |           |     Modeling and  |          |          |          |
|   |           |     Simulation)   |          |          |          |
|   |           |     software      |          |          |          |
|   |           |                   |          |          |          |
|   |           | -   Rover Sim     |          |          |          |
|   |           |     Connector     |          |          |          |
|   |           |                   |          |          |          |
|   |           | -   Navigator Sim |          |          |          |
|   |           |     Connector     |          |          |          |
|   |           |                   |          |          |          |
|   |           | -   Locomotor Sim |          |          |          |
|   |           |     Connector     |          |          |          |
|   |           |                   |          |          |          |
|   |           | -   Motor Sim     |          |          |          |
|   |           |     Connector     |          |          |          |
|   |           |                   |          |          |          |
|   |           | -   I/O Sim       |          |          |          |
|   |           |     Connector     |          |          |          |
|   |           |                   |          |          |          |
|   |           | -   IMU Sim       |          |          |          |
|   |           |     Connector     |          |          |          |
|   |           |                   |          |          |          |
|   |           | Interface modules |          |          |          |
|   |           | only.             |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | S         | -   Communication |          |          |          |
| 5 | imulation |     protocol      |          |          |          |
| . | Imple     |                   |          |          |          |
| 2 | mentation | -   Message       |          |          |          |
|   |           |     syntax and    |          |          |          |
|   |           |     command       |          |          |          |
|   |           |     dictionary    |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Ad        |                   |          |          |          |
| 6 | aptations |                   |          |          |          |
|   | to Rovers |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Rocky8    | -                 |          |          |          |
| 6 |           |                   |          |          |          |
| . |           |                   |          |          |          |
| 1 |           |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
|   | Rocky8    | -   Rocky8 Motors |          |          | Hardware |
|   | Sp        |                   |          |          | s        |
|   | ecialized | -   Rocky8        |          |          | pecific; |
|   | Physical  |     Cameras       |          |          | not      |
|   | C         |                   |          |          | ap       |
|   | omponents | -   Rocky8 IMUs   |          |          | plicable |
|   |           |                   |          |          | if you   |
|   |           | -   Rocky8        |          |          | do not   |
|   |           |     Hardware Map  |          |          | have     |
|   |           |                   |          |          | this     |
|   |           | -   Rocky8        |          |          | platform |
|   |           |     Digital I/O   |          |          |          |
|   |           |                   |          |          |          |
|   |           | -   Rocky8 Analog |          |          |          |
|   |           |     I/O           |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
|   | Rocky8    | -   R8 Locomotor  |          |          | Hardware |
|   | Sp        |                   |          |          | s        |
|   | ecialized | -   R8            |          |          | pecific; |
|   | F         |     Constrained   |          |          | not      |
|   | unctional |     Locomotor     |          |          | ap       |
|   | Component |                   |          |          | plicable |
|   |           | -   R8 Navigator  |          |          | if you   |
|   |           |                   |          |          | do not   |
|   |           | -   R8 Rover      |          |          | have     |
|   |           |                   |          |          | this     |
|   |           |                   |          |          | platform |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Rocky7    |                   |          |          |          |
| 6 |           |                   |          |          |          |
| . |           |                   |          |          |          |
| 2 |           |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
|   | Rocky7    | -   Rocky7 Motors |          |          | Hardware |
|   | Sp        |                   |          |          | s        |
|   | ecialized | -   Rocky7        |          |          | pecific; |
|   | Physical  |     Cameras       |          |          | not      |
|   | C         |                   |          |          | ap       |
|   | omponents | -   Rocky7 Accels |          |          | plicable |
|   |           |                   |          |          | if you   |
|   |           | -   Rocky7 Gyros  |          |          | do not   |
|   |           |                   |          |          | have     |
|   |           | -   Rocky7        |          |          | this     |
|   |           |     Hardware Map  |          |          | platform |
|   |           |                   |          |          |          |
|   |           | -   Rocky7        |          |          | Re       |
|   |           |     Digital I/O   |          |          | ference: |
|   |           |                   |          |          | \[Volpe, |
|   |           | -   Rocky7 Analog |          |          | 1999\]   |
|   |           |     I/O           |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
|   | Rocky7    | -   R7 Locomotor  |          |          | Hardware |
|   | Sp        |                   |          |          | s        |
|   | ecialized | -   R7            |          |          | pecific; |
|   | F         |     Constrained   |          |          | not      |
|   | unctional |     Locomotor     |          |          | ap       |
|   | Component |                   |          |          | plicable |
|   |           | -   R7 Navigator  |          |          | if you   |
|   |           |                   |          |          | do not   |
|   |           | -   R7 Rover      |          |          | have     |
|   |           |                   |          |          | this     |
|   |           |                   |          |          | platform |
+---+-----------+-------------------+----------+----------+----------+
| 1 | FIDO      |                   |          |          |          |
| 6 |           |                   |          |          |          |
| . |           |                   |          |          |          |
| 3 |           |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
|   | FIDO      | -   FIDO Motors   |          |          | Hardware |
|   | Sp        |                   |          |          | s        |
|   | ecialized | -   FIDO Cameras  |          |          | pecific; |
|   | Physical  |                   |          |          | not      |
|   | C         | -   FIDO Accels   |          |          | ap       |
|   | omponents |                   |          |          | plicable |
|   |           | -   FIDO Gyros    |          |          | if you   |
|   |           |                   |          |          | do not   |
|   |           | -   FIDO Hardware |          |          | have     |
|   |           |     Map           |          |          | this     |
|   |           |                   |          |          | p        |
|   |           | -   FIDO Digital  |          |          | latform; |
|   |           |     I/O           |          |          |          |
|   |           |                   |          |          | To be    |
|   |           | -   FIDO Analog   |          |          | imp      |
|   |           |     I/O           |          |          | lemented |
+---+-----------+-------------------+----------+----------+----------+
|   | FIDO      | -   FIDO          |          |          | Hardware |
|   | Sp        |     Locomotor     |          |          | s        |
|   | ecialized |                   |          |          | pecific; |
|   | F         | -   FIDO          |          |          | not      |
|   | unctional |     Constrained   |          |          | ap       |
|   | Component |     Locomotor     |          |          | plicable |
|   |           |                   |          |          | if you   |
|   |           | -   FIDO          |          |          | do not   |
|   |           |     Navigator     |          |          | have     |
|   |           |                   |          |          | this     |
|   |           | -   FIDO Rover    |          |          | p        |
|   |           |                   |          |          | latform; |
|   |           |                   |          |          |          |
|   |           |                   |          |          | P        |
|   |           |                   |          |          | artially |
|   |           |                   |          |          | imp      |
|   |           |                   |          |          | lemented |
+---+-----------+-------------------+----------+----------+----------+
| 1 | K9        |                   |          |          |          |
| 6 |           |                   |          |          |          |
| . |           |                   |          |          |          |
| 4 |           |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
|   | K9        | -   K9 Motors     |          |          | Hardware |
|   |           |                   |          |          | s        |
|   | Sp        | -   K9 Cameras    |          |          | pecific; |
|   | ecialized |                   |          |          | not      |
|   | Physical  | -   K9 Accels     |          |          | ap       |
|   | C         |                   |          |          | plicable |
|   | omponents | -   K9 Gyros      |          |          | if you   |
|   |           |                   |          |          | do not   |
|   |           | -   K9 Hardware   |          |          | have     |
|   |           |     Map           |          |          | this     |
|   |           |                   |          |          | platform |
|   |           | -   K9 Digital    |          |          |          |
|   |           |     I/O           |          |          |          |
|   |           |                   |          |          |          |
|   |           | -   K9 Analog I/O |          |          |          |
|   |           |                   |          |          |          |
|   |           | K9 is NASA Ames   |          |          |          |
|   |           | rover platform    |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
|   | K9        | -   K9 Locomotor  |          |          | Hardware |
|   |           |                   |          |          | s        |
|   | Sp        | -   K9            |          |          | pecific; |
|   | ecialized |     Constrained   |          |          | not      |
|   | F         |     Locomotor     |          |          | ap       |
|   | unctional |                   |          |          | plicable |
|   | Component | -   K9 Navigator  |          |          | if you   |
|   |           |                   |          |          | do not   |
|   |           | -   K9 Rover      |          |          | have     |
|   |           |                   |          |          | this     |
|   |           |                   |          |          | platform |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Decision  |                   |          |          |          |
| 7 | Layer     |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Planner   | -   CASPER --     | Inputs:  | Co       | Re       |
| 7 | Implem    |     Continuous    | science  | mmercial | ference: |
| . | entations |     Activity      | goals,   | example: | \[Chien, |
| 1 |           |     Scheduling,   | eng      | STK      | 1999;    |
|   |           |     Planning,     | ineering | (S       | Chien,   |
|   |           |     Execution and | goals,   | atellite | 2000\]   |
|   |           |     Re-planning   | rover    | Toolkit) |          |
|   |           |     using an      | model,   | from     |          |
|   |           |     automated     | rover    | An       |          |
|   |           |     scheduling    | initial  | alytical |          |
|   |           |     and planning  | state,   | G        |          |
|   |           |     engine        | resource | raphics, |          |
|   |           |                   | and      | Inc;     |          |
|   |           | An integrated     | state    | ILOG     |          |
|   |           | planning and      | data,    | Opti     |          |
|   |           | execution system  | activity | mization |          |
|   |           | that supports     | e        | Suite,   |          |
|   |           | continuous        | xecution | by ILOG, |          |
|   |           | modification and  | status   | Inc.     |          |
|   |           | updating of a     |          |          |          |
|   |           | current working   | Outputs: |          |          |
|   |           | plan in light of  |          |          |          |
|   |           | changing          | Sequence |          |          |
|   |           | operating         | of       |          |          |
|   |           | context.          | ac       |          |          |
|   |           |                   | tivities |          |          |
|   |           | Performance:      | or       |          |          |
|   |           | generates initial | commands |          |          |
|   |           | plan on the order |          |          |          |
|   |           | of minutes.       |          |          |          |
|   |           | Re-planning takes |          |          |          |
|   |           | tens of seconds.  |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | General   | -   Basic planner |          |          | P        |
| 7 | Planner   |                   |          |          | artially |
| . | Infra     |    infrastructure |          |          | impl     |
| 2 | structure |                   |          |          | emented. |
|   |           | Will contain      |          |          |          |
|   |           | basic planner     |          |          |          |
|   |           | infrastructure    |          |          |          |
|   |           | and support code. |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Executive | -   TDL - Task    | Inputs:  | Co       | Re       |
| 7 |           |     Description   | control  | mmercial | ference: |
| . | Implem    |     Language      | tasks,   | example: | \[       |
| 3 | entations |     (CMU)         | rover    | SCL      | Simmons, |
|   |           |                   | model    | (Sp      | 1998\]   |
|   |           | Provides a        |          | acecraft |          |
|   |           | language and      | Outputs: | Co       |          |
|   |           | framework for the | rover    | mmanding |          |
|   |           | development of    | commands | La       |          |
|   |           | robot control     |          | nguage), |          |
|   |           | programs.         |          | by       |          |
|   |           | Includes explicit |          | I        |          |
|   |           | syntactic support |          | nterface |          |
|   |           | for task-level    |          | Control  |          |
|   |           | control           |          | Systems, |          |
|   |           | capabilities such |          | Inc.     |          |
|   |           | as task           |          |          |          |
|   |           | decomposition,    |          |          |          |
|   |           | synchronization,  |          |          |          |
|   |           | execution         |          |          |          |
|   |           | monitoring and    |          |          |          |
|   |           | exception         |          |          |          |
|   |           | handling.         |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | General   | -   Basic         |          |          | P        |
| 7 | Executive |     executive     |          |          | artially |
| . | Infra     |                   |          |          | impl     |
| 4 | structure |    infrastructure |          |          | emented. |
|   |           |                   |          |          |          |
|   |           | Will contain      |          |          |          |
|   |           | basic executive   |          |          |          |
|   |           | infrastructure    |          |          |          |
|   |           | and support code. |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Planner   | -   CLEaR --      |          |          |          |
| 7 | and       |     Closed-Loop   |          |          |          |
| . | Executive |     Execution and |          |          |          |
| 5 | Int       |     Recovery      |          |          |          |
|   | egrations |                   |          |          |          |
|   |           | Provides a        |          |          |          |
|   |           | framework for     |          |          |          |
|   |           | performing        |          |          |          |
|   |           | unified planning, |          |          |          |
|   |           | scheduling, and   |          |          |          |
|   |           | execution by      |          |          |          |
|   |           | balancing         |          |          |          |
|   |           | deliberative and  |          |          |          |
|   |           | reactive          |          |          |          |
|   |           | reasoning.        |          |          |          |
|   |           | Closely           |          |          |          |
|   |           | integrates the    |          |          |          |
|   |           | CASPER planning   |          |          |          |
|   |           | system with the   |          |          |          |
|   |           | TDL executive.    |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Activity  | -   General       |          |          | P        |
| 7 | Database  |     activity      |          |          | artially |
| . |           |     database      |          |          | impl     |
| 6 |           |     structure     |          |          | emented. |
|   |           |                   |          |          |          |
|   |           | Provides a        |          |          |          |
|   |           | central database  |          |          |          |
|   |           | for containing    |          |          |          |
|   |           | information on    |          |          |          |
|   |           | plan activities.  |          |          |          |
|   |           | This information  |          |          |          |
|   |           | could include     |          |          |          |
|   |           | activity          |          |          |          |
|   |           | definitions,      |          |          |          |
|   |           | activity          |          |          |          |
|   |           | instantiations,   |          |          |          |
|   |           | constraints on    |          |          |          |
|   |           | activities, etc.  |          |          |          |
|   |           | This information  |          |          |          |
|   |           | would be          |          |          |          |
|   |           | accessible by     |          |          |          |
|   |           | both planning and |          |          |          |
|   |           | executive         |          |          |          |
|   |           | components.       |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
| 1 | Rover     | -   Description   |          |          | App      |
| 7 | Models    |     of rover      |          |          | lication |
| . |           |     activities    |          |          | and      |
| 7 |           |     and their     |          |          | platform |
|   |           |     constraints   |          |          | s        |
|   |           |     on states,    |          |          | pecific. |
|   |           |     resources and |          |          | Models   |
|   |           |     other         |          |          | are      |
|   |           |     activities.   |          |          | specific |
|   |           |                   |          |          | to       |
|   |           | Includes models   |          |          | rovers   |
|   |           | developed for     |          |          | such as  |
|   |           | CASPER and TDL.   |          |          | Rocky7   |
|   |           |                   |          |          | and      |
|   |           |                   |          |          | Rocky8.  |
+---+-----------+-------------------+----------+----------+----------+
| 1 | I         | -   Functional    | Inputs:  |          | Basic    |
| 7 | nterfaces |     layer         | c        |          | Infrast  |
| . |           |     interface     | ommands, |          | ructure. |
| 8 |           |                   | act      |          |          |
|   |           | Provides a        | ivities, |          | General  |
|   |           | general API and   | resource |          | planner/ |
|   |           | framework for     | and      |          | e        |
|   |           | relaying          | state    |          | xecutive |
|   |           | information       | queries  |          | i        |
|   |           | between Decision  |          |          | nterface |
|   |           | Layer and         | Outputs: |          | is       |
|   |           | Functional Layer. | activity |          | p        |
|   |           | Types of          | e        |          | artially |
|   |           | information       | xecution |          | impl     |
|   |           | relayed include   | status,  |          | emented. |
|   |           | commands,         | resource |          |          |
|   |           | queries, and      | and      |          |          |
|   |           | state and         | state    |          |          |
|   |           | resource data.    | data     |          |          |
|   |           |                   |          |          |          |
|   |           | -   General       |          |          |          |
|   |           |                   |          |          |          |
|   |           | planner/executive |          |          |          |
|   |           |     interface     |          |          |          |
|   |           |                   |          |          |          |
|   |           | Provides a        |          |          |          |
|   |           | general API and   |          |          |          |
|   |           | framework for     |          |          |          |
|   |           | relaying          |          |          |          |
|   |           | information       |          |          |          |
|   |           | between the       |          |          |          |
|   |           | planning and      |          |          |          |
|   |           | executive         |          |          |          |
|   |           | components of the |          |          |          |
|   |           | Decision Layer.   |          |          |          |
|   |           | Types of          |          |          |          |
|   |           | information       |          |          |          |
|   |           | relayed include   |          |          |          |
|   |           | activities,       |          |          |          |
|   |           | commands,         |          |          |          |
|   |           | queries, and      |          |          |          |
|   |           | state and         |          |          |          |
|   |           | resource data.    |          |          |          |
+---+-----------+-------------------+----------+----------+----------+
|   |           |                   |          |          |          |
+---+-----------+-------------------+----------+----------+----------+

# Base Package

The base package contains basic infrastructure components. These
components are not themselves novel or algorithmically interesting, and
have no commercial value. They fulfill common needs encountered by any
robotics project, and robotics projects will generally contain analogs
to these items, either drawn from a variety of available free and
commercial software bases, written custom by the project groups
themselves, or a combination of both. As a result, such projects contain
many analogous, but incompatible, classes to fill these common needs.
This package contains the particular implementations used for the
CLARAty project. Their value comes from the fact that they provide a
common framework allowing the CLARAty packages to be consistent and
self-contained, avoiding unnecessary duplication of commonly needed
classes, and allowing the various CLARAty components to communicate with
each other.

As an example, consider classes to represent and operate on common
mathematical constructs, such as matrices, points, and coordinate
transformations. Any robotics project will need these, and there are a
wide variety of solutions available, including the commercial MATLAB
mathematics environment, the MTL (Matrix Template Library) available for
free download from <http://www.osl.iu.edu/research/mtl>, the linalg
linear algebra library available for free download from sourceforge
<http://sourceforge.net/projects/linalg>, and many others.

Since the need for math classes is common, but there the is no single
standard, there is a profusion of incompatible software implementations
filling the same niche, each with its own set of benefits and drawbacks.
Given any set of robotics projects that were developed in isolation from
one another, chances are that most will use incompatible math
implementations, and this is a significant barrier to collaboration.

To illustrate why this is a problem, imagine that there are two robotics
groups who have decided to work on a project together. Group A has a
superior navigation method, and group B's robot is mechanically superior
at driving over rough terrain. These two projects grew in isolation from
one another, but now the two groups want to put what they have together,
since the result of having B's robot driving around using A's navigation
method should be better than what either group has by itself. Both A and
B will have software that needs to be linked together in order to do
what they need to do. If A and B used different math implementations,
which is a likely scenario, you end up with three types of problems.

One problem is that the combined program that you end up with will be
considerably bigger than it needs to be, since instead of having one
copy of the software which deals with math, you have two, and each takes
up space. The second, which is more serious, is that when you try to
link these two pieces of software together this can lead to conflicts.
For example, both have a type called 'Matrix', but these are not the
same, and the compiler will not let you put the software from A and B
together until you make changes to deal with this. The third, and most
critical, is that the two pieces of software will have incompatible ways
of representing the same information, so they won't be able to talk
directly to each other in a meaningful way. For example, both will have
some way of representing a place to drive to \-- if you were to draw an
X on the ground where you want the robot to go, both would have a way of
representing where that X is. In this example, A's software will
generate a position to go to, and give that to B's software, which will
make tell the wheels to spin appropriately to move the robot there. Each
will represent this position using a mathematical representation of some
sort, but the actual software structures they use to represent it will
be different and incompatible. When A's navigation software wants to
tell B's robot to go somewhere, it will not be able to do it directly.
It will be necessary to create a third piece of software which converts
A's position commands into something B can understand, and B's position
reports into something A can understand. That third piece of software
will need to incorporate the math packages from both in order to do this
conversion, and that piece will probably have to be written specially
for this purpose, greatly increasing the time and cost involved for A
and B to try this experiment.

This scenario plays out in many areas, not just with math libraries, and
the situation gets worse as more collaborators are added to the mix.
What is needed is a 'lingua franca', a central representation that all
can understand, and use to communicate with each other. CLARAty is
working to fill that need, and at the same time provide implementations
that CLARAty itself can use to be consistent and self-contained.
Hopefully new projects could use the CLARAty implementations to fulfill
these common needs in a way that enhances interoperability from the
beginning.

## Share Module

The share module provides common definitions to bridge incompatibilities
and fill in gaps between different compilers and operating systems. It
also provides simple math constants and macros (such as absolute value)
and support for defining functors, operators, and other C++ constructs
in a consistent manner across CLARAty modules. The items in this module
are analogous to standard C++ library and standard template library
(STL) facilities, and primarily fill in gaps rather than providing
fundamentally new capabilities.

## ( - 1.6) Array, Matrix, Point, and Transforms, and Frame

These modules provide classes to represent and operate on common
mathematical constructs, as discussed in the above example. Array
provides storage for one or two dimensional arrays. Matrix adds
mathematical operations for arrays. Point represents and provides
operations on two- and three-dimensional points: (x, y) and (x, y, z).
Transforms provides representations and operations on six
degree-of-freedom locations, (x, y, z, roll, pitch, yaw).

Frame provides representations and operations on a hierarchical tree of
coordinate transformations in order to represent positions in space and
kinematics. For example, your elbow is attached at a certain position
and orientation with respect to your shoulder, as is your hand to your
elbow. When you move just your shoulder, your elbow and hand move with
respect to the rest of your body, but stay the same with respect to each
other. Frame provides a way to represent this type of relationship, and
convert between reference frames. For example, if you know where your
elbow is with respect to your shoulder, and where your hand is with
respect to your elbow, this could calculate where your hand is with
respect to your shoulder.

#  {#section-1 .unnumbered}

## Device Package

This package provides the base classes for the Generic Physical
Components in CLARAty (such as cameras, locomotors, instruments, etc.).
These classes provide multi-thread safe mechanisms for locking, managing
resources, and logging telemetry. Generic physical classes also include
power systems and power-related devices such as power sources,
batteries, and battery chargers.

A generic physical component (GPC) is a class that defines the structure
and behavior of a physical object in an abstract sense. Some of these
classes have partial implementations since they are eventually attached
to physical/simulation objects that complete their implementation. The
objects to which they attach are of the same type. These classes can be
active, *i.e.* they provide their own threading model. Examples of such
components are: Motor, Joint, Wheel, Arm, Mast, Locomotor, Rover,
Camera, FilterWheel, Gyro, DigitalIO, AnalogIO, Socket, and SunSensor.
These components appear at different levels of granularity in the
Functional Layer.

The characteristics of these generic components are:

1.  They represent an abstract view of a physical entity.

2.  They attach to concrete physical classes of the same type. The
    physical classes complete the implementation of the generic class
    interface.

3.  They provide generic public interfaces that supports different
    physical implementations. The interfaces define the functionality
    and services of the component.

4.  They provide the runtime model for component's operation.

5.  They manage local atomic resources and resolve local conflicts.

6.  They encapsulate the states of a component and provide access to the
    states through their public interface. The Decision Layer can query
    any state of a component at any time.

7.  They provide local state estimation based on information available
    within the scope of the component. They *may* attach to external
    generic estimators (e.g. Kalman Filter).

8.  They provide resource usage prediction in response to queries from
    the Decision Layer.

9.  They *may* have internal state machines.

10. They *may* include or reference other generic physical components.
    Such components are made publicly accessible to allow access to
    subordinates.

The "device" module uses the "telemetry" module and provides generic
interfaces for accessing telemetry or parameters from any device in a
consistent manner without losing additional specialized information.

A Device_Group superclass is a generic interface that allows the
aggregations of single devices and other device groups. This class
includes templatized operations to allow safe query and retrieval of
subsets of devices within a Device_Group compatible with an arbitrary
sub-classed Device interface without prior knowledge of or dependence on
those subclasses.

CLARAty also has a factory for mapping Device types to functions for
creating appropriate graphical panels inheriting from Qt_Device, and a
graphical interface using the Qt toolkit for browsing Device_Groups
which will bring up the most specific available panel for a given device
using that factory, without any dependence of these tools on the Device
or Qt_Device subclasses themselves.

## Resource

This module provides additional support for representing and
manipulating system resources, such as time and multiprocessing support
(threads, mutexes, condition variables, etc) for when there are needs
within CLARAty that are not fully provided by the standard facilities.
Analogous support is already present in the system libraries, the POSIX
Threads library, and ACE, the Adaptive Communication Environment, and
this module primarily fills in gaps or provides simple extensions to
those facilities rather than providing anything fundamentally new.

## Containers

This module provides additional support for representing and
manipulating containers, such as linked lists, maps, hash tables, and
trees. These are structures for storing and accessing sets of items.
Analogous support is already present in the Standard Template Library
(STL), but STL is not supported properly on all systems at this time,
and some data structures, such as trees, are not well supported by STL.
This module primarily fills in such gaps or provides simple extensions
to those facilities rather than providing anything fundamentally new.

## State and Telemetry

These modules provide a consistent interface for representing,
transmitting, storing, and logging data generated by devices and other
processes in CLARAty. Devices include items such as cameras, motors,
arms, spectrometers and so on. Components use state variables for
logging, tracking, and recovery strategies. Components can have numerous
state variables depending on what states are interesting to a particular
application. State information can have different forms. It may be
contained in a software variable or a hardware register. To track
hardware registers, state variables are created to mirror these
registers. Doing so enables tracking and logging of a particular state
for planning and recovery purposes. Typical components can have tens of
states. Examples of state for a device such as a motor are: position,
velocity, acceleration, and control mode.

The state mechanism keeps track of transitions, time-tags and logs state
history. Internal state machines keep track of current states and
allowable state transitions. The State can attach to an external
StateHandler, which provides more functionality for all states of the
system. The StateHandler class provides global operations on states,
such as periodic monitoring of any selected subset of the system's
states. Such state tracking can be selectively disabled or eliminated
for applications that do not require this feature.

Analogous facilities are available in the Adaptive Communication
Environment (ACE) (<http://www.cs.wustl.edu/~schmidt/ACE.html>) for
logging system data and ACE types. These modules extend those
capabilities to support the needs of CLARAty types.

## Qt Display Interfaces

These modules provide user interface components to view and manipulate
the state of CLARAty objects, such as frames, motors, manipulators,
locomotors, cameras, etc. These modules use TrollTech's Qt software
toolkit for multi-platform C++ GUI (graphical user interface)
development. Analogous graphical state viewing and manipulation
interfaces exist for a wide variety of free and commercial devices, such
as the Saphira interface ActivMedia provides for the robots it sells,
the PIC-SERVO interface J.R. Kerr provides with the motor controllers he
sells, and the Coriander interface freely available for use with Linux
1394 cameras. These modules provide similar functionality for use with
objects adhering to CLARAty interfaces, such as those for motors,
manipulators, locomotors, cameras, etc.

# Motion Control Package

The motion control package is responsible for controlling and
coordinating electrical motors. Such motors can be either brushed or
brushless DC motors.

## 2.1 Motor {#motor .unnumbered}

The Motor module contains software for providing an interface to a
variety of motor and their controllers. It also defines the behavior of
a single controlled motor. Such behavior includes powering the motors
(on, off), controlling the trajectory of the motor by changing position,
maximum velocity and acceleration profiles, and setting the home
position. This module also provides functionality for querying the
current position, velocity, and acceleration profiles for the motors. It
also contains built-in checks and queries on the current status of a
single motor. These include queries such as whether the motor is moving,
is off, or is in an error state. An abstract list of functions is
provided below.

Main functions of the Motor Control Package are:

-   on() // turn on the motor drive

-   off() // turn off the motor drive

-   start() // start the motor

-   stop() // stop the motor

-   set_home() // set the current motor position to zero

-   set_control_mode() // POSITION or VELOCITY CONTROL

-   set_position() // set desired motor position

-   set_velocity() // set desired maximum velocity

-   set_acceleration() // set desired acceleration

-   wait_until_done() // wait until motion is % complete

-   get_real_position() // get the current motor position

-   get_real_velocity() // get the current velocity

-   get_max_velocity() // get the maximum velocity

-   is_moving() // returns TRUE if the motor is moving

-   is_off() // returns TRUE if the motor drive is OFF

The Controlled Motor module supports single-axis motor control. The
position, velocity, and acceleration parameters of the motion velocity
profile trajectory are set by set_position(), set_velocity(), and
set_acceleration(). Once the motion profile is set, start() starts the
motion. The zero position is set by set_home(). The actual current motor
position, velocity, and acceleration are obtained by get_position(),
get_velocity(), and get_acceleration(). The motor drive can be turned on
or off by on() and off(). The motor_moving or motor_off status can be
tested by is_moving() and is_off(). The function wait_until_done()
provides synchronization or specified timing relations between two
motors. For example, it can be used to support two sequential motions
where the second motion starts when the first motion is complete by a
specified percentage.

Following the general CLARAty design concept, the Motion Control Package
uses the bridge design pattern to support different implementations of
motor controllers. In this bridge design pattern, different specific
implementations are separated from "generic abstraction". Ctrl_Motor
(Controlled_Motor) is a generic Abstraction class, which provides all
the generic interface methods (functions) for motion control.
Ctrl_Motor_Impl is the "Implementation" class, which provides methods
specific to each different motor controller implementation. The
Ctrl_Motor class contains the pointer to Ctrl_Motor_Impl. Specific
implementation examples of Ctrl_Motor_Impl objects are R7_Motors (which
use LM629 motor controller chips) and R8_motors (which use HCTL 1100
motor controller chips on an in-house built widget board), which are
described in Section 3. Motor control can also be implemented in
software as is the case for the FIDO rover motor, which provides
additional classes for generating PID control laws (PID = proportional,
directive and integral control).

## Trajectory and Trajectory Generators

The trajectory and trajectory generator constructs are software modules
that are responsible for generating trapezoidal and other profile
functions. They can also modify a trajectory that is being executed by
combining a number of overlapped trapezoidal or other profile
trajectories in real-time. The trajectory generators send the profile at
every system heart beat to the attached motor. The trajectory generator
can specify the periodicity and priority of this operation.

## Coordinated Motors

The coordinated motor classes use a number of controlled motors to
provide a coordination motion system. These systems are used for
controlling a robotic manipulator arm or controlling a locomotion system
such as a mobile vehicle or a rover. The type of coordination that this
class does is dependent on the kinematic models of the system. Taking
into account the system model, a goal for the motion is input into the
coordination motion system and a set of trajectory profiles is output to
the controlled motors. Some coordinated motor classes will also
continuously received feedback from the mechanism to be controlled in
order to keep all motors in lock step as some motors experience higher
loads compared to others.

***Commercial Equivalents and Freeware***

All robotic manufacturers have an implementation for motion control and
coordination. In order to operate any robotic system, the motors in the
system (which are either DC brushed or brushless, or AC) must be
controlled and coordinated using trajectory inputs and motors' feedback.
Such companies include Irobot and their RWI division, Probotics, and all
industrial robotic companies such as Kuka, Bosch, Adept Technology, Asea
Brown Bovari, Yamaha, Seiko Systems, etc. Commercial examples are not
limited to robotic companies but also include all motion control
companies such as Galil Motion (http://www.galilmc.com/products/) and
Animatics Corporation (http://www.animatics.com/).

# Hardware Drivers Package

The device drivers package contains implementations of all device
drivers used by the supported robotics and rover systems. Device drivers
fall into several categories, which include motor controllers,
framegrabbers, input/output modules (analog and digital), instrument and
sensor device drivers, etc.

## Motion Controllers

The motion controller module supports several hardware implementations
of functionality needed for controlled motions. These include a number
of drivers to control some of the most widely used motor control chips
such as LM628/629 and HCTL1100 motor controller chips. These chips can
be accessible directly, mounted on custom boards, or used in conjunction
with other supporting chips. Capabilities of various motion control
chips can vary. Software implementations are used to compensate for
functionality not available in hardware. The software-based support
includes the generation of trapezoidal or other velocity profiles by
software as opposed to by a hardware motor controller chip.

Two examples of hardware motion controller chips supported by CLARAty
are LM629 for Rocky7 rover platform and HCTL 1100 for Rocky8. The
National Semiconductor LM629 motion controller chip provide closed loop
PID servo control for single axis actuators. Chip functionality includes
quadrature encoder reading and trapezoidal velocity profile generation
with the velocity sampling time up to 256 μs (4 KHz) and a quadrature
encoder-state capture rate of 1 MHz. The CLARAty LM629 chip driver
software provides an interface to send motion control commands to the
chip and receives the data and status reply from the chip. The unique
implementation of this driver allows it to operate on the chip whether
it is directly connected or placed in a commercial-off-the-shelf (COTS)
board or in a custom board. The functions supported include set_home(),
set_position(), set_velocity(), set_acceleration(), reset_trajectory(),
load_trajectory(), execute_trajectory(), read_real_position(),
read_real_velocity(), is_moving(), is_off(), and
is_position_error_exceeded().

The CLARAty Controlled_Motor (Motion Control package) software uses
LM629 chip software to communicate with the LM629 motion controller chip
through the CLARAty digital_IO mechanism (see Input/Output package),
where LM629 chips drive DC brush motors through H-bridge chips. Refer to
the Manipulator Package for more detailed usage including a functional
diagram.

Agilent Technologies (formerly part of Hewlett Packard) provides another
type of motion control chip known as the HCTL-1100. This chip is similar
to LM629 chip. The functions supported by the HCTL-1100 software module
are similar in capability to those by LM629 listed above.

## Framegrabbers and cameras (vision)

Framegrabbers are computer boards that take video RS170 signals and
digitize them for image processing. Several rovers use these
framegrabbers to convert the analog video signal into a digital array of
pixel values for further processing. This module provides software
drivers that will control the functionality of the framegrabber and its
interactions with the main processor and a physical camera.

Another alternative to framegrabbers is the use of digital cameras that
directly interface with the main processor using a high-speed serial
link. Two types of serial buses are most common: the IEEE 1394
(Firewire) interface or the USB (universal serial bus) interface for
image transfer and camera interfacing.

Drivers have been developed to interface with and operate both Firewire
and analog cameras using framegrabbers. For example, the Imagenation
PX610 is a video framegrabber for PCI bus. It captures monochrome
composite video (RS-170 NTSC) in 640x480 pixel resolution with 8 bits
(256 gray levels) per pixel. Two framegrabber boards are simultaneously
used for synchronized stereo-pair image capture. The PX610 framegrabber
driver software is for PCI-bus running under the VxWorks operating
system.

## I/O boards and chips

CLARAty software supports several digital and analog I/O boards and
chips. For example, the Sensoray S720 is a digital input/output board
for Compact-PCI bus. It allows masked input, output, and bi-directional
bus operations. The S720_Board class contains 10 DIO ports, which are
specialized subclasses of a general CLARAty digital I/O interface
implementation known as the DIO_Impl class. The S720 board allows
setting up initial configurations. The port class for the S720 board
defines three operations: input, output, and I/O direction setting.

Another example of a digital I/O board driver that is implemented in
CLARAty is the old VPAR10 board from OR Industries (obsolete VME board).
It is also a digital input/output board that runs on a VME bus. Its
functionality is very similar to the S720 board. The VPAR10 board
supports initial setup configuration, and its ports define input,
output, and direction setting for tri-stated I/O control

Other I/O drivers are in the form of software that controls various
chips directly. These include the drivers for several Maxim Chips such
as: the MAX186 and the MAX529 analog I/O chips. The MAX186 chip is a
12-bit, 8-channel single-ended/4-channel differential analog-to-digital
converter that reads analog voltages and converts them into digital
numbers. The MAX186 class driver supports such functions for setting the
chip mode of operation of the chip (e.g., unipolar, bipolar,
single-ended, differential) and reading analog voltages. The MAX528 chip
is an 8-bit, 8-channel, digital-to-analog converter, generating analog
voltage outputs. The MAX528 class driver supports such functions such as
mode setting for the chip and outputting of analog voltages. In the
current implementations, the MAX chips are used in a custom motion and
I/O control board known as the widget board.

## Custom boards

In additional to many COTS boards used in robotic systems, one often
finds a large number of custom boards using a number of COTS chips. For
example, JPL has developed a single axis motion control board that has a
PIC microcontroller, a number of digital I/O lines, analog-to-digital
converters and digital-to-analog converters. The board, which is
currently used by the Rocky 8 rover and several other robots at JPL, is
known as the "widget board." It is a small-size custom card that
controls the motion of a single DC brushed or brushless motor. The board
communicates with the main CPU board (e.g., Pentium-III, PowerPC750, or
M68060) through an I2C bus. It contains a Microchip PIC16C65A
microcontroller as well as an HCTL1100 motor controller chip (from
Agilent Technologies), a MAX186 A/D converter, and a MAX528 D/A
converter. CLARAty implements driver modules for chips of the widget
board, as well as drivers for groups of chips. The widget board classes
provide a modular set of implementation to allow applications to use
parts or all of the functionality of this board. The widget board
software classes include a Widget_Motor (subclass of HCTL1100_chip
class), a Widget_AI class (subclass of MAX186 chip class), a Widget_AO
(subclass of MAX528_chip class), a Widget_DIO, and an I2C class. In
addition to the driver software for this chip, a set of modules run on
the PIC microcontroller translates the request from the application into
commands to the various chips. The firmware modules, which include an
I2C slave communicator, an I/O module, and a motor control module are
part of the CLARAty repository.

Other drivers for custom boards in CLARAty include the driver for LM629
Board, which is a custom board for several of the National Semiconductor
chips that are directly connected to a host computer via a parallel bus.
The functionality of this board is the control of a number of brushed DC
servo motors. These controlled motors are commanded to follow a given
trajectory profile.

## Other

Other hardware drivers include I2C master controller, PCI controller,
and VME to ISA converters.

##### Commercial Equivalents and Freeware {#commercial-equivalents-and-freeware .unnumbered}

Many commercial boards and chips come with software drivers, technical
specifications, or manuals on how to program these hardware components.
Some companies do not release the source code for proprietary reasons.
In many cases, even though source code is available, drivers are not
available for the operating systems that are used by these robots.
CLARAty ports and provides many drivers for several operating systems,
but primarily focuses on both the VxWorks and Linux operating systems.
In some cases, there are commercial equivalents with the same
functionality that can run under Windows operating systems.

There is often ample freeware that provides drivers and firmware for
boards for developers. Drivers, alone, do not provide much functionality
beyond controlling a particular piece of hardware.

#   {#section-2 .unnumbered}

# Sensor Package

The sensor package contains modules that define the interface and
describe the behavior of various sensors and instruments used in robotic
systems. Such sensors include IMUs (inertial measurement units), sun
sensors, bump sensors, tilt sensors, compasses, and potentiometers.

## ( - 4.2) IMUs and Specific IMUs

For example, CLARAty provides generic classes for the IMU sensor. This
generic class provides an interface and a description of the behavior of
the inertial measurement unit. This unit provides measurements about the
system onto which it is attached. These measurements include roll angle,
pitch angle, roll rate, pitch rate, yaw rate, and accelerations in the
x, y, and z directions. The generic implementation of the driver
software defines these types of measurements and the modes for the
collection of the data. A specialized version of the software provides
the implementation that is necessary to talk to a particular IMU
hardware. The generic IMU software can be specialized to a number of
different IMU units. Specialization of the IMU implementation classes
includes an adaptation that uses a COTS IMU from Crossbow (DMU-HDX). In
this and other IMU units, yaw angle can only be deduced from yaw rate.
This is done by integration of yaw rate for the duration of the motion.

## Orientation Sensors

The orientation sensor software supports generic electronic tilt sensors
and magnetic compasses. The magnetic compass is commonly used on Earth
to determine the vehicle heading, but not that useful on Mars due to a
negligible magnetic field. A sun sensor can be used to determine the
vehicle heading. The sensor uses wide field-of-view lens, facing upward
towards the sky. The centroid of the sun in the sensor is measured by
either using a 2-D analog position-sensing device (PSD) or a CCD. For
the PSD reading, an analog input device is used to analog voltages. For
CCD, a simple image processing function to detect the centroid is
performed. The sun sensor software determines the vehicle heading from
the time of the day and the sun azimuth and elevation angles relative to
the vehicle. It uses an Ephemeris library that has knowledge about the
position of the sun, earth and other planets. From these positions, a
calculation is performed to recover the absolute heading of a robot on
the ground.

## ( - 4.6) Rate Sensors, Temperature Sensors, and Voltage and Current Sensors

Other sensor reading software supports temperature sensors, rocker-bogey
angle measurements using potentiometers, wheel motor currents, arm motor
currents, gyroscopes, and accelerometers.

## Power System Manager

Contains physical classes for a power system, and power related devices
such as power sources, batteries, and battery chargers based on
\'device\' and \'telemetry\', as previously described. Specializations
available for both simple simulated power devices and hardware on the
rovers.

##### Commercial Equivalents and Freeware {#commercial-equivalents-and-freeware-1 .unnumbered}

Commercial sensors normally come with software drivers, technical
specifications, or manuals on how to program (e.g., Crossbow IMU
manual). In addition to drivers commercially available for all these
COTS sensors, CLARAty adds the definition of the generic classes to
allow the interchangeable use of sensors from various vendors.

# Input/Output Package

The input/output package provides a generic software implementation for
controlling I/O in a robot. The I/O includes both digital and analog
I/O. The functionalities supported by this package include digital I/O
ports, analog I/O channels, composite digital I/O, and hardware
interfacing with I/O cards from various vendors.

## DIO

A set of software classes is implemented within the I/O package. The DIO
class is a generic abstraction for digital input and output, which hides
specific implementations from the user. The DIO_Impl class is the
specific implementation class. It provides a parent class for all
specialized I/O port operations. For instance, one 4-bit of generic DIO
and another 4-bit of generic DIO can be put together in one 8-bit
DIO_Impl, where the lower 4 bits are for one 4-bit DIO and the upper 4
bits are for the other 4-bit DIO. When the user reads from and writes to
the two generic DIO's using DIO-supported functions, they are
automatically reflected to the DIO_Impl objects. Therefore, once the
relations between DIO objects and DIO_Impl objects are defined according
to the hardware wiring, the user needs to work on only DIO's. Functions
supported for DIO include set(), set_bit(), clr(), clr_bit(), toggle(),
toggle_bit(), as well as input() and output(). The DIO_Impl class
supports input(), output(), set_IO_direction(), and invert_IO(). The DIO
and DIO_Impl classes allow the user to set some signals to inverted
logic or active low. For instance, if the signal is set to inverted
logic (active low), set(ENABLE_BIT) actually sets the ENABLE_BIT to
zero. Specific digital I/O implementations are defined as concrete
subclasses of DIO_Impl as described above in Section 3 on Hardware
Drivers for I/O boards and chips.

In some specific applications, it is noted that there is a need for the
composite digital I/O class known as CDIO, which enables the user to
define a combination of DIO's. For instance, a CDIO object may comprise
of three DIO's, each linked to a different DIO_Impl hardware port. When
the user manipulates the CDIO object (input & output), the manipulations
are automatically reflected to specific DIO_Impl hardware ports.

In summary, the functionality of the Digital I/O classes is the
manipulation of bit patterns that allow combining, separating, masking,
inputting and outputting of these patterns. It also provides mechanisms
to allow these classes to be multithreaded, which means that multiple
clients or applications can call these functions at any time.

## AIO

The analog I/O classes are similar to the digital I/O classes except
that they deal with analog input and output rather than digital. The AI
class reads analog voltages in digital numbers from analog-to-digital
converters, while the AO class writes digital numbers to
digital-to-analog converters to generate desired analog voltages.
Examples of functions supported include input(), output(), set_gain(),
set_offset(), and set_mode().

##### Commercial Equivalents and Freeware {#commercial-equivalents-and-freeware-2 .unnumbered}

A commercial equivalent to CLARAty's I/O capability is a product from
National Instruments called LabView. LabView has many more capabilities
for I/O control than the CLARAty I/O package, however, it does not
operate in an embedded environment and hence cannot be used with the
CLARAty software. LabView supports generic DIO, AI, and AO device
virtual interfaces (VI) for data acquisition design applications.
Device-specifics are defined in separate configuration VIs, supporting
hundreds of commercial chips for LabView-based data acquisition designs.

# Communication Package

CLARAty currently supports two forms of communication between hosts: a
Decision Layer/Functional Layer interface, and a Functional
Layer/Simulation interface. The interface between the Decision Layer
host and the Functional Layer host is implemented by the Connector
class, a socket-based asymmetric (client-server) middleware that
distributes messages to objects in the form of method calls on those
objects. The interface between the rover simulation host and the
Functional Layer host is implemented using a content-insensitive
messaging system that can be incorporated in any class. The simulation
interface is tailored for smaller, more frequent low-level messages,
whereas the decision-level interface is designed for less frequent
strategy-style commands.

The Connector class, used for host-to-host communication between the two
major layers of CLARAty, is designed as client-server middleware on top
of the Socket class. The Socket class is a symmetrical message transport
layer wrapping the socket services of the underlying operating system.
It can provide either TCP (connection-based) or UDP (packet-based)
service.

The Connector class adds message-level queuing and message-type-based
delegation of commands, as well as subscription service to the transport
layer. A fixed set of message types is supported, and a registry of
bindings between message type and consumer object method is maintained.
A message queue is maintained for both input and output from the
Functional Layer host, isolating the stream-based (TCP) transport layer
from the message processing. Each command received also spawns a new
thread that waits for command completion, enabling consuming classes to
be designed using a preemptive scheduling model, consequently allowing
the use of blocking or greedy objects if desired. The Connector class
itself is run as a server on the Functional Layer host. The client
(Decision Layer) runs client code -- either the connector_client
standalone test utility, or application software using the DL_Listener
class. The Connector class is also responsible for instantiating the
Rover object, which in turn instantiates its components.

## Socket 

The Socket class provides a message-based wrapper to low-level OS
services. The wrapper class provides a platform-neutral symmetrical
transport layer that can provide either a TCP connection or a UDP
reliable or unreliable packet delivery service. The Socket class
provides remote two-way messaging to any class that requires it,
allowing direct content-insensitive communication between any object in
CLARAty and any host also implementing the Socket class. This
lightweight messaging system is suitable for the frequent low-level
messaging occurring in hardware simulation.

The rover simulation interface package (see Section 16) provides a good
example of the use of the Communication Package. The user of the
Communication Package is an object of class SimMotor that performs
ControlledMotor actions. SimMotor is a type of ControlledMotor.
Internally, the SimMotor object, upon receiving a method call commanding
a motor motion, translates the call to an ASCII message that is sent to
the rover simulator host machine (acknowledgement of receipt required),
which then parses it and acts accordingly. Unsolicited motor status
messages are received from the rover simulation by the SimMotor object
in the Functional Layer.

## ( - 6.3) I2C and Serial Driver 

Other modules that are included in the communication package are serial
driver classes, which provide an interface to several serial
implementations such as I2C and RS232. The input and output of these
classes are character streams. There are also control settings for each
class.

##### Commercial Equivalents and Freeware {#commercial-equivalents-and-freeware-3 .unnumbered}

There are several implementation of middleware that have similar
capabilities. These include the implementation of TAO (ORB)
(http://www.cs.wustl.edu/\~schmidt/TAO.html), CORBA
(http://www.corba.org/), and other COTS and freeware packages. While
similar in functionality, the CLARAty implementation is designed to
allow the code to take advantage of optimizations that are not possible
with general purpose ORB architectures. Therefore, the CLARAty
middleware is domain specific.

# Manipulation Package

The manipulator package supports functions for serial-link manipulator
control and there are plans for it to support parallel link
manipulators. A manipulator is a robotic arm that has a number of joints
and a number of links. These manipulators can have redundant joints that
allow for very dexterous robotic manipulation or a limited number of
joints that allow for limited manipulation. Support for manipulators
include moving the arms in various modes (joint and Cartesian). In joint
mode, the arm can be moved by commanding the joints individually or as a
group or joints. In Cartesian mode, the arm is commanded by providing
the desired trajectory for the arm's end effector in Cartesian space.
The software would then use the inverse kinematics of the arm to
translate this request into joint commands that are sent to the
individual joints. In addition to inverse kinematics, the module also
supports the forward kinematics of the arm. For arms that are mounted on
mobile robot platforms, additional functionality includes definitions
for stow and unstow operations of a manipulator.

## Manipulators

Following a general principle of CLARAty Functional Layer Packages, the
CLARAty Manipulator Package (Figure 2) is based on an object-oriented
design that can be adapted to various manipulators. In particular, the
bridge design pattern \[Gamma, et al, 1995\] is repeatedly used at
different abstraction levels. In this bridge design pattern, different
specific implementations are separated from "generic abstraction". In
the top manipulator level, the "generic abstraction" Manipulator class
provides all the generic interface methods (functions) for high-level
manipulator control, while the "specific Implementation\" class provides
interfaces specific to each implementation. Similarly, the
Controlled_Motor class again uses the bridge design pattern to support
different implementations. Specific instances of concrete
Controlled_Motor_Impl objects are R7_Motors (which use LM629 motor
controller chips) and R8_motors (which use HCTL 1100 motor controller
chips on an in-house built widget board). The repeated use of the bridge
design pattern in both Controlled_Motor and Manipulator levels enables
the well-organized, easy-to-maintain, universal support of different
types of manipulators equipped with different motor controllers.

Figure 2. CLARAty Manipulator Package for Rocky7 Platform

A simplified functional diagram of Figure 2 shows modules specific to
the Rocky7 (R7) platform. It is important to note that a concrete
Manipulator object (e.g., R7_mast) can access not only Manipulator-level
(functions) methods but also any lower-level ones when needed. For
instance, R7_mast would normally use Manipulator-level functions.
However, if needed (e.g., during testing and anomaly recovery), it can
use lower-level functions such as a function to control or test a
specific joint motor, since the R7_mast object has access to the
corresponding motor object. The R7_mast→stop() function causes all the
joint motors of the R7_mast to stop, while joint1→stop() causes only the
joint 1 motor to stop.

The CLARAty coordinated joint motion control function move_joints()
employs synchronized motions, where all joints start to move
simultaneously. It is highly desirable to start moving all the joints at
the same time (or almost at the same time), to achieve consistent
manipulator motion trajectories, since different starts with
inconsistent or unpredictable delays could be particularly troublesome
if fine motion control is required.

If the manipulator end effector needs a straight-line motion, Cartesian
motion control is used. There are two methods to achieve straight-line
Cartesian motion control. The most common method when there is enough
computational power is to compute the forward and inverse kinematics on
the fly at every control loop cycle. For instance, at 100 or 200 Hz,
this method makes the Cartesian servo to achieve high-quality
straight-line motions. An alternate method is needed when there is not
enough computational power. In this alternate method the joint motion
trajectory sequence of via-points is first pre-computed to fit a
straight-line motion within a given error tolerance, and then the
manipulator is moved in accordance with the joint motion trajectory
sequence.

The manipulator class also supports unstow() and stow() operations which
are combinations of coordinated joint motions or Cartesian motions. For
synchronization or timely start of the next motions,
wait_until_done(percent_done) is used. It waits until the current motion
is completed by a specified percentage. Thereafter the next motion
starts. Depending upon different timing relations between joint motions,
three types of motions are possible: 1) two sequential stopping motions
by using percent_done = 100%, 2) two sequential non-stopping continuous
motions by using percent_done \< 100%, and 3) two synchronized motions
by not using wait_until_done().

## Sensor-based Manipulation 

The sensor-based manipulation class is a high-level class to perform
advanced manipulation using various sensors such as cameras, switches,
motor currents, tactile sensors, end-point force sensors, and proximity
sensors.

##### Commercial Equivalents and Freeware {#commercial-equivalents-and-freeware-4 .unnumbered}

Commercial examples include software developed to control industrial
robotic arms. This includes commercially available transformations,
forward and inverse kinematic and control algorithms. Some of the
industrial providers of such algorithms are: Adept Technologies, Inc.
(<http://www.adept.com/main/index.html>), Bosch Robotics
(<http://www.robotics-technology.com/robots/bosch/index.shtml>), Seiko
Robotics (<http://www.seikorobots.com/>), Yamaha Robotics
(<http://www.yamaharobotics.com/>), Kuka Robotics
(<http://www.kukarobotics.com/>), and Fanuc Robotics
(<http://www.fanucrobotics.com/>). These companies provide manipulators,
controllers, and manipulation control software for pick-and-place and
par assembly operations.

# Locomotion Package

The locomotor module supports software that is responsible for the
surface mobility control of robots. It provides functions for driving
robots in two different modes (start and stop mode, and continuous drive
mode). Locomotion system can use wheels, legs, or a hybrid of the two

## Wheeled Locomotion

The types of robots that are supported are limited to wheeled robots
with any number of drive and steering wheels. These vehicles can be
fully, partially, or skid steered. The functionality of the software in
this module includes the solving of vehicle forward and inverse
kinematics, the control of multi-wheel vehicles, and the logging of
vehicle operation data.

For example, the Rocky7 rover is partially steerable: all six wheels are
drivable, but only two front wheels are steerable. For a partially
steerable rover, a desired goal position (x, y) without heading
specification can be achieved by a single arc motion, which can be
equivalently specified by the arc distance and angle. A desired goal
position (x, y) with goal heading (d) needs two arc motions. Since there
are an infinite number of sets of two arcs that get the partially
steered vehicle to the desired position and heading, an optimal solution
is selected by using the cost function L1+L2+\|L1-L2\|, where L1 and L2
are the lengths of the first and second arcs.

In contrast to Rocky7, the Rocky8 rover is fully steerable: all six
wheels are both drivable and steerable. For a fully-steerable rover, a
goal position (x, y) without heading specification can be achieved by a
straight-line crab motion. On the other hand, when a specific goal
heading is also desired, a desired goal position with a goal heading can
be achieved by a single arc motion.

Functions for position moves include move(length, heading),
move(from_point_A, to_point_B), and move(from_point_A, to_point_B,
heading). Each move() function generates a motion sequence defining a
sequence of motion segments and then drives the rover according to the
generated motion sequence. Currently it either steers or drives wheel
motors. It does not steer while driving.

The locomotor class diagram (Figure 3) shows the current design of the
locomotor classes and their relationship with other classes in the
system. The Ctrl_Motor class is the same one described in the CLARAty
Motion Control package. The Wheel Locomotor again uses the bridge
pattern: Wheel_Locomotor class for generic abstractions and
Wheel_Locomotor_Impl class for specific implementations. The
Wheel_Locomotor_Impl class supports functions for specific wheeled rover
implementations including mechanism models such as get_wheel_radius(),
get_number_of_steer_motors(), get_number_of_drive_motors(),
get_axle_position(), and get_wheel_position().

#####  {#section-3 .unnumbered}

#####  {#section-4 .unnumbered}

##### ![](media/image1.wmf){width="6.5in" height="3.375in"} {#section-5 .unnumbered}

####### Figure 3. CLARAty Locomotor class diagram {#figure-3.-claraty-locomotor-class-diagram .unnumbered}

#####  {#section-6 .unnumbered}

## Legged and Hybrid Locomotors

##### There are several types of rovers that use legged locomotors. The legs of these locomotors are simple serial link manipulators. Legged locomotion bring together the manipulation and locomotion packages. Currently there are designs and implementations for both wheeled and manipulators but there is no integrated code has been implemented that combines the two. A hybrid locomotor is one that uses both wheels and legs. {#there-are-several-types-of-rovers-that-use-legged-locomotors.-the-legs-of-these-locomotors-are-simple-serial-link-manipulators.-legged-locomotion-bring-together-the-manipulation-and-locomotion-packages.-currently-there-are-designs-and-implementations-for-both-wheeled-and-manipulators-but-there-is-no-integrated-code-has-been-implemented-that-combines-the-two.-a-hybrid-locomotor-is-one-that-uses-both-wheels-and-legs. .unnumbered}

##### Commercial Equivalents and Freeware {#commercial-equivalents-and-freeware-5 .unnumbered}

There are several manufacturers of mobile robots and providers of
software packages that control the mobility of robotic systems. Such
companies include, RWI, a division of Irobot that sells the Mobility
software to control the different mobile robots sold by Irobot. Other
companies include ActiveMedia, Probotics, and Cyberobotics Corporation.
Additionally, there are algorithms available in the open literature on
how to control and implement software for mobile robots.

# Vision Package

The vision package is responsible for the implementation of
image-related data structures, image capture from cameras, image
operations and processing, machine vision algorithms, image related file
operations, and image displaying.

## Image Related Data Structures

The vision package provides a generic image data structure, which
maintains the pixel data of an image, as well as specific image
structures such as a color image (an image made up of color pixels),
multi-planar image (an image made up of multiple planes of data), and
camera image (an image that includes a model of the camera with which it
was taken). Another data structure is the 3D Point Cloud that is a list
of 3-D points in a vector form. This data structure is usually an output
generated from translated range maps to 3-D maps. These data structures
only provide a representation for data and do not include any image
processing operations.

## Cameras and Image Acquisition

The vision package also provides a high level interface for image
acquisition, as well as several specific implementations of a variety of
cameras and image acquisition methods. The high level interface provides
a uniform capability to acquire images and set parameters such as
exposure and gain on a camera. Implementations of specific
cameras/acquisition methods include IEEE 1394 (Firewire) cameras
(adhering to the 1394-based digital camera specification), specific
analog framegrabbers, and USB cameras. Each implementation adheres to
the high level interface but can provide additional capabilities
specific to the camera/method being implemented. The interface and
implementations are implemented using the bridge design pattern,
allowing for both conceptual and functional extendibility.

## Camera Calibration

The vision package also contains several camera calibration algorithms
for generating a camera model. A camera model has both extrinsic
parameters indicating where the camera is relative to the world and
intrinsic camera parameters, which capture the properties of the camera
optics. Camera calibration using CAHVOR \[JPL\] or Tsai/matrix \[OpenCV,
SRI\] model are available. All implementations are published and/or
distributed as a library

## Image Operations and Processing

Image operations, such as convolution, rescaling, subsampling, and
rectification, and image processing, such as edge detection and corner
detection, are also provided by the vision package. These operations all
implement a high-level image operation interface, which defines the
common behavior of all operations (an input image is processed to an
output image). The specific operations all adhere to this common
interface and can be used interchangeably. Additionally, each operation
can also have capabilities specific to the operation.

## Image Related File Operations & Display

The vision package also provides a high-level image file saving and
loading interface, which is implemented for various standard file
formats (including TIFF, PNM, FITS, etc.). The interface simply declares
a common load and save method call and the specific implementations
define the behavior of these calls for the respective file format.
Certain implementations may use external library calls (previously
written, commercially or publicly available code) while others may
implement the load and save methods from scratch.

The vision package provides the ability to display images and visualize
related data structures and algorithms on a host desktop machine using a
platform independent, commercially or publicly available GUI (graphical
user interface) toolkit. Currently, TrollTech\'s QT and the open source
OpenGL are the toolkits being used for visualization.

## Machine Vision Interfaces

This module provide generic classes (base classes) for various machine
vision algorithms. These classes do not have any technological
implementations. They only provide interface and structural designs to
support a number of machine vision algorithm implementations (see below)

## ( - 9.9) Machine Vision Algorithms

The machine vision algorithm types available in CLARAty which include
multiple implementations are:

-   **Stereo vision:** provides depth information from two or more
    images. The input to this algorithm is a number of image taken from
    cameras with known precise location and lens models, and the output
    is a depth or elevation map that provides the (x,y,z) location of
    every point in the image. In practice, there are a number of points
    for which no depth can be generated and the accuracy of the (x,y,z)
    points depends on the accuracy of the knowledge about the camera
    calibration parameters (location and lens model). This algorithm is
    primarily used in obstacle avoidance of mobile robots.

-   **Visual tracking:** provides the spatial motion of a feature in a
    sequence of images. The application of this algorithm is for
    tracking rock feature to allow a mobile robot to reach a designated
    rock in the terrain. The input to this algorithm is a continuous
    sequence of either monocular image or stereo image pairs. The ouput
    is an (x,y) designation in the image of where the selected feature
    is. This is normal fed into a locomotion algorithm to drive the
    robot to the designated goal.

-   **Visual odometry:** provides the spatial motion of a camera from a
    sequence of images taken by that camera. Similar to the above
    algorithm, the visual odometry algorithm track selected set of
    features in consecutive images. In addition to image sequence, it
    also requires an input for the initial estimate of the motion. The
    output is a refined estimate of the mobile robot motion.

-   **Camera calibration:** provides the lens and sensor parameters and
    location of a camera from a set of calibration images taken by the
    camera.

-   **Image matching/integration:** combines multiple images of a scene
    and generates a three dimensional reconstruction of the scene.

Generally, there are multiple implementations or techniques for solving
each problem, and a common interface is defined for each problem so that
the different methods implemented can be used interchangeably.

## *Commercial Equivalents and Freeware* {#commercial-equivalents-and-freeware-6 .unnumbered}

There are many commercial packages that implement the capabilities found
in the vision package. These include:

-   MathWorks\' MATLAB computing environment (provides convolution, edge
    detection, and other similar mathematical operations)

-   Intel\'s Image Processing Library and OpenCV library (provides image
    data structures, image processing, image file operations, and
    machine vision algorithms including stereo and camera calibration)

-   Microsoft\'s VisionSDK (provides image data structures)

-   SRI\'s Small Vision System library (provides stereo, camera
    calibration, and image file operations)

-   University of British Columbia\'s Vista package (provides image data
    structures, image processing, image displaying, image file
    operations, and a few machine vision algorithms including optical
    flow/tracking and camera calibration)

-   Sun\'s Java programming language (provides image data structures,
    image processing, and image displaying).

# Science Package

The science package is responsible for two main functions, 1) to provide
an interface wrapper for a spectrometer device, and 2) to analyze rock
and soil samples from both spectrum and science image data.

##  {#section-7 .unnumbered}

## Spectrometer

The spectrometer class has three distinctive functions: command
verification, data acquisition, and calibration. Command verification
involves checking the instrument state and reporting the readiness of
the device to carry out a requested function. The instrument state is
tracked in the spectrometer_impl class with a set of feature parameters.
Data acquisition is done through the acquire(), acquireAndRead(), and
read() methods. Acquire() captures a raw spectrum and stores it in the
storage buffer, while read() returns that spectrum from the storage
buffer to the user. AcquireAndRead() method captures a spectrum image
and returns a raw spectrum without using the storage buffer. The
exposure duration is an input to the acquire method. The
spectrometer_model for the device determines the maximum buffer size.
The raw data from the device may be calibrated upon request by accessing
an instrument-specific calibration procedure. Due to the performance
variation during operation, the calibration related performance
information would be updated via the spectrometer_model. An abstract
list of methods is provided below:

Main methods of the Spectrometer package are:

-   HasFeature // returns true if an instrument has the requested
    feature

-   Point // point spectrometer at a location

-   Calibrate // calibrate the spectrometer\'s response properties

-   GetSpectrum // returns raw spectrum

-   GetCalSpectrum // returns calibration spectrum

The spectrometer_impl class is a base class that can be used to derive a
device-specific operation control object (my\_ spectrometer_impl). The
operation control involves instrument conditioning for data acquisition
and data retrieve. Depending on the available features an instrument
has, the conditioning process may vary. Therefore, a set of feature
objects are developed with feature-specific control functions so that a
custom implementation class can be flexibly derived. The
spectrometer_impl class employs a set of feature objects to describe the
operational control properties of a device. The features may include
exposure control, gain level setting, buffer usage, scan platform
articulation, and calibration options. Each feature class provides a
list of options and a set of parameters so that the option and the valid
value range for each parameter may be set arbitrarily.

The spectrometer_model class is used to store information about a
spectrometer with respect to its structure, performance, and operation.
The structure information may include rover interface (how it is
attached and articulated) and dynamics related information. The
performance information may include signal quality related aspects such
as sensitivity, noise, and resolution. The operation information may
include a list of available commands, resource usage, and constraints.

## Science Image Analysis

The science image analysis consists of five main parts, which are edge
detection, horizon detection, finding solids, finding layers, and
ellipse summary. First the horizon detector finds the horizon in the
image. Then, the layer detector searches below the horizon for layers.
The spectrometer pointer searches below the horizon for a suitable
target to point a spectrometer. Therefore, the spectrometer pointer and
the layer detector are independent of each other, but in this
application, they depend on the horizon detector. Finally, there is an
elliptic summary than can be given for the output of the layer detector.
In summary, the spectrometer pointer depends on the horizon detector,
the layer detector depends on the horizon detector, and the ellipse
summary depends on the layer detector. This algorithm is currently under
implementation.

## Science Spectrum Analysis

The science spectrum analysis is used to determine rock mineral
composition. Currently only carbonate can be detected. The algorithm to
detect carbonate is implemented in the Carbonate_identifier class under
the module analysis_carbonate. The Carbonate_identifier class inputs a
Cal_Refl_Spectrum to analyze, which is calibrated spectrum data created
by the spectrometer class. The method analyze() is used to analyze this
calibrated spectrum and return --1 if the data is noisy, return 0 if the
sample does not contain carbonate, return 1 if the sample contains
carbonate, or return something else if the result contains wrong
information.

## Science Cameras

Science cameras are a specialization of the camera classes that provide
additional calibration parameters needed for science analysis. In
general science cameras are colored cameras with high fidelity camera
optics. In some instances, generic colored cameras can be used instead
of specialized science cameras

# Estimation Package

The estimation package is responsible for providing tools for estimating
robot related state. These tools include implementations of various
types of estimator filters such as an implementation of a Kalman Filter.
One example of estimation currently implemented and used on the Rocky
rovers is the estimation of the rover\'s current position in the global
coordinate frame. The module provides functions for initializing the
estimator and for querying the current state estimate. This position
estimator is based on inputs received from an Inertial Measuring Unit
(IMU) and wheel odometry. The IMU provides angular velocity and linear
acceleration about three axes. Currently, the estimator uses only the
yaw rate from the sensor. The yaw rate provides information about the
rover heading. By combining both the IMU and the wheel odometry
estimator enables improved position estimation over estimations based on
just wheel odometry alone. The IMU provide this improvement by
compensating for wheel slippage.

## Kalman Filter

This package contains a Kalman Filter module that implements the
mathematics of a Kalman Filter in the general sense. These are adapted
and used for the rover position and orientation estimation.

The rover position estimation module uses a two-tier Kalman Filter to
perform position estimation. The first tier uses a linear Kalman Filter
to estimate the bias in the yaw rate of the IMU. This enables the system
to subtract out noise from the sensor readings. Because the amount of
noise can change over time (e.g. as temperature changes) it is necessary
to estimate the yaw rate bias at intervals throughout the course of
rover operations. Currently, the estimator computes the yaw bias
estimate whenever the rover is stopped. As the rover moves, the
estimated bias is subtracted from the IMU measurement to produce a
corrected measurement.

The second tier uses an extended Kalman Filter to estimate the change in
position of the rover. This is an estimate of the amount of change in
the rover\'s (x,y) location and heading since the last time the filter
was updated. The Kalman Filter uses a system model for an Ackerman-based
vehicle.

The Kalman Filter uses a single sensor model based on the IMU yaw rate.
The estimated change in heading from the filter is compared with the
sensed change in heading from the IMU to produce a residual. The
residual, in turn, is used in the computation of the Kalman gain which
eventually will determine how much weight to place in the predicted
state estimate from the system model and the sensed measurements from
the IMU.

The interface to the estimator includes of the following functions:

> setStateVector() // sets initial state
>
> setStateTransitionMatrix() // specifies the state transition matrix
>
> setEstimatorSysNoise() // specifies the system noise
>
> setEstimatorObsSys() // specifies the measurement model
>
> setEstimatorObsNoise() // specifies the measurement noise
>
> updateKalmanFilter() // propagate/update linear kalman filter
>
> updateRoverKalmanFilter() // propagate/update extended kalman filter

## Pose Estimator Interface

This module contains an interface that ties together any type of pose
estimation with the locomotion modules from which it need information.
This module is contains glue components that tie estimation,
transformations and locomotion.

##### Commercial Equivalents and Freeware {#commercial-equivalents-and-freeware-7 .unnumbered}

There are some commercial packages that implement the capabilities found
in the estimation package. These include:

-   MathWorks\' MATLAB computing environment (provides a toolkit for
    various types of probablistic and estimation filters)

-   The Kalman Filter toolbox - Kevin Murphy, UC Berkley, 1998
    <http://www.cs.berkeley.edu/~murphyk/Bayes/kalman.html> (free
    download)

# Navigation Package

The navigation package is responsible for moving the rover from one
point to another while avoiding obstacles. The navigation module
performs traversability analysis of the terrain, based on sensor input,
and selects actions that satisfy local and global navigation
constraints. The navigation module makes use of the wheel locomotor,
stereo, path planning, and matrix packages, among others.

## Local Navigator 

The basic operation of the navigation package is to move the rover from
one waypoint to another. The navigator object repeatedly invokes the
action selector to find the best motion for the robot to execute. It
then commands the locomotor to perform this motion. Upon completion it
again finds the best action, until it achieves the current waypoint. The
navigator also repeatedly invokes the traversability analyzer, which
gets new sensor data from the stereo vision object and then creates a
map data structure that indicates how difficult it is to traverse
different patches of the terrain. Other objects (such as the local and
global cost functions) can register interest in receiving the results of
the traversability analysis, in order to update their own internal maps.

## Local Path Planner

The basic operation of the action selector is to choose the best motion
for the rover, based on local and global path constraints. Local path
constraints include avoiding obstacles; global path constraints include
minimizing distance traveled to the waypoint. There are several ways to
incorporate both local and global information, including voting and path
integration. Both methods have been used in the past, and both are
supported within the navigator framework. In the path-integration action
selector (the first implementation of the action-selector class), the
action selector determines how the rover will travel along a discrete
number of arcs. The wheel locomotor model is used to predict how the
rover moves, given kinematic and dynamic constraints. At each point
along the path, the local cost function is invoked to determine how
costly it is to travel that part of the path (based on the results of
the traversability analysis) and the global cost function is invoked to
determine how costly it is to travel from that point to the desired
waypoint. Roughly speaking, these two costs are added together, and the
arc with the lowest overall cost is chosen as the next heading for the
rover.

## Navigation Implementations

The navigator package is general enough to handle several different
algorithms that have appeared in the literature. The initial
implementation of this package is based on work at Carnegie Mellon
\[Urmson et.al, 2002\], and features an action selector based on path

integration and a global cost function based on the D\* path planning
algorithm \[Stentz, 1995\]. Another candidate for the action selector is
the GESTALT algorithm, being developed for MER \[Goldberg et.al.,
2002\]. The GESTALT algorithm uses a simple distance-to-goal metric for
the global cost function and uses a voting scheme to combine local and
global constraints (each source gives a weighted vote, or a veto, to the
different arcs, and the non-vetoed arc with the highest total vote
wins). Other candidates include the Sojourner algorithm and a navigation
scheme based on fuzzy logic \[Seraji and Howard, 2002\].

###### GESTALT Navigator {#gestalt-navigator .unnumbered}

Figure 4 shows a simplified functional block diagram of the GESTALT
Navigator as an instance of the CLARAty Navigator. It uses the Stereo
Vision module (see Section 10 on the Vision Package) and Locomotor
module (see Section 9 on the Locomotion Package) as well as various
navigation components.

Figure 4. GESTALT Navigator as an instance of the CLARAty Navigation
Package

The GESTALT (Grid-based Estimation of Surface Traversability Applied to
Local Terrian) is one of the primary technology implementations of a
navigation software module in CLARAty. At its core, GESTALT decides the
next best direction for a rover to move, given a desired waypoint goal
with the current state of the world model and new sensor data. The
desired waypoint goal is typically given as (x, y) or (x, y, z) in a
known world frame. The overhead view of the world to traverse on is
represented by a grid of rectangular cells. Cells are classified as
based on their index of traversability, which is based on slope and
roughness of the terrain at that particular cell. A cell with a high
index is untraversable and is marked as an obstacle. A typical example
is a 10 m × 10 m grid with 20 cm × 20 cm cells, consisting of 50×50
grid-cells. Using sensor data, GESTALT selects the best arc-path for
each incremental step of a typically 35 cm distance.

At each step, the rover heading and distance that corresponds to the
selected best arc-path is sent to the lower-level wheel locomotor
controller to move the rover. At the end of the each step, GESTALT
assumes that a pose estimator provides a reasonably accurate estimate of
the rover's new position. The pose estimator typically uses wheel
odometry, an inertial measurement unit, and a sun sensor. A well-known
problem of the pose estimator is that it accumulates errors as the rover
traverses long distances. A visual odometer that uses 2-D and 3-D
feature tracking could be very helpful to reduce pose estimation errors.

The GESTALT computational procedure during a single navigation step is
as follows:

1.  Invoke GESTALT with a current rover pose estimate and new range
    data.

2.  Compute first and second moment statistics Σx, Σy, Σz, Σxy, Σxz,
    Σyz, Σx2, Σy2, Σz2 about all range points consisting of a set of (x
    y z) in a given cell.

3.  Find the transverability of each cell by merging the moment
    statistics and finding the best-fit plane. Using the plane
    parameters, compute three hazard measures: step hazard, roughness
    hazard and border hazard.

4.  Compute the traversability vote value of each arc path as a weight
    sum biased to consider nearby cells more strongly.

5.  Compute the path (or waypoint) vote value of each arc path as a
    goodness value according to how well it is aligned towards its goal
    point.

6.  Select the best arc path by merging the above two sets of votes.

7.  Send the best arc path to the Locomotor module.

***Commercial Equivalents and Freeware***

The Mobility software from iRobot offers similar functionality for
indoor navigation only. The Saphira software also provides a navigation
software that is based on fuzzy logic to allow a mobile robot to
perceive it local environment, generate motion commands to drive the
rover through that environemtn. Another company that provide small
mobile platforms with navigation capabilities is ActivMedia. They
manufacture small Pioneer robots that use sonar based sensing to do
indoor navigation.

# Path Planning Package

The path planning package is responsible for determining routes that the
rover can take through terrain that minimize some objective cost metric.
The path planning package is used by both the navigator package, which
is described in the previous section, and the Decision Layer. Some
implementations of the path planning package make use of the
traversability analysis functionality of the navigator package. The path
planning packages contains both the generic interfaces for path planners
and various implementations.

## Global Path Planners

The global path planner module contains a generic interface to various
types of path planner implementations. The basic operation of the path
planning is to produce routes to a desired waypoint that adhere to
constraints (such as avoiding obstacles, or staying in the sunlight)
while minimizing a cost metric (such as travel time, distance, or power
usage). The path planning module is able to return the answer to queries
about the cost of the best route from a given point to the waypoint.

## Global Path Planners Implementations

While various path planners use different algorithms for determining the
answer to this, they mostly work in similar ways \-- searching through
space (and perhaps time) to find a path that minimizes the cost metric.
Some path planners use a discrete grid to find the best path \[Stentz
1995\], while others plan in a continuous space \[Laubach and Burdick,
1999\]. In addition, some use a continuous cost metric \[Stentz 1995,
Tompkins et.al, 2002\], while others use a binary (occupied or not)
metric \[Laubach and Burdick, 1999\]. The initial implementations of the
path planning module uses the D\* algorithm developed at Carnegie Mellon
University \[Stentz 1995\], which uses a discrete grid and continuous
cost metric.

# Behavior Package

The Behavior package provides a general mechanism for data fusion from
different sensors. It evaluates the input values using objectives,
weights, priorities, and other metrics, and then calculates the output.
Within this package are plans for several modules including ones for
neural network control, fuzzy logic control, and behavior-based control.

## Behaviors

We have laid out some designs for a few classes in the behavior-based
control domain.

![](media/image2.wmf){width="6.663888888888889in"
height="5.272222222222222in"}

Figure 5: Some Behavior classes and their relationships

In behavior-based control, a robot is controlled using behaviors rather
than goals or commands. Such control can be implemented using the
different granularity levels of the Functional Layer. Depending on the
level of interest, one can implement this control at the motion control
level, at the sub-system level (such as the mobility or manipulation
level), or at the rover level (for multi-rover coordination).
Behavior-based control uses a set of robot behaviors that run in
parallel but are coordinated using a coordinating function. There are
two types of coordination functions to resolve conflicting behaviors:
(1) cooperative coordination and (2) competitive coordination.

Figure 5 shows the Behavior class which provides the core data-structure
for behavior types. It attaches to any member function of generic
physical components or generic functional components. A behavior can be
started and stopped at any time.

## Composite Behaviors

A behavior can also encompass other behaviors. This is accomplished
through the Composite_Behavior class. It is derived from the Behavior
class but it also aggregates that class. By making the
Composite_Behavior a child of Behavior, Composite_Behavior objects will
be of the same type as Behavior objects and can hence be used
interchangeably. The CompositeBehavior class has a BehaviorCoordination
object to resolve behavior conflicts. BehaviorCoordination objects
resolve conflicts between any behavior types. These constructs can be
attached to any operation within the Functional Layer.

The Behavior_IO class represents a generic behavior input or behavior
output link/attachment. It enables output from one behavior to be
attached to the input of another to enable construction of arbitrary
behavior networks.

##### Commercial Equivalents and Freeware {#commercial-equivalents-and-freeware-8 .unnumbered}

There are some COTS packages that implement domain specific
infrastructure. Some use an object-oriented framework such as Mobility
software from Irobot while others use a procedural framework, such as
Saphira. The Saphira package provides an extensive framework for
fuzzy-based control of mobile systems. It is desirable to integrate
functionality of different domain packages into a single framework to
simplify comparative studies of different control and operation
approaches.

# Simulation Interface Package

CLARAty can be interfaced with high-fidelity dynamic graphic-base rover
simulators

This package provides a specialization of the various CLARAty components
so they can be easily interfaced with such simulators. The simulator
itself is not part of this package.

## Simulator Connectors

CLARAty taps into the simulation at any one of three levels of
abstraction: functional (the entire Functional Layer), mobility
(simulated rover-level motion control -- e.g. "go_to \<rover-relative
location\>"), and motor (simulated hardware). The simulation typically
runs on a separate host that contains OpenGL graphics hardware. The
CLARAty Simulation Package is comprised of plug-compatible classes that
simulate the functionality at various levels of abstraction in the
Functional Layer. These objects use the Communication Package software
(described in Section 7) to communicate with a rover simulator via IP
sockets. This message-based middleware provides an infrastructure that
enables any simulation object in the Functional Layer to communicate
with a rover simulator. Additional details of the communication software
can be found in the Communication Package description.

## Simulation Implementation

CLARAty simulation modules are plug-compatible with actualized modules.
The SimMotor module implements the ControlledMotor interface, which is
described in detail in Section 2.1. The simulation is actually computed
by the rover simulator software on a different host. The CLARAty
simulation module provides a front-end model of the motor state on the
CLARAty host. Motor state includes position, velocity, and acceleration
values (both commanded and actual), and power and error state. Methods
that initiate a motor movement cause a message to be built as a string,
which is then sent to the rover simulator host using the middleware
described above. The communication protocol and message syntax are
described next.

**Communication protocol:**

-   All messages are unsolicited and unscheduled (asynchronous)

-   All messages are ASCII formatted and terminated with a semicolon

-   Motor command messages from CLARAty FL to the rover simulator are
    acknowledged by the rover simulator

-   Motor status messages from rover simulator to CLARAty FL are NOT
    acknowledged

-   Status messages from rover simulator will be sent only when state is
    changing

-   Rover Simulator-side send and receive functions will be provided

-   Rover Simulator-side test/demo program will be provided

-   All values are in radians & secs (radians/sec, radians/sec\*\*2)

-   All values are absolute

**Message Syntax and Command Dictionary:**

-   Commands from CLARAty FL:

MPWR\[MotorName\]\[\"0\"\|\"1\"\]; // Motor power on (=1) or off (=0)

MMOV\[MotorName\]\[\"V\"\|\"P\"\]\[Val\]; // Move motor at V rad/sec or
to P rads

MMOV\[MotorName\]T\[TrajAccVal\],\[TrajMaxVelVal\],\[TrajEndPosVal\];

// Move motor according to traj spec

MSTP\[MotorName\]; // Stop a motor

MSTP; // Immediate stop all

-   Status from ROAMS:

MSTA\[MotorName\]\[AccVal\],\[VelVal\],\[PosVal\];

MACK\[MotorCommandMessageCopy\];

Definitions:

\[Val\] Absolute velocity or position values

\[MotorName\] 4 characters set in sim_motor object

\[TrajAccVal\] Trapezoid trajectory params

\[TrajMaxVelVal\]

\[TrajEndPosVal\]

\[AccVal\],\[VelVal\],\[PosVal\]: Motor motion snapshot

##### Commercial Equivalents and Freeware {#commercial-equivalents-and-freeware-9 .unnumbered}

Since this is a specialized adaptation to a specific simulation, there
are no commercial equivalents to this particular example. However, there
are several commercially available robot simulators which include
packages from Delmia Robotics (http://www.delmia.com/), Adept
Technology, Adept Technologies, Inc.
(<http://www.adept.com/main/index.html>), Irobot Corporation
(<http://www.irobot.com/home/default.asp>), and Saphira from (K-team)
(http://www.k-team.com/software/saphira.html)

# Adaptations to Rovers 

The hardware rover platforms supported by CLARAty are Rocky8, Rocky7,
FIDO, and K9. Each rover platform has different hardware components. The
CLARAty architecture facilitates easy adaptations to support a variety
of different hardware. The specific implementation classes associated
with these specific hardware components are first created. These
specific implementation classes are usually concrete subclasses of
certain Impl classes. Their related generic classes and programs do not
need to change. Therefore, in CLARAty, adaptations are relatively
simple: add hardware-specific concrete subclasses and leave the common
or generic portions of the software unchanged.

## The Rocky 8 Rover

The Rocky 8 rover is 6-wheel drive 6-wheel steering vehicle with a
rocker-bogie suspension mechanism. It is an all-wheel drive and
all-wheel steering vehicle. It is equipped with a 4DOF mast and 4DOF
instrument arm. The computational module of Rocky 8 is a cPCI backplane
with 233 MHz processor and 64 MB of RAM. It has a distributed motion
control and I/O control system based on the reusable "widget board." (a
single axis motion control board with digital and analog I/O). It has a
distributed FireWire-based vision system.

The Rocky8 specialized physical components include 1) Rocky8 motors, 2)
Rocky8 cameras, 3) Rocky8 IMUs, 4) Rocky8 Hardware Map, 5) Rocky8
Digital I/O, and 6) Rocky8 Analog I/O. The Rocky8 specialized software
functional components include 1) R8_Locomotor, 2)
R8_Constrained_Locomotor, 3) R8_Navigator, 4) R8_Mast, 5) R8_Arm, and 6)
R8_Rover.

## The Rocky 7 Rover

The Rocky 7 rover is approximately the same size and mass as the Mars
Pathfinder rover, Sojourner. It is a partially steerable vehicle with
6-wheel drive and 2-wheel steering capabilities. It has a rocker-bogie
suspension mechanism. It is equipped with 3 framegrabber-based
stereo-pair imagers, a 3DOF (degree-of-freedom) mast and a 2DOF
instrument arm with 2DOF scoops.  It has a cPCI PPC750 based
computational module, I/O cards, framegrabbers, and a custom motion
control architecture based on the LM629 chip.

The Rocky7 specialized physical components include 1) Rocky7 motors, 2)
Rocky7 cameras, 3) Rocky7 accelerometers, 4) Rocky7 gyroscopes, 5)
Rocky7 Hardware Map, 6) Rocky7 Digital I/O, and 7) Rocky7 Analog I/O.
The Rocky7 specialized software functional components include 1)
R7_Locomotor, 2) R7_Constrained_Locomotor, 3) R7_Navigator, 4) R7_Mast,
5) R7_Arm, and 6) R7_Rover.

##  {#section-8 .unnumbered}

## The FIDO Rover

The JPL FIDO rover, is very similar to the Rocky 8 from a mobility and
manipulation standpoint. It has a PC104-based computational module with
a custom memory-mapped centralized motion control architecture and a
framegrabber-based vision architecture. It also has a number of science
instruments including an infra-red moessbauer spectrometer.

The FIDO specialized physical components include 1) FIDO motors, 2) FIDO
cameras, 3) FIDO accelerometers, 4) FIDO gyroscopes, 5) FIDO Hardware
Map, 6) FIDO Digital I/O, and 7) FIDO Analog I/O. The FIDO specialized
software functional components include 1) FIDO_Locomotor, 2)
FIDO_Constrained_Locomotor, 3) FIDO_Navigator, 4) FIO_Mast, 5) FIDO_Arm,
and 6) FIDO_Rover.

## The K9 Rover

The K9 rover is similar to Rocky 8 from a mobility standpoint. Unlike
Rocky 8, the K9 rover has a fixed mast. It runs a distributed motion
control architecture based on the PICServo motion controllers. It runs
the Linux operating system.  The K9 rovers uses a FireWire based vision
system.

K9 is the NASA Ames rover platform. The K9 specialized physical
components include 1) K9 motors, 2) K9 cameras, 3) K9 accelerometers, 4)
K9 gyroscopes, 5) K9 Hardware Map, 6) K9 Digital I/O, and 7) K9 Analog
I/O. The K9 specialized software functional components include 1)
K9_Locomotor, 2) K9_Constrained_Locomotor, 3) K9_Navigator, 4) K9_Mast,
5) K9_Arm, and 6) K9_Rover.

.

# Decision Layer Package

The Decision Layer package is responsible for providing autonomous
command-sequencing capabilities to coordinate rover activities. The
capabilities include creating a command sequence (i.e., plan of rover
actions) based on an input set of high-level science and engineering
goals, executing that sequence, monitoring the sequence execution, and
modifying the sequence dynamically when necessary. In order to provide
these capabilities, the Decision Layer uses technology from the areas of
Artificial Intelligence planning, scheduling and execution.

## Continuous Planner Implementations 

The current instantiation of the Decision Layer uses several
independently developed software systems to provide planning and
scheduling capabilities.

ASPEN (Automated Scheduling and Planning Engine) \[Chien, et al., 2000\]
is an automated planning and scheduling system, which generates activity
plans based on a set of high-level goals. It is an object-oriented
system that provides a reusable set of software components that
implement the elements commonly found in complex planning and scheduling
systems. These include:

-   An expressive constraint modeling language to allow the user to
    define the application domain

-   A constraint management system for representing and maintaining
    spacecraft operability and resource constraints, as well as activity
    requirements

-   A set of search strategies for plan generation and repair

-   A language for representing plan preferences and optimizing over
    these preferences

-   A temporal reasoning system for expressing and maintaining temporal
    constraints

-   A graphical interface for visualizing plans/schedules

ASPEN was developed at JPL and is written in C++ and Java.

CASPER[^1] (Continuous Activity Scheduling, Planning, Execution and
Re-planning) \[Chien, et al., 1999\] is an extension of the ASPEN system
that supports continuous modification and updating of a plan. Rather
than consider planning a batch process in which a planner is presented
with goals and an initial state, CASPER has a current goal set, a plan
of activities, a current state of the world, and a model of the expected
future state. At any time an incremental update to the goals, current
state, or planning horizon may update the current state of the plan and
thereby invoke the planner process. The planner is then responsible for
maintaining a consistent, satisficing plan with the most current
information. As unexpected events or state updates occur, the planner
stands ready to continually modify the plan to bring it back to a
consistent and preferred state. CASPER was developed at JPL and is
written in C++.

In applying ASPEN and CASPER, we adopted the general framework and
system code, but adapted each system to provide the necessary Decision
Layer functionality. This adaptation included the development of domain
model definitions, algorithms and code to provide the necessary planning
and scheduling capabilities for CLARAty.

## General Planner Infrastructure

The Decision Layer is also intended to contain basic planning
infrastructure that can be used to support different types of planning
algorithms and implementations. This infrastructure will likely contain
interfaces and support for planning search algorithms, structures for
representing plan information (such as goal lists or preference
information), plan visualization tools, etc. This module is currently
not fully implemented and is planned for future work.

## Executive Implementations 

TDL (Task Description Language) \[Simmons and Apfelbaum, 1998\] is an
executive software framework that provides capabilities to support the
execution of a plan of activities or tasks. TDL was created as an
extension of C++ that simplifies the development of robot control
programs by including explicit syntactic support for task-level control
capabilities. These capabilities include task decomposition,
fine-grained synchronization of subtasks, execution monitoring, and
exception handling. TDL provides a compiler that transforms TDL code
into efficient, platform-independent C++ code that invokes a Task
Control Management library to manage task-control aspects of the robot
system. TDL was developed by Carnegie Mellon University (CMU) and is
distributed freely.

In using TDL, we adopted the general framework and system code, but
adapted it to provide the necessary Decision Layer functionality. This
adaptation included the development of domain model definitions and code
to provide specific executive capabilities for CLARAty.

## General Executive Infrastructure

The Decision Layer is also intended to contain basic executive
infrastructure that can be used to support different types of executive
algorithms and implementations. This infrastructure will likely contain
interfaces and support for generic executive capabilities, such as task
decomposition, exception handling, task synchronization, etc. It may
also contain other supporting code and visualization tools. This module
is currently not fully implemented and is planned for future work.

## Planner and Executive Integrations

The Decision Layer also contains support for tightly integrating
planning and executive capabilities. This support is currently providing
by the CLEaR (Closed-Loop Error and Recovery) system, which provides an
approach for unifying the planning and execution processes to increase
the responsiveness of a robotic agent. In particular, CLEaR contains
specific functionality for having CASPER and TDL work closely together
to create and execute a plan of activities. The CLEaR approach is to
provide a tightly-coupled approach to coordinating goal-driven and
event-driven behavior. Planning and scheduling capabilities are usually
"goal-driven," where they can reason about the requirements of
high-level goals and general resource and state requirements. These
capabilities are typically used on a long-term time scale and consider
the global state and quality of the resulting plan. Executive
capabilities are more "event-driven," which enables the system to react
quickly to new events and modify the plan appropriately. These
capabilities usually reason about near-term parts of the plan and only
make local plan changes. However, for many applications, it is
beneficial to have these capabilities available to all activity
granularities and plan timescales. CLEaR provides this capability by
allowing a planner and executive to operate on the same set of plan
activities and allow goal-driven and event-driven behaviors to operate
on both near- and far-term parts of the plan. CLEaR was developed at JPL
and is built on top of the CASPER and TDL systems.

## Activity Database

Another component of the Decision Layer is the Activity Database. This
is a generic data structure that contains information on the current
plan and can be use by different planning and executive system. The
information in this database includes items such as instantiated plan
activities, activity parameter values, plan timelines (which show how
states and resources change over time), constraints on and between plan
activities, etc. During runtime, the Activity Database will also hold a
copy of activity, state and resource definitions so that it may
instantiate new activities into the plan.

Currently the Activity Database is part of the ASPEN and CASPER planning
systems and is only used by these systems. In future work, we plan to
have all planning and executive systems share the same generic Activity
Database structure.

## Rover Models

The Decision Layer also contains model(s) of possible rover activities
as well as resource and state constraints that must be followed for the
particular rover and application. Any generated plan must obey any
relevant model constraints, such as resource limitations, temporal
requirements, or instrument operation rules. Model information can be in
the form of declarative or procedural knowledge. Declarative knowledge
allows for the representation of goal or activity preconditions and
effects (such as how much of a certain resource is required to
successfully perform an activity). Procedural knowledge allows for the
representation of constructs such as conditionals, loops, and how to
decompose a high-level goal or activity into a set of low-level steps.
This model information is used by both planning and executive systems.

## Interfaces

CLARAty contains a set of interface software that connects the Decision
Layer to Functional Layer capabilities. The Connector class, which is
used to communicate between these two layers, is discussed in Section 7.
This section discusses the types of information that are sent between
layers.

Currently, the Decision Layer can interface to the Functional Layer in
several ways.

First, the Decision Layer sends commands to the Functional Layer and the
Functional Layer returns status information on those commands. After
plans are constructed in the Decision Layer, plan activities are mapped
to commands. When the commands are scheduled for execution, they are
relayed to the correct Functional Layer object. After a command has been
executed, the Functional Layer returns an execution status to the
Decision Layer reflecting the success or failure of the command. Second,
the Decision Layer queries the Functional Layer during plan execution
for state and resource information (such as how much energy is left in
the battery). A query can be for a single time point or for an iterative
return of state over a time interval. Third, the Decision Layer can
query during plan construction for resource prediction estimates
associated with particular activities. For instance, the Decision Layer
might request an estimate on how much memory storage a science-data
operation will require.

CLARAty also contains a set of interface specifications between planning
and executive systems. Since many planning and executive system are
independent pieces of code (as opposed to an integrated approach such as
CLEaR), it will often be necessary to pass information between the
planner and executive. We are in the process of designing a generic API
and framework for relaying information between planning and executive
system modules. The type of information that would be sent between these
modules includes activities, commands, queries, and state and resource
data. Currently this framework is still in the design phase.

***Commercial Equivalents and Freeware***

There are several companies that have planning and scheduling software
products. These include Analytical Graphics, Inc.,
(<http://www.analyticalgraphics.com/>) which provides analysis and
visualization products for aerospace and other applications, and ILOG,
Inc, (<http://www.ilog.com/>) which provides resource management and
automation software for application areas such as aerospace,
transportation, etc.\
\
***Related Mission/Flight Adaptations***

Some of the software systems mentioned in this section have been adapted
to support several small missions that NASA has either jointly run or
supported. However, please note that none of this software has been used
to handle critical mission or flight functionality such as entry,
descent and landing or trajectory control. This software is primarily
used to schedule science observations and related activities, such as
radar calibration, image acquisition, science processing, etc. The
CLARAty adaptation is intended to primarily support research effort as
opposed to being used for actual flight software.

**References**

\[Brad, et al., 1982\] M. Brad, J. M. Hollerbach, T. L. Johnson, T.
Lozano-Perez, and M. T. Mason, eds, Robot Motion Planning and Control,
MIT Press, 1982.

\[Balaram, 2000\] J. Balaram, "Kinematic State Estimation for a Mars
Rovers," Robotica, 18:251-262, 2000.

\[Chien, et al., 1999\] S. Chien, R. Knight, A. Stechert, R. Sherwood,
G. Rabideau, \"Integrated Planning and Execution for Autonomous
Spacecraft,\" IEEE Aerospace Conf., Aspen, CO, March 1999.

\[Chien, et al., 2000\] S. Chien, G. Rabideau, R. Knight, R. Sherwood,
B. Engelhardt, D. Mutz, T. Estlin, B. Smith, F. Fisher, T. Barrett, G.
Stebbins, D. Tran , \"ASPEN - Automating Space Mission Operations using
Automated Planning and Scheduling,\" SpaceOps 2000, Toulouse, France,
June 2000.

\[Craig, 1986\] J. Craig, Introduction to Robotics: Mechanics and
Control, Addison-Wesley, 1986.

\[Dalheimer, 2002\] K. Dalheimer, Programming with Qt, O'Reilly, 2002.

\[Gamma, et al., 1995\], E. Gamma, R. Helm, R. Johnson, and J.
Vlissides, *Design Patterns, Elements of Resuable Object-Oriented
Software*, Addison-Wesley, 1995.

\[Goldberg et al., 2002\] S. Goldberg, M. Maimone and L. Matthies.,
"Stereo Vision and Rover Navigation Software for Planetary Exploration,"
*Proceedings of the IEEE Aerospace Conference*, Big Sky, Montana, March
2002.

\[Intel, 1999\] Open Source Computer Vision Library Reference Manual,
Intel Corporation, 1999.

\[Laubach and Burdick, 1999\] S. Laubach and J. Burdick, "An Autonomous
Sensor-Based Path-Planner for Planetary Microrovers," *Proceedings of
the IEEE Conference on Robotics and Automation*, Detroit, Michigan, May
1999.

\[Laubach, et al., 1999\] S. Laubach, C. Olson, J. Burdick, and S.
Hayati, \"Long Range Navigation for Mars Rovers Using Sensor-Based Path
Planning and Visual Localisation,\" 5th International Symposium on
Artificial Intelligence, Robotics, and Automation in Space
(iSAIRAS\'99), June 1999.

\[Maybeck, 1979\] P. S. Maybeck, Stochastic Models, Estimation, and
Control, Academic Press, 1979.

\[McKerrow, 1991\] P. J. McKerrow, Introduction to Robotics,
Addison-Wesley, 1991.

\[Nesnas, et al., 2000\] I. Nesnas, M. Maimone, H. Das, "Rover
Maneuvering for Autonomous Vision-Based Dexterous Manipulation," IEEE
Int. Conf. on Robotics and Automation, Apr. 2000.

\[Olson, et al., 2000\] C. Olson, L. Matthies, M. Schoppers, M. Maimone,
"Robust stereo ego-motion for long-distance navigation," IEEE Conf. On
Computer Vision and Pattern Recognition, June 2000.

\[Paul, 1981\] R. P. Paul, Robot Manipulators: Mathematics, Programming,
and Control, MIT Press, 1981.

\[Schmidt, 2002\] Schmidt, Douglas. The Adaptive Communication
Environment (AC E) <http://www.cs.wustl.edu/~schmidt/ACE.html>, 2002.

\[Seraji and Howard, 2002\] H. Seraji and A. Howard., "Behavior-Based
Robot Navigation on Challenging Terrain: A Fuzzy Logic Approach," *IEEE
Transactions on Robotics and Automation* 18:3, June 2002.

\[Shi and Tomasi, 1994\] J. Shi, C. Tomasi, "Good Features to Track,"
IEEE Conf. On Computer Vision and Pattern Recognition, June 1994.

\[Simmons and Apfelbaum, 1998\] R. Simmons and D. Apfelbaum, "A Task
Description Language for Robot Control," Conf. on Intelligent Robotics
and Systems, Vancouver Canada, October 1998.

\[Stentz, 1995\] A. Stentz, "The Focused D\* Algorithm for Real-Time
Replanning," *Proceedings of the International Joint Conference on
Artificial Intelligence*, Montreal, Canada, August 1995.

\[Tompkins et.al., 2002\] P. Tompkins, A. Stentz and W.L. Whittaker,
"Mission Planning for the Sun-Synchronous Navigation Field Experiment,"
*Proceedings of the 2002 IEEE International Conference on Robotics and
Automation*, May, 2002.

\[Urmson, et al., 2002\] C. Urmson, M. Dias, and R. Simmons, "Stereo
Vision Based Navigation for Sun-Synchronous Exploration*," Proceedings
of the Conference on Intelligent Robots and Systems*, Lausanne,
Switzerland, Sept, 2002.

\[Volpe, 1999\] R. Volpe, \"Navigation Results from Desert Field Tests
of the Rocky 7 Mars Rover Prototype\" International Journal of Robotics
Research, Special Issue on Field and Service Robots, 18(7), July 1999.

[^1]: Not to be confused with CASPER (the Cassini Sequence Planner),
    which is different piece of software.