Echtzeitanbindung von MATLAB und Simulink an … · Echtzeitanbindung von MATLAB und Simulink an komplexe Robotersysteme in der Forschung ... (Brooks et al. 2005),

Echtzeitanbindung von MATLAB und Simulink an komplexe Robotersysteme in der Forschung

Berthold Bäuml

Autonomous Learning Robots LabInstitute of Robotics and Mechatronics

German Aerospace Center (DLR)[email protected]

mailto:[email protected]

mailto:[email protected]

DLR Institut für Robotik und Mechatronik

• Teil des Deutschen Zentrums für Luft- und Raumfahrt

• Standort Oberpfaffenhofen bei München

• Weltweit eines der führenden Forschungsinstitute in der Entwicklung komplexer mechatronischer Systeme• grosse Forschungs-/Entwicklungs-/Fertigungstiefe:

“von der Schraube bis zum intelligenten Humanoiden”

• Eckdaten

• ca. 200 Wissenschaftler

• 59% Studenten (Bachelor/Master/PhD)

• eigene Mechanik- und Elektronikwerkstätten

DLR Institute of Robotics and MechatronicsSpace Robotics

ROTEX 1993first robot in space

ROKVISS 2005-20116 year mission on ISS

DEOS (planned 2014)On Orbit Servicing (OOS) DEOS-Simulator Teleoperation: “shared autonomy”

DLR Institute of Robotics and MechatronicsNew Paradigm: Soft Robotics

Change of paradigm in robotics: From large, rigid and position controlled to light-weight, compliant, and adaptable

Programmable stiffness and damping Safety tests

Zero gravity behaviour

“Agile” Robots

• dynamic

• reactive

• intelligent

Complex Mechatronic SystemsNew Level of Complexity for Agile/Autonomous Robots

• complex single robotic component(DLR-Hand-II: 13DOF, 100 sensors)

• compound systems with tightly interacting parts(Justin: 53 DOF, 250 sensors)

• rates of up to 3kHz over all DOF (up to 10kHz in next generation)

• sophisticated control algorithms (e.g. gravity compensation, impedance)

• tight coupling to non-realtime modules for user interaction, perception and planning

Challenges:

• scalable computing power

• distributed execution in hard realtime

Complex Mechatronics Systems Development Flow Agile

• heterogenous team developing software (~ 10 members)

• experts in mechanics, electronics, control, ..., but NOT in software

• many students (>50%)

• Iterative, flexible and adaptive development flowr

• research on prototypes

Challenges:

• decoupling of development flow in a team

• code reusability

• flexible reconfiguration, e.g. testbeds for system parts

• rapid prototyping, e.g. Quick “edit-compile-debug”-cycles--> Software concept, that provides an agile development flow for building agile robots

teststands partial system full system

Abstract Functional View

torso dev

arm dev

hand dev hand dev

torso JC (3x) 0.3ms dev TC

1ms

arm JC (7x) 0.3ms dev AC

1ms

hand JC (3x4x) 1ms dev FC (4x)

1ms

QNX

hand dev

vision

world model

dev camera GUI

EC path planning

dev input

device

3D viewer

Monitoring Configuration


1ms PC

1ms ipol 3ms

invkin 6ms

cartesian impedance

1ms state

machine


1ms


1ms ipol 1ms

invkin 1ms

collision avoidance

3ms

hand dev

Edit Compile Debug

…

REALTIME

vision

world model

dev camera GUI

EC path planning

dev input

device

3D viewer

Edit Compile Debug

…



1ms PC

1ms ipol 3ms

invkin 6ms

cartesian impedance

1ms state

machine


1ms


1ms ipol 1ms

invkin 1ms

collision avoidance

3ms

Linux

Linux Linux

Linux

VxWorks

VxWorks

QNX

Linux/ Windows

hand dev

REALTIME

CPU 1 CPU 2

“Decentral net of functional blocks and communication links”

Software concept has to provide• abstract, functional view and• mapping to a concrete hardware setup.

Robot Middleware

• ORCA (Brooks et al. 2005), MARIE (Cote et.al. 2004), MIRO (Utz et al. 2002), Player (Vaughan et al. 2003), OROCOS (www.orocos.org), OpenHRP (Kanehiro et al. 2004), MCA (www.mca2.org), YARP (Metta et al. 2006)

