Iris.3 Mobile Robot: Status Reports

Summer 2000

These are the weekly reports of the four students actively working on the Iris3 robot.

Matt Eisenbraun
Wenyan Dong
Andy Schmidgall
Jeremy Tessendorf

Matt Eisenbraun

7/24/00

I spent time this week on two major activities: writing documentation for SIE for the website and adapting the existing TTT engine to the SIE environment. I am should be able to finish the TTT adaptation by the end of the week. When that's done, I'll probably work on revising the SIE docs. Because I fear that I'll run out of stack space if I start writing reports about reports, I'll skip ahead to the TTT work.

The TTT engine is accessed by /learning/prano:prano(). There are numerous subroutines and source file that make up the engine, but this is the interface. /learning/prano.h includes these extra source files. prano() is also independent of any windows specific code. Copied the /learning/prano directory to stv227a-2 and was able to compile them without any trouble.

As with all devices in SIE, the TTT engine has an unique protocol for communication between the agent and the device. This is not finalized yet, and will be detailed at a latter time (hopefully next week). Like the arms I have coded an interface to SIE that is independent of the device code. The interface will then call prano() when appropriate.

I have also converted the interface portion of the TTT program to work with sockets, for testing purposes. Because the engine accessed through prano(), I simply created a new prano(), pranoSocks() which contains all of the socket communication. I then changed /learning/prano.h to include only the new file, pranoSocks.c. This way the socket version of the TTT program can be substituted for the normal version just by changing /learning/prano.h. I also had to add code for initialization and handshaking to /winfront.cpp:WinMain(). These conversions are intended for testing purposes only. To adapt the interface into an agent will require changing how I/O is handled, and will be very dependent on what will ultimately function as the agent (PT, for example).

7/14/00

This week I spent a considerable amount of time debugging the logging functions. The logging library is now finished. I have removed all of the logging-related functions from arms.C and placed them in $SIEHOME/utils/sie_logs.c. I have also adjusted the $SIEHOME/utils Makefile to cause sie_logs to compile to a static library, $SIEHOME/lib/libsie_logs.a.

Furthermore, I have began a great documentation effort. I have already written (and adapted from existing SIE documentation) five pages on SIE, and I've only just started. In this documentation I will assume that the reader is familiar with Andy Ritger's research paper. I will therefore be focusing on how the system actually works and is configured, and I will mention the design principles only when absolutely necessary. I anticipate this will take the next several days at the very least, and may take the entire week.

Now that the logging functions have been perfected, all new development should make use of them, and existing code should be retrofitted as time permits. Use of these functions will make future code much more programmer-friendly.

A program does not have to do anything special to link to the sie_logs library. I have already updated COMMON_LIBS variable in $/SIEHOME/Makefile.Linux to -L$(SIEHOME)/lib -lsie_logs. Since this Makefile is included by all lower-level Makefiles, all other Makefiles have likewise been updated. Therefore, the only thing that a program needs to do to use the sie_logs library is to include 'logs.h', which is in $SIEHOME/common_include (which is in the include path, so #include 'logs.h' will work just fine).

Last week the following items were reported as not yet implemented:

  1. DEBUG output mode
  2. default values for missing items in the config file
  3. log_output_hdr support in error_output()
  4. administrator graceful shutdown of devices

Of these 1) is now implemented, 2) remains untested, 3) is implemented (see note below), 4) is not fixed and most likely will not be fixed any time soon.

NOTE on #3: The global variable system for placing a header on output messages does work for what I've tested it on, arms.C, as the sole device and the win_arm_agent as the agent. The more I think about this the more I think that this was a bad idea and that I should probably change it to something else. I am think that it will fall apart as soon as two programs try to use logs (maybe not even the same logs). This is just something to keep in mind, if it doesn't work (I don't think it will) at least you have fair warning. I'll try to remember to fix it next week . . .

