Modification history:

Team Members:

• Jeff Goodman (Jeff2379@aol.com)
• Jeff Miller (J_Miller68@hotmail.com)
• Michael Wales (Mag7Rule@aol.com)

High-Level Architecture

Design Issues

High-level Architecture

Manual Controller Program:
The manual controller program will either be implemented in Java or C++. It is unsure at this point because we haven't done any research on the pros and cons of XWindows GUIs. We are very familiar with Java GUIs from previous experience, but would like to avoid needlessly integrating a C++ module with a Java module. If we do decide to use Java, we will use a socket to communicate with a C++ adapter for the Robot Controller API. If we implement the Manual Controller Program simply using C++, then we will only need to have an implementation of the Robot Controller API and no sockets will be required.

We will probably use the keyboard's arrow keys for direct control of the robot. If we implement the module in C++ we might be able to use a joystick as an interface. Using a joystick would be possible on a PC using Linux, but wouldn't be practical on Sun or SGI workstations. The GUI will display the orientation of the robot and the user will be able to see how fast it is moving. It will also have a text display of the speed and orientation. The user will likely give the robot new directions using the keyboard, and the computer will show in the GUI how the robot should react. The GUI will also have a text window displaying the different commands being sent to the robot.

SAF Simulator:
Another way to control the robot besides using the Manual Controller program would be to integrate the Robot Controller API with a SAF simulation. A SAF entity could be associated with the real physical robot, and each time the SAF simulates a movement, it also sends the movement to the robot. The Robot Controller API could simply be an object instance associated with a specific entity in the simulation. It is only optional that we implement this module, and we probably won't because of our unfamiliarity with SAFs.

Robot Controller API:
This will be a set of C++ classes that are implemented to establish a communication link between a SAF simulation or Human Controller Program and a robot (or robot surrogate program). A controller program will execute function to send commands to the robot. The API will also support a robot sending data back through to the controller software. ...

Robot Surrogate Program:
The robot surrogate program will be an emulation of an actual robot. This program is designed to be used for situations where a SAF simulation is being developed to have robot support, but the developers don't have a robot, or don't want to use the robot during testing. The robot surrogate will accept and respond to commands as if it were a real robot. The robot surrogate will also simulate it's own position and orientation to correspond with the outcome of the commands it is receiving. The Robot Surrogate Program will also have a display showing robot "status", orientation, command log, and other useful information.

Communication:
The system will be designed to allow different communication scenarios. The communication technology we will build into the system will be LAN support. There are many implementations of LANs that will support wireless communications. We can test and develop our system on a hardwired LAN and then later move it to a wireless LAN without any modifications. Other possible communication systems could be RF, IR, and cellular dial-up modem.

Design Issues:

The whole purpose of our system is to be reused, so we will make sure our system design reflects this. There is a good chance that someone else will reuse everything we design in our project at a later date. Reuse is the most relevant issue to our project. We are going to try to make it easy for people to reuse and maintain the code that we write for this project. We feel that if we write well-documented code it will be easier for future users and designers to maintain the code and fully understand it so that it can be reused often.

One of the issues we considered when deciding on what language to design our code in was portability. Java is more portable that C++ but it is also slower. We had to decide if we would trade portability for speed. Most of the existing code was written in C++ so we also had to take that into consideration. We decided to design the code in C++ mainly because of the existing code.

Some of our technical issues are that since we have never written an interface in C++, we will either need to learn how to do it or find a suitable alternative. One idea that we had was to write the interface in Java since we are all familiar with writing GUIs in Java. The major drawback from doing the GUI in Java is that we would have to integrate that with the rest of our C++ code. This would just add more possible problems for us that we could be easily avoided. Dr. Franceschini has provided information on other ways we could do the GUI and we are currently doing research on what is the best way to design it.

Another technical issue that we encountered was how to make the controller. We were deciding upon using a joystick, mouse, or just the keyboard. We have all taken basic electronics courses but none of us had the knowledge to build our own controller. As of now it looks like the user will give the robot controls using the keyboard.

This page last modified by Jeff Goodman (Jeff2379@aol.com) on April 9, 2001