When Hard Realtime Matters: Software for Complex Mechatronic Systems - - PowerPoint PPT Presentation

▶
when hard realtime matters software for complex
SMART_READER_LITE
LIVE PREVIEW

When Hard Realtime Matters: Software for Complex Mechatronic Systems - - PowerPoint PPT Presentation

Apr 30, 2023 587 likes •851 views

When Hard Realtime Matters: Software for Complex Mechatronic Systems Berthold Buml and Gerd Hirzinger Institute of Robotics and Mechatronics DLR German Aerospace Center berthold.baeuml@dlr.de Dokumentname > 23.11.2004 Mechatronic

slide-1
SLIDE 1

Dokumentname > 23.11.2004

When Hard Realtime Matters: Software for Complex Mechatronic Systems

Berthold Bäuml and Gerd Hirzinger

Institute of Robotics and Mechatronics DLR – German Aerospace Center berthold.baeuml@dlr.de

slide-2
SLIDE 2

Dokumentname > 23.11.2004

Mechatronic Systems

  • “Mechanics in the loop”
  • demands hard realtime

(= short latencies and determinism)

  • to prevent injury and damage !
slide-3
SLIDE 3

Dokumentname > 23.11.2004

New Level of Complexity

  • complex single robotic component

(DLR-Hand-II: 13DOF, 100 sensors)

  • compound systems with tightly interacting parts