The logging functions and other miscellaneous changes have been committed to CVS, so now everyone can have fun logging!

The other day I was looking through the CVS manual and I discovered that it does keyword substitution. CVS will replace the string $Id$ in any committed document to an ID string containing the committer's login, the version number, the filename, and a time/date stamp. I think that it would be a good idea for all submitted source file (including Makefile and scripts) to include this string as the first line in the file. This should make it somewhat easier to keep track who make what changes to what file. See http://www.cs.utah.edu/dept/old/texinfo/cvs/cvs_16.html for more information on CVS keyword substations.

7/9/00

This was a short week, because of the holiday. This week I was mostly concerned with getting the logging functions I referenced last week operational. This is now (almost) done. There are a few minor things to do yet, which will be mentioned below.

My next task will be to integrate the TTT engine that we have available. After the frame_grabber software is online, I (or someone else) will have to begin looking a ANN software and begin the training.

The logging routines have two main interfaces: log_output() and error_output(). This is a configuration utility, process_config_file(), which processes a configuration file for the logging routines. There are also a large number of utility functions, but these do not need to be understood to use the log functions.

proceess_config_file() process the configuration file of the logging functions. It takes two parameters: the name of the config file and the address of a LogPrefs struct. The config file has three line. The first is the filename for the standard output log. The second is the filename for the error log, and the third is the output level. The output level has three different settings: CONCISE, VERBOSE, DEBUG (not yet supported).

These values are read from the file and stored in the struct. It is up to the programmer to test the output level and provide differing functionality depending on the output level. It is also up to the programmer to choose which log to use for a given message.

Any one of the three parameters may be omitted. If the standard log is omitted, it will default to stdout. If error log is omitted, it will default to stderr. If the output level is omitted, it will default to VERBOSE. This feature has not yet been tested, and may not work, so a word to the wise: include all three settings.

The config file also supports comments. A comment is indicated with the character ‘#’ and goes to the end of the line.

