This company is using Linux to control industrial robots—here's why.
At MYDATA automation AB (a Swedish robotics company) we have chosen Linux 2.0 as the new operating system for our pick-and-place machines. The Linux version of our control software is currently running on in-house test machines. Linux will completely replace the older “real-time Unix” on customers' machines in the third quarter of 1997.
A pick-and-place machine is a special-purpose industrial robot. It is designed to pick electronic (surface mountable) components and place them in the correct position on a printed circuit board (PCB). PCBs are boards found inside electronic equipment, such as motherboard and plug-in cards found in any personal computer.
The design of a pick-and-place robot is built around a split-axis concept. We have a high speed X “wagon” (yes, we call it a wagon, despite the fact that it isn't pulled by horses) moving from left to right (the X axis) on top of the machine. On the X wagon we have a mount head, moving vertically on the Z axis and rotating on the phi axis. We also have a Y wagon, called a “table”, moving on the Y axis. (See Figure 1.)
The components are supplied in tape reels, component sticks, or on trays which are loaded into “smart” magazines that position the component in a pick position directly under the path of the X wagon.
Let us follow a single mount cycle. First, the magazine positions a component in the pick position. Next, the X wagon moves to the position above the magazine. The mount head is lowered, and the tool tip touches the component. Vacuum is applied, and the component is sucked to the tool, much like drinking through a straw. (See Figure 2.) The mount head moves up, lifting the component, and the X wagon moves to the Y wagon.
As each component must be placed with a much higher precision than the carriers in which it was delivered, some means of centering the component on the tool is needed. Thus, two centering jaws push the component to the middle of the tool tip, while the dimensions of the component are measured. Then the tool and component turn 90 degrees and the centering and measuring is done in this direction, too. Finally, the electrical properties of the component are measured. (See Figure 3.)
During this X movement towards the place position, the Y wagon carrying the PCB positions itself at the correct Y coordinate for the component to be placed. Finally, the mount tool lowers and places the component in the correct position. The entire mount cycle is completed in approximately half a second.
To speed up mounting many small components there is also a Hydra head on the X wagon which picks eight components simultaneously and places them individually. This device cannot use mechanical centering, and it uses optical centering instead. During optical centering the position of the component on the tool is measured optically and adjusted for when placing the component. (See Figure 4.) In addition, the Y wagon can “dock” to a conveyor to load or unload PCBs. (See Figure 5.)
Long ago MYDATA made the smart design decision to separate the hard real-time requirements from the complex algorithms of optimization, user interface and database management. In a typical MYDATA machine, there is a computer box containing one Pentium PC motherboard and several servo computers. (See Figure 6.) We call the servo system “hard real-time” and the Un*x system “soft real-time”.
The servo computers are programmed in Z80 assembler and take such commands as “move to position 2500 with acceleration parameters XA XB XC”. The positions given are in ticks on the sensors.
The PC motherboard currently runs Un*x—a true multitasking system running several programs written in C++. One of the programs is a mounter process that generates the commands sent to the servo computers specifying where to mount each component, and also handles coordinate system transformations and conversion to sensor “ticks”. The optimizer process optimizes the mount order for maximum throughput. The data server daemon stores information about packages, components, PCBs and component locations. There is also a Man-Machine-Interface process to communicate with the user.
In the servo programs accurate timing is a must. However, in the Un*x system a short delay will not break anything, but will result in poor overall mounting speed. Thus, what is needed for the Un*x system is not a guaranteed response time, but a very fast average response time.
When I joined MYDATA, I had been using Linux for years. I thought that programming Unix on PC hardware would be comparable to running Linux. MYDATA was then using Venix 3.2, an “industrial strength real-time operating system” from VentureCom based on System V, release 3.2. After a short time of programming Venix I was very disappointed. None of the tools that I usually relied on were available: no emacs, no bash, not even a strerror function in the C library.
In the summer of 1995, I began lobbying for a more modern operating system. There were two alternatives: Venix 4.2 (supported mostly by old timers), and Linux 1.2.8 (supported by a few young programmers). A change to either of these operating systems meant a massive porting effort.
After a lot of nagging I got permission to test the interrupt response time for both operating systems under different load conditions. The test was done with a special plug-in card with output ports and interrupt generation connected to an oscilloscope.
Everyone expected this test to kill Linux as an alternative. In Venix I had a hard real-time process, and in Linux I used the nice levels to create a high priority process. The surprising result was that the average interrupt response time was three times faster on Linux—and the worst case interrupt response time was ten times faster on Linux.
Despite the great test results, there was not much interest in Linux. A few programmers wanted to use Linux, but the marketing department had invested a lot in Venix as the “industrial strength real time OS”. There was also strong resistance from people who were unwilling to learn a new operating system.
Then, in December 1995, circumstances changed. 3Com could no longer deliver the 3c503 Ethernet card that Venix 3.2 used. MYDATA managed to find an old stock of WD8003 cards with device drivers for Venix, and I got permission to start a one man project doing a pilot port of the system to Linux.
An industrial robot such as the MYDATA pick-and-place machine has a lot of special hardware. My first job was to rewrite all the device drivers for Linux, which was interesting, produced no surprises—and was completed on schedule. Of course, the fact that I had source code for the Venix device drivers was a distinct advantage.
In early 1996 I learned that Markus Kuhn (a German student) had added POSIX real-time scheduling to Linux 1.3. This was a gift from heaven—hard real-time priorities and memory locking in Linux.
During the spring I worked on porting the application programs. This work proved to be a lot more difficult than I had expected. I would get a program to compile, just to have it immediately crash when running. After long hours of debugging I found an uninitialized variable. Due to different memory layouts, the program just happened to work in Venix. With the bug fixed I would run the program again, and again it would crash for similar reasons.
Another cause of great grief was using C++ objects in file scope and in global scope. If you declare two C++ variable in file scope, the constructors for those variables will be run before main is started. However, if the variables are declared in different files, the order in which the constructors are run will be defined by the implementation. It turned out that the Venix linker ordered the constructors in alphabetical order of object file names, whereas the Linux linker ordered them in the sequence the object files were added to the library using ar (archive).
The result was that suddenly we had a lot of code which contained uninitialized variables. After fighting with the code to solve these problems I am firmly convinced that both file scope and global variables should be banned from C++.
As spring grew into summer I continued in this manner with welcome help from another programmer, Carl Martinsson. Finally, in June 1996, our joint effort was rewarded. We had a MYDATA pick-and-place machine running Linux and actually mounting components on a PCB.
The main lesson I learned from this porting effort is that moving non-portable Unix programs from one Unix-like OS to another is much harder than one might think. Also, rewriting device drivers for Linux is not that hard.
During the work on the port to Linux, the software team developed a new version of the software (with new features) for Venix. In October 1996 we finally received the decision that the next release of the software was to run under Linux.
With the help of our code-management system from Perforce (http://www.perforce.com/), we managed to merge the newly developed features for the Venix system with the Linux system. Of course, this resulted in another round of debugging.
Now, in early 1997, the Linux version of our software is the main development environment and is fully functional. Support hardware currently being developed needs to be completed before we can start the verification tests and ship the software to beta test sites. The release of the Linux-based system to customers worldwide is scheduled for the third quarter of 1997.
The MYDATA pick-and-place software consists of 8,000 files and 150MB of source code. MYDATA is shipping roughly one pick-and-place machine a day at $150,000 each. I think this is the first project to utilize Linux as a real-time platform on this scale.
Most of the hardware in the MYDATA machines is manufactured in-house. This hardware is impossible for the average person to buy and would be useless unless he had a MYDATA machine. For this reason, we have not made the device drivers publicly available. In any case, MYDATA hardware is already bundled with the most up-to-date software available.
We do, however, use two pieces of hardware that can be used by anyone: the Decision PCCOM-8 multi port serial card and the parallel port to SCSI conversion cable from Shuttle Technologies called EPST. We contracted Signum Support, a Swedish consulting company specializing in GNU software, to write device drivers for these two. The contract states the device drivers are to have the GNU GPL license and that Signum should try to include the drivers in Linus Torvalds' next kernel release. These drivers are currently available and fully functional. Contact Signum Support at http://www.signum.se/ for download information.
From a purely economic point of view, we get a lot of beta testers for these device drivers free of charge. Even better, we get to give something back to the Linux community.
From a programmer's and lawyer's point of view, MYDATA supplies four different software packages that interact.
The Linux operating system (free of charge)
The device drivers for MYDATA hardware (as loadable modules)
Servo programs (running on servo computers)
However, from the user's point of view MYDATA offers an industrial robot with hardware and a software system. The user is not usually concerned with implementation details such as the choice of an operating system.
Until now, the software installation and upgrades have always been done by service engineers. With the next generation of software we want to provide an installation CD-ROM which the user can use without a service engineer or thick manual by his side. The vision is that the user will insert the CD-ROM and the boot floppy, turn on the power and let the installation process automatically. Well, we might have to ask for an IP address. This installation CD-ROM is being developed in cooperation with Signum Support and is based on Red Hat 4.0 with a limited choice of hardware and added hardware detection.