(Justin: 43 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

  • Heterogenous team of experts developing software (~ 10 members)
  • Iterative, flexible and adaptive development flow (esp. for research prototypes)

Challenges:

  • “modern” software paradigms for complex systems:
  • modularity (“component based software engineering”)
  • concurrent execution (“services”)
  • distributed execution (“multi core, multi CPU, networked clusters”)
  • but under hard realtime constraints.
slide-4
SLIDE 4

Dokumentname > 23.11.2004

“Decentral net of functional blocks and communication links”

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

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

slide-5
SLIDE 5

Dokumentname > 23.11.2004

Robot Middleware

ORCA (Brooks et al. 2005) MARIE (Cote et.al. 2004) MIRO (Utz et al. 2002) Player (Vaughan et al. 2003) used in mobile robotics soft realtime in the 100Hz range MS Robotics Studio (msdn.microsoft.com/robotics WindowsXP -> non realtime, WindowsCE ? OROCOS (www.orocos.org) hard realtime, >500Hz for two 6DOF arms more complex systems, distributed computation ? OpenHRP (Kanehiro et al. 2004) RT-Middleware, based on CORBA in applications hard realtime part in monolithic modules with proprietary communication MCA (www.mca2.org) used in humanoid robots ARMAR hard realtime on one node, but TCP/IP YARP (Metta et al. 2006) used in complex robots like “Domo”, but there the hard realtime parts run on DSP boards supports QNX and based on ACE -> distributed hard realtime execution possible ? MIRPA hard realtime, distributed execution performance when many DOF ?

slide-6
SLIDE 6

Dokumentname > 23.11.2004

Pragmatic Approach

  • None of the existing middleware concepts seemed to fit our main needs:

hard realtime, scalable computing resources, easy to use.

  • How far can we go, when doing it as simple as possible ?
  • 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: eg. switched Ethernet or P2P links

No !

slide-7
SLIDE 7

Dokumentname > 23.11.2004

Pragmatic considerations

What is essential ?

  • deterministic, concurrent execution
  • fast, deterministic communication
  • standarized interfaces for communication
  • mechanisms for system configuration, startup and shutdown

and what is not ?

  • dynamic reconfiguration at runtime
  • higher levels of abstractions (e.g abstract “range sensor”)

What can we get from a realtime OS ?

  • Processes
  • Shm on one PC
  • Fast, deterministic drivers to (multiple) network cards

What has to be done ourselves ?

  • standardized interfaces
  • abstraction of distributed communication
  • system handling
slide-8
SLIDE 8

Dokumentname > 23.11.2004

1.

aRDnet-suite: lightweight (~3000 lines)

  • aRDnet-library (C/C++): implementation of block’s ports
  • ardnet block: bridge between blocks on different PCs

Implementation of aRD-concept (“agile Robot Development”)

slide-9
SLIDE 9

Dokumentname > 23.11.2004

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

slide-10
SLIDE 10

Dokumentname > 23.11.2004

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

slide-11
SLIDE 11

Dokumentname > 23.11.2004

1.

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 for communication

2.

Matlab/Simulink-toolchain

  • standard tool for control design
  • Automatic code generation with RTW
  • Parallelizing with RTLab from OpalRT (www.opal-rt.com)
  • stubs for interfacing aRDnet-blocks

Implementation of aRD-concept

slide-12
SLIDE 12

Dokumentname > 23.11.2004

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

slide-13
SLIDE 13

Dokumentname > 23.11.2004

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

slide-14
SLIDE 14

Dokumentname > 23.11.2004

1.

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

2.

Matlab/Simulink-toolchain

  • standard tool for control design
  • Automatic code generation with RTW
  • stubs for interfacing aRDnet-blocks

Key decision: QNX for realtime and Linux for non-realtime (limited support for VxWorks and Windows)

Implementation of aRD-concept

slide-15
SLIDE 15

Dokumentname > 23.11.2004

  • 1. send
  • 4. rec

QNX

Performance:

QNX-PC with Core2Duo, 2.8GHz roundtrip of packet of 1kByte size between two standalone blocks

  • n one QNX-PC: 20us in worst case
  • n two QNX-PCs with ardnet-bridge (UDP) over P2P 1GB-Ethernet link:

200us in worst case (160us on average)

  • 1. send
  • 4. rec

QNX

  • 2. rec
  • 3. send

QNX

e t h I P I P e t h

1GBit / UDP

aRDnet performance

slide-16
SLIDE 16

Dokumentname > 23.11.2004

QNX

Performance: High Rate

Simulink-HIL-setup: reading analog values and writing them to harddisk

  • Rates > 50 KHz without drop-outs possible
  • At 30 KHz system overhead is less than 10 % cpu-time

AD HD

world

slide-17
SLIDE 17

Dokumentname > 23.11.2004

Applications: (July 2005) Preliminary study for Two-Hand-Arm-System

slide-18
SLIDE 18

Dokumentname > 23.11.2004

hand dev VxWorks/Intel

I P e t h e t h I P e t h

hand dev VxWorks/PPC

I P e t h e t h I P e t h

arm dev VxWorks/PPC

I P e t h e t h I P e t h

arm dev VxWorks/PPC

I P e t h e t h I P e t h

control 1ms Windows

I P e t h

Linux

I P e t h

Debug Monitor Profile switch

e t h I P e t h I P

(from VxWorks) QNX

1kHz 1kHz 1kHz 1kHz

slide-19
SLIDE 19

Dokumentname > 23.11.2004

Applications: (May 2006) Two-Hand-Arm-Torso Justin

slide-20
SLIDE 20

Dokumentname > 23.11.2004

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 QNX Linux/ Windows REALTIME arm dev hand dev

CPU 1 CPU 2

slide-21
SLIDE 21

Dokumentname > 23.11.2004

vision world model dev camera GUI EC path planning dev input device 3D viewer state machine hand dev Linux Linux Linux Linux QNX Linux/ Windows REALTIME hand dev torso dev arm dev VxWorks arm dev VxWorks

slide-22
SLIDE 22

Dokumentname > 23.11.2004

Two-Hand-Arm-Torso Justin

slide-23
SLIDE 23

Dokumentname > 23.11.2004

Applications

  • Two-Hand-Arm-Torso Justin
  • Virtual reality with haptic feedback
  • Telepresence/Telemanipulation
  • Medical robotics
  • Brain/Muscle-Interface-Group
  • Teststands
  • Finger
  • Arm
  • Micro-surgical devices
  • …
  • Dynamics simulators
  • Ball catching
  • …
  • …

~ 15 “aRD-seats” at our intsitute

slide-24
SLIDE 24

Dokumentname > 23.11.2004

Conclusions

  • hard realtime is a must, when mechanics is in the loop
  • increasing complexity of mechatronic systems demands for modern

software concepts also there, namely: modularity, concurrent execution, distributed execution

  • an “operating system for robotics” has to provide hard realtime
  • ur pragmatic and lightweight aRD concept proved the feasibility even on

“cheap” PC based computing hardware by

  • introducing only a thin layer of abstraction above the realtime OS
  • allowing to configure the QoS of all communication

Hope, that a perfect operating systems for robotics will emerge soon, so that we can again work on that, what roboticists love to do …

slide-25
SLIDE 25

Dokumentname > 23.11.2004

Justin Serving Tea …