RSS I Handout 5-B

Guide to the Use of the Carmen Mobile
Robot Control Package Within RSS

Overview:

Carmen is an extensible, modular open-source package for mobile robot control. The name "Carmen" is an acronym for "Carnegie-Mellon Robot Navigation Toolkit." Initially designed to "provide basic navigation primitives including: base and sensor control, obstacle avoidance, localization, path planning, people-tracking, and mapping" [1], Carmen has since been adopted and extended by many robotics educators and researchers to support a wide variety of mobile robotics platforms and applications.

The design principles underlying Carmen include easy extensibility, robustness, and a desire to abstract away low-level robot management issues to enable robot developers to focus on higher-level algorithmic issues (for example, mapping, planning, etc.).

Process Isolation and Data Sharing:

Carmen is a collection of software modules, each of which runs as a separate process in its own address space (i.e., there is no shared memory or multi-threading explicit in the use of Carmen). All Carmen processes communicate through IPC (InterProcess Communication), a package providing networked message passing with per-message procedure callbacks called "handlers."

In order to share data, a given pair of modules must participate in Carmen's "anonymous publish-subscribe" mechanism, through which any module may publish data of interest, and all modules receive notifications in the form of messages (through invocations of callback functions provided by the receiver module) of changes in the values of any published data to which they have subscribed. Carmen uses IPC for all message passing. This enables any Carmen process to run on any machine (subject to the availability of hardware resources), and communicate transparently with any other Carmen process (provided that sufficient network connectivity exists). Of course, efficiency and communication latency considerations often dictate that particular Carmen processes run on particular hosts. In RSS, for example, OrcDaemon can run only on a processor whose serial interface is physically connected to the OrcBoard, and the RobotGUI will normally run on the remote Sun workstation.

Here is a block diagram of the Carmen modules used within RSS:

The diagram is also available as PDF.

The rendezvous mechanism, through which modules decide to subscribe to published data of interest, is provided by the Carmen developer, i.e., the human programmer. There is no Carmen mechanism through which a module can discover the set of all data types available for subscription.

Carmen Data Types:

All data types in Carmen are classes. Most class data types have corresponding message types; a message of any type can be parsed simply by inspecting each of the message's fields.

MessageDaemon Process (executable file: message_daemon):

The MessageDaemon process provides the fundamental message-passing mechanism to all Carmen modules, and normally ensures that subscribers receive published data in a timely fashion. The MessageDaemon must be started before any other Carmen process. There are abnormal operating conditions (e.g., flooded or disconnected network) under which MessageDaemon fails, but these should not be an issue within RSS.

ParamDaemon Process (executable file: param_daemon):

The ParamDaemon process is responsible for reading a plaintext file carmen.ini of robot operating parameters at startup, and publishing those parameters to any subscribers. This file is in rss_release/bin. It is further documented at http://www-2.cs.cmu.edu/~carmen/config_param.html#ini. ParamDaemon must be started after MessageDaemon, but before any other Carmen process, for a given robot operating session. Under some conditions ParamDaemon can re-read the configuration file during robot operation and re-publish any modified parameter values.

OrcDaemon Process (executable file: orc_daemon):

The OrcDaemon process is Carmen's version of the orcd process from RSS's first four labs. The OrcDaemon manages the robot's motor drivers and odometry sensors, and any other hardware (light sensors, bump sensors, sonar) whose physical interface is provided by the OrcBoard. To handle motor command messages, OrcDaemon converts the contents of any received messages into appropriate commands (in this case, dispatched over a serial line) for the OrcBoard. OrcDaemon translates sensor data in RS 232 format coming from the OrcBoard for transfer to RobotCentral. OrcDaemon enforces rate control on such commands, limiting the frequency with which it reads command messages to a fixed value (typically 100Hz).

QuickcamDaemon Process (executable file: quickcam_daemon):

Because the robot camera produces relatively high-bandwidth output, and does so through a USB connection to the laptop rather than the OrcBoard, we employ an additional Carmen process CameraDaemon to repeatedly capture and publish camera images. CameraDaemon also manages the camera's configuration parameters at startup and (infrequently) during robot operation.

RobotCentral Process (executable file: robot_central):

Carmen's RobotCentral process integrates other modules' published outputs (which always include a local timestamp) by odometry-stamping, then re-publishing, those data values (e.g., odometry, images). All time-stamps are local, that is, they reference the clock of whatever host CPU was the source of the stamped data. Thus, the typical start-up procedure for any other Carmen module is to connect to RobotCentral, and announce those message types to which the module wishes to subscribe.

RobotCentral also provides local response (or "reflex") behaviors for current or imminent collisions, e.g., based upon bump sensor reports or fast-closing sonar returns. This local response suppresses application level control requests. Finally, RobotCentral also provides a "timeout" mechanism for autonomous operation: if it has not heard any published messages within 10 seconds, it halts the robot's motion.

VisualServo Process (executable file: VisualServo):

The VisualServo process (written in Java) subscribes to stamped images from RobotCentral, and publishes rotational and translational velocities that servo the robot to center and appropriately size the visual target in the robot's field of view. VisualServo can be run on the Sun (for prototyping and debugging) or on the laptop (for lower-latency operation). For Lab 5, we provide you with a version of VisualServo that is missing target detection, image modification, and velocity publishing functions.

RobotGUI Process (executable file: RobotGUI):

The RobotGUI process (written in Java) provides remote visualization and modification capability for your robot state. RobotGUI could in principle be run on the laptop, but for efficiency reasons (i.e., to avoid the cost of forwarding X windowing directives) you will likely wish to run it on the Sun. For Lab 5, we provide a working (though basic) RobotGUI executable, which you should not need to modify.

Additional Information:

References:

1. "CARMEN Carnegie-Mellon Robot Navigation Toolkit," Jared Glover, Dirk Haehnel, Michael Montemerlo, Nicholas Roy, Cyrill Stachniss and Sebastian Thrun http://carmen.sourceforge.net.

Author: Seth Teller, February 2005.