Low‐cost solution in international robotic challenge: Lessons learned by Tuscany Robotics Team at ERL Emergency Robots 2017

European Robotics League (ERL) Emergency Robots is an outdoor robotics contest focusing on multidomain emergency response scenarios. In this context, the deployed robots are expected to fulfill land, underwater, and flying cooperative tasks which emulate real‐world situations inspired by the 2011 Fukushima accident.

signal was available) and images/video to the control station during the run. Then, robots had to enter the building and find a safe path (a path that a ground robot can follow) to the machine room. An unobstructed entrance (at least 70 cm wide) had to be found first as well as a safe and unblocked path from the starting position of the ground robot. Robots had to create a floor (2D) or 3D map of the indoor part of the building.
Mission-C: Pipe inspection and stemming the leak. The cooling system was to use pipes that connected the reactor to the sea. After the staged earthquake and tsunami, these pipes might have been damaged, and substances might have been leaking from them. The valves that close and open the pipes were located inside the building in the machine room. If any leak or damaged was detected, the robots had to stem it by closing the correct valves.
The paper focuses on the development of a ground robot, but the missions are part of a broader context, where also air robots and underwater robots are involved to achieve tasks cooperating in a multidomain scenario.

| Aim of the paper
The participation of the Tuscany Robotics Team was significantly influenced by the irreparable damage (and resulting unavailability) of the Clearpath Husky UGV planned for use in the competition. This occurred 3 days before the challenge, during the first test session.
Since a minimum of one land, one aerial, and one underwater robot was required to participate in the Grand Challenge, the team moved toward building a new mobile platform from scratch in less than 2 days to compete in the challenge.
The unexpected damage of the Husky UGV involved not only the building of a new ground robot, which demanded the planning of another design process in a rather short time, but required also a change in approach to the competition itself.
The purpose of this paper is to provide a complete technical description of the work conducted to create a fresh system on the competition field, in a short amount of time. From a technical point of view, the adopted solution, described in detail in the remainder of the paper, is based on the same pillars characterizing most of the related works for a low-cost platform, namely: • Adoption of open-hardware and open-software technology, providing cheap and fast-prototyping solutions.
• Use of smartphones, allowing sophisticated sensors to be exploited in an affordable way.
• Employment of Cloud infrastructures, to reduce the computational burden of offloading heavy processes.
The achieved results allowed the team to obtain fourth place in the overall standings and to receive the Creativity Award from the competition committee.
Finally, the results of this experience represent a concrete demonstration that quality of robotic technologies is growing fast, and low-cost solutions that can achieve favorable complex task scoring in the European robotic competition are available.
The paper is organized as follows: • Additional low-cost solutions for robotic applications are presented in Section 2.
• Overall developed system is detailed in Section 3.
• Results, in terms of successes in the competition tasks, are reported in Section 4.
• A posteriori discussion with lessons learned is presented in Section 5, and the conclusion is given in Section 6.

| RELATED WORK: LOW-COST ROBOTIC SOLUTIONS IN LITERATURE
A key feature of low-cost solutions is undoubtedly the use of remote or Cloud resources. Mohanarajah, Usenko, Singh, D'Andrea, and Waibel (2015) presented architecture, protocol, and parallel algorithms for collaborative 3D mapping in the Cloud with affordable robots. The lowcost (<$600) platform consisted primarily of a differential drive base (iRobot Create), an RGB-D sensor (PrimeSense), an advanced RISC machine (ARM)-based single-board computer (ODROID-U2), and a dualband universal serial bus (USB) wireless device. All processes were managed by Rapyuta (Mohanarajah, Hunziker, D'Andrea, & Waibel, 2015), a Cloud robotics framework that runs in a commercial data center.

| SYSTEM
The new system was built upon the low-cost chassis lent by the ENSTA Bretagne team, with adaptation of software modules already developed.
The resulting platform QUick Operative Kiddie KArt (QUOKKA, name inspired by the homonym animal 8 ) is a remotely controlled mobile platform, depicted in Figure 3. It is composed of several modules: chassis, Intel NUC, Arduino board, webcam, smartphone, and Li-Po batteries.
The remainder of this section details the hardware, firmware, and the entire software architecture of the system.

| Hardware and firmware
The developed low-cost prototype was built on the GM 4WD Crawler Punisher chassis, along with some assembled components of the original ground vehicle. Figure 4 reports an overview of the connection scheme adopted to build the platform. In the following sections, a detailed description is given for each component.