• Microsoft Robotics Studio (msdn.microsoft.com/robotics)• not open source

• runs only on Windows

• ROS (Robot Operating System, www.ros.org)• open source

• multi platform (Linux, Mac OS X, easy portable, e.g. QNX, ...)

• rapidly growing community

Discussion:

• Component based software engineering

• Distributed communication and execution

• Successfully used in robotics applications

• BUT not distributed execution with > some 100Hz in hard realtime !

http://www.orocos.org

http://www.orocos.org

http://www.mca2.org

http://www.mca2.org

http://www.ros.org

http://www.ros.org

Pragmatic considerationsWhat is essential ?

• deterministic, concurrent execution

• fast, deterministic communication

• standardized interfaces for communication

• mechanisms for system configuration, startup and shutdownand what is not ?

• dynamic reconfiguration at runtime

• higher levels of abstractions (e.g abstract “range sensor”)

Hardware constraints ?

• D/A- and A/D-conversion in the robots

• fast buses up to 1GBit/s to the robots

• CPU clocks > 3GHz, Multi-Core and Multi-CPU (e.g. Quad-DualCore Opteron >50GFLOPS)

• fast communication with low delay (1GBit: 1.5KByte in 15us)

• configurable infrastructure: e.g. switched Ethernet or P2P links

No !

Pragmatic considerationsWhat is essential ?

• deterministic, concurrent execution

• fast, deterministic communication

• standardized interfaces for communication

• mechanisms for system configuration, startup and shutdownand what is not ?

• dynamic reconfiguration at runtime

• higher levels of abstractions (e.g abstract “range sensor”)

What has to be done ourselves ?

• standardized interfaces

• abstraction of distributed communication

• system handling (distributed startup, shutdown, …)

What can we get from a realtime OS ?

• Processes (concurrency, protection)

• Shm on one PC (efficient IPC)

• Fast, deterministic drivers to (multiple) network cards

additional design goals

• protection between blocks (safety in HiL setup, debugging, ...)

• easy integration with other tools (minimal dependencies, “no threads”, ...)

“agile Robot Development” (aRD) Framework

aRDnet-suite: lightweight (~3000 lines)

• aRDnet-library (C/C++): implementation of block’s ports

Author's personal copy

10 B. Bauml, G. Hirzinger / Robotics and Autonomous Systems 56 (2008) 5–13

Fig. 4. Example for a simple aRDnet stand-alone block with one in- and one out-port. If the data packets are composed only from the basic data types the aRDnetsuite provides, the aRDnet library assures for consistent data representation on distributed, multi-platform setups. After creating and initializing the block’s ports,where e.g. the binding to the ports of other blocks is done as specified by the port names given as command line options, they can be used for receiving and sendingdata packets.

3.1.2. ardnet executableThe ardnet executable serves two important purposes with

regard to the communication abilities in the network of blocks.Being also based on the aRDnet library it can be seen as a block,however, with special features.

First, ardnet realizes the communication between twoblocks on different computers by running a corresponding pairof ardnet processes as a network bridge. For this purposeardnet has built-in functionality for transmission of data overthe network providing a “virtual wire” between the twocommunicating blocks.

In the current implementation ardnet uses bare UDPsockets (with packet sizes up to 64K). In combination withswitched and point-to-point Ethernet connections this allowsfor an efficient (see Section 4 for benchmarks) and reliablecommunication without lost or out-of-order packets. Thebinding between the two ardnet blocks is done by specifyingthe corresponding hostname and port number as command lineoptions.

To address the problem of blocks running distributed evenon heterogenous computers (with differing CPU families,operating systems and compiler versions) the aRDnet suitedefines compatible basic data types for integer and floatingpoint numbers (see also Fig. 4). If data packets are composedonly from these provided data types, the aRDnet library assuresthe right representation on both sides of the communicationchannel.

Furthermore, a detailed control of quality of service (QoS) ispossible by choosing different network connections, e.g. point-to-point or switched Ethernet, using separate network stacks(a particular feature of the QNX microkernel architecture) andfinally by adjusting process priorities. This way we have been

able to achieve realtime communication over four ports with arate of 1 kHz on each line (for details see Section 4 and Fig. 5).

The second purpose ardnet serves is to provide a portmultiplier block. Therefore ardnet can be configured to haveone input but multiple output ports. Each data packet arrivingat the input is distributed onto all output ports.

