Design of an open hardware architecture for the humanoid robot ARMAR

Transcription

1 Design of an open hardware architecture for the humanoid robot ARMAR Kristian Regenstein 1 and Rüdiger Dillmann 1,2 1 FZI Forschungszentrum Informatik, Haid und Neustraße 10-14, Karlsruhe, Germany Regenstein@fzi.de 2 IRF Universität Karlsruhe (TH), Haid-und-Neu-Strasse 7, Karlsruhe, Germany Dillmann@ira.uka.de Abstract. In this paper a new scalable hardware architecture for increased performance and improved human-robot-interaction is presented. The new hardware architecture is based on Digital Signal Processors (DSP) connected by CAN bus to PC/104 systems. Connections between PC/104 systems will be established by a broad bandwidth bus system (e.g. firewire). By this, easy integration of commercially available peripherals like ethernet-, sound- or other I/O-cards is possible. 1 Introduction In contrast to industrial robots a humanoid robot shall interact with human beings in the same workspace. To be able to interact with a human being in a human like way certain sensorimotor skills of the robot are required. For example to achieve smooth and human like movements it is necessary to reduce control cycles on the servo level to a minimum. For safety reasons the humanoid robot must be equipped with a number of different sensors to monitor its state and to avoid collisions with humans or objects in the environment [1]. Further perceptual sensors are needed to allow interaction with the human operator. Recently there is growing interest in humanoid robotics. In this context the Collaborative Research Centre SFB 588 ( Humanoid Robots - Learning and Cooperating Multimodal Robots ) was set up. As preparatory work the humanoid robot ARMAR (Fig. 1) was developed [2] at the FZI Forschungszentrum Informatik Karlsruhe. Within the SFB 588 the humanoid robot ARMAR will be equipped with additional sensors and a new hardware architecture will be developed. 2 Requirements Explicit restrictions on the architecture for a humanoid robot are posed by the limited availability of space. As the robot should operate autonomously the

2 Fig. 1. The humanoid robot ARMAR problem of energy consumption arises. The robot has to carry all its energy resources with him. As electrical energy can not be stored efficiently care must be taken to choose components with a low energy consumption. Viewed abstractly a robot is a data processing machine. It consists of data sources, a data processing device and data sinks. On the side of data sources there is mainly a variety of different kinds of sensors. To mention a few there are for example optical encoders, force torque sensors, microphones, cameras or ultrasonic sensors. This list shows that on the sensory side there are very heterogenous inputs that have to be taken into account when building a hardware architecture. Data processing will be done in some kind of PC or microcontroller. On the hand of data sinks there is the data processing part itself and definitely the actuators of the robot. The actuator part is heterogenous as well. Though in robotics usually electric motors are used for locomotion there still exist different approaches like pneumatic or hydraulic actuation. And even for electric motors different types like brushed or brushless motors do exist. Another aspect that shows how different the requirements of the sensors are is the required bandwidth and cycle time. For example cameras have very high demand concerning bandwidth but the cycle time may be in the area of about 20 ms. Compared to this the bandwidth requirements for actuator control are much lower but the cycle time must be as low as 1 ms. Looking at the topology of a robot i.e. the distribution of available space for data processing it is obvious that in most cases the location of data sources and data processing cannot be in the same place. In detail usually the greatest availability of space in a robot is in the torso or for humanoid robots without legs in their mobile platform. In contrast to this most of the data sources like cameras and sensors for motion

3 control are in the extremities of the robot. Especially fulfilling the computing power needed to process the data of the camera directly in the head of the robot is nearly impossible. A suggestion for a hardware architecture able to deal with these different kinds of sensors will be presented in this paper. Summarizing the requirements there are: hardware architecture must comply with needed computing power scalability modularity standardized interfaces availability of compiler and debug software Especially in humanoid robots there are additional requirements like: energy efficiency small outline lightweight small effort in cabling 3 Architecture A hardware architecture is characterized by its components and the connections between these components. First of all the connection between the components must have a sufficient bandwidth. As the whole architecture shall be able to process data in real time the connection as well has to be able to transmit data in real time. Other requirements are: there should be means to recognize an error in the transmission and the number of nodes should be sufficient. For use in a robot some other aspects are especially important. These are for example a small effort in cabling. This is important because a thick cable harness would constrict the movement of the actuators. Ideally there would only be a pair of wires for power supply and another pair for commanding the actuators. Evaluating the needed bandwidth for servo control in a humanoid robot it is obvious that it can be dealt with one or more CAN buses. CAN bus was chosen because of its characteristics i.e. it can transmit messages in realtime, in other words the message with the highest priority will be delivered within a guaranteed latency time. Other important properties of CAN are: bandwidth up to 1 MBit/s: in a humanoid robot this is sufficient to control 5 to 10 axes (e.g. one arm of the robot) differential data transmission: this is important to reduce effects of EMI caused by the electric motors large number of nodes error recognition: CAN protocol implements several means to recognize errors like bit stuffing and CRC. physical length of connection: at 1 MBit/s cabling can be up to 40 m long. This length will not be exceeded in a humanoid robot.

4 availability: CAN bus is approved in the automotive industry, so highly reliable components are available. The presented hardware architecture (Fig. 2) is structured as follows: Microcontrollers or DSPs are responsible for control and sensor value acquisition. These are connected to a more powerful data processor like a PC via a bus system [3][4][5]. On the servo control and sensor data acquisition level CAN-bus and Motorola DSPs [6] are used. Every DSP-board is responsible for controlling two Fig. 2. Structure of the hardware architecture electric motors. For each motor both the revolution speed of the motor and the angle of the driven axis will be measured. Further the motor current will be