| GM 4WD crawler punisher platform
The low-cost chassis, provide by the ENSTA Bretagne team, is a commercial product from Graupner/SJ GmbH. It is typically used as a mobile base for off-road remote-controlled vehicles. Composed of a F I G U R E 2 Andruino-A1 robotic base (top) and Andruino-A1 mobile robot (bottom), source: López-Rodríguez and Cuesta (2016) [Color figure can be viewed at wileyonlinelibrary.com] metal chassis, four steering wheels, and a suspension system, the base proved suitable for the different terrain types encountered during the competition. The structure (Figure 4, center-right) is equipped with two RC 390 brushed motors to provide a four-wheeldrive system, a regulator with cooling fan, and two GM S3660 servos for steering functions.

| Arduino firmware
The low-level motor control is implemented on an Arduino MEGA, which processes incoming commands through a serial communication to obtain basic movements. The firmware was developed with the aim to have a reliable working module in a short amount of time. Thus, it was developed under strict constraints of reduced development and testing time. For this reason, its architecture was intentionally kept as simple as possible. The firmware continuously listens to the serial port, executing one of eight distinct functions. Specifically, forward and backward control the brushed motors, left and right use the servos to steer the wheels, increment and decrement, and stop control the speed, and the last function acts to straighten the wheels up. Additionally, as a low-level safety mechanism, the commands must be sent at least at 1 Hz; otherwise, the motors are stopped.

| Vision and communication
The LOGITECH Webcam HD PRO C920, previously used on Husky UGV, is mounted in front of the chassis to provide the real-time video streaming used for teleoperation feedback and image analysis. The position is fixed and orientated to give the best field of view regarding both the floor and the building wall. A smartphone (Lenovo Vibe P1m) is used to communicate with the ground station through the 4G protocol. This technology allowed operation of the robot all along the competition field, both outside and inside the building. It is worth noting that all the other teams 9 used expensive WiFi antennas to cover the entire area, and they experience frequent connection problems and interference. This solution was already discarded by our team after the first day of on-site testing. The use of the 4G technology allowed us to deploy a communication infrastructure, which was reliable, fast, and cheap and avoided the need to modify the environment with the installation of additional networking devices. Thus, we prevented the connection problems experienced by the other teams. In addition, the smartphone was used not only to connect the platform to the system but also to provide and send the current GPS location of the robot to the ground station.

| Computing system
The computing system is represented by an Intel NUC D34010WYKH, equipped with an Intel Core i3-4010U processor, dual rear-panel USB 3.0 ports, a 19-V (65-W) direct current power connector, and a mechanical chassis size of 116.6 mm × 112.0 mm × 49.5 mm. Ubuntu 16.04 was chosen as the operating system, along with the robot operating system (ROS) framework (Quigley et al., 2009) due to its flexibility and easy communication module interface, including a large collection of tools and libraries. Thanks to its portability features, the adoption of ROS allowed us to reuse part of the software already developed for the damaged UGV. The USB 3.0 ports were used to connect the Arduino MEGA and manage the serial connection, webcam, and mini USB adapter for the smartphone.

| Battery
The entire system is powered by two portable batteries. A LiPo 2S, 8,000-mAh, 7.4-V battery is used for the brushed motors and servos, while an XTPower MP-32000 with an output of 19 V/4.5 A is connected to the NUC, which also powers the Arduino and the webcam through the USB 3.0.

| Software architecture
The software architecture of the entire system includes the QUOKKA robot, ground station, and remote Cloud resource (see Figure 5). The architecture, already presented in Manzi et al. (2016), is designed to have real-time performance and interoperability features. In fact, it relies on the WebSocket protocol and on the ROS framework. The first provides a full-duplex communication channel over the hypertext transfer protocol (HTTP) suitable for real-time data transfer and is widely supported by modern browsers that can be easily used as graphical front-end. The latter represents the de facto standard robotic middleware.
In this system, each of the three components operates on a different network. While the Cloud virtual machine (VM) has a public IP address, both the ground station and the robot are not directly accessible.
Generally, a common solution to solve this issue is to set up a virtual private network (VPN), which extends a private network across the F I G U R E 5 Software architecture of the complete system. It includes the QUOKKA prototype, ground station, and remote Cloud resource. QUOKKA: QUick Operative Kiddie KArt; ROS: robot operating system [Color figure can be viewed at wileyonlinelibrary.com] public network. However, establishing a VPN is not a straightforward operation, and all the agents that want to access the system must be set up with it. To overcome this limitation, this architecture uses the "ssh tunneling" mechanism, which allows forwarding of a transmission control protocol (TCP) connection only (Manzi et al., 2016). It has to be underlined that the solution described in this paper is still based on configuration methods, as in the case of VPN configuration, rather than on implementation of new software. The rationale beyond this choice is based on the aim to achieve a reliable system starting from mature technologies already available.