To write to a logfile (again the programmer must supply the path, don't let the name fool you), the log_output() and error_output() functions are provided. There is a global char*, log_output_hdr that is used to specify a header message for the logging routines. The format of a log message is the following log_output_hdr:userStr. It is very important to use realloc() when assigning a value to log_output_hdr. log_output_hdr is not yet supported by error_output().

log_output() takes two parameters, the filename for the logfile, and the message to log. The output file should not already be opened; log_output() will open and then close it. This may seem somewhat wasteful, but it is necessary to guarantee that logged messages make it to the file, even in the event of a program crash. This can be very important for debugging.

error_output() is similar to log_output(), but it has one difference. error_output() will first call perror and output that before the user's message.

In debugging these functions I encountered a number of memory bugs. To help correct them, I downloaded and installed the mpr tool. The URL for the ftp site where this (and a number of other) Linux tool is distributed is ftp://sunsite.unc.edu/pub/Linux/devel/lang/c/. This tool was mentioned in chapter 6 of Linux Application Development.

The logging functions still need some testing, but they work pretty well. The next step will be to build them into a library within the SIE hierarchy. Right now all the logging functions are in arms.C, the arm device code.

I also spent some time over the last week looking an implementing a graceful shutdown for the arms device. Then I realized that it is not the arm code that is at fault for not shutting down correctly; it is the administrator. This is a bug (noted in a comment) in the administrator, and I am not going to attempt to fix it (ultimately, of course, it will have to be fixed. I'm just willing to let IWU do it; I think it can wait).

There's probably more that I've forgotten about. If you have any questions on any of the functions I've discussed here please e-mail me (mpeisen@ilstu.edu). Please do not alter any of the functions in arms.C without consulting me, no matter how sure it needs to change. I have spend a long time tracking down a number of very subtle bugs, and I have no desire to do so again (on the same functions, any ways).

6/30/00

This week, I worked primarily on porting shelley_sockets to Windows. I only worked on porting the shelley_sockets functions that the client needs; I have spend no time working on porting server functions, as I did not see this to be a priority. I also spent time working on enhancements to the arm driver code that I wrote last week.

Specifically the enhancements allow for more streamlined logging of output and error messages. With these functions it will be very easy to redirect all of the programs output to a file, or to the screen, or somewhere else.

After I finish debugging these enhancements I will work on interfacing the tic-tac-toe engine that we have with SIE. I have no idea how challenging this task will be; I haven’t yet seen the code.

As I have previously indicated the main thing I did this week was port the shelley_sockets to Windows. This was successful. I have placed the Windows version of the shelley_sockets library in the SIE hierarchy in CVS. It is located in $SIEHOME/utils/winSock. There is no makefile, and this library will not compile under linux. It is included in SIE for connivance.

When writing a winSock application, the function WSAStartup() must be called before any socket can be used. This function initializes the DLL for winSocks. The exact format of this (and all other winSock functions) can be found online in the MSDN at http://msdn.microsoft.com. I found this to be an invaluable resource in porting shelley_sockets.

That's all I can think of right now. The logging and configuration functions are not yet debugged; I’ll report on them next week.

6/23/00

This week I shifted gears from working with the frame_grabber and vision code to work with Wenyan on the arms. I started on Saturday by getting the Jameco controller to communicate with the arm code provided with SIE. The existing arm code was built completely outside of the SIE framework, so I spent the next several days incorporating the arm code into SIE.

The next step is to test and debug the arm interface code that I wrote, and then write scripts for the arms. Wenyan is working with developing the scripts. After I finish debugging the code I am going to turn my attention to developing an agent to run under Windows.

Before getting into the specifics of what is described above, I have an update to the device_list bug I reported on last week (as an addendum to the previous week's report). The bug seems to be intermittent; I haven't corrected for it (changing filenames), and, as far as I know, know one has fixed it. And yet I haven't encountered it in over a week. I'm thinking it is caused by a memory leak of some kind, but I have know idea where it is.

As mentioned above, I spent considerable time over the last week integrating the existing arm controller code with SIE. In doing so I had to change some of the code in jameco.C. There is a member function of the jameco class, stillon, which is supposed to determine whether or not the jameco (hardware) board still has power. It seems to work only intermittently, and I had to comment it out in line 356. stillon() appears in two other locations in the code, but it seems to work fine there. I'm not sure why stillon was failing on that line (it kept asking me to turn the arms on, even though they already were) and nowhere else, but I'm not sure that it matters (so I'm just going to leave it unless it becomes an issue).

In the ${SIEHOME}/devices/arms directory are the three primary source file that the arms used by the old arms setup: jameco.C, tt_arms.C, servo.C, and xyCoor.C. jameco.C contained all of the low-level routines for operating the arms. tt_arms.C contained routines specific to IWU's Tic-Tac-Toe game. Hardcoded values abound here. servo.C is a server program that processes requests from a client, ${SIEHOME}/device_wrappers/Tt_Arms.C. Again, this takes place completely outside of SIE. xyCoor.C contains routines for converting between coordinate systems.

Of these files, tt_arms.C and servo.C will probably have to be ignored altogether. They are both designed and coded to be specific for IWU's setup, and there is little chance of (or value in) adapting them to other purposes. The SIE interface I built for the arms is designed around jameco.C; the functions it contains are general enough to be useable almost without modification. xyCoor.C may prove useful in the future for conversions between coordinate systems. I haven't spent a lot of time working with these functions, but if they were used correctly (i.e. as a separate device in the SIE hierarchy) they could be quite helpful.

jameco.C contained a (apparently unused) script interpreter. The interface to SIE is built around this interpreter. A script contains one or more lines of the following form:

SV#M#

Where the first # represents the servo number, and the second # represents move number (I don't know what this is in terms of -- degrees, robix-steps, or something else; Wenyan was looking into this). I'm planning on adding support for comments to the scripting interpreter, but I haven't done it yet.

The basic idea behind the interface that the agent sends only completed scripts to the device. At the same time the device does nothing on its own; it does exactly what the agent tells it to do. This will ensure that the arm code will be general enough to be used by a variety of different agents (such as ttt, blocks, shaking hands with Dr. A.), without needing to be changed at all. This is a very large improvement over the native SIE code which was not general at all.

The Interface for jameco.C to SIE can be found in ${SIEHOME}/devices/arms/arms.C. Like all other components of SIE the arms device has a communication protocol, outlined in table 1. The arms device connects to the administrator over a socket connection, just like other SIE components. An agent uses the standard SIE protocol for communication with the administrator (this is important, the agent still has to go through all of the necessary back-and-forth with the administrator; the commands in table 1.1 apply come into effect only when the administrator send the data on to the device). The possible responses from the devices are listed in table 2. As of this writing, all commands and responses can be represented by an int8. This may change, in the future, however. The commands and responses in tables 1 and 2 are defined in ${SIEHOME}/common_include/arms_protocol.h. This file must be included to be able to use the interface.

Command Description
ARMS_SEND_SCRIPT

Instructs the arm device that script data follows. After sending the command, the agent must also send the following information to the device (in this order):

  1. The length of the filename the script should be saved to.
  2. The filename the script should be save to.
  3. The length of the script. This is currently defined as an int32, putting an upper limit on the length of a script.
  4. The script data. Write all of the data into the socket at one time. The device will save the script, and send back:
  5. The return message. This will be either ARMS_YES or ARMS_NO, and will be an int8.
ARMS_RUN_SCRIPT

Instructs the arm to run the name of script that follows. After sending this instruction, the agent must send (in this order):

  1. The length of the filename for the script.
  2. The file name for the script.
  3. The arm number that the script applies to as an int32.

The device will run the script, and send back:

  1. The return message. This will be either ARMS_YES or ARMS_NO, and will be an int8.
ARMS_SAME_POS_ARM

Query the device to see if the specified arm (sent into the socket after this message) is in the same position that it last was (Makes sure that if it was moved, it was moved by the program). After the command is send, the agent must send one additional pieces of information:
1) The arm number to check as an int32.
The device will then return one item:
1) The return message. This will be either ARMS_YES or
ARMS_NO. and will be an int8.

ARMS_ADD_ARM

Instructs the device to add a new arm, if possible. No additional information is necessary.
The device will return ARMS_YES if the new arm could be added, and ARMS_NO if it could not (the max number permitted arms has already been reached).

Table 1. Arms interface protocol commands

Response Description
ARMS_YES Returned by device upon successful completion of the command.
ARMS_NO Returned by the device upon failure in the command.
ARMS_UNKNOWN_COMMAND Returned by the device upon encountering an unsupported command.
Table 2. Arms device responses

6/16/00

THE SIE

First, an addendum to last week's report. Last week I uncovered, but neglected to report on, a bug I encountered in the SIE code. When an agent requests a device, the administrator looks to the device_list file to see where the device program is, and then starts up a new thread for this program. The problem is that the program that the administrator tries to run is not the file indicated in device_list, but rather that file followed by 'I'. For example, if device_list contained the entry:

1 share 1 3 ${SIEHOME}/bin/device

Then administrator would try and run ${SIEHOME}/bin/deviceI. The best I can figure this is caused by a memory issue in one or more of the internal data structures maintained by the administrator, but I do not know how to fix it. For the time being a simple workaround for this bug would be to make sure the actual file name ends in one more 'I' than the corresponding entry in the device_list file.

Over the course of the last week I have configured CVS (Concurrent Version System) and I have worked with Andy towards getting the frame_grabber functional.

Right now CVS is setup on the P120 machine (128.87.106.14), and unfortunately only on the P120 machine. I have not been able to set it up to allow access from remote machines. What this means is that work must either be done from the P120 or files must be ftpd from that machine and then sent back when ready to be committed. To ftp an entire directory structure the easiest thing to do is to use tar to create a single file, ftp that file, then untar at the other end.

To create the tar file use the command:

tar -cvf <yourdir>.tar <yourdir>

And to untar:

tar -xvf <tarfile>

CVS requires several environmental variables to function properly. The following lines should be added to the end of .bash_profile on the P120.

export CVSROOT=/usr/local/cvsroot

export EDITOR=/usr/bin/pico

CVSROOT defines the location of the CVS repository that we're interested in.

EDITOR defines the default editor that CVS will use. This can be any editor in the system, here it is set to pico. If this is not set the default is to use vi.

Also, if its not already there add the following line to the .bash_profile on both machines:

export SIEHOME=$HOME/sie

Without this SIE will not compile.

In order to use the repository for the mobile robot group, you must be a member of the mobot group. You will not be able to checkout files or update files if you are not in this group (This is aimed at future developers - Andy, Wenyan and myself have already been setup).

I have already imported the code snapshot of SIE from the Shelly website, http://www.iwu.edu/~shelley/, into the repository. To retrieve it, use the command: cvs checkout sie.

The CVS manual can be found at http://ximbiot.com/cvs/manual/. This is a must read for all members of the mobile robot group.

That's about it for CVS, now for the camera.

THE CAMERA

First Andy found a better API for the camera (and all image capture devices) than the one that we were using (which was a mess). The Scanner Access Now Easy (SANE) API should allow us to communicate effectively with our camera, or any number of other camera. So if, in the future, we decided to switch over to a different camera model, we should be able to do so with only minimal changes to our code. That's the first good point. The second is that this API (unlike our previous candidate) is being actively supported by the linux community. This means that future upgrades are likely, and again those upgrades should be able to be incorporated into our code with only minimal rewrites.

The bad point is that right now we are having some difficulty linking to the libraries provided by SANE. I am confident, however, that this is only a temporary setback.

I have installed the following two RPM packages from http://fr.rpmfind.net/ onto both linux machines:

1) sane-1.0.1-1.i386.rpm

2) sane-devel-1.0.1-4.i386.rpm