3.1.3. Simulink stubTo connect aRDnet blocks to blocks implemented in a

Simulink model the aRDnet suite provides a template S-function code. This easily allows one to generate a stub blockfor Simulink representing the actual block. The developer hasonly to implement three functions. One specifies the stubblock’s layout (number and dimensions of in- and out-ports).The other two functions translate the data packets being sent bythe aRDnet block through its output ports to the outport lines ofthe stub block and, in the other direction, translate the data atthe stub’s inport lines to the data packets received at the aRDnetblock’s input ports.

The connection between the aRDnet block and its stub isimplemented with the help of the standard aRDnet librarymechanisms. This allows for a seamless integration of aSimulink model in the network.

3.1.4. Startup and shutdownStarting the decentralized network of blocks distributed over

a network of computers is done by using a hierarchy of scriptsvery similar to the way a Unix system starts up. A master scriptcalls subscripts for setting up particular system parts, whichagain can call sub-subscripts and so on.

To allow for the startup of a distributed system from asingle central command station the aRDnet suite provides the




• ardnet block: (UDP)-bridge between blocks on different PCs

vision

world model

dev camera GUI

EC path planning

dev input

device

3D viewer

Edit Compile Debug

…



1ms PC

1ms ipol 3ms

invkin 6ms

cartesian impedance

1ms state

machine


1ms


1ms ipol 1ms

invkin 1ms

collision avoidance

3ms

Linux

Linux Linux

Linux

VxWorks

VxWorks

QNX

Linux/ Windows

hand dev

REALTIME

CPU 1 CPU 2




• ardnet block: (UDP)-bridge between blocks on different PCs• Unix-like hierarchical startup and shutdown of distributed system,

with detailed configuration of QoS of communication links

• only depends on POSIX primitives (mutexes, semaphores, shm)

• no extra threads at client side

important decision: QNX for realtime and Linux for non-realtime(limited support for Mac OS X, iOS, VxWorks and Windows)

1. send4. rec

2. rec3. send

QNX

Performance:

QNX-PC with Pentium 4, 3GHz

roundtrip of packet of 1kByte size between two standalone blocks

o on one QNX-PC: 14us in worst caseo on two QNX-PCs with ardnet-bridge (UDP) over P2P 1GB-Ethernet link:

180us in worst case (120us on average)

1. send4. rec

QNX

2. rec3. send

QNX

eth

IP

IP

eth

1GBit / UDP

Preliminary study for a Two-Hand-Arm-System

hand dev

VxWorks/Intel

IP

eth

ethI

P eth

hand dev

VxWorks/PPC

IP

eth

ethI

P eth

arm dev

VxWorks/PPC

IP

eth

ethI

P eth

arm dev

VxWorks/PPC

IP

eth

ethI

P eth

control1ms

Windows

IP

eth

Linux

IP

eth

DebugMonitorProfile

switch

eth

IP

eth

IP

(from VxWorks)QNX

1kHz

1kHz

1kHz

1kHz

Integration of aRD and Matlab/Simulink Toolchain:Easy-to-Use Interface to Complex Robotic Systems

• research in controllers for many-DOF systems institute’s core topic

• Matlab/Simulink/Coder toolchain highly productive for controller design

• familiar tool for students (>50% of our researchers)

• Master students and trainees can do significant research

• even classes with our robots

• Simulink and aRD fit naturally: “blocks and signals”

vision

world model

dev camera GUI

EC path planning

dev input

device

3D viewer

Edit Compile Debug

…



1ms PC

1ms ipol 3ms

invkin 6ms

cartesian impedance

1ms state

machine


1ms


1ms ipol 1ms

invkin 1ms

collision avoidance

3ms

Linux

Linux Linux

Linux

VxWorks

VxWorks

QNX

Linux/ Windows

hand dev

REALTIME

CPU 1 CPU 2

vision

world model

dev camera GUI

EC path planning

dev input

device

3D viewer


torso dev

state machine

arm dev

hand dev

Linux

Linux Linux

Linux

VxWorks

VxWorks

Linux/ Windows

Edit Compile Debug

…

QNX

REALTIME

CPU 1 CPU 2

vision

world model

dev camera GUI

EC path planning

dev input

device

3D viewer


torso dev

state machine

arm dev

hand dev

Linux

Linux Linux

