Tom Wilson University of Tennessee Department of Electrical and Computer Engineering

1. An overview of:Mobile Robotic Architectures(including an introduction to JAUS)IRIS Laboratory Presentation June 21, 2005 Tom Wilson University of Tennessee Department of Electrical and Computer Engineering Imaging, Robotics, & Intelligent Systems Laboratory

2. Overview Remotec Andros iRobot Packbot Allen-Vanguard Vanguard MKII Mesa Robotics Matilda Foster-Miller Talon

3. Overview • Unmanned systems reduce exposure of personnel to harmful environments, perform tasks not possible for humans, and provide cost effective solutions to repetitive tasks. • As a result, a large number of unmanned system products are being introduced to the market. • Many of these systems are characterized as task dependentand non-interoperable.

4. Overview • Issue: The selected robotic systems are all specially built – none of them can be interchanged! • E.g., we can’t take a Foster-Miller manipulator and put it on a Remotec Andros…

5. Overview To resolve these issues: • A standard open architectureis needed that isdesigned to support the rapid and cost-effective development of unmanned systems.

6. Overview • What does an “open architecture” provide? Interoperable Control: The selected robotic systems must have a standard by which they can be (interchangeably) controlled! • Solution: Implement 4D/RCS and JAUS into the “system architecture.” • Note: 4D/RCS and JAUS will be implemented in the Modular Robotic System designed in the IRIS Lab.

7. Presentation Overview • Background - Review of Fundamental Mobile Robotic Operational Architecture. • How does JAUS fit in the overall schema of robotic architectures? • Definition of the scope of theJoint Architecture for Unmanned Systems(JAUS).

8. Architectures - Background Types of Architecture and their integration The three (3) types of architectures for mobile robotic systems are: • Operational Architectures - OA • Technical Architectures – TA • Systems Architectures - SA

9. Architectural Overview Types of Architecture and their integration Operational Architectures Technical Architectures System Architectures

10. Architectural Overview Operational Architectures - (OA) • Tasks • Operational Units, and • Information Flows required to accomplish a mission.

11. Architectural Overview Operational Architectures => Hierarchies, e.g., military, business organizational structure… • Tasks - search the vehicle undersides for threat objects • Operational Units –EOD squad, Military Police platoon, Command and Control (HQ) unit … • Information Flows – SOP information networks, event-driven protocols … (a distributed hierarchy)

12. Architectural Overview Technical Architectures (TA) should contain a set of rules governing the: • Organization, • Interaction, and • Interdependence of the system components. This is to facilitate interoperability when the system’s or system-of-system’s components conform to the specification. TA specifies conceptual paradigms of the processing, database, and communication. TA also specifies standards and data dictionary.

13. Architectural Overview Systems Architectures - (SA) • Systems Architectures describe physical system components and interconnections that integrate for particular missions. • The systems architecture is constructed to satisfy operational architecture requirements per standards defined in the technical architecture. • The system architecture developed in the IRIS Laboratory is a modular systems approach – Thus the name Modular Robotic System

14. Architectural Overview Generic Organization of Mobile Robotic Architecture Operational Architectures Technical Architectures System Architectures

15. Architectural Overview Operational Architecture Technical Architecture 4D/RCS JAUS Modular Robotic System Systems Architecture

16. 4D/RCS Real-time Control System (RCS) => A methodology for conceptualizing, designing, engineering, integrating, and testing intelligent systems software for vehicle systems with any degree of autonomy.

17. Value Judgment Sensory Perception 4D/RCS Sense Plan Changes and Events Simulated Plans Task Goals perception, focus of attention World Modeling Behavior Generation plans, state of action Knowledge Database Act Commanded Actions Observed Input A schematic representation of the RCS Reference Architecture

18. 4D/RCS Sensory Output Commanded Task (Goal) Status RCS Node VJ Value Judgment Operator Interface Perceived Object & Events Peer Input Output Plan Evaluation SP WM BG Update Plan Sensory Processing World Modeling Behavior Generation Predicted Input State Knowledge Database KD Status Commanded Actions (Sub-goals) Sensory Input Observed Input

19. 4D/RCS Sensory Output Status to Superior Command from Superior Outputs to Peers Operator Input RCS Node Inputs from Peers Status to Operator Sensory Inputs Status from Subordinates Commands to Subordinates

20. 4D/RCS RCS integrates the function elements, knowledge representations, and flow of information so that intelligent systems can analyze the past, perceive the present and plan for the future. It enables systems to assess the cost, risk, and benefit of past events and future plans, and make intelligent choices among alternative courses of action.

21. Operator Interface 4D/RCS – mass customization Orders SP BG SHOP WM Plans for the next day Batches SP BG CELL WM Plans for the next hour Trays of parts and tools Plans for the next 5 minutes – tasks to be done on tray of parts SP BG WORKSTATION WM Plans for the next 30 seconds – task to be done on one object Objects MACHINE SP BG WM E-MOVE PRIMITIVE SERVO Sensors and Actuators

22. 4D/RCS – mass customization Plans for the next 30 seconds – task to be done on one object Objects MACHINE SP WM BG Surfaces E-MOVE 3 second plans – Subtask on object part Obstacle-free paths Inspection Communication Part Handling Tool Motion BG BG SP BG SP SP SP BG WM WM WM WM Lines PRIMITIVE 0.3 second plans – Tool Trajectory SP SP SP BG BG BG SP BG WM WM WM WM SERVO Points 0.03 second plans – Actuator Output Sensors and Actuators

