Lucas Henrique Cavalcanti Santos
Optimized Real Time Radio Frequency Network for Multiple Mobile Robots Communication
Federal University of Pernambuco graduacao@cin.ufpe.br www.cin.ufpe.br/~secgrad
Recife 2019
Optimized Real Time Radio Frequency Network for Multiple Mobile Robots Communication
A B.Sc. Dissertation presented to the Center of Informatics of Federal University of Pernambuco in partial fulfillment of the requirements for the degree of Bachelor in Computer Engineering.
Concentration Area: Wireless Network Advisor: Edna Natividade da Silva Barros
Recife 2019
ACKNOWLEDGEMENTS
I want to thank my family, who supported and guided me through my life and gave me the best conditions they can. I want to thank especially my mother and girlfriend to share and hold up the whole graduation journey by my side.
I would like to thank my advisor, Prof. Edna Barros, who guided me during all the graduation, trusting and supporting me in all my projects and ideas. I also would like to thank Prof. Hansenclever Bassani, because without him and Edna there isn’t RobôCIn.
I want to thank the Centro de Informática (CIn), and all the professors, for the best education, facilities, and infrastructure, that leads the course and its students to excellence in computation. I would like to thank especially Prof. Daniel Cunha that accepted the invitation to examine that work.
I cannot forget to thank my RobôCIn’s colleges and classmates, who shared their routine with me and taught me to become a better person. Also, I would like to thank the RobôCIn’s young members, that motivates me daily and brought a purpose for my position on the team.
Finally, I want to thank my friends Roberto Fernandes, Renato Sousa, Heitor Rapela, Gabriel Bandeira, Cristiano Santos, Carlos Pena, Jailson Gomes, Geovanny Lucas, Raphael Brito, Pedro Magalhães, Mariana Barros, Walber Macedo, Victor Sabino, and many others that shares their journeys, studies, worries and dreams with me.
–African Proverb
ABSTRACT
Industrial robots increased 30% from 2017 to 2018 due to the rise of Industry 4.0 and the Internet of Things (IoT). Both concepts may change the production chain and the people’s interaction with the environment. IoT that expects to reach 214 billion dollars in 2020, tries to embedded connectivity to every device. Additionally, Industry 4.0 uses the IoT contributions together with robotics, to increase production customization and autonomy. In this context, the challenge of adequately controlling and monitoring robots arises. In some robotics competitions, these challenges are present and attract researches and teams to bring their research and solutions.
In one of these competitions, the RobôCIn team plays soccer with its autonomous system.
Composed by a computer and six mobile robots, the RobôCIn’s system controls their robots through wireless communication and aims to monitor them. Because of the dependence around the wireless network, this work intends to build an optimized architecture that deliveries wireless messages quickly and receives robot telemetry as well. Starting from the computer that sends encoded data, passing through a base station, where the data entry in wireless media, until it reaches the robot that receives and decodes it in actions, this work proposes an architecture and protocol to fulfill the real-time requirements while monitoring the robots. The delivery time of the messages was exhaustively tested to find the best approach and its limitations. It results in delivering control messages, with telemetry enabled, in 4,39ms, i.e., a control system of 227 messages per second.
Keywords: Wireless communication, motion control network, mobile robots, embedded systems, autonomous robots, RoboCup competition.
Robôs industriais cresceram 30% de 2017 a 2018, e este aumento no número de robôs veio junto com a Industria 4.0 e Internet da Coisas (IoT). Conceitos que podem mudar a forma com que os produtos são produzidos e como as pessoas interagem com o ambiente a sua volta. A IoT introduz conectividade nos dispositvos e hoje já tem expecitativa de vender 214 bilhões de dólares em 2020. Além de que a Industria 4.0 usa o concento de IoT, junto com robótica, para aumentar a customização e autonomia nos processos industriais. Neste contexto, o desafio de adequadamente mover e monitorar os robôs surge. Assim, algumas competições de robótica atraem pesquisadores a levarem suas pesquisas e soluções. Em uma destas competições a equipe RobôCIn joga futebol de robôs com seu sistema autônomo. Composto por um computador e 6 robôs, o sistema da equipe controla seus robôs através de comunicação sem-fio, e deseja monitora-los da mesma forma. Por conta da depedência em redes sem-fio, este trabalho visa construir uma arquitetura otimizada que entregue mensagens sem-fio de forma rápida e com telemetria presente. Começando pelo computador que envia dados, passando pela estação base que os move para a comunicação sem-fio, até o robô que recebe e interpreta as mensagens, esse trabalho propõe uma arquitetura junto com um protocolo que entregue mensagens, em tempo real, enquanto recebe mensagens de monitoramento. O tempo de entrega de mensagens foi de exaustivamente testado, para descobrir a melhor abordagem e suas limitações. Então o resultado alcançado em entrega de mesanges de controle, com a telemetria ativa, foi de 4,39ms, ou seja, um sistema de controle com 227 mensagens por segundo.
Palavras-chave: Comunicação sem-fio, rede de controle, robôs móveis, sistemas embarcados, robôs autonomos, RoboCup.
LIST OF FIGURES
Figure 1 – General Structure of the Small Size League Competition Autonomous System (WEITZENFELD,2015). . . 13 Figure 2 – SPI Signals (Leens,2009). . . 16 Figure 3 – RS232 and UART singal voltage (SparkFun,2010). . . 16 Figure 4 – Transistor-Transistor Logic method with sent bits and its function (Spark-
Fun,2014). . . 17 Figure 5 – The types of power supplies for different wireless technologies (Proskochylo
et al.,2015). . . 19 Figure 6 – The specifications of WiFi, ZigBee, and Bluetooth modules (Proskochylo
et al.,2015). . . 20 Figure 7 – nRF24l01 packet bytes and its functions (Nordic,2008) . . . 21 Figure 8 – Control scheme of a mobile robot (Siegwartet al.,2011a). . . 22 Figure 9 – Dependence of lost packets rate between distance and throughput (Kordas
et al.,2010). . . 24 Figure 10 – SSL network layout using the Tigers’ team approach of a network-
capable base station (Andre Ryll,2016). . . 25 Figure 11 – Project network overview with a computer that sends commands to a
base station which transmits the message wirelessly to multiple robots. 26 Figure 12 – RobôCIn’s Small Size Soccer (SSL) robot. . . 29 Figure 13 – Base station architecture of the proposed wireless network with Serial
and Ethernet options between the Computer and Base Station. . . 30 Figure 14 – Diagram of radios used for control and telemetry network on the Base
Station and Robot, together with its way of communication. . . 31 Figure 15 – Proposed Base Station hardware. . . 32 Figure 16 – Architecture of the method developed for testing the network configura-
tions and interfaces. . . 34 Figure 17 – Reception delay for 30 tests at each different sending interval, using a
Serial base station transmitting computer messages at the configured sending intervals. . . 35 Figure 18 – Reception delay for 30 tests at each different sending interval, using a
Ethernet base station transmitting computer messages at the configured sending intervals. . . 36 Figure 19 – Delivery time of base station approaches with the minimum sending
interval. . . 36
Figure 22 – Comparing delivery time with two and six nodes network at two different robots. . . 40 Figure 23 – Delivery time of Ethernet base station packets with different telemetry
sampling time at 6 robots control network. . . 41 Figure 24 – Angular speed on time of each wheel is the robot, monitored by the
developed telemetry network. . . 41
LIST OF TABLES
Table 1 – User Datagram Protocol packet with bits offset and its content. . . 18 Table 2 – Nordic nRF24l01 Specifications. . . 21 Table 3 – Message protocol created to control RobôCIn’s robots. . . 27 Table 4 – Telemetry protocol created to receive RobôCIn’s robots’ information. . . 28 Table 5 – Project Modules and Configuration in Base Station and Robots . . . 30 Table 6 – Ethernet Base Station with Telemetry Different Sampling Interval . . . . 37
CPU Control Processing Unit
CRC Cyclic Redundancy Check
CSV Comma-Separated Values
IEEE Institute of Electrical and Electronics Engineers
IoT Internet of Things
LARC Latin American Robotics Competition
MAC Medium Access Control
mbedOS mbed Operating System
RS232 Recommended Standard 232
SPI Serial Peripheral Interface
SSL Small Size Soccer
TCP Transmission Control Protocol
TTL Transistor-Transistor Logic
UART Universal Asynchronous Receiver / Transmitter
UDP User Datagram Protocol
LIST OF ALGORITHMS
Algorithm 1 – Transmission Concept for Base Station Serial Interface Approach . . 31 Algorithm 2 – Transmission Concept for Base Station Ethernet Interface Approach . 32
1 INTRODUCTION . . . 12
2 BACKGROUND . . . 15
2.1 COMMUNICATION INTERFACES . . . 15
2.1.1 Serial Peripheral Interface . . . 15
2.1.2 Universal Asynchronous Receiver / Transmitter . . . 16
2.2 ETHERNET NETWORK . . . 17
2.3 WIRELESS MODULES . . . 18
2.4 MOBILE ROBOTS . . . 21
2.4.1 Control . . . 23
2.4.2 Telerobotics . . . 23
2.5 RELATED WORK . . . 24
3 SYSTEM ARCHITECTURE . . . 26
3.1 COMMUNICATION PACKETS AND PROTOCOL . . . 27
3.2 SYSTEM IMPLEMENTATION . . . 29
3.3 TIME ANALYSES . . . 33
3.3.1 Test Method . . . 33
3.3.2 Control Message Interval Time . . . 34
3.3.3 Telemetry Message Interval Time . . . 37
4 RESULTS . . . 38
4.1 DIFFERENT DISTANCES . . . 38
4.2 MULTIPLE ROBOTS . . . 39
4.3 TELEMETRY . . . 41
5 CONCLUSION . . . 42
REFERENCES . . . 44
12 12 12
1
INTRODUCTION
Today there are more cell phones than people in the world (BankMyCell,2019). However, despite the high number of cell phones, other embedded systems arrived people’s live. Therefore, day after day, the interaction with an increasing number of dedicated devices that help people’s daily tasks is becoming normal. The technology entrance on people’s lives came supported by an increase of the semiconductor industry, which showed significant growth in sales, passing 1 trillion units sold in 2018, 10% higher than in 2017 (IC Insights,2019).
The embedded system exchanges information with the Internet gives the sensors and actuators the IoT concept. The IoT is a reality with an expectation of selling 214 billion dollars in 2020 (Radiant Insights,2015). This market takes the power of internet wireless communication to facilitate the interaction between the people and the environment.
The semiconductors and IoT concept are fundamental to Industry 4.0, an industry concept that brings autonomy and customization to products manufacture (Wanget al.,2017). In other words, Industry 4.0 ends with "dumb" robots that only do programmed movements, and brings sensors and external communication so the robots can react and adapt to the necessities.
According to the International Federation of Robotics (IFR), the industrial robots in- creased 30% from 2017 to 2018 (IFR,2018). IFR also affirms that since 2017, the robots can work alongside humans, and no more cages are needed. Also, in its report,IFR(2018) concludes that robot-human interactions are increasing. On the other hand, robots are not in daily life because people create a highly dynamic environment that is even more challenging than an industrial environment. As people live in homes, that environment is a complicated place where robots need sensors to interact autonomously safely.
In an autonomous system, we cannot prioritize some parts over others. Every piece should work as a symphony, for example, if there is a lack of sensors, there is not enough information to analyze, and without actuators, there is not an action to take. Additionally, without wireless communication in systems, robots will not move correctly in the environment, even though it has input information and functional agents.
Competitions like RoboCup, the most significant autonomous robotics competition, cre- ates high dynamic environments where robots should play soccer autonomously against another team (Kitanoet al.,1997). The soccer competition is perfect for developing interdisciplinary
technologies, as it has obstacles and target position moving at every second. That dynamics requires accurate sensing of the field situation, combined with fast decision algorithms and real-time communication.
Figure 1: General Structure of the Small Size League Competition Autonomous System (WEITZENFELD,2015).
RoboCup(2018) soccer categories, like Small Size Soccer (SSL), where a team of six robots plays soccer autonomously against another team, the sensing comes from a vision system that captures images from the field and process camera images in a computer that detects the positions of the objects. After the positions go to each team, decision algorithms are executed together with a wireless station to send movements to each team robot on the field, as illustrated in Figure 1.
At the Small Size Soccer (SSL), where a complex robotic system is required, motion control is considered the output of the system. Furthermore, to wireless control robots, high accuracy and speed is needed. Additionally, systems capable of precisely move the robots need a closed loop of control; in other words, it sends the desired movements to the robots and measures it to fix any mistake. The closed-loop benefits are proportional to the updating frequency of the loop, so, besides fast and accurate algorithms and sensors, it is essential to use real-time communication in order to move the robots precisely. Robots movements act in order to play soccer, and, as competitions are, the best team with the best system performance and strategy wins.
The main goal of this work is to leverage the network efficiency and quality of the SSL robots made by the team of the Centro de Informática (CIn), the RobôCIn. The first step relies on efficiency, as it reduces the wireless latency when sending control packets to the robots. For that, this work proposes an optimized wireless controller communication through the study of the technologies available. With wireless and embedded technologies, this work goes more in-depth,
14 14 14 building and analyzing peripherals connections, configurations, and protocols that minimize the delivery time on the robots. In other words, the work develops protocols that, together with interfaces, works to optimize communications between computer, base stations, and transceivers.
Moreover, without it, no matter how fast the robot’s sensing and cognition are, the motion control does not perform the path planned.
Taking into consideration that systems should be monitored, this work also aims to bring quality for the network with the development of telemetry without affecting the control latency. The telemetry, which was not in the RobôCIn’s system, consists of sending information from robots to the computer, closing the loop between the vision, motion control, and robot.
The challenge appears when the system has multiple robots using only one base station, which controls robots and receives telemetry.
The contribution of this works is a control network that improves path execution accuracy by the delivery of real-time messages. The network, different from other control networks, con- tributes to detect and prevent failures in robots by its closed-loop communication. Furthermore, the cognition code is benefited by the telemetry contribution that enables monitoring the robots online and its displacement.
This work is divided as follows: Chapter 2 is a short introduction to computer and embedded systems communication interfaces, followed by an explanation of wireless communi- cation, and its available modules together with possible configurations, benefits, and limits. Such information supports architecture decisions; we also introduce, in Chapter 2, what is meant by mobile robots, and the challenges to control them, and to receive telemetry information, essential to understanding the project impact. Also in Chapter 2, other teams’ network is shortly presented in order to explain the differences in these work requirements and decisions. In Chapter 3, the proposed system is described. Its architecture is explained together with the connection interfaces, algorithms, protocols, experimental system parameters, and test methods. In Chapter 4, the results are shown, and the analyses of the proposed system at different conditions are discussed. Finally, in Chapter 5, the conclusion of this work is presented.
2
BACKGROUND
This section goes through the technologies and its characteristics necessary to build a radio frequency network that is capable of controlling a mobile robot in real-time.
2.1 COMMUNICATION INTERFACES
Nowadays, there are tons of sensors and actuators present on the market. Additionally, there are modern embedded processors that, combined with these peripherals, are capable of creating quality systems and solutions. To spread the numbers of embedded solutions on the world and to facilitate the use, were created development boards and peripheral modules that masks the complexity behind the new microcontrollers, sensors, and actuators. These facilities came alongside the popularization of communications interfaces, that made possible a uniform and fast integration.
2.1.1 Serial Peripheral Interface
Serial Peripheral Interface (SPI) is a protocol present in almost all development boards in the world. Made to facilitate the data exchange between devices, it uses one device as master, which controls the communication bus, and one or more slaves that answer and respect the master signals.
The SPI works with only four signals (Leens,2009). The first one, called SCLK, is the clock signal sent from the master to all devices, to provide synchronous signals. The second, the slave select, known as SS, is responsible for choosing the slave which the master communicates.
In other words, the master has one signal as SS for each slave that he wants to exchange bytes.
The third and fourth signals are analogous, one called MOSI is the signal that outputs from the master and goes to the slaves as input, and the other is the MISO, which is input signal to the master that came as output from the slaves.
The downside of this communication protocol is the number of signals needed. It starts with four signals to communicate with one peripheral and increases one SS signal for each slave added. Otherwise, this type of communication reaches high throughput (Leens,2009). The high
16 16 16 speed comes because the MOSI and MISO signals only change when there is clock changing, an effect illustrated by the signals transitions in Figure 2. The synchronization between devices reduce bit error, and overall, the synchronization and multiple devices’ communication make the SPI a powerful and widely used interface.
Figure 2: SPI Signals (Leens,2009).
2.1.2 Universal Asynchronous Receiver / Transmitter
The Universal Asynchronous Receiver / Transmitter (UART) is a well-known type of communication that a few years ago was the principal communication between computers and external peripherals. Before the USB protocol, printers and computers used to use UART communication with the Recommended Standard 232 (RS232). Although the RS232 is a method introduced in 1962, with low speed and no support to multiple devices communication (Hazen, 2003), it strongly standardizes the UART communication and suffered updates that made possible the continuous use in an ample amount of micro-controllers as an interface with programmers.
Figure 3: RS232 and UART singal voltage (SparkFun,2010).
Figure 3 shows the original RS232 with its voltage varying between -13v and +13v, but also shows a RS232 with a reduced operating voltage that floats between 0v and 5v, for 0 and 1
bits. Named as Transistor-Transistor Logic (TTL) method of communication, that reduction of operating voltage also reduces the necessity of power components, which usually increases the price. Otherwise, that improvement was possible only with circuits improvement since 1962, because the voltage reduction brings more noise, interference, and degradation (Santitoro,2003).
Like all serial interfaces, the TTL method sends and receives bit after bit until it makes one complete byte. The synchronization implemented is the starting and stopping bits that delimits one byte sent asynchronously. Figure 4 illustrates the start and stop bit together with the bits that composes the two byte sent. Serial interface has only in two wires, the first one is the receiver signal, called RX, and the other is the transmitter, called TX. As every device sends in the TX and receives in the RX, two devices need to cross the RX and TX to communicate.
Additionally, two devices in the same serial bus need a configuration on the same throughput of bits, or as commonly called, the same baud rate.
The need for two signals and a baud rate configuration makes this UART a simple and easy implemented interface because, with a small setup and fewer pins, the cost decreases in every device. The downside comes with the necessity of speed configuration in both devices and no clock synchronization, different from SPI.
Figure 4: Transistor-Transistor Logic method with sent bits and its function (SparkFun,2014).
Although it is possible to connect multiple devices by adequately connecting the TXs and RXs pins, there is not support implemented. In other words, devices cannot communicate at the same time, because no collision and interference are supported.
2.2 ETHERNET NETWORK
Ethernet is the most common network technology used in the world. No matter if it is a local, metropolitan, or wide area network, it plays a crucial part in the Internet web. It is a network that connects devices on the same bus, directly or through switches and routers, the technology enables a vast number of applications.
Standardized by the IEEE organization, Ethernet uses Medium Access Control (MAC), a six-byte number unique to each device, to identify the device in the network. Ethernet initially made with coaxial cables, nowadays are made by twisted pairs of cable that reduce noise interference. The noise reduction and the IEEE standard updates made the Ethernet reach 10Gbps and contribute to the development of a safe and resilient communication (Santitoro,
2003). Significant on the Internet connections, and to locals applications, Ethernet link devices, and process, even at the same machine.
18 18 18 Table 1: User Datagram Proto-
col packet with bits offset and its content.
Bit Offset Content
0 Source port
16 Destination port
32 Length
48 Checksum
At the seven layers of the OSI model of the Internet (Briscoe,2000), the Ethernet comes right after the hardware. The second layer, called the link layer, has Ethernet and is a strategic point to build and control the physicals connections using MAC. Upon the link layers, there is the network layer, where the Internet Protocol (IP) addresses lives and helps to establish, maintain, and terminate connections. Different from MAC, where the device hardware chooses it, the IP is given to the device by routers or switches that control network routing and device connections.
The fourth OSI layer, known as the transport layer, is where Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) lives. Both protocols are the most used in the Ethernet networks; consequently, it is the most used on the Internet. The TCP can maintain connections, so it guarantees order, byte streaming, and reliability. On the other side, UDP sends independents packets without maintaining connections, so it does not guarantee order or reliability. However, as illustrated by the bits offset and the its content in Table 1, the UDP has a light packet suitable for Internet application that requires real-time data, like video streaming.
2.3 WIRELESS MODULES
Over the years, people empower more and more devices with wireless technology. In other words to reach the Internet or share information locally, devices like cell-phones, laptops, and even television use wireless modules intending to create a unified ecosystem of devices.
Wireless is commonly known as WiFi, but they mean different things. While wireless includes all technologies that exchange data without wires, WiFi is a wireless technology with pattern and protocol defined by Institute of Electrical and Electronics Engineers (IEEE) (IEEE, 2007), same as Bluetooth. Furthermore, even using similar frequencies, WiFi is optimized in other to access the Internet and Bluetooth to exchange data locally between devices. In other words, they were developed differently to increase advantages in it is desired applications.
Most of the modern wireless technology uses frequency modulation of waves to exchange data. Even with the high complexity and high cost to build wireless modules from scratch, there are different needs, that just one module cannot resolve. So, the companies continuously build different modules that try to fill the application’s requirements. At Figure 5, there is a power comparison and possible power supply to each technology. Commonly with less power
consumption, less is the signal coverage, but in our daily life, we use some of the technologies at Figure 5 to different applications.
Figure 5: The types of power supplies for different wireless technologies (Proskochyloet al., 2015).
With different standards and protocols, there are some options for wireless modules present on the market. Usually, the modules are made suitable for building embedded systems, using SPI to integrate it at the microcontroller. The variety and specification of wireless mod- ules bring the necessity of choosing only one module, with one standard, one protocol, and consequently, a group of optimizations and limitations.
Authors are continuously analyzing the wireless modules present in the market. Three modules that always come as options to embedded systems are WiFi, Bluetooth, ZigBee.
Proskochyloet al.(2015) tested these three modules to create a detailed comparison of technical specifications and limitations. The comparison in Figure 6 shows that the WiFi module is faster, has a larger operating frequency band, and more configuration options. On the other hand, the WiFi module consumes ten times more energy than the other modules.
The WiFi technology has a consumption not suitable for batteries used in embedded devices. Looking between ZigBee and Bluetooth, the ZigBee has more flexible characteristics, connects to a large number of devices while consuming only 30mA, less than the Bluetooth module.Proskochyloet al.(2015) also affirms that ZigBee is low cost and oriented to tasks like telemetry.
20 20 20
Figure 6: The specifications of WiFi, ZigBee, and Bluetooth modules (Proskochyloet al.,2015).
A few years,Nordic(2008) launched the nRF24l01 and, year after year, increases its usage inside the embedded systems, including IoT applications. The Nordic module came to compete with the ZigBee modules because it has similar characteristics. On the other hand, the nRF24l01 does not follow the IEEE pattern as ZigBee, in other to bring more flexibility and Nordic’s frequency protocols.
At embedded systems, the Nordic modules send wireless packets from one module to another if they have a proper configuration. In other words, it sends from one module to another if they are operating in the same frequency, and the sender packet has the receiver address. This operation is similar to UDP but different from ZigBee that changes packets only with paired devices.
In the end, the nRF24l01 module is way more flexible and lower power than ZigBee (Sahaet al.,2017). Although it does not reach the WiFi modules speed (Wanget al.,2014), the Nordic module has high performance allied to low consumption, shown at Table 2, that fits in embedded applications.
Table 2: Nordic nRF24l01 Specifications.
Characteristics nRF24l01
Frequency 2.4 GHz
Speed Rate 2 Mbit/s
Level of OSI ShockBurst
Modulation GFSK
Power Lever 0 - 18 dBm
Power Consumption 13.5mA TX, standby 26 uA
The SPI appears as an interface to configure and send packets through the nRF24l01.
The configuration step chooses the transceiver mode of operation, frequency channel, address, throughput, payload, and specific options like the use of acknowledgment reception packet and Cyclic Redundancy Check (CRC). The packet transmission occurs sending the message bytes to the radio sending register, where the nRF24l01 gets the bytes to fill the packet illustrated at Figure 7.
Figure 7: nRF24l01 packet bytes and its functions (Nordic,2008)
At the nRF24l01 packet, shown at Figure 7, the preamble is a byte of zeros and ones to help the receiver demodulation and address is the receiver address, defined at the configuration step. The packet control field has the message payload, packet identification, and the requirement of acknowledgment packet or not. The payload is the bytes to send, and the CRC is a code that helps detection of bit corruption at the message.
2.4 MOBILE ROBOTS
As the industry was the first application of robotics. The first robots came to facilitate and speed up industries process, so in general, they were articulated arms that precisely manipulate products. However, the increase of other areas such as computer vision, embedded systems, and neural networks brought to robotics much more power and options to robotics (Siegwartet al., 2011b).
With the increase of different areas, robotics integrated most of them in robots. The interdisciplinary enabled the creation of more sophisticated robotics systems. The mobile robots
22 22 22 came as a challenge to unify mobility, with autonomy and interaction; in other words, they are robots capable of moving and doing tasks without human guidance.
Siegwart et al. (2011a) affirms that a mobile robot control scheme is made from a perception, localization, cognition, and motion control, as shown at Figure 8. Perception is the extraction of the information based on sensors; this information should serve the environment model to start the localization task. The localization uses the perception together with a local built map or an online map process to discover the position of the robot. The robot and object positions go to the cognition step, where the robot interacts with the ambient planning movements that may accomplish simple or complex tasks. The final step is motion control that the robot should act as planned, moving the robot’s wheels and arms or any actuator based on the cognition planning. Motion control is also considered as the robot output to the real world, as it is the process that interacts with the environment.
Figure 8: Control scheme of a mobile robot (Siegwartet al.,2011a).
No matter the task, the process of sensing, planning, and moving robots should work continuously, to not fail the task process even with technology impressions, and above all, to continue the task with environment changes (Siegwartet al.,2011b). The steps to build a mobile robot can goes into an embedded system on the robot or not. That advantage reduces the cost and complexity of some systems because the designer can have a global vision of the environment and share information with multiple agents.
Some organizations, as RoboCup (www.robocup.org), creates controlled environ- ments to gradually increase the researches quality and challenges in the robotics domain. The main challenge proposed by the RoboCup is to build robotics teams that autonomously play
soccer. Soccer is a highly dynamic environment with multiple agents, and all kinds of robotics systems, from wheeled to humanoid robots, need to implement perception, localization, cog- nition, and motion control, locally or not. In other words, the soccer competition serves as a benchmark for a lot of technologies and researches, opening doors to innovation (Kimet al., 2014).
The success of some mobile robot systems animated the industry, not to fill the factories with fully autonomous robots, but also to bring some autonomous systems that can increase the speed and quality of productions (Brogårdh,2007).
2.4.1 Control
After years of robotics development, a challenge present from the beginning until today is properly control actuators. Siciliano and Siegwart affirm that exists mathematics models for controlling manipulators and mobile robots. Made a few years ago, the models take in consideration robot structure and output control equations to actuators (Sanz,2009) (Siegwart et al.,2011b). However, the models are a reality; the robot interaction with the real world has a lot of complex effects like wheel slipping, which is undesired and cannot be predicted by the models (Cerkala & Jadlovska,ˇ 2015).
Solving actuators control interaction challenges is part mobile robot loop. As some undesired effects depend on mechanics, electronics, and environment, they are specific for the robot in question and not predictable. So, repeating the process of perception and motion control gives the robot the ability to recover from wrong movements to the desired position.
2.4.2 Telerobotics
The telerobotics comes to overcome the complexity inside robots because it proposes to divide the embedded computation with external computers. As telerobotics proposes to communicate robots with an external computer, it may divide the computational load, which can process perception, localization, or cognition out of the robot. Besides the reduction of load, the external computer can reduce robot cost, power consumption and give a broad vision of the environment, as it can access multiple robots or even access different sensors like external cameras (Liu Jianbanget al.,2008).
External process downside comes when is needed real-time operations, like at soccer robots, where the process from sensing to motion control needs to occur in a few milliseconds. To maintain the telerobotics system in a few milliseconds, it needs resilient wireless communication and optimized data exchange for sending crucial information. To achieve that time requirement is essential to develop a dedicated communication embedded system (Liu Jianbanget al.,2008), but together with proper software and infrastructure development (Kanget al.,2013).
24 24 24
2.5 RELATED WORK
This section briefly summarizes related works that have been applying wireless networks to mobile robots. Most authors have been applying wireless networks with IoT concept to create sensors network. As IoT usually require low power technologies, authors also uses its transceiver at robots. In other words, robotics take advantage of the lower consumption, but adds tight requirements of message delivery time.
Talking about the construction of the network embedded system, the work ofKordaset al.
(2010) proposed a transceiver embedded device to control mobile robots using the nRF24l01 (Nordic,2008). They tested performance varying network topology between peer and broadcast communication. At peer communication, each robot receives its message through a specific address of the radio. On the broadcast topology, all robots message are condensed in only one packet and received by all robots simultaneously. Although the broadcast strategy is fast, the maximum radio bytes per packet is 32, and this limits the number of robots in the network.
Figure 9: Dependence of lost packets rate between distance and throughput (Kordaset al.,2010).
Furthermore, Kordas et al. shows that more bytes in packets or further the transceivers are, more packets are lost. On the other hand, the Figure 9 compares 1 Mbps and 2 Mbps transmission speed, and shows that a higher throughput do not increase the lost packet rate. As Kordas et al. analyzed the transmissions lost rate and delivery time of bytes, they didn’t analyzed the whole system flow, including the computer, that sends messages to the embedded device where the messages are transmitted.
Moreover, it is possible to find works that analyze different communications technologies applied to soccer robotics requirements.Nadarajah & Sundaraj(2012) work does not compare with nRF24l01 technology, but gives an excellent overview of the network requirements for the application, and also put in balancing the pros and cons of each technology compared (Nadarajah
& Sundaraj,2012).
The Tigers robotic soccer team proposes a shared interface of communication, using a transceiver base station connected to the network (Andre Ryll, 2016), shown in Figure 10.
Although Andre et al. affirms that it speeds up the communication between perception and transceiver due to the Ethernet network, Tigers’ base station has no isolation between its computer and adversary computer.
Figure 10: SSL network layout using the Tigers’ team approach of a network-capable base station (Andre Ryll,2016).
The Tigers’ protocol sends and receives much information with high precision between computer and robot, so it almost uses the maximum number of bytes in one packet (Andre Ryll, 2016), which may increase the number of lost packets on the network (Nadarajah & Sundaraj, 2012).
26 26 26
3
SYSTEM ARCHITECTURE
In this Chapter, the proposed architecture is presented. It consists in an optimized wireless network architecture that controls multiples mobile robots and monitors them, as illustrated by Figure 11. It starts with commands from a computer, that generally is called as the commander and has the cognition. The commander’s code sends messages, defined by the cognition, that includes identifications and actions, to each robot at a time. This information leaves the computer and needs to reach the robots, so the data needs to reach through wireless media. For that, the commander connects itself to a base station, which is an embedded system that receives the commander’s message and transmits it using a wireless module. Each robot also needs a wireless module, responsible for receiving packets sent from the base station. Finally, with the message, the robots interpret the data and execute the command sent by the computer.
Figure 11: Project network overview with a computer that sends commands to a base station which transmits the message wirelessly to multiple robots.
The opposite way of communication is needed to create the telemetry ability. Although the robot can use the modules of the control network to send telemetry information, an additional transceiver is added, creating then a second channel of data exchange that not interfere with the flow of control messages.
Around the message flow, there are two communication points. The first between the computer and the base station, and the latter between the base station and robots. Both connections need common patterns to exchange data; in other words, the system needs the same language of communication.
3.1 COMMUNICATION PACKETS AND PROTOCOL
The first protocol, defined as the communication between two transceivers, communicates wirelessly. It was essential to define a communication topology that minimizes the configuration overhead, not depending on messages order, neither fails due to lost packets. When considering the nature of the control and telemetry messages, there is no need to recover them, because they require only the current information. So, the communication between the base station and robots is entirely broadcast; in other words, the messages transmitted by the base station are received in all robots, as shown in Figure 11.
The broadcasted topology of messages removes the overhead in dynamic changing the receiver address at wireless modules. Using broadcast, the system not requires acknowledgment packets from receivers, which permits disabling the re-transmission of lost packets. On the other hand, the message should include a robot identification, to enable the option of addressing each robot independently.
Table 3: Message protocol created to control RobôCIn’s robots.
Bits Offset Bits Size Information
0-3 4 Message Type
4-7 4 Robot Id
8 - 27 20 vx - Linear Speed 28 - 47 20 vy - Linear Speed 48 - 67 20 ω - Angular Speed 68 - 87 20 θ- Robot Angle
88 1 Kick Front
89 1 Kick Chip
90 1 Charge the Kick
91 - 98 8 Strength of the Kick
99 1 Turn on the Dribbler
100 - 107 8 Speed of the Dribbler 108 - 111 4 Additional Command
Moreover, after choosing the robot to control, the commander needs to send desired movements and peripheral functions, so the project needs a control protocol. The developed
28 28 28 protocol aims to minimize the payload size while enabling accurate control of the robots. So, the bits offset and message interpretation works according to Table 3 description. It includes, in the first byte, the message identification, which defines the interpretation of the message bits.
At the first byte, there are also bits that identifies which robot the commander wants to control.
These two initial slots, of four bits each, permit the robots to act only when the commander addresses the message to it. In other words, even receiving all broadcasted messages, the robots identify when they need to perform some action. Finally, the last thirteen bytes define the robot’s movements and its peripherals actions, like the kicker that allows the robot to kick the ball.
After controlling the robots, the network should enable the ability to monitors them.
Then, another messaging protocol is created, now described at Table 4. It also uses the minimum bits required to represent the robot’s information. Equally to the control protocol, the telemetry message has the message and robot identification in one byte, to inform the commander which message arrived and from which robot it came. Differently from the control protocol, the telemetry protocol has each motor speed, measured by the robot’s sensors, and that information assures the commander the correct behavior of the motors. Alongside with motors speed, the telemetry packet includes essential information measured at the robot, like battery level and more, which enables the identification of malfunction in robots.
Table 4: Telemetry protocol created to receive RobôCIn’s robots’ information.
Bits Offset Bits Size Information
0-3 4 Message Type
4-7 4 Robot Id
8 - 23 16 m1- Motor 1 Speed 24 - 39 16 m2- Motor 2 Speed 40 - 55 16 m3- Motor 3 Speed 56 - 71 16 m4- Motor 4 Speed 72 - 86 15 Dribbler’s Motor Speed 87 - 94 8 Kick’s Capacitor Load
95 1 Ball on the Robot
96 - 103 8 Robot’s Battery
After defining the communication between transceivers and the protocol to control and monitor robots, the communication between the computer and base station is defined. Although it uses wired communication, there is data flowing, and its correctness is essential to transmitting and receiving messages. Independently of the interface used, the base station does not need to encode or decode messages of the control and telemetry protocols. It only needs to transmit messages from computer to robots, and from robots to computer. Furthermore, there is no necessity for defining a protocol, as the information exchanged between the computer and base station only needs the size of the packet to receive and send the right message. The defined protocols of messages makes the commander sends control messages of 14 bytes, while receives
telemetry messages of 13 bytes from the base station. On the other hand, the base station sends 13 bytes to the commander and receives 14 bytes from it.
3.2 SYSTEM IMPLEMENTATION
The network implementation started by choosing the best modules that fit the project requirements and budget. The RobôCIn’s robot, shown at Figure 12, already has two nRF24l01 (Nordic, 2008) transceivers modules and uses a NUCLEO-F767ZI (ST, 2019a) board pro- grammed with mbed Operating System (mbedOS) (Arm,2019), which is a real-time operating system for ARM microcontrollers that allows the development of C++ codes, gives support for ARM peripherals, and emulates virtual thread.
Figure 12: RobôCIn’s Small Size Soccer (SSL) robot.
The mbedOS comes with built-ins libraries that implement different interfaces of commu- nication while controlling the board peripherals. So, the SPI between the board and transceivers used the read and write functions implemented in the mbedOS. On the other hand, the transceivers only accept and return messages if the program communicates with the correct register’s address.
The chosen module, the nRF24l01 transceiver, has specific registers for configuring the radio (address, power, and function), sending and receiving bytes. All of them are presented in the module datasheet (Nordic,2008). After configuring the nRF24l0, with the specification shown in Table 5, the radio sends and receives data with Enhanced Shock Burst (Nordic,2008), a proprietary technology. That technology allows the exchange of at most 32 bytes of payload and includes a CRC of bits, calculated inside the transceiver module.
30 30 30 Table 5: Project Modules and Configuration in Base Station and Robots
Base Station Robots
Transceiver nRF24l01 nRF24l01
Embedded Board Nucleo F767ZI Nucleo H743ZI
CPU Frequency 400 MHz 216 MHz
Operating System mbedOS mbedOS
Radio Frequency (Control) 2504 MHz 2504 MHz Radio Frequency (Telemetry) 2529 MHz 2529 MHz
Radio Address 0x753FAD299ALL 0x753FBD299ALL
Together with the RobôCIn’s robots and its software, this work proposes an embedded system for the base station. The Figure 13 shows the base station architecture and interfaces.
There are two nRF24l01 modules coupled by SPI to a NUCLEO-H743ZI (ST,2019b) pro- grammed by mbedOS, using the SPI library. The base station takes into consideration the hardware and software used in robots to maintain the same operating system while adding a faster microcontroller board, as shown by its Control Processing Unit (CPU) frequency at Table 5.
The choice of using a faster board is because even the robots receiving all broadcasted message, there is only one base station for multiple robots, which creates a bottleneck of messages.
Figure 13: Base station architecture of the proposed wireless network with Serial and Ethernet options between the Computer and Base Station.
The control communication from the computer to the robot uses one transceiver at the base station and another at the robot, as shown in Figure 14. In the base station, the transceiver is configured as a sender radio that targets the message to the address of the robots, shown in Table 5. On the other hand, the transceiver configuration in the robots uses the receiver mode with robot’s network address.
Finally, the computer, base station, and the robot share information with the protocols made. The base station and robots exchange bytes with nRF24l01 transceivers using the
configuration presented, but between the computer and station, this work brings two options of the interface: Serial and Ethernet (Figure 15). Moreover, both interfaces have support at the NUCLEO board and have built-in libraries in the mbedOS, allowing the transmission and reception of bytes between embedded boards and computers.
Figure 14: Diagram of radios used for control and telemetry network on the Base Station and Robot, together with its way of communication.
Due to the characteristics of the Serial interface, it is easy to implement, but it can only receive and send one byte at a time. Furthermore, to control the robots, was developed a base station that read each byte until they compose a message. Only with the message complete, the base station transmits packets to the nRF24l01. This concept is shown by Algorithm 1.
Algorithm 1:Transmission Concept for Base Station Serial Interface Approach
1 Initialize byte array and counter;
2 whiletruedo
3 //Read one byte at Serial;
4 byte array[counter] = read serial();
5 counter++;
6 ifcounter == message sizethen
7 //Send message to transceiver;
8 send bytes (byte array, message size);
9 clear (byte array);
10 counter = 0;
The second interface, the Ethernet, is used with UDP protocol present in the chosen embedded board, by the mbedOS support, and present at every personal computer. The UDP protocol is suitable for streaming data, as the control network. Moreover, different from the Serial approach, the Ethernet sends a group of bytes containing the sent message and also a header, as described in Chapter 2. In other words, the developed algorithm only waits for a message and re-transmits its bytes by the payload of the nRF24l01, as shows in Algorithm 2.
32 32 32 Algorithm 2: Transmission Concept for Base Station Ethernet Interface Ap-
proach
1 Initialize byte array;
2 whiletruedo
3 //Receive complete message and send.;
4 byte array = read packet();
5 send bytes(byte array);
6 clear (byte array);
Finally, the telemetry network to monitors the robot was developed using an additional transceiver present in the robot and the base station, as illustrated in Figure 14. First, the robot code was modified to measure robot’s status on top of RobôCIn’s robot code (RobôCIn,2019).
In the code, the telemetry transceiver is configured in sender mode, but different from the control network it uses the telemetry network frequency and addresses the base station (Table 5). With the robot status, the code encodes it, following the telemetry protocol, and sends through the telemetry transceiver to the base station.
At the base station, a virtual thread, parallel to the control code, was developed, and it configures the second transceiver of the base station as a receiver, expecting messages at the telemetry frequency. So, whenever a wireless message reaches the telemetry transceiver at the base station, it forwards the payload bytes to the computer, where the message is appropriately decoded and identified.
Figure 15: Proposed Base Station hardware.
3.3 TIME ANALYSES
3.3.1 Test Method
After implementing the network configurations, the system does not have a defined period between sending each message. That interval is essential to the network operation and it is different for the Serial base station, for the Ethernet one, and even for the telemetry messages.
Then, this work proposes a method for testing the delivery delay of packets at the robots, where is the main requirement of the network.
The proposed method tests the delivery time, independent of the interface, and also evaluates the telemetry impact on the network. It is robust to analyze delay performance, because, no matter the parameters, it measures the interval between messages that should arrive continuously at the robots.
The interval between messages delivery varies a lot because the network broadcast topology works asynchronously, and sometimes wireless packets are lost. So, the delivery time between messages in one configuration means the average interval between each of the 500 messages received. Moreover, tests performed with a slow network or losing packets increase the average interval time, calculated with
timeinterval =∑500i=1(messageTimei−messageTimei−1) 500
3.1 and, because of the varying time interval between messages, a not optimized network also increases the standard deviation, calculated by
sinterval= v u u t
1 499
500
∑
i=1
(messageTimei−messageTimei−1) 3.2 The test flow described at Figure 16 begins with the commander sending messages to a Serial or Ethernet base station, with manually configured interval. At the base station, it maintains its code and configuration. On the other hand, the robot has an additional code that measures the interval between the reception of 500 messages. Then, the robot sends the measured intervals to an additional computer through USB connection encoding the data in Comma-Separated Values (CSV) file. At that computer, the data is plotted and analyzed. After manually analyzing the time performance of the test, another configuration or experimental intervals is configured at the commander to realize another test.
34 34 34
Figure 16: Architecture of the method developed for testing the network configurations and interfaces.
Although the test of telemetry impact on the network uses the same flow, the telemetry sending interval is configured at the robots and not in the commander. So, the same analyses were performed to assure the efficiency of the control network, even monitoring the robots.
3.3.2 Control Message Interval Time
To choose the interval in which the commander should send messages, at the Serial and Ethernet base station, the control message interval time was experimentally found. For each interface, multiples intervals are tested and compared in order to define an optimal interval.
When we search for the optimized interface, the computer and base station code have a significant effect on the tests. As described in Chapter 3, the base station uses the Algorithm 1 for the Serial communication approach with the maximum Serial speed supported (115200 bits per second), and Algorithm 2 for Ethernet approach. The interval that the computer sends messages means the throughput that each base station supports. Moreover, that interval should exist because the computer processor is a way faster than the embedded system.
An interval in microseconds is defined based on RobôCIn’s cognitive software processing time (few milliseconds) and according to what each base station approach supports. This process tries to find the minimum interval between messages which each base station algorithm supports.
Finally, to find the maximum throughput, the interval time was decreased until the robot correctly receives the messages. Then, a larger interval was tested in order to search for the optimal one.
Analysing the results in Figure 17, the network with base station Serial approach has the best throughput with the 1900us of interval. However, the minimum interval at Figure 17 was
1850us, that throughput made the base station lost some bits when reading the commander, which caused undesired behaviors on the robots. With a smaller interval, like 1800us, the messages do not even reach the robot. In the end, the optimal result is with 1900us of interval, that also has a small amplitude of the box-plot limits, meaning that the message delivery time was more constant than in other intervals.
Figure 17: Reception delay for 30 tests at each different sending interval, using a Serial base station transmitting computer messages at the configured sending intervals.
At Figure 18 is shown that the optimum interval time between messages in the network with Ethernet interface is 500us. Almost four times smaller than the Serial, the Ethernet approach does not corrupt the bits with a shorter interval time than 500us. However, as shown at Figure 18, smaller intervals increases and vary the delivery time at the robot.
36 36 36
Figure 18: Reception delay for 30 tests at each different sending interval, using a Ethernet base station transmitting computer messages at the configured sending intervals.
The analysis presented previously found different intervals of time for each communica- tion interface — an optimal interval of 1900us for Serial and 500us for Ethernet. So, Figure 19 presents the delivery time at 25 tests with each communication interface and its optimal interval.
There, one test is represented by one point in the figure, and it is the average reception between each one of 500 messages received together with its standard deviation. However, the Serial approach is three times slower than Ethernet; each approach has its test interval similar, with a similar standard deviation, which means a uniform network.
(a) Serial station with 1900us of interval (b) Ethernet station with 500us of interval
Figure 19: Delivery time of base station approaches with the minimum sending interval.
3.3.3 Telemetry Message Interval Time
Finally, with the optimal interval for each base station approach, the telemetry is devel- oped on the network in order to the commander receive robots’ feedback. However, the interval for the control network was found; no interval between telemetry packets sent from the robot is known. Again, the tests are applied to find an optimal interval for the telemetry network, and they analyze the delivery time of control packets, as it is essential to move robots even with telemetry enabled. In order words, the robot should send telemetry packets, and the tests continue as described at Figure 16, but changing the telemetry interval in robots code.
At the initial tests with the Serial interface, the bits exchanged between the commander and base station are usually corrupted, which made it impossible to use Serial to send and receive a message between the base station and the computer. Then, the Ethernet approach is the interface that supports duplex communication without affecting the throughput or corrupting messages. In other words, monitoring the robots was only possible on the Ethernet base station.
Similar to the computer sending interval time, the robot should have an interval between each telemetry packet sent. Furthermore, the tests initially used the interval of 200ms between telemetry messages because of the RobôCIn’s requirement. With the baseline of 200 milliseconds or five messages per second, the tests decreased the telemetry interval to find a balance that guarantees quickly sampling without damaging the control network.
Table 6: Ethernet Base Station with Telemetry Different Sampling Interval Test Condition Delivery Time Time Increase
Average Standard Deviation Average Standard Deviation Without Telemetry 721.98ms 140.12
200ms Sampling 724.78ms 159.44 0.39% 13.79%
50ms Sampling 730.89ms 196.07 1.23% 39.93%
10ms Sampling 768.80ms 217.69 6.48% 55.36%
Table 6 shows the network time performance of an Ethernet base station, with a sending interval of 500 microseconds. It compares the delivery time of a network using different telemetry intervals, with a network without telemetry. So, Table 6 presents an impact of 0.39% with a 200ms telemetry interval; at 50ms of sampling, the receive interval increases 1.23%. Additionally, the standard deviation without telemetry compared to 200ms and 50ms of telemetry interval shows that telemetry increases the variation of messages delivery interval. Furthermore, the 10ms sampling increases 6.48% of average delivery time, together with an increase of more than
50% at the standard deviation, which may affect the control network performance.
Finally, the Ethernet base station receiving telemetry packets at every 50 milliseconds guarantees a control update in every 730.89 milliseconds.
38 38 38
4
RESULTS
This Chapter presents the results from the performance tests applied to the network.
Described in Chapter 3, the test methodology aims to analyze network time performance at the chosen configurations. To achieve minimum delivery time at robots, no matter the approach, the performance was measured in the robots using a network of six robots. Therefore, tests were realized in the same environment, hardware, and when not the goal of the test, the same software.
The network efficiency is tested changing the number of robots, its distances to the base station, and enabling and disabling the telemetry. These tests were designed and performed in order to assure the robustness and scalability of the proposed network for RobôCIn’s soccer robots.
4.1 DIFFERENT DISTANCES
An important characteristic of a network that controls soccer robots is a short delivery time with different distances. As the robot moves around the field, it may move next to the base station transceiver or not. The tests that simulate different distances needed to repeat the tests using both base station approaches and positioning the RobôCIn’s robot at different parts of the field. First, the robot was next to the transceiver, 0.4m of distance, after it was at midfield, 2.5m of distance, and finally at the opposite side of the field, 5m of distance.
(a) Delivery time of Serial base station different distances
(b) Delivery time of Ethernet base station different distances
Figure 20: Delivery time of base station with different distance between transceivers.
Figure 20 shows that the only difference in delivery time is the interface used between the computer and the base station. So the delay in reaching farther distances does not increase the delivery time. In other words, the time to navigate to a farther point is insignificant. Furthermore, the small standard deviation at the box-plot shows that the number of lost packets was also insignificant.
4.2 MULTIPLE ROBOTS
The robot soccer game that RobôCIn plays have 12 robots, six from each team. So, the network performance test analyzed multiple robots to evaluate the delivery time and its consistency and equality between robots. Using the optimal interval discovered for Serial (1900us) and Ethernet (500us) interfaces, and each robot is placed at 2.5m away from the base station.
Figure 21 shows that the delivery time in a network with six robots increased around six times compared with one robot network. This outcome is expected because the number of robots increased six times, and, even with the broadcast topology, each message address only one robot. In other words, the base station sends six messages to control all robots as one message only controls one robot. That outcome does not change with different communication interfaces between computer and base station because it is intrinsic of network topology. Figure 21(b) also shows that the delivery delay at one robot increases together with the number of robots in the network.
40 40 40
(a) Delivery time of six robots network (b) Delivery time with different number of nodes at Ethernet base station
Figure 21: Delivery time analysis between interfaces (a) and network size (b).
Therefore, to test consistency in the delivery time capture at two different robots sepa- rately, two different tests were realized in the Ethernet base station network. The first one was analyzing the delay at two different robots in a two robots’ network, and the other one at the same base station and robots but with six robots network. The result of both tests, presented at Figure 22, confirms the expectation that a network with two robots (Figure 22(a)) has a delivery time three times shorter than the six robot network. Similar result presented at Figure 21.
(a) Delivery time of Ethernet base station at two robots network
(b) Delivery time of 6 robots network with Ethernet base station at two nodes
Figure 22: Comparing delivery time with two and six nodes network at two different robots.
Although the delivery time increased with more robots in the network, both networks, when comparing Robot 1 and Robot 2 delivery times, shown at Figure 22(b), are similar at both nodes. That result proves that the proposed broadcast protocol works equally for every robot, and even though the robots receive all sent packets, it correctly filters messages by the robot id.
4.3 TELEMETRY
Analyzing the control network with telemetry activated for the whole team, six robots, was crucial to confirm the ability to use telemetry at the games. The results, shown at Figure 23, had a higher gap between the delivery delay at a network with and without telemetry when compared with the tests realized with one robot, shown at Table 6. The increased gap shows a delay coming from the base station higher load of messages because now it needs to transmit six packets of control and six of telemetry.
Figure 23: Delivery time of Ethernet base station packets with different telemetry sampling time at 6 robots control network.
Although, the delivery time of the control network increased from 4308us, when it is without telemetry, to 4672us, when it is with a 50ms sampling telemetry in each of the six robots.
Now, with telemetry, it is possible to monitor the robot’s status, like the angular speed of each wheel on time, represented at Figure 24.
Figure 24: Angular speed on time of each wheel is the robot, monitored by the developed telemetry network.
42 42 42
5
CONCLUSION
In the context of houses, Industry 4.0, Internet of Things (IoT), and robotics, wireless communication is essential. It can share information across devices, give functionalities, or, like the soccer robots at SSL, may control mobile robots movements. Therefore, technologies and systems should be developed and integrated to fill the necessity present at each application developed. Although there are no perfect modules or technologies, there are options to find a balance that maximizes the desired efficiency at each application.
At robotics systems, the challenge is higher. Besides the perception and cognition, there are tasks like wireless communication, which is fundamental to accomplish real-time motion control at the robots. At communication wireless, this work proposed architecture of the base station that efficiently controls the RobôCIn’s SSL robots. The work reviewed modules and interfaces to reach a system architecture that, when analyzed in a real robotics soccer environment, fulfill the requirements.
The results show a system that reached 4.33 milliseconds of latency at robot when it is on a six robot network. Only the Ethernet base station proposed reaches that latency, and it is almost three times faster than the serial base station. What endorsed the benefits of using a faster and updated interface of communication, even between the computer and base station.
Even though the number of robots in the network increases the latency proportionally because the station should divide its throughput to more robots, continuously emitting messages at one, two, and six robots’ networks, showed consistent message reception and consistent latency. Even when measuring in two different robots and also at different distances from the base station, the proposed network delivered at least 230 messages per second, faster enough to SSL competition, that usually uses 60 fps cameras.
When developed the telemetry at the robot and base station, the delivery time of the packets in the six robots’ network, with 50ms of telemetry sampling enabled, reached 4.39 milliseconds. This latency permits the delivery of 227 messages per second per robot. Moreover, although 4.39 milliseconds represents an increased of 1,39% compared with the network without telemetry, the telemetry network brings the benefit of monitoring each robot and should avoid failures and increase precision.
Results reliability working with wireless networks is trick, because many phenomena
may occur and noise the results. So, every test made measured 30 receptions intervals, and each interval is the average time between the delivery of 500 packets. This amount of measures in a real environment statistically endorse the real-time network efficiency, which also has telemetry ability at each robot.
With the results shown at this work, the RobôCIn team already used the proposed network at the Latin American Robotics Competition (LARC) - 2019. Without any failure or delayed control, it was a pleasure to see the team using the proposed network to control and monitor its robots. At the competition, RobôCIn did not play any match with malfunction robots due to telemetry. The robot status, received at the computer, enabled the team prevent robot’s failures before and during the game. This work also brought to RobôCIn a quickly maintenance and consistency in the championship.
After the RobôCIn’s experience, the proposed network proved its ability to support multiple devices in real-time and is suitable for IoT and Industry 4.0 applications.
For future work, a study of new modules and its technologies should be considered to speed up the network data exchange. Moreover, future work may find alternatives to reduce the delivery time impact when adding more robots to the network. Changes like the embedded boards or different interfaces may increase the network cost but may reduce the delivery of the whole system. Together with bets specifications, future work may develop an automatic time analyzes that search the optimal parameters using the hardware in the loop.