Linux

VxWorks

VxWorks

Linux/ Windows

Edit Compile Debug

…

QNX

REALTIME

CPU 1 CPU 2








• each Simulink model as one “meta”-block in aRD

• each (connected) aRD block has S-Function stub in Simulink model

• usage beyond control design

vision

world model

dev camera GUI

EC path planning

dev input

device

3D viewer


torso dev

state machine

arm dev

hand dev

Linux

Linux Linux

Linux

VxWorks

VxWorks

Linux/ Windows

Edit Compile Debug

…

QNX

REALTIME

CPU 1 CPU 2

Stateflow

interpreted Simulink








• each Simulink model as one “meta”-block in aRD

• each (connected) aRD block has S-Function stub in Simulink model

• usage beyond control design

• Stateflow for complex realtime application logic

• non-realtime interpreted Simulink + embedding in Matlab allows for quite complex application prototypes including GUIs

-> students need only one (well-known) tool to do research

Integration of aRD and Matlab/Simulink Toolchain:Implementation and Usage

• S-Function stub block mirrors aRD-block

• user only provides translation function from aRD packet to Simulink signals

• Simulink model can be synchronized on arriving aRD packets

samplepackets.hsfunardtmpl.c

S-Fun stub


• S-Function stub block as mirror of an aRD-block



• only the small aRD library has to be linked (no extra threads, no dependencies)

• works with realtime (Coder generated) and interpreted Simulink models

• Simulink models can be “plugged in and out” without restart of the aRD network -> fast edit-compile-debug-cycle

vision

world model

dev camera GUI

EC path planning

dev input

device

3D viewer


torso dev

state machine

arm dev

hand dev

Linux

Linux Linux

Linux

VxWorks

VxWorks

Linux/ Windows

Edit Compile Debug

…

QNX

REALTIME

CPU 1 CPU 2

Stateflow

interpreted Simulink


• S-Function stub block as mirror of an aRD-block



• only the small aRD library has to be linked (no extra threads, no dependencies)

• works with realtime (Coder generated) and interpreted Simulink models

• Simulink models can be “plugged in and out” without restart of the aRD network -> fast edit-compile-debug-cycle

• parallel and distributed execution of large Simulink models by manually partitioning them in smaller models and connecting by aRD

Examples: JustinEdit-Compile-Execute for Whole Body Model

Examples: Toro -- DLR Walking Research PlatformMatlab/Simulink Based Control and Application Env.

2011• only 1 year build-time• LBR technology• impedance control

2013

Matlab GUI

Stateflow Aufgaben-Logik

UDP-Kommunikation mit externen Anwendungen (z.B. instant reality viewer)

Effiziente Reglerimplementierung mittels Matlab/Simulink

Co-Simulation: ardNet-Kommunikation mit Mehrkörper-Simulation (OpenHRP)

Experiment: - SERCOS-Kommunikation mit Experimentalsystem - Automatische Code- generierung mit Realtime Workshop

Schrittplanung

Examples: Toro -- DLR Walking Research PlatformMatlab/Simulink Based Control and Application Env.

Examples: Brain-Machine-Interface (BMI)Matlab/Simulink/Stateflow Realtime/Non-Realtime

High Level Controlusing Stateflow

Low Level Controlusing Realtime Workshopwith VxWorks target


realtime: Simulink/Coder

non-realtime: interpreted Simulnik

part of application logic

non-realtime interpreted Simulink (snippet):monitoring, GUI-elements, logic


stub for realtime model

Examples: DLR-Hand-II-> Live-Demo at Exhibition in Foyer

Conclusions• complex mechatronics systems are demanding wrt software architecture

• distributed sensor, actuator and computing resources

• hard realtime constraints

• agile development flow with highly volatile teams (>50% students)

• -> DLR’s aRD component based and hard realtime communication framework

• tight integration of aRD and Matlab/Simulink/Coder toolchain-> “agile development flow for agile robots”

• highly productive and homogeneous development environment

• from teststand -> complex component -> full robotic system

• controller design in simulation and hardware-in-the-loop

• model based and generation of realtime code (for non-software experts)

• prototyping of whole applications with realtime logic (Stateflow) and non-realtime components: GUI, ... (interpreted Simulink/Matlab)

• -> students do significant research on worldwide most advanced robots with well known Mathworks toolchain -> even classes on our robots

