Robot Client and Server
The server side program contains a robot server, a link to the physical robots,
local robot objects, a user interface, and a client link (see Figure 1).
The client side program contains a client, local robot objects, a user interface,
and a server link (see Figure 1). Each part can be extended to provide
various functions.
Figure 1
Server Side
The main job of the robot server is to maintain connections with the robots
and the clients and to act as a link between corresponding clients and robots.
The server starts by opening a port for communicating with the robots.
It will poll for new robots and create a Robot object for each robot found.
The server will automatically update robot sensor data, which is then stored
in the local Robot objects. When clients send commands for robots,
the server puts them into a queue for each robot. The server will also
send the robot sensor data to each corresponding client upon request.
The user interface is basically a list displaying the name of each robot
that is currently connected along with a “Local Client” button. The
button creates a local client for controlling the selected robot.
Current functionality/Possible extensions:
The user interface currently only displays the robot’s name as well as changing
font to reflect whether or not a client controls it. This can easily
be extended to display more information about each robot.
The server currently only connects to one port and only uses physical robots.
It can easily be changed to connect to multiple ports and create simulated
robots (as defined by the user). The robot link would also need to
be updated to reflect these changes.
The server has only been tested on a serial line connected to one robot.
Ideally, if a wireless connector is used, multiple robots could connect to
the server. Along with using wireless, some form of reliable data transfer
would have to be implemented.
Right now, only a local client link is created to connect to a local client.
A remote version of the client link can be added for communication with remote
clients.
Client Side
The client basically acts as a remote controller and viewer. There
are two sorts of clients in this server/client relationship; one is a robot
client (defined in robotclient.doc), and the other is the remote controller/viewer.
The client normally starts without connecting to a robot, but it can be optionally
started with a robot chosen already. There is a robot chooser
for viewing and switching to available robots. The main job of the
client is to display sensor data and to send commands to the robot.
Current functionality/Possible extensions
The user interface currently displays sonar sensor data in a box and lists
the remaining sensor data on the right. There is a control panel for
moving the robot and scanning. The other sensors can be displayed in
a graphical manner since there is a type, location, and value for each sensor.
Perhaps a small pictorial image of the robot can reflect the sensors and
their states. All aspects of controlling the robot can be extended,
but may require extending the implemented command codes for the robot.
The client itself can only be run as a local client for now. A remote
version of the client can be made, which will require the robot chooser to
be completed. This will also require a remote server link to be made
for connecting remotely as well as updating the server side to handle it
(as noted above).
Besides having simulated robots, there can also be simulated clients (automated
clients) which utilize some AI to determine actions based on sensor data.
Both Sides
There is currently only a physical robot object. A simulated robot
object can be created that would update its sensors automatically based on
.
There are a limited number of opcodes currently implemented, but many more
can be added (up to a total of 255).
Extendable Subclass/Inheritance structures (see Figure 1 above)
note: not all are implemented
