Exploring Tekkotsu Programming on Mobile Robots:

Introduction

Prev: ----
Up: Contents
Next: On-line Documentation

Tekkotsu (see www.Tekkotsu.org) is an application development framework for mobile robots. It was originally developed for the Sony AIBO robot dog, but now supports many other platforms. ("Tekkotsu" literally means iron bones in Japanese, and refers to a metal framework, such as the skeleton of a building.) At its lowest level, Tekkotsu provides primitives for sensory processing, smooth control of effectors, and event-based communication. Higher level facilities include a hierarchical state machine formalism for managing control flow in the application, a vision system, and an automatically maintained world map. Tekkotsu also provides housekeeping and utility functions useful to application developers, such as timers and profilers, and a set of remote monitoring tools to permit real-time monitoring of what's going on inside the robot.

Tekkotsu is object-oriented, making extensive use of C++ templates, multiple inheritance, and polymorphism (operator overloading). This makes it easy for application developers to create their own customized facilities without having to change the Tekkotsu source code. They simply define subclasses that inherit from the Tekkotsu base classes, and override any member functions requiring customization.

A Tekkotsu application is organized as a collection of Behavior and MotionCommand classes. Their member functions run in two cooperating processes, "Main" and "Motion". Separate processes are used because they require different execution styles. Main handles perception and decision making; these are deliberative processes where each operation can potentially take a substantial amount of time. Motion is concerned with realtime control of effectors: all operations must be guaranteed to complete quickly, because several may have to be performed within the current 32 msec timeslice. (If a Motion process doesn't run quickly enough, the robot might fall over, or its actions might appear jerky.) A third process, SoundPlay, handles audio output, and operates under the same realtime constraints as Motion. The processes are labeled MainObj, MotoObj, and SoundPlay in the diagram below:


Behaviors are instantiated in and run exclusively in the Main process' address space (green hatching in the diagram above). MotionCommands are instantiated in shared memory (solid blue in the diagram). Most of their computation is done in the Motion process (orange hatching), but certain member functions run in Main. A clever mutual exclusion mechanism called an MMAccessor provides Behaviors running in Main with a safe way to update shared memory structures while they are in use by the MotionManager running in Motion.

Prev: ----
Up: Contents
Next: On-line Documentation

Last modified: Wed Jan 14 00:00:40 EST 2009