23. Operator Interface 4D/RCS – DARPA XUV III Battalion Formation SP BG Surrogate Battalion WM Plans for the next 24 hours Platoon Formation SP BG Surrogate Platoon WM Plans for the next 2 hours Section Formation Plans for the next 10 minutes – tasks to be done on tray of parts SP BG Surrogate Section WM Plans for the next 30 seconds – task to be done on one object Objects of Attention Vehicle SP BG WM Subsystem Primitive Servo Sensors and Actuators

24. 4D/RCS – DARPA XUV III Plans for the next 30 seconds – task to be done on objects of attention Objects MACHINE SP WM BG Surfaces E-MOVE 5 second plans – Subtask on object surface Obstacle-free paths RSTA Communication Mission Package Locomotion BG BG SP BG SP SP SP BG WM WM WM WM Lines PRIMITIVE 0.5 second plans – Steering, Velocity SP SP SP BG BG BG SP BG WM WM WM WM SERVO Points 0.05 second plans – Actuator Output Sensors and Actuators

25. 4D/RCS In conclusion: RCS defines interfaces to the conceptual and semantic level. But, not to the syntactic, message, and transport levels (JAUS). RCS is a highly detailed hybrid-hierarchical architecture that does not specify how messages are passed or which communication protocols must be used.

26. JAUS JAUS – Joint Architecture for Unmanned Systems JAUS is a technical architecture that is concerned with the data structure of unmanned systems which are comprised of software elements, the externally visible properties of those elements, and the relationships among them.

27. JAUS JAUS is a common language consisting of well-defined messages, enabling internal and external communication between unmanned systems.

28. JAUS JAUS System Topology

29. JAUS A component is the lowest level of decomposition in the JAUS hierarchy. A component is a cohesive software unit that provides a well-defined service or set of services. Generally speaking, a component is an executable task or process.

30. JAUS One of the principal goals of JAUS is to provide a level of interoperability between intelligent systems that has been missing in the past. Towards this end, JAUS defines functional components with supporting messages, but does not impose regulations on the systems engineer that govern configuration.

31. JAUS To achieve the desired level of interoperability between intelligent computing entities, all messages that pass between JAUS defined components (over networks or via airwaves), shall be JAUS compatible

32. JAUS GOA Stack Application SW Application SW Class 4L Class 4L Class 4D -> System Services Operating System Services XOS Services Other Nodes or Operational Subsystems Class 3L Class 3X Class 3D -> Resource Access Services Resource Access Services Class 2L Class 2L Class 2D -> Physical Resources Physical Resources Class 1L Class 1L Class 1D -> External Environment Interface

33. JAUS GOA Stack JAUS defines messages and data formats for application layer components, as well as XOS services for message handling Application SW Application SW Class 4L Class 4L Class 4D -> System Services Operating System Services XOS Services Other Nodes or Operational Subsystems Class 3L Class 3X Class 3D -> Resource Access Services Resource Access Services Where other organizations define standards, JAUS does not interfere (e.g., JTA, IEEE, SAE, etc.) Class 2L Class 2L Class 2D -> Physical Resources Physical Resources Class 1L Class 1L Class 1D -> External Environment Interface

34. JAUS Subsystem Remote Controller Mobility Platform Sensor Brick Node JAUS Compliant Message Format Wireless System Wireless System Component

35. JAUS Subsystem Remote Controller Mobility Platform Sensor Brick Node ? Wireless System Wireless System Component

36. JAUS Subsystem Remote Controller Mobility Platform Sensor Brick Node Wireless System Wireless System Component JAUS Compliant Message Format Concept of Inter-Operability Alternative Controller

37. JAUS In conclusion: • Support all Classes of Unmanned Systems - JAUS should ensure platform independence • Rapid Technology Insertion - JAUS should not impose a specific technical approach • Interoperable Operator Control Units (OCU) - JAUS should allow for the interoperability of operator control units • Interchangeable/Interoperable Payloads - JAUS should allow technical advancements while not imposing specific hardware or software implementations • Interoperable Unmanned Systems - JAUS should allow for communication between unmanned systems independent of platform type

38. Value Judgment Sensory Perception Research Focus Sense Plan Sensors Changes and Events task goals Simulated Plans + Intelligent Systems World Modeling Behavior Generation MRS Thesis Chapter 8 perception, focus of attention plans, state of action = Knowledge Database Act Mobility Platforms commanded actions Observed Input Real-time Control System (RCS-4) Modular Robotic System + JAUS

39. Conclusion • Modular Robotic System is JAUS compatible. • Compliant with 4D/RCS – expanding the system to include multiple mobility platforms. • Conforms to the key concept of (being capable of) interoperability!

40. Questions?

41. References 1.Robotic Architecture Standards Framework in the Defense Domain with Illustrations Using the NIST 4D/RCS Reference Architecture, Hui-Min Huang1, James Albus1, Jeffery Kotora2, and Roger Liu3. 1 – National Institute of Standards and Technology 2 – Chair, JAUS Working Group, Titan Systems, Huntsville, Alabama 3 – Army Systems Engineering office (ASEO), Fort Monmouth, New Jersey 2.Joint Robotics Program Master Plan FY 2004, published by Office of the Undersecretary of Defense (Acquisition, Technology & Logistics) Defense Systems/Land Warfare and Munitions4. 4 – 3090 Pentagon, Washington, DC 20301-3090 3. Engineering of Mind: An Introduction to the Science of Intelligent Systems, James S. Albus5 and Alexander M. Meystel6 (2001). 5 – Senior NIST Fellow, Intelligent Systems Division, Manufacturing Engineering Laboratory, National Institute of Standards and Technology 6 – Professor of Electrical and Computer Engineering, Drexel University, Guest Researcher NIST

42. References 4.Volume I: JAUS Domain Model (DM) 5.Volume II: JAUS Reference Architecture (RA)