Contents

Overview

Garcia is a core robot platform for use in a hybrid reactive and deliberative control model applications.  Acroname provides a high level C++ application programmer interface (API) to work with Garcia.  Low level tasks are handled by the API allowing a user to focus on mission planning and task delegation.  The API allows the creation of one main C++ class (acpGarcia) that handles robot communication, provides a primitive scheduling queue and robot property manipulation. 

The acpGarcia object is a wrapper around the acpStem C++ class.  Many API commands are wrappers around commands that get sent and received from the BrainStem network inside Garcia.  The source code for the acpGarcia is provided in the Garcia download. 

Garcia API structure.

The Link

The link is an abstract connection between the software support libraries and the physical BrainStem modules inside the Garcia.  At one link connection end is the BrainStem GP's serial port.  This will not change regardless of the Garcia configuration that is being used.  The other link connection end is more flexible. 

One configuration is to have the host run the API using a "serial" linktype.  This is where a host computer executing API code is talking directly to the BrainStem serial ports.  An example is when the GarciaTool application and a serial interface connector to connect to the BrainStems GP serial port.  Another example would be cross compiling acpGarcia C++ code to execute on an embedded host processor like the Gumstix Verdex Pro.  This will require building a toolchain for the embedded processor.  Both examples have API code communicating directly to BrainStems. 

Another configuration is to have the aRelay on a network bridge the BrainStem GP serial port to an TCP/IP port.  This configuration facilitates the Garcia API to use an "ip" linktype that allows API code to be developed on a remote machine, such as a laptop or desktop PC, and control the Garcia remotely. 

The Garcia API provides an internal link management thread for heartbeats and communication with the BrainStem controllers.  The link thread handles the appropriate system calls for the desired linktype. 

Monitor

The monitor watches Garcia using TEA and reflexes.  While API code focuses on navigation and mapping tasks at the host level, there is a collection of tasks running in the background on your Garcia.  These tasks are collectively called the monitor. 

The monitor checks for the following conditions:

• Obstacles in view of front rangefinders
• Obstacles in view of rear rangefinders
• Loss of detection from downward proximity sensors
• Stall on one or both motors
• Reception of an IR command

Any one of these may make the robot halt, but the monitor may be reconfigured to check conditions specific to a particular motion.  This usually depends on geometry.  For example, if the robot is going forward then obstacles behind the robot don't matter.  Power is turned off to the rear rangers in this case to save battery usage. 

The monitor also performs some important IO tasks.  It provides a host interface for reading the state of an input button and turning range finders on and off.  The monitor also initializes all the IO and system constants at power-up. 

Primitives

Robotic systems gain usability and robustness from layered control designs.  Wheeled mobile robots typically perform a core set of actions, such as moving a prescribed distance or arc, independent of the application environment. 

The Garcia API provides primitives to coalesce common robot actions that can be stacked up in a sequential queue for execution.  Primitives are structured API objects with callbacks providing execution, running, positioning and finish information.  At a primitive's core is a TEA application stored onboard the Garcia's BrainStem controllers that gets executed once the primitive is run.  These TEA programs are optimized and designed to perform tight sensing and actuation control loops asynchronously from the host that is using the acpGarcia object. 

Queue

The acpGarcia API Queue is an unique process that handles the sequencing and execution of primitives.  The queue communicates with the link thread to handle appropriate primitive callbacks to execute.