HIL/SIL BY DEVELOPMENT OF SIX-LEGGED ROBOT SLAIR2

HIL/SIL BY DEVELOPMENT OF SIX-LEGGED ROBOT SLAIR2 DZHANTIMIROV 1, PALIS 2, SCHMUCKER 1, TELESH 2, ZAVGORODNIY 2 1 Department Virtual Engineering, Fraunhofer Institute for Factory Operation and Automation, Sandtorstrasse 22, 39106 Magdeburg, Germany 2 Institute for Electrical Energy Systems, University of Magdeburg, Universitätsplatz 2, P.B. 4120, 39106 Magdeburg, Germany The development process of CLAWAR is a complex task. The Hardware- and Softwarein-the-Loop frameworks, which are used by development of new 22 DoF six-legged robot SLAIR2 are presented. A novel universal real-time communication bridge system is introduced and test results are presented. The ability to real-time communication and service tasks related control of the robot is discussed. Keywords: Embedded and Real Time Systems, Modelling and Simulation Languages, Automatic Code Generation. 1. Introduction The control system of the full or part of autonomous legged robot is almost controlled by embedded system. Commonly the embedded systems are designed to control complex plants such as engines, satellites, vehicles, spacecrafts, and of course CLAWAR. They generally require a high level of complexity within the embedded system to manage the complexity of the plant under control. Development and test of complex real-time embedded systems consists of many steps from modelling and simulation of the plant till the implementation of the source code in the real hardware. Hybrid techniques, that are used increasingly, are the Hardware-in-the-Loop (HiL) and Software-in-the-Loop (SiL) simulations (see Fig.1). In our work we use these methods within the development and testing process of six-legged robot. The embedded system (i.e. real electronic control device or real mechatronical component) within a HiL-framework is connected to corresponding HiL-simulator (which emulates real system response) via its IOs building a closed loop. The system to be controlled (i.e. legged robot) is then simulated to test the correct performance of the control system (i.e. drive control). The inputs of control system under test are stimulated with the modelbased sensor outputs. To close the control loop is the reaction of the control system outputs (i.e. motor voltage) guided back into robot model. 1

2 controller object Computer Aided Control Engineering (MATLAB/Simulink, etc.) Physical simulation (Vortex,ODE) VR virtual I - simulation SIL HIL II - test controller (, SPS, MC, DSP) object real III - operation Figure 1. Common scheme of the HiL/SiL structure of the mechatronical system. In the pure simulation phase a virtual control system is connected to a virtual object. Both software systems communicate via pure software interface. In the hybrid simulation phase for such communication a hardware interface needed. The development process is through communication inconsistence more complex and needs more effort to transfer of results [5]. And moreover with the change of communication interface is even more effort to expect. The paper presents the developed six-legged robot SLAIR2 [3] as well as the environment, which was used in the pure simulation phase and the hybrid HiL/SiL phase by development and test separate robot components. Moreover the flexible communication bridge for real-time communication between the virtual/real control system and the virtual/real robot is presented as well. 2. Modular Six-Legged Robot SLAIR2 Figure 2 represents the multi-legged robot with articulated body SLAIR2 that has been developed at the Fraunhofer Institute for Factory Operation Ottovon-Guericke University both from Magdeburg in Germany [4]. The robot mechanics, sensor system and control system make it possible to maintain the additional flexibility in the body, to measure and control the support reactions as well as to control and forecast the robot motion stability.

3 Figure 2. Modular six-legged robot SLAIR2 : CAD and real implementation. 2.1. Mechanics and Sensor Systems The robot construction consists of n = 3 modular segments (shoulders) linked to each other through two DOF joints and 6 legs. Each shoulder includes one articulated body segment linked with two 3-DOF-insectomorphic legs. It is possible to extend the construction to the case of n > 3 shoulders. The main mechanical parameters are shown in the Table 1. The robot drives are servomotors, with maximal power PDC = 4. 5 W, with potentiometer with o angular range ϕ POTI = ±90 and gears with ratio i GEAR = 251 and efficiency η = 85%. GEAR Table 1. The main mechanical parameters of the robot leg lengths total: l LEG = 300 mm thigh: l 1 = 120 mm shank: l2 = 180 mm body dimensions total robot mass maximal speed max power consumption total length: l B = 660 mm segment length: l BS = 220 mm m ROBOT = 3,20 kg V ROBOT = 1 km/h P MAX = 90 W The sensor system of the robot consists of components that are standard for mobile robots and that make it possible to achieve autonomous robot functions in an environment. It includes: 22 potentiometers and 22 current sensors (installed in each robot joint), 6 three-component force sensors (mounted in each leg s shank), 2-axis gyroscopic sensor (located in body), and

4 further it will be equipped with near navigation sensor system (stereoscopic camera). In accordance with the requirements on measurement and control of the support reactions, the developed force sensor consists of two parts: the core measuring lateral components of support reaction, and the elastic parallelogram module for measurement of the longitudinal component. The sensor is designed for loadings up to FCONTACT = 50 N; interference between channels does not exceed 1%. 2.2. Control System und Control Structure The hierarchically organized modular control structure (Fig.3a,3b,3c) is completely located on -side that implement additionally the interaction with user and produces the control signal for robot drives as well as monitors all actuators and sensors of the robot. The robot-side is implemented by fast and flexible FPGA, includes the hardware abstraction layer (HAL) for drive and sensors. The real-time connection between two parts is made via proposed [1] based communication bridge described below. All this provides flexibility and simplifies the development of control algorithms. The control system can also be extended for the additional shoulders in exactly the same manner as the mechanical structure. Figure 3a. The hierarchically organized robot control system: action level

