GUI components for real-time simulation and control
This project aims at the development of a set of reusable GUI components for networked real-time simulation and control.
They are meant to be used together with the non-GUI framework Orocos, but for very simple tasks it might be possible to build an application with these components, but without Orocos.
There is ongoing discusion about the best way, to design these components. Look at: http://lists.mech.kuleuven.be/pipermail/orocos-users/2011-August/004299.html
The original proposal:
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 each clock event)
FuncGen (generates sinus, triangle and sqare signals and optionally white noise)
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
Related project:
Back to FrontPage