Overview

This interface follows the client/server approach, and is consists of two main parts.

On the client side, there is an external predicate module that can be loaded as a library by the Eclipse Prolog interpreter running on a Unix-based computer. This module, shown as the AiboPred module in the diagram below, provides the Golog interpreter with a predefined set of actions that can be performed to interact with the robot.

On the server side, there is a Tekkotsu program (or a Behavior in Tekkotsu's terminology) that runs on the AIBO and continuously listen for commands from the client over the wireless network.

Software Architecture of the interface

 

Software Design Notes

 

The client

The client is implemented in the file aibopred.c. Its operations can be summarized by noting that each robot action is represented by a corresponding action predicate, and each action predicate is implemented by a corresponding C function in the AiboPred module. To execute a robot action, the Golog interpreter asks Eclipse Prolog to evaluate its corresponding action predicate. To evaluate an action predicate, Eclipse Prolog executes a corresponding C function in the AiboPred module.

When an AiboPred function is called, it parses all the actionís arguments and assembles them in to an appropriate data structure, which we will refer to as a TCP Command, and send it over the wireless network to the GTI server to be carried out. Then, upon receiving a reply from the server, the client will return to Eclipse with any applicable results.

For more information about external predicates in Eclipse Prolog, please refer to Eclipseís Interfacing and Embedding Manual.

 

Client-Server Communication

All data structures that are used in client-server communications are defined in the file TCPComm.h.

As mentioned above, when an AiboPred function is called, it sends a TCP command to the server to be carried out. This command is consists of two parts: a header, which is defined using the same data structure for all commands, and a body, which is defined by different data structures for different command types.

Command headers are defined by the following data structure:

struct CmdHdr{

     int type;

     int len;

};

where type is an enumerated value representing the different robot actions, and len is the length (in bytes) of the command body, which is different for different command types as well as different command arguments.

When it sends a TCP command to the server, the client does it in two separate stages. First, it sends the command header, which tells the server the type and the amount of data it should expect to receive. Then, it sends the command body, which contains all necessary information about the command.

The following table shows the names of the data structures that are used to represent the command body and the serverís reply for the different robot actions.

 

Action

Data Structure representing

Command Body

Serverís Reply

querySensors()

struct SensorCmd

double array

queryBall()

int (enumerated ball colors)

struct Ball

searchBall()

int (enumerated ball colors)

int

moveJoints()

struct JointCmd

N/A

motion()

string (name of motion sequence descriptor file)

N/A

walk()

struct WalkParam

N/A

turn()

struct WalkParam

N/A

 

The server

This section describes the GTI serverís design and operations. Readers who are new to Tekkotsu should refer to the Tekkotsuís Beginnerís Tutorial (TBT), which describes the basics components of a Tekkotsu behavior as well as all the main concepts used in Tekkotsu. To point the reader to the background needed to understand the operation of the Gti sever, relevant sections in the tutorial will be cited throughout this discussion.

The Gti server is consists of three different components: A Tekkotsu behavior called the Gti Behavior, which handles all network communications with the clients, and two motion commands called the GtiMC and GtiHeadMC, which interacts with Tekkotsu on behalf the the GtiBehavior to controls the robot joints. (Please refer to the TBT for information about the role and design of Tekkotsu behaviors and motion commands.) The following diagram shows how the three components of the Gti server, along with other library provided motion commands, fit together:

 

The Motion Commands

The WalkMC and MotSeqMC are library motion commands that can be used by Tekkotsu behaviors to make the robot walk and perform motion sequence. (Please refer to the sections about Walking and Motion Sequences for information about how these MCs can be used).

GtiMC is a custom motion command that interacts with Tekkotsu on behalf of the Gti Behavior to move the robot joints. Whenever the Gti Behavior needs to move a set of joints to satisfy a clientís request, it passes appropriate parameters to the GtiMC, which in turn converts the parameters into appropriate units, and then follows the necessary procedures to fill out the joint control frame buffers to make the joints move. Please refer to the section about Motion Command in the TBT for information about the procedure of filling in the joint control frame buffers.

GtiHeadMC is similar to GtiMC, but it only deals with the three head joints instead of all the joints available on the robot. This MC is called by the Gti Behavior whenever it need to scan the robot head around to satisfy a searchBall() request. The reason of having a separate MC for the three head joints is that scanning the head around requires back-and-forth motions, as opposed to unidirectional motions in the case of regular moveJoints() requests, and hence a different arithmetic algorithm for filling in joint control frame buffers.

GtiMC and GtiHeadMC are implemented in GtiMC.h and GtiHeadMc.h. Their operation and design are completely straight-forward and is standard to all motion commands.

The Gti Behavior

The Gti Behavior is a standard Tekkotsu behavior and contains all the methods (functions) that can be expected to be found in standard Tekkotsu behaviors such as DoStart(), DoStop(), ProcessEvent(), etc. The operation of the Gti Behavior can be described by its methods (i.e., functions):

The initial starting state is the ReceivingCmdHdr state, in which the server waits for a TCP command header from the client. Depending on the type of the header it received, the method switches to one of the command body receiving states, in which it waits for the command body of a certain type to arrive from the client. Upon receiving the command body, the server appropriately carries out the command, replies to the client if necessary, and then switches back to the RecieingCmdHdr state.

Each type of command is carried out differently. For example, querySensors() commands are carried out by simply returning the latest set of sensor values, which are made globally available in the form of an array by Tekkotsu (see the section about WorldState in the Tekkotsuís Beginnerís Tutorial); moveJoints() commands are carried out by passing the joint commandsí arguments to the GtiMC Motion Command; queryBall() commands are carried out by simply returning the latest info about the ball, which arrives via processEvent(), described below; walk() commands are carried out by passing appropriate parameters to Tekkotsuís WalkMC motion command module (see the section about WalkMC in TBT); motion() commands are carried out by passing the motion sequence descriptor filename to the Tekkotsuís MotSeqMC Motion Command module (See the section about MotionSequence in TBT).

The Gti Behavior is implemented in the file GtiBehavior.h and GtiBehavior.cc