Motion control over realtime ethernet

The first example shows a prototype realtime control application using Krypton's 6D measurement device K600 CMM. (Click the images for MPEG videos.) The K600 measurement device consists of three linear cameras that measure the 3D coordinates of pulsed infrared LEDs. The spatial accuracy is in the order of 10 to 100 microns, in a workspace of several meters in depth. The K600 outputs UDP packets containing the 3D coordinates on plain ethernet, at a programmable frequency.K600K600

The video (click on the image) shows the movable camera setup (there is one camera behind each of the three "holes" with the yellow rims) and its interface box. The data flow between cameras and interface box runs on ethernet, and in the interface box, a router transfers the data further to the control PC.

Two cooperating robots This application involves two robots controlled with Orocos on RTAI. The robot on the right carries a box with a hole, and with three LEDs for the Krypton K600 measurement system, which outputs its 3D measurements on an Ethernet line. This robot can be moved by the user with a mouse.

Two cooperating robotsTwo cooperating robots The robot on the left uses RT-Net to read in the K600 measurements, and to adapt its motion. This motion is composed on-line, by taking into account one specification (moving the end-point of the surgical tool along the red wire), one constraint (making the tool pass through the hole), and one feedback control (adapting to the motion of the hole).
This demonstration was put together by Johan Rutgeerts, and master students Ruben Smits and Jan Matthysen.

XY TableXY Table The K600 is connected via a dedicated cable to a control PC running RT-Net (for the realtime ethernet connection) and Orocos on RTAI. The control PC steers a two-degrees-of-freedom XY table, on which one of the K600 LEDs is attached. The measurements can be collected with a frequency of more than 500Hz, and a delay of less than 2.5 milliseconds (with very little jitter).

The video (click on the image) shows, from right to left: (i) the XY table; (ii) the hardware drives with, on top, a box with voltage source and hardware interfaces; (iii) the break-out box for the National Instruments AD card (NI 6024 with Comedi device driver); and (iv) the screen of the control PC.

The PC itself is hidden below the table top. It is an Intel Celeron 600MHz with 256 Mbyte RAM. It runs RTAI 3.0v2 (ADEOS-r10), the CVS versions of Comedi and RT-Net (April 2004), on a Linux 2.4.24 kernel.

RTNet TrackingRTNet Tracking The video shows the LED being taken off the XY table and moved around manually. The XY table is controlled to track this motion. The tracking errors are caused by the low bandwidth of the XY table (due to its high inertia) and a very sub-optimal tuning of the control gains.

Tracking a moving targetTracking a moving target The video shows the realtime tracking of a moving target (the white box), while at the same time executing a desired motion (a circle) on that target. The motion of the target is sensed by a LED and compensated for in the control. Tracking errors occur as soon as the motion is too fast for the XY table to follow. (The control gains and the analog range of the power electronics have been increased with respect to the tracking experiment above.)

These results are joint work of: Jan De Geeter (Krypton); Peter Soetens, Takis Issaris, Klaas Gadeyne and Johan Rutgeerts (Orocos(@)K.U.Leuven); and Dirk Cauwenbergh and Tom Vander Straeten (master students).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

OROCO-Xenomai-RTNet

Hi folks, I wonder use OROCOS-Xenomai-RTNet environment on my PC making a communication with another machine (Gumstix ARM) where I also wanna run OROCOS-Xenomai-RTNET to control subsystems of an AUV.

I'd like to know how did you make a communication between process in different machine. Did you use Corba? Or RTAI RPC?

I've read OROCOS manual and I found:

Components should not call remote components during real-time
execution.
However, real-time components may be called upon by any component,
local
or remote. A component may thus always receive a request from any
component, but not every component should send a request to any
component.
If you violate this rule, it will not crash your program, but your
execution timing will be worse.

Have you faced any problem like that? What is your suggestion considering my intention? Should I drop CORBA on my application?

Thanks for all
Breno Carneiro Pinheiro
Electrical Engineering