5 Figure 3b. The hierarchically organized robot control system: primitive level Figure 3c. The hierarchically organized robot control system: servo level 3. NetX Communication Bridge and its implementation in Matlab/Simulink Environment The communication bridge emulates a router, which connects the control system with all the components of the control object (i.e. legged robot). These components can be connected to the bridge via diverse bus systems (Ethernet, CAN, UART, SPI etc). The robot components in such system can also be represented in virtual environment. Through a common physical interface is the virtual or real control system isolated from the object, and therefore the development effort of communication interface to the legged robot is reduced. The output signals from the control system (reference signals) are demultiplexed and sent to corresponding actuators with the help of the communication bridge. On the other side the outputs from the robot (actual

6 sensor signals) are multiplexed by bridge and sent to the control system. These routing tasks are entirely performed by the communication bridges. The physical implementation has been done using ARM9-based - SoC [1], which is able to communicate with all well known fieldbus and real-time Ethernet systems. Figure 4 represents the proposed flexible communication system based on communication processors. full duplex full duplex full duplex com0 com0 com1 com0 com1 com0 com1 Host- A B C DPRAM DPRAM DPRAM FPGA FPGA FPGA Figure 4. Flexible communication system based on processors. The parameterisation of the communication bridge takes place in control program of embedded ARM processors. This program can be compiled with conventional tools, but in order to simplify the reconfiguration of the bridge within simulation framework the programming via RTW and GUI in Matlab/Simulink was selected. For these purposes a special software stack (s.fig.5) was developed and the communication bridge was integrated into Matlab/Simulink framework (s. Fig.6) under Real-Time Workshop [2]. Figure 5. Software Ethernet communication stack implemented in Matlab/Simulink.

7 Figure 6. Integration of based communication system into Matlab/Simulink. This framework allows convenient development and HiL/SiL tests of the control system and generation of the application code for the target processors under Matlab/Simulink environment only (s.fig.7). Figure 7. HiL/SiL structure by development of six-legged robot SLAIR2 4. Test of the NetX based Com Bridge in Real Six-Legged Robot For the execution of the communication tests a soft and a hardware configuration have been suggested, which represents the SiL - application. The

8 hardware part of the test platform consists of a host and two units. The units are interconnected via serial communication chain. The communication is implemented in full duplex mode, whereby simultaneous sending and receiving of the packets are possible. The task of the host is in the periodic sending of request and the collecting of all response packages in the same communication cycle with all units (s.fig.8) Host Request for A A Host Request for B A B Master Slave Master Slave Slave Host A Reply from B B Host Reply from A A Master Slave Slave Master Slave Figure 8. Data flow within communication cycle between Host- and chain. The packets are led to and from the second unit B over the first unit A. In order to reduce the turn-around time of the those Ethernet frames, whose goal MAC address does not agree with the own MAC address of the current unit, the first unit A functions in the so-called switch mode. To test purposes the response time of units is interesting, which corresponds to the performance of the program generated by the RTW, as well as the entire cycle time for the operation of the chain with the Simulink model, running at the host. To check the performance of the whole system the forward and backward communication flow with distributed control units have been used (s.fig.9). Host- A B Request A Request B working time Switch-delay Reply A working time Reply B Host- A B Request B Switch-delay Request A working time working time Reply B Reply A Cycle time difference Figure 9. Forward and backward communication sequence with 'A' and 'B'

9 The timing measurement is accomplished in certain places over GPIO exits and observed thus at the oscilloscope (s.fig.10). The measurement shows the incoming and processing times of the request packages for both units. Figure 10. Packet incoming and processing time for 'A' and 'B' The test results (table 2 and 3) show the maximum cycle rate of about 3 khz for the presented test system. Table 2: Network monitor records by 'direct' communication ( - A - B) A out B out A in B in A out...a in B out...b in A out...b in 0000000 0000066 0000200 0000293 200 227 293 1016545 1016638 1016747 1016863 202 225 318 2016530 2016593 2016727 2016819 197 226 289 3016509 3016570 3016706 3016794 197 224 285 4016503 4016589 4016701 4016826 198 237 323 5016486 5016570 5016684 5016802 198 232 316 Average runtime: T Bround /T Around /T round 199 229 304 Table 3: Network monitor records by 'inverse' communication ( - A - B) B out A out B in A in B out...b in A out...a in B out...a in 0000000 0000100 0000228 0000297 228 197 297 1011693 1011764 1011926 1011958 233 194 265 2011657 2011729 2011883 2011927 226 198 270 3011631 3011720 3011850 3011910 219 190 279 4011627 4011697 4011860 4011888 233 191 261 5011598 5011666 5011833 5011853 235 187 255 Average runtime: T Bround /T Around /T round 229 193 271 The cycle times for separate units let estimate the switch turn-around time of approximately 15-18 µs, whereby the pure transmission time of 100 byte

10 package via 100 Mbit/s Ethernet is about 10 µs. This indicates the fact that the passing package is completely buffered by the switch. The source code generated by the RTW for the units is not optimal concerning to the response time. Therefore the additional manual optimization of this source code allows the reduction of the cycle time from about 270 µs down to 90 µs. References 1. http://www.hilscher.com Hilscher GmbH, Hattersheim, Germany 2. http://www.mathworks.com/products/rtwembedded/ 3. http://www.uni-magdeburg.de/ieat/robotslab 4. F.Palis, V.Rusin, U.Schmucker, A.Schneider, Y. Zavgorodniy. Legged Robot with Articulated Body in Locomotion over Complex Terrain. 7th Int. Conference on CLAWAR, 22-24 September 2004, Madrid. 5. F. Kanehiro et.al. Distributed Control System of Humanoid Robots based on Real-time Ethernet. IEEE/RSJ Int. Conference on Intelligent Robots and Systems, 9-15 October 2006, Beijing