The first package provides the low-level device drives that interface with the actual devices, and the second provides the programming interfaces (libraries, headers, etc.).

Next I am going to spend some time working with Wenyan to try and figure out what is going on with the arm code, I will also continue to work with Andy whenever possible.

6/11/00

Since it was decided that mobile robot project will use the SIE for its central control program, I have been setting SIE up to meet our needs. As this task is pretty much complete at this point, my next step will be to help the other two group members (Andy and Wenyan) to get the camera and arms, respectively, communicating correctly with SIE.

More specifically, the first thing that I needed to due was to make the SIE compile on the linux machines in the lab. This involved two things. First, I had to download and install the openGL graphics libraries. The files I downloaded from http://www.redhat.com were:
1) Mesa-3.1-1.i386.rpm
2) Mesa-demos-3.1-1.i386.rpm
3) Mesa-devel-3.1-1.i386.rpm
4) Mesa-glut-3.1-1.i386.rpm
5) Mesa-glut-devel-3.1-1.i386.rpm

The second thing I had to do to allow the SIE to compile was to set the environmental variable SIEHOME to the directory where SIE was located. Under bash, this can be done with the following command: export SIEHOME=$HOME/sie. Currently, I am writing a sample agent that will test the camera through the frame_grabber functions that Andy is working on now.