5 supervised and can be used for implementing torque control. The servo control will take place in the DSP while position requests are received via CAN-bus. As well current encoder values are sent back to higher control level via CANbus. The optional middle layer is intended to group several DSP into a unit. For example having two CAN-busses controlling one arm of the humanoid robot one could combine them using a device of the middle layer. The middle layer is introduced to enhance the scalability of the architecture and to map the modularity of the robot onto the hardware architecture. The connection between the components of the middle layer on the one hand and the connection to the PC layer will be established by firewire. On the PC layer PC/104 systems will be used because of their small size and low energy consumption. As well there is a great variety of additional modules for PC/104 systems like CAN-bus, firewire, wireless LAN or PCMCIA cards. The connection between the PC devices will be established via firewire for real time critical transmissions and via ethernet for other transmissions. Also a link to PCs in the laboratory outside the robot will be provided by wireless LAN. The scalability and modularity of the presented hardware architecture is fulfilled by dividing the architecture into three layers. Depending on the number of sensors and the bandwidth needed more CAN-buses can be added and joined in the middle layer. The number of devices in the middle layer can also be adapted to the required computing power and the desired number of modules. Modules that can be identified in a humanoid robot could be: right arm, left arm, torso, platform and head. To enhance the computing power the number of PCs on the PC layer can be increased. With CAN bus and firewire well standardized interfaces were chosen to be compatible with most components. For Linux and RT-Linux free compiler and debug software is available. In terms of energy consumption the chosen PC/104 systems are suitable to be used in a mobile robot. 4 Realization We started to realize the presented concept by building the motor driver board. The driver board will consist of a power stage that can be plugged into a DSP board. Following requirements must be met by the driver board: control of motor revolution speed control of angle of the driven axis (e.g. elbow joint) measurement of the motor current connection to the CAN-bus These demands are meant per axis. As the power stage is designed to control two axes the DSP board must be capable of supplying the necessary I/O ports to measure these values. To keep the DSP board flexible we decided to use a Motorola DSP in connection with a Field Programmable Gate Array (FPGA). Thus the required number of I/O ports can be achieved. To disburden the DSP the counter for measuring the revolution speed and angle of axis will be realized

6 Fig. 3. Image of one motor driver board capable of powering two motors in the FPGA. The board will be equipped with the Motorola DSP56F803. The size of the power stage is only 55 mm x 60 mm. 4.1 Initialization Phase In the startup phase all motor driver boards must receive a unique ID by which they can be identified by the software running on the PC layer. A dynamical distribution of IDs is implemented to avoid that swapping a defective board requires reconfiguring the whole system. With this distribution also the order of the boards can be recognized. To accomplish this, besides the CAN-bus a further init-line is needed. The idea is to have two dedicated I/O pins on every driver board: one init-in and one init-out pin. By default all these pins are pulled up by a resistor. To start the distribution of the IDs the init-out pin of all boards is pulled to low so that only the first board in the line has a high input at its init-in pin. By this the first board is identified. To identify the last board in the line a similar procedure is applied, this time the init-out pin is set back to high and the init-in pin is pulled low thus leaving only the init-out pin of the last board at a high level. In the next phase boards are assigned ascending numbers by sequentially pulling the init-out pins to low. The number that the board is assigned that receives a low level at its input is transmitted via CAN-bus. 4.2 In-System Programming To ease development of prototypes [7] a possibility to program the driver boards inside the robot via CAN-bus has been implemented. So far it is possible to program the flash memory of a DSP via CAN-bus. The advantage of programming the DSP via CAN-bus over serial programming is that it is not necessary to plug a programming adapter into each DSP if a new software version is to be programmed. Downloading different software to each DSP is as well possible as downloading the same software to several DSPs at once.

7 5 Conclusion and further work In this paper an open hardware architecture for the humanoid robot ARMAR was discussed. It allows easy integration of different kinds of sensors and offers the possibility of further extension. Further work includes applying the new hardware architecture to the successor of ARMAR and integrating new sensors into the robot. For example force torque sensors will be integrated into the wrists of ARMAR II. Furthermore an analysis of the proposed hardware architecture will be conducted. 6 Acknowledgement This work is supported by the German Research Foundation (DFG) within the Collaborative Research Centre SFB 588 Humanoid Robots - Learning and Cooperating Multimodal Robots. References 1. J. Martin, R. Keppler, D. Osswald, W. Burger, K. Regenstein, G. Bretthauer, J. Wittenburg, H. Wörn, A. Albers, and K. Berns. Mechatronische konzepte zur verbesserung der mensch-maschine-interaktion. In Human Centered Robotic Systems, T. Asfour, K. Berns, and R. Dillmann. The humanoid robot ARMAR: Design and control. Int Conference on Humanoid Robots, G. Hirzinger. On a new generation of torque controlled ligth-weight robots. In Proceedings of the 2001 IEEE International Conference on Robotics and Automation, Kazuo Hirai. The development of honda humanoid robot. In Proceedings of the 1998 IEEE International Conference on Robotics and Automation, M. Wargui. Application of controller area network to mobile robots. In Electrotechnical Conference, MELECON 96., 8th Mediterranean, pages , Motorola. Data Sheet for Motorola DSP56F803, K.-U. Scholl, V. Kepplin, J. Albiez, and R. Dillmann. Developing robot prototypes with an expandable modular controller architecture. In Proceedings of the International Conference on Intelligent Autonomous Systems, pages 67 74, Venedig, June 2000.