World Representation for Vehicle Navigation and Standards for Cooperative Vehicles

1. World Representation for Vehicle Navigation and Standards for Cooperative Vehicles Dr Javier Ibanez-Guzman 31st, January 2007 Orbassano

2. An architecture for Intelligent Vehicle Navigation • The 4-D/RCS architecture • The ability to model the immediate environment is fundamental for an autonomous ground vehicle • This World Model provides a representation of the world that enables machines to gain un understanding of their surroundings, • Designed to facilitate situation understanding for sensor-based goal-directed functions • It is multilayered, multi-resolutional. Each layer contains sensor processing, world modelling, decision making and behaviour generation functions • SafeSpot is also multilayer, multi-resolutional, having a similar architecture with the exception that it is based on distributed sensing (V2V and C2I) The sample architecture originates from the work by James Albus (NIST-USA)

3. 4-D/RCS Architecture John Albus • Diagramme needs to be printed for visualisation purposes. • Layered Structured • Different levels of granularity • Different frame rates • Different Perception horizons

5. What is the World Model? The LDM? YES • “The world model is the intelligent vehicle best estimate of the state of the world. It includes a database of knowledge about the world, plus a database management system that stores and retrieves information. • It should have an application oriented simulation capability that generates expectations and predictions e.g. trajectories. • It provides answers to requests about the present, past, and probable future states of the world. • It provides this information service in order to make intelligent plans and behavioral choices in a cooperative manner. • It provides informationto the sensory processing system element to perform correlation, model matching, and model-based recognition of states, objects, and events. • It provides information to the Safety Margin Module to compute values such as cost, benefit, risk, uncertainty, importance, and safety . • It is kept up to date by the sensory processing system element.” From Meazel, Albus and Alexander.

6. JAUS-Joint Architecture for Unmanned Systems - message definition, US MOD • Primary Purpose to attain • Specifications independent from technology, computer hardware, control means and platform. • JAUS Defines the behaviours and messages of the software components in unmanned vehicles • All the information is available at: http://www.jauswg.org/ • Standard specification of the U.S. Department of Defence for unmanned systems, to become an SAE standard WHY? Messaging system is similar, and subscription/registration scheme

7. JAUS-System Topology System: Expresses the whole; the application/use case Subsystem: Single unit/machine (Vehicle, Infrastructure, etc.) Node: Computer resource Component: Functional unit (Software module) Instance: Execution form of a component (Process）

8. JAUS-Implementation of the Components Safety Margin Safety System Engine Control

9. JAUS-What is it for us? Message Formats • The messages for unmanned systems are already defined. (currently, 110 kinds). Several can be mapped directly to SafeSpot • The system of JAUS is driven by the message communication between components. • Message format = header(16bytes) + option data • The messages are classified into six categories. (Command, Query, Inform, Event Setup, Event Notification, Node Management） • The option data is specific to each kind of message.

10. JAUS-How is this being implemented?

11. JAUS-Components Command and Control Components. • System Commander (ID 40). Communications Components. • Communicator (ID 35). Platform Components. • Global Pose Sensor (ID 38). • Local Pose Sensor (ID 41). • Velocity State Sensor (ID 42). • Primitive Driver (ID 33). • Reflexive Driver (ID 43). • Global Vector Driver (ID 34). • Local Vector Driver (ID 44). • ….. Many can be converted into current Safespot messages

12. JAUS defines six classes of messages at the component level. JAUS-Message Classes

13. JAUS-Message Classes Command class messages are used to effect system mode changes, actuation control, alter the state of a component or subsystem or to otherwise initiate some type of action. Query class messages are used to solicit information from another component. An inform class message is generated in response to a query class message. Inform class messages allow components to transmit information to each other. Event setup class messages are used to setup the parameters for an Event Notification message and to have a component start monitoring for the trigger event. An Event Notification Message is generated whenever parameters are set within the Event Setup message. Event notification class messages communicate the occurrence of an event. Node Management class messages are only used by the Node Management task. These messages are used for node specific communications including the conveyance of configuration information and component registration.

14. JAUS-Message Composition

15. JAUS- Information • Some Links • Links with the Society of Automotive Engineers (USA), http://www.iaqg.sae.org/servlets/aerostd/documentHome.do?comtID=TEAAS4&docID=AIR5664&inputPage=dOcDeTaIlS • JAUS compliant support tools http://www.appliedperception.com/products/products.asp http://www.resquared.com/ http://www.autonomoussolutions.com/products/products-main/jausnow-trade-library-home.html http://www.coroware.com/default.aspx