We are in the process of setting up a lab experiment in which an inverted pendulum mounted on a cart is to be swung up by a feedback controller. Measurements should be taken every 7ms, and the control signal is to be transmitted every 70ms.
We chose to implement the controller (in C) on Phidgets' single board computer, which runs Debian Linux (SBC3, see http://www.phidgets.com). The measurements are received by interface cards (also bought from Phidgets) which are connected to the SBC via USB.
Problems:
A) We are currently unable to schedule measurements so that they are taken every 7ms. In fact, using the sleep command of C our sampling times vary wildly between 3ms and 15 ms. That's a problem, since our observer (for the angular velocity of the rod and the cart's velocity) is designed for a fixed sampling rate. We have verified that the computational resources required by the controller and the observer are not responsible for these variations.
B) We are also unable to transmit the control signal on time, as it happens that the controller is unexpectedly inactive for at least 200ms. Increasing the priority of the process that runs the controller relaxes the problem somewhat, but the "dead times" are still too long and too frequent to successfully run the experiment.
Questions:
1) What are the chances that we can solve the problems described above by installing a suitable real time linux system on our SBC? Is there a specific OS you can recommend?
2) Is it a problem that the measurements are transmitted via USB to the SBC? If so, is it possible to tune the USB interface so as to better comply with real time requirements?
3) If the setup we are currently using (SBC plus interfaces via USB) turns out to be inappropriate for the above experimental setting, what alternatives could you recommend?
Thanks.
Hello,
1) - A "least effort" approach would be to try to improve preemtion of you Debian kernel. This can be done by applying of preemtion patches and probably replacing of the standard scheduler. It is doubtful whether you can solve your problem this way, but no big changes neccessary in your system and you can easily roll back to the initial setup. As you understand, this would only improve you chances, not brinning you to real-time.
- I would recommend trying RTAI (Real-Time Application Interface). First try to build you application as a kernel module. If succeed, you may decide to move it to the user-space (more safe solution). Note, that a real-time OS is not enough: you also have to use real-time drivers and libraries for your hardware. There are quite a few RT drivers for some DAQ boards/controllers available, check RTAI website and forums.
2) and 3) I think connection of your system via USB is not a problem itself. However, i have no experience building something real-time with USB.
Andrej,
thank you for your valuable comments. Here is an update of our efforts in this project:
Problem A: We are now using the command clock_nanosleep from time.h to replace sleep. This decreased the variation of the sampling times: They are never smaller than scheduled, most of the time only slightly larger, but sometimes still twice as large (the latter phenomenon happens in a periodic fashion; we are still looking into this issue).
Problem B: We have removed some of the services of the OS which has appearently resolved the problem.
We have also tried, as you suggest, to play with the preemtion stuff, but with not much of success, as I was told. Our admin is currently testing several real time OS, including Xenomai, on a RaspberryPi (our target hardware is still the Phidget SBC 3; the Rasp is used for the purpose of testing only).
You also mention real time drivers. We have not yet found any ready-to-use solution for usb drivers that come close to "real time". There have been some projects in this area, such as usb4rt, but all of them seem to have been abandoned many years ago. Any specific hint as to what (almost) real time usb driver could be used would be appreciated.
There is another problem that we have just recognized: The Phidget encoders for incremental sensors (1047_1 at http://www.phidgets.com) have a fixed sampling rate (125/s) and provide access to the most recently measured values. However, you never know the precise time at which the measurements have actually been taken: already 7ms ago, or just the moment before you read the value? I wonder if there is a clean way to get information about the time of the measurement, and any hint to more suitable encoder hardware would be appreciated.
I'm also doing similar experiments on a BeagleBone Black SBC with Ubuntu. As far as I see your phidget, even it costs 200$ has a very old generation processor compared to the 45$ BeagleBone Black.
- I suggest you to stop all background services that you don't need before doing any experiment.
- Check for CPU power management stuff. It is quite possible that kernel sets the CPU governor to something dynamic which adjusts processor speed on-the-fly. If your processor supports this kind of dynamic scaling, disable it and set CPU to the full speed. Look for "dmesg" output, check with "cpufreq" utilities in Debian repositories, etc.
- If you are using an ethernet connection with SSH to connect to the SBC, this can also affect the timing of your experiments. If you print something to the screen periodically for example, those bytes are transferred back over ethernet. If possible, try to connect to the device over a serial communication line.
- If you miss the timing periods you need, don't use sleep() based blocking techniques but go with an infinite loop based timing logic. This has the risk to hog the CPU but if you intend to run a single C application on the board that's not a big problem. So for example,
1. Measure and save the measurement time
2. Check if (current time) - (prev measurement time) >= 7ms
- If yes, go to 1
- If no, go to 2
Gunther,
There is at least this usable RT implementation of the USB stack:
https://www.rtai.org/RTAICONTRIB/usb20rt-rtai-0.1.tar.bz2
- Linux/RTAI
It must be possible to get it working on a Phidget SBC 3; check READMEs for detail on support/patches of the hardware you are using.
Ozan,
thank you for your comments. I believe our admin has already tested your first three suggestions. The fourth one seems to be difficult to implement as the CPU has other things to do as well (observer, controller, ...).
Gunther
- Badges
- Science topic
- Similar topics
- Computer Communications (Networks)
- Simulators