• Future

DLR HASy (Hand Arm System)

• 50 DOF in one Arm/Hand

• robustness through muscle-like intrinsic compliance

• high rate control on integrated FPGAs

aRDx

Ê Ê Ê Ê Ê Ê Ê ÊÙ Ù Ù ÙÙ

Ù

Ù

Ù

Á Á ÁÁ

Á

Á

Á

Á

‡ ‡ ‡ ‡‡

‡

‡

‡

Ï Ï Ï Ï ÏÏ Ï ÏÚ Ú Ú Ú Ú Ú Ú Ú

Ê aRDx Ù aRD

Á Orocos ‡ ROS

Ï ROS HfixedL Ú YARP

1 102 104 106 10810-6

10-4

10-2

1

packet size @byteD

roun

d-tri

ptim

e@sD

process

Ê Ê Ê Ê Ê Ê Ê ÊÙ Ù Ù Ù

Ù

Ù

Ù

Ù

Á Á Á ÁÁ

Á

Á

Á

‡ ‡

‡ ‡

‡

‡

‡

‡

Ú Ú Ú Ú ÚÚ

Ú

Ú

10-3 110-4

10-2‡ ‡

‡

‡ ‡

*

pause @sD

1 102 104 106 10810-6

10-4

10-2

1

packet size @byteD

host

Ê Ê ÊÊ

Ê

Ê

Ê

Ê

Ù Ù ÙÙ

Ù

Ù

Ù

Ù

Á Á Á Á

Á

Á

Á

Á

‡ ‡

‡

‡‡

‡

‡

‡

Ú Ú Ú ÚÚ

Ú

Ú

Ú

1 102 104 106 10810-4

10-3

10-2

10-1

1

10

packet size @byteD

distributed

Ê Ê Ê Ê Ê Ê ÊÙ Ù Ù Ù

Ù

Ù

Ù

Á Á ÁÁ

Á

Á

‡ ‡ ‡ ‡ ‡

‡

‡

‡

Ï Ï Ï Ï Ï Ï Ï ÏÚ Ú Ú Ú Ú Ú Ú

1 102 104 106 10810-6

10-4

10-2

1

packet size @byteD

roun

d-tri

ptim

e@sD

process

Ê Ê Ê Ê Ê Ê Ê

Ù Ù Ù Ù

Ù

Ù

Ù

Á Á Á ÁÁ

Á

Á

‡ ‡

‡ ‡

‡

‡

‡

Ú Ú Ú Ú Ú

Ú

ÚÚ

1 102 104 106 10810-6

10-4

10-2

1

packet size @byteD

host

Ê Ê Ê

Ê

Ê

Ê

Ê

Ù Ù Ù

Ù

Ù

Ù

Ù

Á Á Á ÁÁ

Á

Á

‡ ‡

‡

‡

‡

‡

‡

Ú Ú ÚÚ

Ú

Ú

Ú

1 102 104 106 10810-4

10-3

10-2

10-1

1

10

packet size @byteD

distributed

