echtzeitanbindung von matlab und simulink an … · echtzeitanbindung von matlab und simulink an...
TRANSCRIPT
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]
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
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
torso JC (3x) 0.3ms dev TC
1ms PC
1ms ipol 3ms
invkin 6ms
cartesian impedance
1ms state
machine
arm JC (7x) 0.3ms dev AC
1ms
hand JC (3x4x) 1ms dev FC (4x)
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
…
Monitoring Configuration
torso JC (3x) 0.3ms dev TC
1ms PC
1ms ipol 3ms
invkin 6ms
cartesian impedance
1ms state
machine
arm JC (7x) 0.3ms dev AC
1ms
hand JC (3x4x) 1ms dev FC (4x)
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 !
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
“agile Robot Development” (aRD) Framework
aRDnet-suite: lightweight (~3000 lines)
• aRDnet-library (C/C++): implementation of block’s ports
• 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
…
Monitoring Configuration
torso JC (3x) 0.3ms dev TC
1ms PC
1ms ipol 3ms
invkin 6ms
cartesian impedance
1ms state
machine
arm JC (7x) 0.3ms dev AC
1ms
hand JC (3x4x) 1ms dev FC (4x)
1ms ipol 1ms
invkin 1ms
collision avoidance
3ms
Linux
Linux Linux
Linux
VxWorks
VxWorks
QNX
Linux/ Windows
hand dev
REALTIME
CPU 1 CPU 2
“agile Robot Development” (aRD) Framework
aRDnet-suite: lightweight (~3000 lines)
• aRDnet-library (C/C++): implementation of block’s ports
• 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
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
…
Monitoring Configuration
torso JC (3x) 0.3ms dev TC
1ms PC
1ms ipol 3ms
invkin 6ms
cartesian impedance
1ms state
machine
arm JC (7x) 0.3ms dev AC
1ms
hand JC (3x4x) 1ms dev FC (4x)
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
Monitoring Configuration
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
Monitoring Configuration
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
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”
• 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
Monitoring Configuration
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
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”
• 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
Integration of aRD and Matlab/Simulink Toolchain:Implementation and Usage
• S-Function stub block as mirror of an aRD-block
• user only provides translation function from aRD packet to Simulink signals
• Simulink model can be synchronized on arriving aRD packets
• 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
Monitoring Configuration
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
Integration of aRD and Matlab/Simulink Toolchain:Implementation and Usage
• S-Function stub block as mirror of an aRD-block
• user only provides translation function from aRD packet to Simulink signals
• Simulink model can be synchronized on arriving aRD packets
• 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: 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.
High Level Controlusing Stateflow
Low Level Controlusing Realtime Workshopwith VxWorks target
Examples: Brain-Machine-Interface (BMI)Matlab/Simulink/Stateflow Realtime/Non-Realtime
realtime: Simulink/Coder
non-realtime: interpreted Simulnik
part of application logic
non-realtime interpreted Simulink (snippet):monitoring, GUI-elements, logic
Examples: Brain-Machine-Interface (BMI)Matlab/Simulink/Stateflow Realtime/Non-Realtime
stub for realtime model
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