| QUOKKA software
The mobile platform runs a minimal set of ROS nodes to keep the system light and fast. Details of these modules are provided below.
Arduino controller: As anticipated in Section 5.4 and summarized in Table A1, the autonomous navigation software was not installed on the new prototype, due to the limited time and lack of sensors (i.e., encoders and laser scanner). Therefore, according to ERL Emergency Robots 2017 rulebook, the teleoperated mode was selected as the only viable solution. As described in Section 3.1, Arduino firmware was implemented to manage information received on the serial port, which interfaced with the motors. The connection between the ROS framework and Arduino was implemented upon ROS serial 10 package.
Basically, serial commands (viz., chars) were constantly sent at a fixed 5-Hz frequency. The code adheres to the ROS geometry_msgs Twist message standard to integrate the platform with the ROS ecosystem.
Rosbridge server: Provides the WebSocket transport layer, allowing web pages to communicate with ROS through JavaScript object notation (JSON) messages.
Web video server: Provides a video stream of ROS image transport topic that can be accessed via HTTP.
Camera: Interfaces with standard USB cameras and publishes ROS images, allowing compressed images as well to reduce the bandwidth usage.
To solve the aforementioned visibility issue between different networks, a dedicated program executes a "reverse ssh tunneling" on the Cloud VM. This solution allows the robot simply to connect to the Cloud, without becoming part of its network. Hence, the rosbridge and web video servers have their own "tunnels," which are accessible from other networks with Internet access.

