[Orocos-users] GUI components for real-time control and simulation

[Uwe Fechner]

 Hello,

we (ASSET Institute, TU Delft) started the development of a set of
GUI components for our kite-power control system.

Many of these components are generic and might be useful in a
different context, too.

Components
----------------
Components, that are currently in development:

- Clock  (emits a fast clock and a slow clock, using UDP packages)
- CarSim (very simple model of a car, that is moving on a straight line)
- FileReader (reads csv files, sends UDP packages on eauch clock event)
- FuncGen (generates sinus, triangle and sqare signals)
- Oscilloscope (displays scalar and vector data streams)
- UDPLogger (logs UDP messages and displays them in a human readable format on the screen)
- UDPClient (emits UDP messages of type SCALAR, VECTOR or EVENT)

The components can be used for simulations with up to 100 Hz sampling rate
without using OROCOS, or together with orocos for much higher sampling rates.

All components are implemented as stand-alone executables. They shall have a default
screen size of 1/8 or 1/4 of a 1280x1024 screen, so that up to 8 of the small
components can be used at the same time on one screen.

Configuration files are used, to define the port numbers and ip numbers of each
input and output. Any number of inputs can be connected to one output.

Communication protocol:
---------------------------------

Requirements:
- it must be possible, to use it for the communication between
  processes on one computer, but also an a LAN segment between
  different computers
- the protocol must be able to transport messages with a size
  of up to 32 double values
- multicasting (one output, multiple inputs) must be possible
- hard real-time (bounded latency of e.g. 3 ms) must be possible
- all messages must be unambiguous
- the protocol shall be simple and easy to use

Current implementation:
- uses UDP packages
- binary or ASCII message format
- messages have the type SCALAR, VECTOR or EVENT
- all numbers are transferred as double values
- lost packages can be detected
- all packages have a time-stamp, so the latency of each transfer
  can be calculated with a microsecond resolution (if you have
  synchronized clocks)
- on the input side a message- queue is used, to avoid package losses,
  if the processing needs too much time (normally this should not be
  needed, but it is needed for example for slow display components)
- it uses hard coded enumerations for the physical quantity, and
  the defined events
- runs an Linux with rt-preemt patches or xenomai

Any comments welcome.

Regards:

Uwe Fechner