Wenyan Dong

7/17/00

ARM:

In the SIE environment, three components are needed in order to have the arms properly functioned: arm agent, arm device, arm interface. Arm interface defines the functions that the arms can perform, and the communication protocol between the agent and the device. Arm agent request one of those functions through the SIE administrator to the arm device. Arm device interpret those function request and perform them.

The main function of the arm is to move to a particular position, which is decided during the process of playing tic-tac-toe. This is mainly achieved by sending scripts from the agent to the device. The agent will generate the scripts and the device will interpret the scripts. Again, the communication of scripts between those two will be controlled by the interface protocol and the administrator of SIE.

The following explains the three components (interface, agent, and device) in more detail.

Interface:

The file defining the interface is sie/common_include/arms_protocol.

ARMS_ADD_ARM command instructs the device to add an arm, if possible. Currently, the maximum number of arms that SIE can create is five. The agent only needs to send the command, no additional information is needed. The device will return ARMS_YES if the new arm could be added, and ARMS_NO if it could not, which means that the max number permitted has already been reached.

ARMS_SEND_SCRIPT command instructs the arm device that agent is sending the script data over to the device. After agent sends the command, it must also send the following information to the device (in this order):

  1. The length of the filename the scripts should be saved to.
  2. The filename of the script should be saved to.
  3. The length of the script. This is currently defined as an int32 (unsigned integer), putting an upper limit on the length of a script.
  4. The script data. Write all of the data into the socket at one time. The device will then pull it out in BLOCK_SIZE (512 bytes) increments, if the file is bigger than 512 bytes.