| Cloud resource
The remote resource was implemented on the Microsoft Azure Cloud, running a Linux VM equipped with Ubuntu 16.04 and the ROS framework. The VM at our disposal was a low-power machine with one core and 0.75 GB RAM. The role of this Cloud Resource is twofold.
First, it acts as a bridge for the different networks, namely, the 4G connections of the robot and the ground station, providing the tunnels for communication. Second, it runs the objects of potential interest (OPI) classifier. Hence, the VM contains two modules: the ROS node classifier and a WebSocket client written in Python to handle ROS images.
The classifier is a basic convolutional neural network (CNN), which implements an architecture similar to the LeNet-5 (LeCun, Bottou, Bengio, & Haffner, 1998). The choice of such a simple architecture is driven by the fact that the competition requires recognition of only four classes, which also enables use of a relatively small dataset for the training phase. The CNN is implemented using Keras (Chollet, 2015) with Tensorflow (Abadi et al., 2015) as a backend. The network takes as input a 180 × 180 RGB image and has a total of four layers: two convolutional layers and two feed-forward fully connected layers (see Table 1

| Ground station
To improve the usability of the operator charged to monitor and manage the robot during the challenge, a ground station laptop was equipped with a web-based graphical user interface (GUI) that was used to control the platform remotely.
The ground station GUI was implemented on the ROS package rosbridge_suite 11 and shows both the video streaming from the robot   Furthermore, the implemented low-cost solution was one of the four teams (among seven) that were able to:

| RESULTS
• Enter the structure (robots find a safe and unobstructed path to the unblocked entry of the building for a ground robot; from the starting point, a ground robot follows a safe path to the unobstructed building entrance; a ground robot enters the building through the unobstructed door).
• Enter the machine room (from the building entrance, a ground robot follows a safe path to the machine room; a ground robot enters the machine room).
• Perform real-time recognition automatically (a robot localizes the unobstructed entrance in real-time in automatic way).
• Localize all four OPIs related to obstructed entrances and damages on indoor walls (robots localize the obstructed entrances; the ground robot(s) recognize the damages on the wall of the building).
In a deeper analysis, it can be highlighted that, considering the actual hardware configuration without laser sensors and manipulator, only 19 tasks can be accomplished concretely (success rate~74%), namely. In particular, the tasks that cannot be achieved were as follows: • A ground robot reaches the WayPoints within a precision of 3 m in autonomous navigation; not possible due to lack of navigation sensors (laser, odometer, and so forth).
• A ground robot deploys the first-aid kit (within radius 1 m) from the worker inside the building; carriage of first-aid kit not possible due to the reduced size of QUOKKA platform.
• The ground robot(s) builds a geometric indoor map of the building; not possible due to lack of mapping sensors (laser).
• A ground robot closes the correct valve. The robot must close one valve of the set autonomously and the other one manually; not possible due to lack of manipulator.
• The ground robot and the underwater robot close the correct valves in a synchronized process; not possible due to lack of manipulator.
The best performance on the same available tasks was 18 of 19 (success rate:~94%). In other words, compared with the best available results, the solution developed here was not able to As a final result, the team ranked fourth among seven teams, with a difference of two points with respect to the third place.
The ranking is based on the overall performance in the three domains (sea, land, and air).
Furthermore, the Tuscany Robotics Team was honored with the Creativity Award, given by Prof. Bernd Brüggermann from Fraunhofer FKIE, "for building a land robot from scratch in less than 2 days when their ground platform broke" (see Figure 9).

| LESSONS LEARNED
The lessons learned range from technical solutions to planning methodologies and human experiences. In the following sections, some guidelines useful when reacting to unexpected events are provided. In particular, it is evident that tests conducted in a | 595 laboratory environment are not always enough to face the issues that arise in the real world. Hence, thinking from a new perspective, outlining a strategy according to the available resources, and designing a system with adaptability features are fundamental aspects to achieve of sound results.

| "Thinking outside the box"
During the competition, the Tuscany Robotics Team had to face irreparable damage to the UGV platform, and thus had to find a way to address the situation by thinking from a new perspective. The unexpected condition forced out team to look for solutions that were not part of the initial master plan.
The concept of "thinking outside the box" proposes a restatement of the solution strategy: The heart of the matter is the unspecified barrier that people typically perceive. Specifically, it concerned designing a new platform in a short amount of time, trying to optimize the available means, "reshuffling" of resources, and searching for and inserting new elements: • Low-cost chassis lent by another team participating in the competition.
• Replacement of GPS and connectivity hardware with a smartphone, a device available in every team member's pocket.
• Shift of computational power on a remote infrastructure, reducing the computational costs of the limited onboard device.
The lessons learned in approaching a realistic robotic competition, and, more generally, deploying a system in real conditions, can be summarized in "expect the unexpected" and always be ready to face adversity, and avoid discouragement and giving up by "thinking outside the box."

| Platform-based strategy
The methodology behind the participation in a robotic competition should always include the definition of a detailed master plan that the human operator of the robot must follow. In this strategy, the order of the tasks to accomplish must be defined. Particularly, for each task, it is important to consider the weight of the system (points from the rulebook) and the reliability of all the platform features involved in that particular task.
The use of a new platform with different and limited features meant that the tactics had to be replanned. This analysis, which occurred before the competition, allowed the operator to clarify the strategy to adopt and to optimize the successful tasks. It is worth noting that the QUOKKA platform was never tested on the competition field before the competition, while the other teams had 3 testing days.

| System adaptability
In addition to the resiliency demonstrated by the team to manage the unexpected events, the obtained results were achieved, thanks to the adaptability of the developed system. Specifically, it was conceived by focusing on three main features that made the system more flexible to dynamic changes: Dynamic settings of video streaming: The ground station GUI permits the operator to adapt the quality and size of the video streaming to manage possible network instabilities introduced by a moving platform.
Machine learning classifier: The use of a CNN allows use of a classifier can generalize having good performance despite the unknown samples. In fact, even with the unavailability of a dataset built with the competition samples due to the missed test days, the classifier was able to recognize the OPIs (see Figure 7).
Software interoperability: The use of the ROS middleware led to hardware abstraction, which was a key element for quickly reusing the developed software on a different platform with fewer efforts.
Furthermore, the adoption of the rosbridge library for the communication between the machines of the system (see Section 3.2), facilitated the migration of the classifier from the original robot to the remote resource. As a matter of fact, the abstraction performed through the use of ROS framework was the key to reuse most of the software already implemented, as detailed in the next section. The lesson learned is that "moving from labs to the real world" always introduces aspects that are difficult to foresee. Because of this, the development of a system which is easily reconfigurable on-the-fly with adaptability and interoperability features represents a fundamental aspect which should not be underestimated.

| Reshuffling of resources
After the breakage of the main UGV, the team investigated the reason for the fault, and found an electrical failure that was impossible to repair during the competition (controller area network [CAN] motor board damage). Consequently, a brainstorming activity to analyze the situation was conducted. Subsequently, the team decided to build a totally new platform from scratch to continue in the competition. Due to the limited amount of time and resources, the only feasible solution was to make a low-cost prototype. In a display of good sportsmanship, a lightweight chassis was lent by the ENSTA Bretagne team. Thus, an analysis of the resources still available and reusable was performed. The result of this reshuffling process is summed up in Table A1.
It is worth noting that the damage of a fundamental UGV component compromised the use of most of the original hardware (i.e., motor board and motors). Furthermore, the use of a lightweight and low-cost chassis made reshuffling of several devices, such as the UR5 robotic arm, SICK and Velodyne laser scanner, and Novatel GPS, impossible, mainly due to their weight and power consumption.
Nevertheless, lighter hardware components became the basis for the new low-cost platform. For instance, the Intel NUC, planned to be used as support to the main computational device, turned into the new control unit, powered by the Li-polymer 32,000 mAh battery, originally used as complementary power supply for additional devices (e.g., amber emergency light).
Contrarily, most of the developed software (i.e., low-level teleoperation control, web-based GUI, object classifier, video streaming module, and communication infrastructure) was completely reused without (or with few) modifications and with minimal effort. Exceptions involved the software modules for unusable hardware, such as mapping and autonomous navigation based on laser measurements.

| Scheduled bottom-up development
The decision to build a new prototype from scratch with limited time and resources required careful definition and scheduling of the work plan to closely monitor the entire process. A Gantt chart is shown in Figure 10. The chart details all the steps that occurred during the competition days. Note that meal breaks were conceived as "milestones" for internal briefings and fast brainstorming activity.
Basically, the work plan was organized as a pipeline, where the activities were serially performed, except for the high-level software migration done in parallel with the hardware/firmware development. This was primarily due to the dearth of human resources and to the prerequisites between activities (e.g. motor firmware implementation could not start before the end of necessary electrical tests). Furthermore, it is worth noting that the development process followed a bottom-up approach. This is driven by the fact that the approach is particularly suitable because the new system starts from existing modules. In fact, the reusability of code is one of the main benefits of the bottom-up approach, which emphasizes also the coding and early testing (Gamma, Helm, Johnson, & Vlissides, 1995).
After 2 days, the new platform passed the competition safety check, and the entire system, including ground station and Cloud infrastructure, was further refined and tested. Unfortunately, no time remained to exploit early competition test sessions. Therefore, the prototype was directly used in the final challenge. It is important to emphasize this aspect in light of the obtained results.

| Low cost intervention
The QUOKKA platform was developed in response to an unexpected event in a short amount of time (less than 2 days), and was based on the reshuffling of available resources. As a direct consequence, the resulting solution was characterized by the use of (relative) low-cost elements. This section outlines a cost evaluation of the prototype, providing an optimization of the adopted hardware using currently available commercial devices.
Chassis: The cost of the GM 4WD Crawler Punisher is €168.99. 13 Cheaper solutions can be found in the market; however, the used chassis represents an acceptable trade-off between cost and semiprofessional performances. Similar solutions provided by the same manufacturer can offer more powerful devices but at higher costs. 14 F I G U R E 1 0 Gantt chart used to represent the activity schedule to perform as a reaction to the unexpected breakage [Color figure can be viewed at wileyonlinelibrary.com] Intel NUC, this battery can also be used to power the main computer system. 4G connectivity: During the competition, a team member's low-cost smartphone (~€150) was used to provide 4G connectivity to the platform. Nevertheless, most telecommunications companies offer a tariff plan including a portable device at approximately €10 per month.
GPS device: The sensor included in the smartphone was used during the competition to provide the current position of the robot remotely. The least expensive solution that can be found in the market is the GlobalSat USB GPS receiver (~€24.95 17 ).
Remote PC/Cloud infrastructure: The Microsoft Azure Cloud was used as provider of VMs. The cost of a standard instance (1 core; RAM: 3.5 GB; hard disk: 50 GB) is negligible (€0.125/hr). 18 The optimized costs for the QUOKKA platform are reported in Table 2. The overall cost of the developed prototype is approximately €320. Obviously, the detailed costs of the other UGV participants cannot be provided. However, from a qualitative analysis, the costs of the original Husky platform, which is approximately €50,000, including arm and sensors, can be considered in the average of the competition opponents. In conclusion, the low-cost QUOKKA platform was able to achieve 19 of the 23 tasks achieved as the best result of the competition (~83%), at a cost two orders of inferior size of magnitude less than the competition. The team developed a low-cost platform in less than 2 days and in a short amount of time, reshuffling the available means and replanning the overall competition strategies.
Concerning the competition results, the work conducted has demonstrated how a low-cost solution can achieve a level of performance comparable with expensive solutions (the team ranked fourth among seven opponents, achieving~83% of the tasks accomplished by the best performer). In particular, the use of the remote Cloud resource and the 4G connection represented a completely different approach to the competition, and enabled drastic reduction of costs while improving the reliability of the overall system. Finally, from a personal and subjective point of view, despite the short duration of the event, the knowledge and experience gathered during ERL Emergency Robots 2017 cannot be easily assimilated through other forms of professional growth (classroom lessons, research in the lab, academic conferences, etc.). In other words, the participation in international robotic challenges is a worthwhile activity that should be promoted and supported in any research department, whether academic or industrial, and public or private.