The Mathematics and Engineering program at Queen's University in Kingston, Ontario operates a control and robotics laboratory as part of the course offerings in the control systems area. The lab experiments use our custom-built electro-mechanical setups and require the students to write algorithms in C for controlling the hardware.

The lab began using C under DOS as the software environment for the lab experiments, but not all students had an easy time with the environment. Generally, it was too easy for configuration files to be inadvertently changed with frustrating consequences. Subsequently, an integrated experiment environment known as dlxlab has been developed for simulating and running control lab experiments. It consists of a single program, run as dlxsim for simulations or as dlxrun for controlling hardware experiments. The program was developed using the XView toolkit under Linux (see “Programming with XView” by Michael Hall, LJ, March 1998), and operates in the lab on a variety of PC-compatible hardware running Linux 1.2.13.

The students taking the lab vary widely in computing background and skill. The primary intent of the control labs is to investigate the application of control theory to actual motors, carts, inverted pendula and so on, without having software operation dominate the experience. On the other hand, understanding low-level interfacing code is also a desirable outcome, so the hardware interface has to be “visible”.

In order to design a control algorithm for a physical system, one must have a mathematical model of the system to be controlled in the form of either differential or difference equations, and knowledge of the physical parameters in the model. The user interface to dlxlab was designed so that, as far as possible, this is the only information that must be supplied by the user.

This goal is attained for the case of the program running in simulation mode. For the situation where actual hardware is being controlled, information describing the hardware interface must also be provided, although it can be largely hidden from the user through header files.

The user input to the program takes place through interactive construction of a system file which describes the system under investigation.

To simulate a system, one invokes dlxsim with a system description file as argument.

dlxsim sim.sys &

One of the lab experiments consists of a pair of track-mounted carts, coupled by springs and driven by a servomotor. A simple system file for simulating such a pair of spring-coupled carts is shown in Listing 1. The format of the system file is a sequence of begin ... end delimited blocks. The blocks are of two types:

Figure 1. Main Program Panel and Other Windows

The main program panel (see Figure 1) contains a “Build” button, which when pressed causes processing of the system file. That is, the user system file is converted into a series of C code files by a parsing process. The files are compiled to a shared object file by gcc, and the contents of the resulting shared object module are dynamically linked into dlxsim as it runs. The linked code contains not just the system differential equations, but also modules for interactively manipulating parameters and plotting results on the basis of the variable names provided in the system file.

Figure 2. Run Manager

Assuming that the system file contains no syntactic errors, the program log window contains only progress messages, and a pop-up panel for controlling simulations appears (Figure 2). As long as only parameter changes are made, a series of simulation runs can be made. Plotting and printing is handled by gnuplot running as a child process.

If the system file contains errors, the error location is reported in the log window, and the pop-up does not appear. The errors are caught either at the parsing level or within the C code segments. In the latter case, the error messages from gcc refer to lines in the user system file, since the generated C files include #line statements referring to the user system file. Since the dlxsim system file edit window is an XView textsw, it inherits the line searching menus associated with XView applications.

Simulations can be run and plotted, as long as the system file contents (such as variable names, equations of motion and so on) are not changed. If such changes are made, the “ReBuild” button must be invoked to cause freeing of resources, recompilation of the dynamic module and relinking of the generated codes.

The system file for an actual experiment contains code sections which mediate between floating-point program variables and the binary hardware levels, in addition to the requirements of a simulation file. A file for measuring the response of a servomotor to a constant voltage input is shown in Listing 2. This file illustrates the use of so-called utility code and definition sections in the system file. There is really no restriction on the type of code placed here. The program user guide contains an example of such code written to carry out a recursive least squares identification algorithm using measured data resident in files. The example in Listing 2 is much more modest and uses library include files to abstract the interface board data access.

The include files serve to hide the actual hardware interface behind port access macros like set_dac() for setting digital-to-analog converter levels and get_encoder() for reading the count of the optical quadrature position encoder from the interface boards. The code blocks using these macros are converted to dynamically linked subroutines and repeatedly called by the program main real-time control loop.

This example is really “open loop control” and primarily illustrates the hardware interface provided by the program. Feedback controllers typically employ filtering of the measured data, and the system file for such a controller includes a system code section which implements the dynamics of the filters.

True, certainly we would be in trouble trying to run a print server and a copy of the Apache WWW daemon at the same time that we were balancing an inverted double pendulum. However, in the lab environment, the window manager (preferably Open Look olvwm) and the control environment dlxrun are the only user level applications running. The program dlxlab is an XView application, written in the explicit dispatch mode. This means the timing of the control loop is under control of the programmed loop and not the XView notifier.

As long as the lab machines are provided with enough memory to avoid swapping during the experiments, the effect of timing jitter has a smaller effect than, for example, pretending that the behavior of servomotors is entirely linear. It was originally thought that selectively killing and restarting certain daemon processes would be necessary, but our experience has shown that this is not the case. In any event, one of the aims of control design is to produce controllers which are robust against unmodelled disturbances, and timing jitter provides an example of such a disturbance.

We run lab experiments on machines ranging from a 12MB 486SLC-66 to a Pentium P5-166. There is no problem running the experiments on our set of 486DX2-66 boxes, with sample rates up to several thousand samples per second. The lab machines are on a local network with 10Base-2 coaxial cable, with a salvaged 386DX-16 staggering along as the resident print server.

The Linux machine in my office is running the Apache web server and has a WWW page for our control and robotics lab. The address is http://jhd486.mast.queensu.ca/. The lab page has photos of the lab equipment and links to my home page where documentation, sources and binaries for the dlxlab programs are available.

The dlxlab environment described began life as an awk script that turned a system file (ancestor of the ones above) into an XView control system simulation program, running under SunOS-4.1. After a Linux conversion experience, I came upon a version of the Kernel Hacker's Guide by Michael Johnson and discovered that user level I/O port access was possible under Linux. This allowed the program to accomplish hardware control as well as simulation tasks.

The low cost and wide availability of interface boards for PC-compatible machines make them ideal for a lab such as the one we have set up. The complete openness of the Linux system made it possible to undertake program development with the confidence that it could be made to work. It is also helpful to have the same operating environment in the office, at home and in the robotics and control lab.

Virtual beers all around.