Using Linux in a Control and Robotics Lab
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.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- RSS Feeds
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Designing Electronics with Linux
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- What's the tweeting protocol?
- Kernel Problem
3 hours 58 min ago
- BASH script to log IPs on public web server
8 hours 25 min ago
12 hours 57 sec ago
- Reply to comment | Linux Journal
12 hours 33 min ago
- All the articles you talked
14 hours 56 min ago
- All the articles you talked
15 hours 3 sec ago
- All the articles you talked
15 hours 1 min ago
19 hours 26 min ago
- Keeping track of IP address
21 hours 17 min ago
- Roll your own dynamic dns
1 day 2 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?