DOC PREVIEW
Saphira Robot Control Architecture

This preview shows page 1-2-3 out of 8 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Saphira Robot Control Architecture Saphira Version 8.1.0 Kurt Konolige SRI International April, 2002 Copyright 2002 Kurt Konolige SRI International, Menlo Park, California1 Saphira and Aria System Overview Saphira is an architecture for mobile robot control. Originally, it was developed for the research robot Flakey1 at SRI International, and after being in use for over 10 years has evolved into an architecture that supports a wide variety of research and application programming for mobile robotics. Saphira and Flakey appeared in the October 1994 show Scientific American Frontiers with Alan Alda. Saphira and the Pioneer robots placed first in the AAAI robot competition “Call a Meeting” in August 1996, which also appeared in an April 1997 segment of the same program.2 With Saphira 8.x, the Saphira system has been split into two parts. Lower-level routines have been re-organized and re-implemented as a separate software system, Aria. Aria is developed and maintained by ActivMedia Robotics. It is a production-level system for robot control, based on an extensive set of C++ classes. The class structure of Aria makes it easy to expand and develop new programs: for example, to add new sensor drivers to the system. The Saphira/Aria system can be thought of as two architectures, with one built on top of the other. The system architecture, implemented entirely in Aria, is an integrated set of routines for communicating with and controlling a robot from a host computer. The system architecture is designed to make it easy to define robot applications by linking in client programs. Because of this, the system architecture is an open architecture. Users who wish to write their own robot control systems, but don’t want to worry about the intricacies of hardware control and communication, can take advantage of the micro-tasking and state reflection properties of the system architecture to bootstrap their applications. For example, a user interested in developing a novel neural network control system might work at this level. On top of the system routines is a robot control architecture, that is, a design for controlling mobile robots that addresses many of the problems involved in navigation, from low-level control of motors and sensors to high-level issues such as planning and object recognition. Saphira and Aria share the control architecture duties, with Aria providing the basic elements of action and sensor interpretation. Saphira’s contribution to the control architecture contains a rich set of representations and routines for processing sensory input, building world models, and controlling the actions of the robot. As with the system architecture, the routines in the control architecture are tightly integrated to present a coherent framework for robot control. The control architecture is flexible enough that users may pick among various methods for achieving an objective, for example, choosing between a behavioral control regime or a more direct control of the motors. It is also an open architecture, as users may substitute their own methods for many of the predefined routines, or add new functions and share their innovations with other research groups. In this section, we’ll give a brief overview of the two architectures and discuss the main concepts of Saphira and Aria. More in-depth information can be found in the documentation at the SRI Saphira web site (http://www.ai.sri.com/~konolige/saphira ) and ActivMedia Robotics’ (http://www.activrobots.com/SOFTWARE) website. 1.1 System Architecture Think of the system architecture as the basic operating system for robot control. Figure 1-1 shows the structure for a typical robot application. Saphira/Aria routines are in blue, user routines in red Saphira/Aria routines are all micro-tasks that are invoked during every synchronous cycle (100 ms) by Aria’s built-in micro-tasking OS. These routines handle packet communication with the robot, build up an internal picture of the robot’s state (Aria), and perform more complex tasks, such as navigation and sensor interpretation (Saphira). 1 See http://www.ai.sri.com/people/flakey for a description of Flakey and further references. 2 A write-up of this event is in AI Magazine, Spring 1997 (for a summary see http://www.ai.sri.com/~konolige/saphira/aaai.html ).12. API Reference 1.1.1 Micro-Tasking OS The Saphira/Aria architecture is built on top of a synchronous, interrupt-driven OS. Micro-tasks are finite-state machines (FSMs) that are registered with the OS. Each 100 ms, the OS cycles through all registered FSMs, and performs one step in each of them. Because these steps are performed at fixed time intervals, all the FSMs operate synchronously, that is, they can depend on the state of the whole system being updated and stable before they are called. It’s not necessary to worry about state values changing while the FSM is executing. FSMs also can take advantage of the fixed cycle time to provide precise timing delays, which are often useful in robot control. Because of the 100 ms cycle, the architecture supports reactive control of the robot in response to rapidly changing environmental conditions. The micro-tasking OS involves some limitations: each micro-task must accomplish its job within a small amount of time and relinquish control to the micro-task OS. But with the computational capability of today’s computers, where a 500 MHz Pentium processor is an average microprocessor, even complicated processing such as the probability calculations for sonar processing can be done in milliseconds. The use of a micro-tasking OS also helps to distribute the problem of controlling the robot over many small, incremental routines. It is often easier to design and debug a complex robot control system by implementing small tasks, debugging them, and them combining them to achieve greater competence. Synchronous micro-tasking OS Packet communications State reflector Control and application routines User micro-tasks and activities User async routines TTY or TCP/IP connection Saphira/Aria Client Processes Figure 1-1 Saphira/Aria System Architecture. Blue areas represent routines in the Saphira/Aria libraries, red routines are from the user. All the routines on the left are executed synchronously every 100 ms. Additional user routines may also execute asynchronously as separate threads and share the same address space.1.1.2 User Routines User routines are of two


Saphira Robot Control Architecture

Download Saphira Robot Control Architecture
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Saphira Robot Control Architecture and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Saphira Robot Control Architecture 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?