March 1998, Issue 92

Picking a PC RTOS

So, where do we start? The beginning always seems like the best place, doesn’t it? For us, that means the specification for the system we’re trying to implement.

In other words, we need to identify our system’s hardware and software components and know what real-time constraints, if any, it has. We also need an idea of what the target system costs ought to be, and maybe we even need to write some code to model the system’s behavior.

To make this a little more real, let’s spec out a system and try to find an RTOS for it. Since this issue of INK is featuring robots, let’s consider a robot controller to drive one of the six-legged robots I work with. Figure 1, the system block diagram, shows the software and hardware components.

The system needs to run on a PC/104 platform to be able to fit on the robot and interface with it. It uses 12 parallel output lines to drive 12 radio-control servos, which serve as the actuators. The two actuators for each leg control the up/down and forward/backward functions of the leg.

Besides the actuators, there is also a serial port connected to a radio modem, which sends motion-control commands to the robot from a process on a Unix workstation. These commands are high level, so they focus on things like telling the robot to walk in a certain direction, stop, or walk backwards, and so on.

Our controller has to generate the appropriate leg motion for each of the walking-mode commands. Besides generating the actuation patterns for each walking mode (i.e., gait), it also needs to generate the appropriate control signals for the servos.

RC servos use a pulse-width coded signal, in which the pulse width indicates the desired position of the servo. The servo itself has a position feedback-based controller, which controls its electric motor.

The pulses vary between 1 and 2 ms, encoding positions of 0–90°, and are repeated at 10–20 ms. Figure 2 shows how the position relates to the pulse width. Experimentation has shown that providing four steps, or positions, from 0 to 90° (22.5°/250-ms resolution) is sufficient.

Figure 2—Here we see the timing for an RC-servo actuator used on the robot. The width of the pulse, which needs to be repeated every 10– 25 ms, controls the position of the actuator. A 1.0-ms pulse represents 0°, and 2.0 ms represents 90°.

However, these particular servos chatter (i.e., vibrate) when the pulse width signal has too much jitter (typically greater than 100 ms). This means we need to control the jitter in the timing of the servo signal to within ±50 ms.

When the servo is set to 45° (1.5 ms), the signal needs to be between 1.450 and 1.650 ms. Excessive chattering causes unnecessary wear in the servo mechanism and heating.

The wireless modem runs at 9600 bps and provides a communication channel to the serial port of a Unix workstation. Over this channel, I want to run PPP so high-level control processes on the Unix workstation can control the robot.

It does this by establishing a network connection using TCP/IP to the process on the robot that deals with gait control. I don’t really care what the software on the Unix workstation does. I’m only concerned with the controller on the robot and how it interfaces.

The hardware for this application can be covered by using a standard off-the-shelf PC/AT PC/104 CPU with at least one serial port and 12 parallel I/O ports. As part of the PC/AT architecture, a timer chip can be programmed to post an interrupt to the system. The resolution of the channel 0 timer on a PC/AT is 0.86 ms, which should be sufficient for our purposes.