June 28, 2000 Architecture Review 1 Examples: Implementing Common Solutions within CLARAty

June 28, 2000 Architecture Review 2 Overview of the Examples Elaboration to different resolution levels Executing Traditional Sequences Resource estimation at different resolution levels Adding Behaviors to the System

June 28, 2000 Architecture Review 3 Example 1: Elaboration to different resolution levels

June 28, 2000 Architecture Review 4 N S M N G S M M= Simplified Mission N= Navigate S= Science Measurement G = Waypoint Goto rover locomotor path planner rover locomotor path planner G G CASE 1: Functional Layer provides navigation to Science Target CASE 2: Decision Layer gets waypoints apriori Accessing the Functional Layer at Different Levels of Granularity Elaboration to different resolution levels

June 28, 2000 Architecture Review 5 CASE 1: Functional Layer provides navigation to Science Target CASE 2: Decision Layer gets waypoints apriori x x x x x x Navigation Example: Move to a Science Target

June 28, 2000 Architecture Review 6 Navigation Example, cont. Decision Layer further breaks down activity Functional Layer CASE 1 CASE 2 Position Science Time Navigate (2.53, 10.34)(1.32, 5.79)Transit Time (2.53, 10.34)(1.32, 5.79) Science Goto Time (2.53, 10.34) ScienceGoto Eng Functional Layer (1.32, 5.79) Time Science Time (2.53, 10.34)(1.32, 5.79) Position Transit Science Navigate (1.32, 5.79) Position Time Science

June 28, 2000 Architecture Review 7 Navigation Example, cont. Decision Layer further breaks down activity Functional Layer CASE 1 Time (2.53, 10.34)(1.32, 5.79) Position Transit Science Navigate (1.32, 5.79) Position Time Science No Further Elaboration: Decision Layer passes Navigate activity directly to Functional Layer as a command. Eng activity would have to be scheduled at a later (possible less optimal) time. Less Control in Decision Layer: Elaboration is quick and simple. Resource/State Analysis only done at high-level. More Control in Functional Layer: Navigation activities are strictly handled in Functional Layer. More tight control of critical/risky activities.

June 28, 2000 Architecture Review 8 Navigation Example, cont. Decision Layer further breaks down activity CASE 2 Position Science Time Navigate (2.53, 10.34)(1.32, 5.79)Transit Time (2.53, 10.34)(1.32, 5.79) Science Goto Time (2.53, 10.34) ScienceGoto Eng Functional Layer (1.32, 5.79) Time Science Further Elaboration: Decision Layer interacts with path planner to further break down navigate activity into waypoints Optimality: May notice that another science or engineering operation can be scheduled in between individual gotos. Can globally optimize over all states and resources.

June 28, 2000 Architecture Review 9 Example 2: Executing Traditional Sequences

June 28, 2000 Architecture Review 10 rover camera arm joint heater P Q M M= Simplified Mission P= Planning Activity S= Science Measurement Q= Traditional Sequencer rover camera CASE 1: Sequence is generated on the ground by operators. CASE 2: Sequence generated by on-board planner. Executing Traditional Sequences Do this then that Then do something else Then do the first thing again Then do nothing for a while Now repeat four times Then check power Then move to (x,y) Then phone home If answer then talk Else call someplace else And so on arm joint heater P Q M Ground Sequence

June 28, 2000 Architecture Review 11 Traditional Sequence Example: Take an image of a particular location

June 28, 2000 Architecture Review 12 Traditional Sequence Example: Command Sequence sent to Decision Layer :12:52 (10:16:43) [25064]:[ROVER] Imaging of mini-matterhorn :12:52 (10:16:43) [25065]: Set Error Mask (0) :12:56 (10:16:47) [25066]: [ROVER] Heat modem :12:56 (10:16:47) [25067]: Heat :18:00 (10:21:43) [25068]: Set Parameter: tbuf_mode to :18:04 (10:21:47) [25069]: Image (left,auto,ops,comp:no,r40-r220,c184-c724,s2) :27:02 (10:30:30) [25070]: Image (left,auto,ops,comp:no,r205-r383,c184-c724,s2) :35:55 (10:39:08) [ 0]: Auto Health Check (level 2) :35:55 (10:39:08) [25071]: Image (right,auto,ops,comp:no,r40-r220,c44-c584,s2) :44:53 (10:47:53) [25072]: Image (right,auto,ops,comp:no,r205-r383,c44-c584,s2) :53:46 (10:56:31) [25073]: Set Parameter: tbuf_mode to :53:50 (10:56:35) [25074]: Set Error Mask (255) :53:54 (10:56:39) [25075]: Clear Errors (247) :53:58 (10:56:43) [25076]:[ROVER] End imaging Functional Layer Traditional Sequencer Decision Layer Rover Camera acquire_image(Image) set_parameter(p1)

June 28, 2000 Architecture Review 13 Example 3: Resource estimation at different resolution levels

June 28, 2000 Architecture Review 14 P N M M= Simplified Mission P= Planning Activity N= Navigation GAM rover Resource Estimation to Varying Resolution vision path_plan locomotor rover vision path_plan locomotor rover vision path_plan locomotor CASE 1: Simple estimate using Euclidian distance CASE 3: Very detailed estimate using all of case 2 plus accurate rocker bogie kinematic models CASE 2: More detailed estimate using vision and path planning

June 28, 2000 Architecture Review 15 Resource Estimation to Varying Resolution CASE 1: Simple estimate using Euclidian distance CASE 3: Very detailed estimate using all of case 2 plus accurate rocker bogie kinematic models CASE 2: More detailed estimate using vision and path planning Estimating: -Traversal Time -Power -Risk

June 28, 2000 Architecture Review 16 Resource Estimation to Varying Resolution Rover PathPlanning Rover Vision PathPlanning Vision RockerBogie_Locomotor CASE 1: Simple estimate using Euclidian distance CASE 3: Very detailed estimate using all of case 2 plus accurate rocker bogie kinematic models CASE 2: More detailed estimate using vision and path planning Simple Detailed Complex

June 28, 2000 Architecture Review 17 Example 4: Adding Behaviors to the System

June 28, 2000 Architecture Review 18 M= Simplified Mission P= Planning Activity S= Navigation GAM B= Behavior A= Arbitrator Functional Layer controller is implemented by behaviors and arbitrators. Selection of mix can be default or specified by Decision Layer. Adding Behaviors to the System rover B3 locomotor P N M B2 B1 A2 A1

June 28, 2000 Architecture Review 19 Adding Behaviors to the System

June 28, 2000 Architecture Review 20 Adding Behaviors to the System Wheel Linkage Controlled_Motor PID_Controller Behavior Rover Wheeled_Locomotor Vision_System Visual_Odometer Move_to_target Avoid_obstacles Coordination Limit_Wheel_Velocity Flock * Hierarchical Access Safe Must Resolve Conflicts CoordinatedMotion BehaviorBasedRover

June 28, 2000 Architecture Review 21 Concluding Remarks

June 28, 2000 Architecture Review 22 Summary Described problems currently encountered in Robotic Autonomy system development, including critical mass in software development and insufficient integration of tradition system parts. Introduced CLARAty, an evolutionary improvement in previous system architecture concepts: Comprised of Functional and Decision Layers with an additional dimension of Granularity Merger of Executive and Planning Functions in the Decision Layer. Object Oriented design which adds a fourth dimension of abstraction through class inheritance. Connectivity between Functional and Decision Layers possible at different levels of Granularity. Adopt standards such as UML and C++, and open-source software paradigm. Leverage other efforts such as MDS. Provided a detailed description of the Functional Layer design. Described the concepts, and past and future directions of planning and executive functions in the Decision Layer. Showed examples describing the implementation of some current solution concepts within the new architecture.

June 28, 2000 Architecture Review 23 Next Steps Field questions and take comments now. Extensive feedback, comments should be sent to Prototype implementation of rover navigation under CLARAty this year. Develop plans: Including mature software packages into framework Extend framework when needed to enable widest possible user community and control techniques comparison. Bring other projects and their systems under the architecture. Establishing open-source development community with software review and repository maintenance. Reap the benefits of critical mass, where each participating party receives far more benefit than overhead by subscribing to a common architecture.

June 28, 2000 Architecture Review 24 Thank you for your Attention