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
Action	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):

DoStart() This method is called when the behavior is first loaded by Tekkotsu. It first initializes some data structures, and then registers with Tekkotsu that it wants to listen to a TCP/IP port (port 12345, defined in TCPComm.h), and that it wants to receive event notification messages regarding ball detections and regarding the GtiHeadMC, which generates an event every time it finishes scanning the head.

DoStop() This method is called to do the necessary clean-ups whenever the behavior is about to be unloaded by Tekkotsu.
ProcessNetwork() This method is called by Tekkotsu every time network data arrives at the TCP/IP port. Its operations can be described using the following finite state machine:

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).

processEvent() This method is called by Tekkotsu every time an event of the types a behavior has registered to receive occurs (See the section about Events in TBT for information regarding events generation and processing in Tekkotsu). In the case of the Gti Server, since we have registered, in DoStart() method, to receive all events generated by the system’s ball detection engine and by the GtiHeadMC, this method is called every time a ball of some predefined color (pink, orange, yellow, green) is detected within the robot’s camera image, or every time the GtiMC generates an event signaling it has completed the scanning of the head. In the case of a ball detection event, the method save all the relevant data about the ball (i.e., whether it is still visible or has been lost, its center’s coordinates, its area) into a global data structure so that subsequence queryBall() requests can be quickly served.

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