The device will save the script, and send back the return message. ARMS_YES means that script is successfully saved, and ARMS_NO means that script is unsuccessfully saved.

ARMS_RUN_SCRIPT command instructs the arm to run the name of script that follows. After sending this instruction, the agent must send the following information to the device (in this order):

  1. The length of the filename for the script.
  2. The filename for the script.
  3. The arm number that the agent wishes the script to be run on.

The device will run the script, and send back the return message. ARMS_YES means that script is successfully run. ARMS_NO means that script is unsuccessfully run.

ARMS_SAME_POS_ARM command query the device to see if the specified arm (sent into he socket after this message) is in the same position that it last was (Makes sure that if it was moved, it was moved by the program). After the command is send, the agent must send one additional pieces of information:

  1. The arm number to check as an int32.

The device will then return the return message. ARMS_YES if arm moved. ARMS_NO if arm didn’t move.

Note that all the information, whether it is send from the agent to the device, or from device to the agent, is sent through the sockets established by the SIE administrator, so the communication is controlled by the SIE administrator.

AGENT:

The file for the arm agent is sie/agents/arm_agent

Note that before sending anything to the device, the agent must send the AGENT_SEND_TO DEVICE command, which is required by the SIE, so that the administrator would know that the agent is attempting to send something to the device. The additional information required following this command is as follows (in this order):

  1. The id number of the device
  2. The total length of the message. Note in the case of arm agent, the total length would be the length of the command (in the arms protocol) and the additional information following the command, not just the length the command itself.

After finish sending all the above information, agent uses the commands defined in the interface to instruct the arm to do something useful.

Currently, there are three functions written in the agent. AddArm function uses command ARMS_ADD_ARM to instruct the device to initiate a new arm. In this function, specific information required for the ARMS_ADD_ARM command is written to the socket. Then the agent reads to response message (ARMS_YES< ARMS_NO) from the device through the sockets.

SendScript function uses command ARMS_SEND_SCRIPT to instruct the device to write the script to a file. In this function, specific information required for the ARMS_SEND_SCRIPT command is written to the socket. Then the agent reads to response message from the device through the sockets.

RunScript function uses command AMRS_RUN_SCRIPT to instruct the device to run the specified script. In this function, specific information required for the ARMS_RUN_SCRIPT command is written to the socket. Then the agent reads the response message from the device through the socket.

Note that before using any of these functions, the agent must connect to the SIE administrator first. The functions used to perform this task are agent_handshake (handshake with the administrator), and request_device (requesting the ownership of the arm). Those functions are defined in the file sie/utils/shelley_sockets.c

Device:

The file for the arm device is sie/devices/arms/arms.C

The main structure for the device program is the switch case structure, based on the command it receives from the agent. First, it reads the command from the socket. Then it determines which way to go depending on the command it receives.

