Real-time systems have been around for a long time. Networked systems have been around for almost as long. The problems associated with real-time systems are compounded by indeterminate network latencies. These problems are not new, and much work (such as QOS) has been devoted to resolving these issues. This paper does not contribute to this research, but instead strives to illustrate their importance by showing their effect in an easily comprehended situation that may have a realistic importance in the near future.
Latency occurs in an enormous number of situations, which are not neccessarily computer related. The simple (!) act of driving a car exposes one to latency effects all the time, caused by the mass of the car. Acceleration to any speed takes time, and more importantly slowing down for traffic lights takes forethought, to stop in time. Games such as slotcars (model racing cars) have greatly reduced latency effects since the mass of the model cars is so small.
Slotcars are normally controlled by a hand-held variable resistor which forms part of the power supply to the car. Changing the resistance results in a very rapid change to the speed of the car, so that latency does not appear to be an issue. By introducing a computer speed controller which uses a wireless network to control the device we are able to see the effects of network induced latency: failure to make allowance results in the cars spinning off the track.
Slotcars use a DC motor which runs off a 0-16 volt power supply. Variations in voltage are usually controlled by a hand-held variable resistor which is in serial with the slotcar.
Computer interfaces to slotcars seem to be limited to lap timing systems: each car has a magnet which can trigger a detector as it passes over a point of the track. Several systems are commercially available which will use this mechanism to display laptimes on a local PC.
Researchers at DSTC have used lap timing hardware to interface to the Elvin content based routing system. This allows a slotcar track at one location to broadcast lap events across the Elvin system so that they can be displayed at another location. One of the disadvantages of distributed work environments is the difficulty of sharing experiences, and Elvin has been used to share races across different locations, where each site hs an identical racetrack and event information is passed between the different sites. For example, race start times are sent as Elvin events between all participating sites, so that the races all start together - with allowances for network latency delays.
There do not appear to be any reported systems where the slotcars are controlled from the PC. This is not too difficult: using a parallel port interface to a PWC (pulse width controller), signals can be sent though the parallel port to vary the mean voltage seen by the slotcar, and hence to control the speeed of the car.
A set of Java classes have been written using the commAPI
(serial/parallel communications API) with public class
public class PowerController {
void setPowerLevel(int level);
int getPowerLevel();
}
This class was used to build a GUI application running on the PC connected to the slotcar track. This allows measurements to be made which reflect any consequences of PC control without network effects.
We then used Jini to publish a slotcar controller as a network service. The actual service was exported as an RMI proxy. This meant that once the service was found a slotcar could be controlled by remote method invocation from the client.
To make it more interesting, we built clients that could run on a Compaw Ipaq. We installed the Savaje Java Operating System on the Ipaq, which allows all Java 1.2 applications to run, including those using Jini and the Java 1.2 RMI extensions. The Ipaq was equipped with a WiFi IEEE 802.11b wireless card running at 11M/s. This connected to a wireless access point on the same local ethernet as the slotcars PC, with the ethernet running at 10M/s.
We now had three systems: