IROS2019国际学术会议论文集A Ring Network Protocol for Articulated RobotsVIP

Abstract Articulated robots such as the humanoid robot often have multiple joints implemented in its limbs. It is common for sensor and controller cables to be routed inside of the limb, impacting mobility. A network protocol with high efficiency, low latency, fault tolerance is needed to facilitate communication of sensor and controller data over a more compact communications channel. In this paper, we propose a ring network protocol with fault tolerance in low latency, high efficiency communication over a compact channel. The performance of the proposed network protocol was verified in simulation and experiment, showing that low latency, high efficiency, and fault tolerance can be achieved over a single communications channel. I. INTRODUCTION To achieve complicated tasks in a narrow environment, articulated robots such as a humanoid robot have been attracting a lot of attention for several decades. It is suitable for moving in diverse environments 3 12. It is required to control many components on the articulated robot such as joints. When the articulated robot is operating in a real environment, there are many cases where the robot contacts with the environment presents fatal problems for the robot. In addition, a problem may occur in the firmware of each control device, making joints unable to move. In such a case, the system usually gets stuck because it cannot generate whole body motion, and in the worst case the robot may fall over and get damaged. However, a multi-legged robot with multiple limbs can use other limbs even if one limb fails. By this, the robot can continue to achieve its tasks using its remaining movable limbs. For example, if one hand cannot be operated during a manipulation task, the task can be completed by using the other hand. Moreover, if a failure occurs in the distributed control device that drives the ankle joint in a biped robot, it can be recovered by a system reset. In addition, along with miniaturization of sensors such as cameras and 3D distance sensors, multiple external sensors have been mounted at the tip of each limb to measure the state of the working environment. To transfer such data, low latency is not required as with joint angle and force data. In any failures, it is necessary to maintain a stable state by performing recovery operations or degeneracy operations. It is thus desirable to keep controlling as many joints as possible. Therefore, it is necessary to be able to reset only an abnormal device rather than the whole limb. In this paper, we propose a 1 Honda Research Institute Japan Co., Ltd, FORESTHILLS EASTWING 1F, 4-18-11, Minami-aoyama, Minato-ku, Tokyo, Japan, ryusuke_ishizakin.f.rd.honda.co.jp 2 Honda R&D Co., Ltd 8-1 Honcho, Wako, Saitama, Japan new protocol with fault tolerance that allows data requiring broadband to transmit on the same communication line while guaranteeing low latency for control data. II. RELATED WORK There are several types of communication networks used in modern articulated robots. Table I shows a comparison of several networks implemented in modern systems. The Multipoint Low Voltage Differential Signaling (MLVDS) used in Valkyrie 1 and the Controller Area Network (CAN) used in HRP-4C 2 are bus type networks. This network is good for saving the number of wire to realize slim joint, but not suitable for high-speed communication because it is difficult to match the impedance of the wiring. On the other hand, the ring network uses only two cables, but since it is connected point-to-point between nodes, impedance can be easily matched so it is suitable for high-speed communication. We thus employ a ring network for our robot. TABLE I. COMPARISON OF NETWORK PROTOCOL ContentsHondaMLVDS / CAN EtherCATARCNETResponsive Link SERCOS TopologyRingBusRingRing, BusFree(p2p)Ring Wire saving 2:opt fiber 2 2 8:CAT5 4:twist pair 2 8 8:CAT5e Latency 75u16node Rate 1Gbps 100Mbps 100Mbps 5Mbps 500Mbps 16Mbps Efficiency 99.2%:Any node, Any time Master-slave Master-slave Token-Passing Master-slave Master-slave Fault tolerant (CPUReset if hung-up) INTP Fault tolerant (Degeneracy if wire break) Detection of abnormal part Impedance cant be match Loopback ： Ring : Bus Impedance cant be match if multiple connection Concerning performance in low latency and high efficiency, EtherCAT 6 is used in Robosimian 3, Hydra 4, TALOS 5, Walk-Man 14, etc. to communicate within low latency. However, it uses a Master-Slave method, every node cannot send data without an instruction from the Master module. In addition, communication timing is considered when some nodes are added. On the other hand, ARCNET 7 has a Token-Passing method which the transmission right is necessary to avoid data collision. By this reason, it consumes time. As a result, latency may increase, so the system may not be able to be controlled in real time. Responsive Link 8 is proposed by Yamazaki et al. which has dedicated lines for real time communication to ensure high performance, but these dedicated lines use many wires. Although SERCOS II 10 A Ring Network Protocol for Articulated Robots Ryusuke Ishizaki1, Takeshi Misumi2 and Takahide Yoshiike1 2019 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS) Macau, China, November 4-8, 2019 978-1-7281-4003-2/19/$31.00 2019 IEEE3882 used in DLR TORO 9 can communicate with low latency, the packet header overhead is large since it uses a packet conforming to Ethernet. Therefore, it is difficult to improve efficiency. In addition, due to data collisions occur by CSMA/CD 11, a network node retransmits data at random times, so the latency cannot be guaranteed. CHIMP 12 can reboot the power supply modules on each limb and is designed to be aware of fault tolerances. However, it is desirable to be able to recover on a node-by-node basis. To achieve complicated tasks, the protocol must have both low latency and high efficiency and with a fault tolerance function, which can be applied to the wire-saving ring type network. We target as following functions, Improvement of protocol performance in low latency and high efficiency A fault tolerance on the articulated robot This paper is organized as follows: Section III shows a new network protocol compatible with low latency and high efficiency, Section IV presents a fault tolerance function, Section V describes implementation and evaluation of new protocols. Finally, this paper concludes in section VI. III. NETWORK PROTOCOL In this section, we propose a new protocol for ring networks in low latency and high efficiency. The core concept is as follows: A) a communication method which any node can transmit at any time without any data collision, B) a packet format with low overhead and two types of packet (data packet for normal data transmission, and interrupt packet that guarantees in hard real-time), C) on the fly processing as packets pass through nodes. A. Design of Communication As described in the previous chapter, the Token Passing method or the Master-Slave method have been used in the ring type network. Each node cannot transmit data unless there is a Token or a command from the master. Thus, the latency increases while the efficiency is decreased. For example, as shown in Fig. 1 (b), since there are lines that do not have Token or data in the Token Passing method, the network efficiency is degraded. If there is a mechanism that all nodes can transmit at any time without transmission right, network efficiency can be improved. In addition, since each node does not need to wait for the arrival of the transmission right, it also leads to a reduction in the latency required for transmission. Therefore, we propose a communication method that allows packets to flow simultaneously on all lines between network nodes. Fig 1 (a) shows the structure of the network controller (NC) for realizing the communication method. It consists of the following main four blocks. Relay block: Bypass data externally input. Discard the packet sent by its own node. Increment HOP value of the packet header Transmit block: Send data by command from CPU of own node Packet Manager block: Switch data to be output for data input from Relay block and Send block Receive block: Interpret whether it is a packet addressed to its own node then receive or discard it Since each network node operates asynchronously, there is a possibility to overlap the timing of relaying the data sent by other nodes and the timing of its own sending out. Currently, both of data collide and then corrupt. To prevent this, the Packet Manager has a function of sending out the previously inputted data preferentially, buffering the other data until the priority packet passes through, and sending it after passing. Node A Node D Node C Node B (a). Our Approach (Anytime, Anynode) Relay Transmit CPU Packet Manager Network Controller Receive Network Node Packet from D Packet from C Packet from A Packet from B Node A Node D Node C Node B T Token （Free） Token (Received) Transmit to D Receive Token （Free） (b). Coventional Method (Token Passing) Packet from B Input Packet Output Packet Node A Node D Node C Node B T Node A Node D Node C Node B Node A Node D Node C Node B T T Figure 1. New communication method for the ring network Also, when inputting at the same time, we decided to prioritize the Send part. This is to prevent the transmission latency of the own node from being greatly increased when relay data is continuously input. Therefore, even if all nodes simultaneously transmit data, all lines can be efficiently used without data collision. B. Implementation of two types of packet with low overhead To prevent increasing latency in packet generation and decreasing efficiency due to packet overhead, we designed packet structures to be as simple as possible. However, in the past, it was not possible to guarantee real-time processing 3883 because of the large communication load, so the communication line was separated 8. But it is difficult to reduce the number of wires. It is desirable to be able to communicate joint control data requiring real-time property and data requiring broadband although it is unnecessary to real-time like external sensor data on the same network line. Therefore, to realize a network in low latency and high efficiency, we designed two types of packets: data packet for normal data transmission and interrupt packet to trigger other nodes with low latency. Due to the size of overhead, the communication efficiency can be low. Therefore, we designed a packet format in which the header, trailer, CRC are only 32 bits each. The structure is shown in Fig. 2. The header and the trailer are each divided into four fields. The header and trailer of the data packet and interrupt packet are identical except for the last field of the trailer. By setting destination ID (DID field located in the trailer) to 0 xff, it becomes a broadcast packet received by all nodes. 1) Data Packet (DATP) Data packet (DATP) is used for transferring normal data. There are four levels of priority in the data packet (PRI field located in the trailer of the data packet), and transmission / reception processing is performed in order of priority. Joint control data can be sent with top priority and external sensor data with low priority. Header CodeSOPHOPSID Data (1512byte)TrailerCRC EOPFBCDIDPRI Start of Packet Number of Hopping Source ID Free Buffer Counter Destination ID Priority (4 levels) End of Packet (a). Data Packet (DATP) Header CodeSOPHOPSID TrailerCRC EOPFBCDIDINT Number of Interrupt Factor (8 factors) (b). Interrupt Packet (INTP) Figure 2. Packet Format 2) Interrupt Packet (INTP) Even if our network system can communicate with low latency, if a destination node takes too much time to interpret packets due to firmware, processing of critical data such as synchronization between nodes may be delayed. Therefore, we introduce an interrupt packet (INTP) that contains hardware interrupts to control hardware without CPU processing in the destination node. There are 8 interrupt factors that can be used by setting the number of factor in the INT field of Trailer. As shown Fig. 3(a), after setting the DID and INT field, INTP is sent from the interrupt packet transmission block in NC by the interrupt request from firmware or hardware in source node. Upon receiving this INTP in destination node, the interrupt packet receive block in NC generates control signal on the interrupt pin of the number stored in the INT field of this INTP (Fig. 3(b). If these interrupt pins are connected to hardware (e.g. CPU interrupt pin or CPU reset circuit) in the circuit, they can be used to control hardware in destination node directly. Transmit Interrupt Packet Source Node Software Interrupt request INT07 Command (INT07) Hardware 8 Transmit INTP Destination Node Receive Interrupt Packet Receive INTP INT0 Control target0 INT1 Control target1 INT7 Control target7 Generated control signal NC NC (a). Transmit INTP (b). Receive INTP Figure 3. The Structure of Hardware Interrupt C. Data Flow to realize low latency communication In this section, the data flow and its characteristics are described. In a conventional network, packets are sent from the source node and received by the destination. After that, destination node sends an acknowledgement (ACK) packet indicating reception completion to the source node. Then, one data processing is completed. However, since the number of transactions is two, the efficiency is bad, and latency will increase because the next packet cannot be sent until ACK comes. In this network protocol, the transmitted packet is relayed by all nodes regardless of the destination node, and it is circulated to the source node and discarded. By returning the packet to the source node, it can be determined that the Transmit Data Packet CPU INTP Header INTP Trailer INTP CRC DATP Header DATP CRC DATP Trailer DATP DATA D0D1D2D3D4 Input timing for Packet Manager Input Output One DATP One INTP Relay Transmit Transmit Interrupt Packet Packet Manager (a). Insertion of INTP DATP CRC DATP Trailer DATP DATA D2D3D4 DATP Header DATP DATA D0D1 INTP Header INTP Trailer INTP CRC (b). Output Data Figure 4. Priority Hanling of Interrupt Packet destination node has received it, so that the ACK packet from the destination node is not necessary. Therefore, since transmission / reception can be confirmed in one transaction, 3884 latency can be lowered. Also, if the destination ID of the input packet is its own node, the reception process must be performed, but if the packet is relayed after judging the availability of reception, the latency will increase. Therefore, by connecting the Relay and Receive blocks in parallel to the data input line and performing the relay processing and the reception processing on the fly, the latency in the relay was reduced. Interrupt packets are used to realize hard real time such as synchronization between CPUs. The transmit interrupt packet unit is independent of the transmit data packet unit, and they are processed in parallel. Outputs of these units are connected to Packet Manager, and Packet Manager controls transmission. When the input timing to Packet Manager is simultaneous, an interrupt packet is sent with priority. However, while a DATP is being relayed, if a CPU of its own node requests INTP transmission, the INTP will be kept waiting until the DATP passes to prevent collision. If the size of the DATP is large, it takes time to transmit the INTP, so there is a possibility that the real-time property may be impaired. Therefore, as shown in Fig. 4(a), Packet Manager has a function to insert an INTP by breaking a data packet even during transmitting DATP. Fig. 4 (b) shows the output data from Packet Manager at that time. As a result, low latency transmission of interrupt packets was realized. If a node kept transmitting a DATP, other nodes cannot transmit it. For example, when there is a node that keeps flowing data of camera, it is implied that the other node cannot transmit DATP such as joint control data that should be transmitted in real time. By this reason, we also set a constraint that the next packet cannot be sent until the packet returns to own node for each packet. In addition, we set the maximum size of DATP to 512 bytes. Fig. 5 shows an example of data flow when Node A sends a DATP to Node C (Source ID (SID) = A, Destination ID (DID) = C). When Node A sends it (), Node B can relay it because Node A Node D Node C Node B SID=A DID=C Packet Relay Relay Receive Discard =Completion Relay SID=A DID=C Packet Transmit SID=A DID=C Packet On-the-fly 1 2 3 4 5 Figure 5. Data Flow of Proposed Network the node know that the packet was sent by another node by the SID value of the packet header (). After that, it reaches Node C as the transmission destination. Since Node C knows that it is a packet addressed to itself by DID, it performs reception processing. At the same time, since the SID is not its own node, the packet is relayed(). The packet relayed by Node C is similarly relayed by Node D () and then returns to Node A. When Node A confirms that the source is its own node, the packet is discarded(). By this data flow, the maximum latency is 75 us even in the state where the communication load is the highest, such as 16 nodes sending 512 bytes of data packet at the same time. Therefore, it can be said that it is a network protocol that can realize low latency. IV. FAULT TOLERANCE When the articulated robot performs work remotely, it is necessary to continue to move without getting stuck even if some failure occurs in a part of the system. For example, when a firmware error is occurred on a node, the system should be recovered by resetting only the CPU of