In case the command is ADMIN_QUERY_DEVICE_STATUS, which is sent by the administrator to query to the status of the arm, the arm would have to check its status and write the response message back to the administrator. Note that currently we have not figured out a way to check the status of the arm, so for now, the arm just sends back DEVICE_A_OK message.

In case the command is ARMS_ADD_ARM, the device checks to see if the number of arms initiated has exceed the max number. If it has, the device sends back ARMS_NO message. If it has not, the device initiate an arm using the jameco class defined in the file sie/devices/arms/jameco.C. The details of this file is explained later on. Upon the successful completion of adding an arm, the device sends back ARMS_YES message through the administrator to the agent. Otherwise, the device sends back ARMS_NO message.

In case the command is ARMS_SEND_SCRIPT, the device first reads the length of the filename of the script, allocate the memory base on that length, and record the filename. Then it reads the length of the script data. If the data size is bigger than BLOCK_SIZE (512 bytes), the device will allocate the memory one BLOCK_SIZE at a time, and record the data one BLOCK_SIZE at a time. If the data size is smaller than the BLOCK_SIZE, the device will allocate the memory based on that size, and whole data at one time. The purpose of this is to prevent the memory allocation issues. Upon the successful completion of recording the script data, the device sends back ARMS_YES message through the administrator to the agent. Otherwise, the device sends back ARMS_NO message.

In case the command is ARMS_RUN_SCRIPT, the device first reads the length of the filename of the script, allocate the memory based on that length, and record the filename. Then it reads the arm number, and checks to see if the arm number sent by the agent is greater than zero and smaller than max arm number. If it is true, then the device calls the runScript function in the file sie/devices/arms/jameco.C to interpret the script data and move the arm to the desired position. The detail of the runScript function is explained later on. Upon the successful completion of running the script, the device sends back ARMS_YES message through the administrator to the agent. Otherwise, the device sends back ARMS_NO message.

In case the command is ARMS_SAME_POS_ARM, the device first reads the arm number, and checks to see if the arm number sent by the agent is greater than zero and smaller than max arm number. If it is true, then the device calls the samePos function in the file sie/devices/arms/jameco.C to check if the arm has moved. The detail of the samePos will be explained later on.

In case the command is ADMIN_DISCONNECT_DEVICE, the device sends back ARMS_YES message, finishes the loop the switch statements, and disconnect itself from the administrator.

Jameco function:

Jameco constructor initializes an arm by establishing a terminal between the arm and the computer it connects to. It also records the position of the servos on the arm.

RunScript function:

runScript function is a part of jameco class. It first open a particular script file, and reads the file. The main structure of the runScript function is a looping switch structure.

The jameco controller board processes information one ASCII string command at a time. Each command string follows the format:

L n L n … <enter> (maximum of 20 characters/line)

Where L is the command letters in caps, n is a decimal integer number. This is the format of the script file. The commands currently implemented in the runScript function are as follows:

BD: the command selects a board, followed by a decimal number defining the number of the desired controller board. (ex: BD1 – selects number 1 controller board). If there is only one controller board connected, it will become the default board.

SV: select a servo, followed by a decimal number defining the number of the desired servo of selected board. (ex: SV2 – selects number 2 servo on the selected controller board). Once a board or a servo is selected, it will stay selected until power is removed or another select command is received.

M: move the selected servo to an absolute position. The range of the position is between 1 and 255. (ex: SV244 – move the selected servo to position 244).

I: incremental move relative to the current position.

