Senior Design Project

High-Level Design Version 1.0

Senior Design I and II - Spring / Summer 2001

Modification history:

VersionDateWhoComment
Version 0.0August 15, 2000G. WaltonArtifact Template
Version 1.0April 9, 2001Michael WalesInitial Version

Team Members:


Contents of this Document

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++ adaptor for the 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 implementation 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:

Reuseability:
The whole purpose of our system is to be reused, so we will make sure our system design reflects this. ....


This page last modified by Michael Wales (Mag7Rule@aol.com) on April 9, 2001