1 / 64

James Robert Wilson III The University of Tennessee

Formulation of Sensor Brick Concept as a Modular Robotic System Architecture Thesis Defense September 1, 2005. James Robert Wilson III The University of Tennessee Department of Electrical and Computer Engineering Imaging, Robotics, & Intelligent Systems Laboratory.

kmcconnell
Download Presentation

James Robert Wilson III The University of Tennessee

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Formulation of Sensor Brick Concept as a Modular Robotic System Architecture Thesis Defense September 1, 2005 James Robert Wilson III The University of Tennessee Department of Electrical and Computer Engineering Imaging, Robotics, & Intelligent Systems Laboratory

  2. Presentation Overview 1. Research Contributions 2. Introduction and Pipeline 3. Formulation of the Sensor Brick System 4. Robotic Architectures Overview (Literature Survey) 5. Description of the Sensor Brick System as a System Architecture 6. Introduction to the Real-time Control System (RCS) 7. Implementing RCS in the Sensor Brick System for an Under-Vehicle Inspection Scenario 8. Conclusion

  3. Research Contributions • Definition of the Sensor Brick • Formulation of the Sensor Brick Concept as the System Architecture • Conceptual Application of the Real-time Control System as the Operational Architecture of the SBS

  4. Introduction “Big Safebot” loaded with the (mostly exposed) blocks of the four (4) sensor bricks. Developed in the University of Tennessee Imaging, Robotics, and Intelligent Systems Laboratory

  5. Introduction • Why formulate a mobile robotic system using a modularsystem architecture? • Currently, commercial robotic system development depends on methods that do not use a strictly modular approach. This results in systems designs that are based on specific types of application. • These systems have limited usefulness because of the specialized but limited ranges of application, a lack of inter-operable control capability, and an inability to easily interchange sub-systems due to unique and proprietary design.

  6. Introduction Remotec Andros iRobot Packbot Allen-Vanguard Vanguard MKII TARDEC ODIS Foster-Miller Talon Commercial Mobile Robotic Systems Courtesy of: Remotec, iRobot, Allen-Vanguard, TARDEC, and Foster Miller.

  7. Introduction • The Sensor Brick System: • Based on the Concept of Independent Sensor Brick units • Strictly Modular Design Approach Overcomes the Weaknesses that are Inherent to Commercial Systems • Can Be Adequately Applied to a Wide Scope of Issues • Modular Design Facilitates an Inter-Operable Control Capability • Interchanging Sub-Systems Easily Accomplished

  8. Introduction - Pipeline Mobility Bricks Sensor Bricks

  9. Value Judgment Sense Plan Changes and Events Sensory Perception task goals Simulated Plans World Modeling Behavior Generation perception, focus of attention plans, state of action Knowledge Database Act commanded actions Observed Input Introduction - Pipeline Real-time Control System (RCS) JAUS Compliant Message Format

  10. Vehicle Level Safebot + Laser Range Sensor Brick Subsystem Level Communications Mechanical / Power Computing / IS Primitive Level Driver Servo Level Left Motor Left Motor Sensor / Actuators Introduction - Pipeline The initial application of RCS to the Sensor Brick System No formal system organization Level 0 Intelligent Navigation Systems

  11. Safebot + Laser Range Sensor Brick Communications Mechanical / Power Computing / IS Driver Left Motor Left Motor Sensor / Actuators Introduction - Pipeline Additional applications of RCS to the Sensor Brick System Level 0 Level 2 Safebot + Laser Range + Visual Block Section Level Vehicle Level Safebot + Laser Range + Visual Block ANDROS + Laser Range + Thermal Block Vehicle Level Subsystem Level Subsystem Level Intelligent Systems Intelligent Systems Primitive Level Primitive Level Gaze Driver Gaze Driver Left Motor Right Motor Left Motor Right Motor Servo Level Aperture Motor Aperture Motor Servo Level

  12. Introduction – Mission Statement Purpose of Research: • To Validate the Efficacy of the Modular Sensor Brick Concept as a Intelligent Mobile Robotic System Architecture. • Although other methods of development are prevalent in commercial robotic systems, those methods present issues that are undesirable or problematic.

  13. Formulation of the Sensor Brick System • Sensor Brick Concept • Modular Design Methodology Simplifies and Facilitates Robotic System Development • Identifies Essential Sub-Systems as Modules • Modules are Bundled as Standardized, Commercial Technology • Modules Characterize Notion of Operational Independence • Sensor Brick System is Adaptive to aWide Variety of Applications

  14. Formulation of the Sensor Brick System Sensor Brick System Intelligent Systems Mobility Platforms Sensors Power

  15. Formulation of the Sensor Brick System • Sensor Brick System as the System Architecture 1. “Blueprint” for Robotic Systems Development 2. Wider Range of Applications - Adaptive 3. Facilitates Evolution to Greater Autonomous Operation - works well with the Operational Architecture (Real-time Control System)

  16. Formulation of the Sensor Brick System • Unmanned Systems • Reduce Exposure of Personnel to Harmful Environments • Perform Tasks Not Possible for Humans • Provide Cost Effective Solutions to Repetitive Tasks. • Large Numbers of Unmanned System Products are being introduced to the market. • Many of the Systems can be Characterized as: • Task Dependent – Can Not Be Applied to a Wide Variety of Circumstances • Lack an Interoperable Control Capability • Can Not Interchange Sub-Systems

  17. Formulation of the Sensor Brick System • To Resolve These Issues, Mobile Robotic Systems Must Incorporate: • Standard,Open ArchitecturesDesigned to Support the Rapid and Cost-Effective Development of Unmanned Systems Source: Robotic Architecture Standards Framework in the Defense Domain with Illustrations Using the NIST 4D/RCS Reference Architecture, Hui-Min Huang (1), James Albus (1), Jeffery Kotora (2), and Roger Liu (3). 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

  18. Robotic Architectures Overview • Open Architectures: • Interoperable Control: Inter-System Control is Addressed by Aspects of the Technical Architecture - Joint Architecture for Unmanned Systems (JAUS) • Interchange of Sub-Systems and System Control: Intra-System Control is Addressed by Aspects of the Operational Architecture • The Formulation of a Physically Demonstrable System (System Architecture) Source: Robotic Architecture Standards Framework in the Defense Domain with Illustrations Using the NIST 4D/RCS Reference Architecture, Hui-Min Huang (1), James Albus (1), Jeffery Kotora (2), and Roger Liu (3). 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

  19. Robotic Architectures Overview • What Factors Drive the Holistic Development of the Sensor Brick System? • - The Continuing Development of the System (Operational Architecture) • Interoperable Control Issues (Technical Architecture) • Interchangeability of Sub-System Issues (System Architecture) Source: Robotic Architecture Standards Framework in the Defense Domain with Illustrations Using the NIST 4D/RCS Reference Architecture, Hui-Min Huang (1), James Albus (1), Jeffery Kotora (2), and Roger Liu (3). 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

  20. Robotic Architectures Overview • Three (3) types of architectures for mobile robotic systems are: • Operational Architecture – OA • Technical Architecture – TA • System Architecture - SA Source: Chatfield, Jennifer, et al (1998 January). New Architecture Directions. The Edge (The Mitre Corporation Advanced Technology Newsletter), Vol. 01, No. 03.

  21. Operational Architecture Technical Architecture System Architecture Robotic Architectures Overview Generic Organization of Mobile Robotic Architecture Source: Chatfield, Jennifer, et al (1998 January). New Architecture Directions. The Edge (The Mitre Corporation Advanced Technology Newsletter), Vol. 01, No. 03.

  22. Robotic Architectures Overview • Operational Architecture - (OA) • Tasks • Operational Units • Information Flows Source: Robotic Architecture Standards Framework in the Defense Domain with Illustrations Using the NIST 4D/RCS Reference Architecture, Hui-Min Huang (1), James Albus (1), Jeffery Kotora (2), and Roger Liu (3). 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

  23. Robotic Architectures Overview • Technical Architecture (TA) - Should Contain a Set of Rules Governing the: • Organization • Interaction • Interdependence of the System Components • This is to facilitate interoperability when the system’s or system-of-system’s components conform to the specification • Largely addressed by JAUS, IEEE 802.x, etc. From: Robotic Architecture Standards Framework in the Defense Domain with Illustrations Using the NIST 4D/RCS Reference Architecture, Hui-Min Huang (1), James Albus (1), Jeffery Kotora (2), and Roger Liu (3). 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

  24. Robotic Architectures Overview • System Architecture - (SA) • Systems Architecture Describes Physical SystemComponents and Interconnections that Integrate for Particular Applications • 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 uses a Modular Design Approach From: Robotic Architecture Standards Framework in the Defense Domain with Illustrations Using the NIST 4D/RCS Reference Architecture, Hui-Min Huang (1), James Albus (1), Jeffery Kotora (2), and Roger Liu (3). 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

  25. Robotic Architectures Overview Operational Architecture Technical Architecture RCS JAUS, IEEE 802.x, etc. Sensor Brick System System Architecture

  26. The Sensor Brick System as the System Architecture • Question: • How can Mobile Robotic Systems Be “Improved” vs. Present Commercial Systems? • Answer: • Utilize the Proper System Architecture so the system can evolve in a meaningful, coordinated manner.

  27. The Sensor Brick System as the System Architecture • Commercial Robotic Systems: • Commercial Systems have Many Similar Capabilities with Marginal Variations • - Robust with respect to the Intended Application • Limited Range of Application • Lack of Intelligent Systems • Interoperable Control • Interchange of Sub-Systems

  28. The Sensor Brick System as the System Architecture • System Architecture: • Rectify the Weaknesses of Commercial Systems • Be strongly commensurate with the Operational Architecture

  29. The Sensor Brick System as the System Architecture • The Proper Collaborationbetween a modular System Architectureand an application of Operational Architecture results in: • Robust Operational Capability in a Large Variationof Applications • Optimal Use of Intelligent Systems Resources • A Control Structure that Enables Interoperable Control and the Interchange of Sub-Systems

  30. Introduction to the Real-time Control System (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. Source: Albus, James S., Meystel, Alexander M. (2001). Engineering of mind: an introduction to the science of intelligent systems.

  31. Introduction to RCS • RCS integrates the functional 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. Source: Albus, James S., Meystel, Alexander M. (2001). Engineering of mind: an introduction to the science of intelligent systems.

  32. Plan Plan Act Sense Sense Sense Plan Act Plan Sense Act Introduction to RCS A Hybrid Deliberative-Reactive Architecture Highest Level Lowest Level Source: Albus, James S., Meystel, Alexander M. (2001). Engineering of mind: an introduction to the science of intelligent systems.

  33. Introduction to RCS Objects Most Abstract Surfaces SP BG WM Lines Points Least Abstract Sensors and Actuators Source: Albus, James S., Meystel, Alexander M. (2001). Engineering of mind: an introduction to the science of intelligent systems.

  34. Introduction to RCS Objects Most Abstract Surfaces SP BG WM Lines Points Least Abstract Sensors and Actuators Source: Albus, James S., Meystel, Alexander M. (2001). Engineering of mind: an introduction to the science of intelligent systems.

  35. Value Judgment Sensory Perception Introduction to 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 Source: Albus, James S., Meystel, Alexander M. (2001). Engineering of mind: an introduction to the science of intelligent systems.

  36. Introduction to 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 Source: Albus, James S., Meystel, Alexander M. (2001). Engineering of mind: an introduction to the science of intelligent systems.

  37. Introduction to 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 Source: Albus, James S., Meystel, Alexander M. (2001). Engineering of mind: an introduction to the science of intelligent systems.

  38. Introduction to RCS 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 Source: Albus, James S., Meystel, Alexander M. (2001). Engineering of mind: an introduction to the science of intelligent systems.

  39. Operator Interface Introduction to RCS 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 Source: Albus, James S., Meystel, Alexander M. (2001). Engineering of mind: an introduction to the science of intelligent systems.

  40. Operator Interface Implementing 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 Source: Albus, James S., Meystel, Alexander M. (2001). Engineering of mind: an introduction to the science of intelligent systems.

  41. Implementing 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 Source: Albus, James S., Meystel, Alexander M. (2001). Engineering of mind: an introduction to the science of intelligent systems.

  42. Conclusion - RCS • 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. Source: Albus, James S., Meystel, Alexander M. (2001). Engineering of mind: an introduction to the science of intelligent systems.

  43. Introduction to Joint Architecture for Unmanned Systems • 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 Source: Volume I: JAUS Domain Model (2004).

  44. Introduction to JAUS • JAUSis a common language consisting ofwell-defined messages, enabling internal and external communication between unmanned systems Source: Volume I: JAUS Domain Model (2004).

  45. Introduction to JAUS JAUS System Topology Source: Volume I: JAUS Domain Model (2004).

  46. Introduction to 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, a Component is an Executable Task or Process. Source: Volume I: JAUS Domain Model (2004).

  47. Introduction to 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 that govern configuration Source: Volume I: JAUS Domain Model (2004).

  48. Introduction to 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 Source: Volume I: JAUS Domain Model (2004).

  49. Introduction to 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 Source: SAE ?????????.

  50. Introduction to 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

More Related