Fig. 5. Results of the stress test benchmark for 1 (top) and 20 (bottom) clients and for the three domains (columns). Each plot shows the mean round-triptime (averaged over some 100 runs) over the packet size for the various frameworks. Please, be aware of the log-log-scaling of the plots. The performance ofaRDx is almost always the best – most dramatically for the host domain where no other framework can provide zero-copy semantics. Only for small packetsizes (up to 1KB) where the transfer time is dominated by the constant overhead of a framework aRDx is beaten by aRD’s minimalistic implementationand in the 1-client case and large packets YARP is about 10% faster presumably due to a slightly more clever configuration of the TCP sockets. In the20-client case aRDx beats in the distributed domain all other frameworks by a factor of 2 because it has to transfer the packets sent from the master to theremote client only once and, hence, in each round of the test instead of 20+20 packets only 2+20 packets have to be transmitted over the GigE network.The increased constant overhead of aRDx for the host compared to the process domain is about 5x and, hence, close to the theoretically expected 6x dueto the indirect communication through the daemon. Interestingly, although aRDx needs a quite complex logic to provide zero-copy semantics in the hostdomain, its constant overhead is still 4x smaller than that of all other (except aRD) frameworks. In what follows we discuss some feature and quirks ofthe other frameworks we came about. All these frameworks scale very well and roughly linear with the number of clients. For the process domain YARPcan provide zero-copy semantics. In this domain ROS with its nodelets also was expected to show constant transfer times but could do so only after wefixed the implementation (labeled ROS fixed) – standard ROS (labeled ROS) completely initializes the memory of newly constructed packets, hence, thetransfer time has to scale with the packet size. For the host and the distributed domain YARP and ROS perform very similar as both communicate overTCP sockets (side note: for YARP, because of instabilities, we could use the potentially more efficient mutlicast and shared memory modes) . In caseof the host domain and large packets (> 1MB) they even reach almost the performance of the shared memory based transport of aRD showing that theLinux loopback sockets are very efficient. In all tests the performance of Orocos was worst, although we always tried the optimal parameters. We suspectthat this comes due to the additional abstraction layer with ACE/TAO in its communication stack. For ROS we found another severe quirk in the host anddistributed domain and packet sizes of 10KB to 100KB. There the round-trip time dramatically increases 100x. A further analysis (showed that this effectdisappears completely when adding a pause of at least 100ms between each round of the test (see the inset in the 1-client plot depicting the round-triptime over the pause time for 1KB packet) . This means, ROS is not really stress resistent.

with 100 clients running in the kHz range. Even for thedistributed domain the worst-case round-trip latencies are nolonger than 500µs.

IV. CONCLUSIONS

We presented the design considerations and implementa-tion details of the new highly performant, realtime capable,minimalistic and simple communication layer of our aRDxsoftware framework. In an in-depth benchmarking on Linuxof the raw communication performance of aRDx and thepopular robotic software frameworks ROS, YARP, Orocosand aRD it was shown that aRDx performs excellent in bothextreme performance aspects, namely latency and bandwidth,and partially dramatically outperforms the other frameworks.In addition due to the ”stress” character of our tests we coulduncover a number of severe quirks in all other frameworks.

Running on QNX, aRDx provides hard realtime perfor-mance even for distributed applications.

aRDx is already successfuly in use on our advanced andcomplex humanoid robot Agile Justin. In future publicationswe will describe its other, high level parts, like the dynamicand flexible but less performant communication layer or theadvanced mechanisms for startup and shutdown of largedistributed applications.

REFERENCES

[1] PR2 - personal robot 2. [Online]. Available:http://www.willowgarage.com

[2] M. Quigley, B. Gerkey, K. Conley, J. Faust, T. Foote, J. Leibs,E. Berger, R. Wheeler, and A. Ng, “Ros: an open-source robot oper-ating system,” in Proceedings of the Open-Source Software workshopat the International Conference on Robotics and Automation (ICRA),2009.

[3] icub. [Online]. Available: http://www.icub.org

• highly performant hard realtime communication layer

• radical approach with “One Language for All”

• based on modern “Programmable Programming Language” (Lisp family)

• DSLs

• only small, high performance function in C/C++

• tighter integration with MathWorks toolchain

• automatic generation of Simulink stubs for aRDx blocks

• monitoring and “data mining” with Matlab/Simulink by connecting to any signal at runtime

Conclusions• complex mechatronics systems are demanding wrt software architecture

• distributed sensor, actuator and computing resources

• hard realtime constraints

• agile development flow with highly volatile teams (>50% students)

• -> DLR’s aRD component based and hard realtime communication framework

• tight integration of aRD and Matlab/Simulink/Coder toolchain-> “agile development flow for agile robots”

• highly productive and homogeneous development environment

• from teststand -> complex component -> full robotic system

• controller design in simulation and hardware-in-the-loop

• model based and generation of realtime code (for non-software experts)

• prototyping of whole applications with realtime logic (Stateflow) and non-realtime components: GUI, ... (interpreted Simulink/Matlab)

• -> students do significant research on worldwide most advanced robots with well known Mathworks toolchain -> even classes on our robots

• Future

• pushing distributed computing into hardware (FPGA, HDL-Coder)

• new aRDx: higher performance, Lisp for higher levels, DSLs,tighter intergration with Simulink ->automatic interface (block) generation

Rollin’ and Agile Justin Playing Ball>100 DOF precisely controlled

Documents

Echtzeitanbindung von MATLAB und Simulink an … · Echtzeitanbindung von MATLAB und Simulink an komplexe Robotersysteme in der Forschung ... (Brooks et al. 2005),