(ex: M100 <enter> I10<enter> I-10<enter> -- the selected servo will first move to position 100, then to position 110 (100+10), and finally to position 100 (100+10-10).

D: delay/pause in milliseconds (ms)

(ex: M200 D1000 M100 <enter> -- servo will move to position 200 first, then there is a one-second delay, and then it will move to position 100)

runScript file will read the script file one line at a time, and write it to the control board to let the board execute the command itself.

7/3/00

Documentation: I have revised the arm agent so that it reads from a script file instead of initializing a string as script in the agent code. So that agent will be able to read a a script stored as a file. Next, I am still working on writing the scripts so that the arm can move to the squares on the board, and make circles and Xs.

6/25/00

Documentation:We have found that according to Wesleyan's SIE, arms do not go through the administrator. In other words, agent and device(arm) communicate directly. By now, we have created a protocol between the agent and the device, which defines the things that we wish the arm can do. In order to make the arm move to the position we want, the agent will be able to generate scripts and send it to the arm through the administrator. The administrator send the scripts to the device, and the device will interpret the script and move accordingly. By now, we have wrote an agent, device, and protocol to tie the arms to the whole SIE. In the agent code, we hard coded the scripts. In the device code, we intepreted the script using the function Wesleyan wrote that was included in the SIE. For the next step, we will try to write programs that will be generating scripts to move the arm to more positions, or make the arm draw circles and Xs. In the long run, the agent should generate scripts dynamically using t

Hours: 20 hours - writing codes for the agent, debugging the device and agent code so that it conforms to the SIE.

6/10/00

Two kinds of arm controller board were used for the robot. Robix RCS-6 (www.robix.com)runs on a DOS computer, or Windows in a DOS session if the DOS session has exclusive use of CPU and its sensitivity is set to minimum. Plug the servos into the adapter (yellow wire on the innermost side), connect the adapter into the commputer through a printer cable to the LPT port. After installing the Robix software, start robix with command rbx f.

SV 203 control board is used on a Linux computer (www.pontech.com). An AC adpater is designed to supply the power. Plug the servos to the board, connect the board into the COM port of the computer. Software controlling the board can be found on Weslyan Shelley website under the directory of SIE/devices/arms.

Andy Schmidgall

6/17/00

I have been working on writing a new frontend for the SANE drivers we got last week. I was having trouble linking to the dynamic libraries, but finally i figured out what I needed to do. After I get a full working copy I can go back and check out little details, but this works right now:

text [in brackets] is exactly how i'm doing it

-Must use gcc compiler (g++ won't work) and use a small c extensions '.c' not '.C' or anything else. [saneCam.c]

-Must include sane.h header file [#include <sane/sane.h>]

This is what my makefile looks like:

---

saneCam : saneCam.o

gcc -o saneCam saneCam.o -L/usr/local/lib/sane -lsane-qcam -ldl

saneCam.o : saneCam.c

gcc -c saneCam.c

---

explanation of some of the arguments:

-L/usr/local/lib/sane

the -L option defines additional directories to look for libraries in (past the default directories) In this case the dynamic library 'sane-qcam' is located in the /usr/local/lib/sane directory

-lsane-qcam

this tells the compiler to include the sane-qcam library. This is needed as this library defines the functions laid out in the SANE API

-ldl

This tells the compiler to include the dynamic linking library or something like that. It will compile fine without this but the program you make will choke at runtime.

6/10/00

I found out that Connectix does NOT support the quickCams anymore. Logitech now owns the rights to the cameras.

I found drivers/programs for both Linux and Windows here:

Windows (mainly for the USB camera, because we have the parallel drivers on disk): http://www.logitech.com/cf/support/10403.cfm

Linux: http://www.cs.duke.edu/~reynolds/cqcam/

(How-to for Linux here: http://www.dkfz-heidelberg.de/Macromol/wedemann/mini-HOWTO-cqcam.html)

---

I have also been writing a framegrabber program for Linux to interface with the SIE. It's not done yet, but in a couple days I'll be able to put up code for a preliminary version...

Jeremy Tessendorf

6/30/00

Researched Yuasa batteries, could not find pictures of batteriers we have Worked on Lynxomotion robot and found other possibilites for sensors Fould sensors that will follow a black line or wall perimeters.