# End-to-End Automated Guided Modular Vehicle
## 6 Development
### ROS Integration  
Hardware architecture described previously in Section 5.1 was managed by the Robot Operating System (ROS), a collection of open-source software. It provides a wide range of computational tools such as low-level device control, process communication, hardware abstraction, and package management. ROS is based on the computational graph model, which allows a wide range of devices to run the same programs if they comply with some basic hardware specifications. The communication between platforms is straightforward and simple. Each ROS process is called a node, which is jointly interconnected through topics. A node is a hardware or software element that requests or provides data, which can be a single value or clustered elements. Data are sent through topics. An ROS Melodic Morena was used on an Ubuntu 18.04 OS [52]. Each element described in Section 5.1 was a node. The master node was a C++ or Python program used during the data acquisition and testing, respectively. This node subscribed to each input element: cameras (usb_cam), LIDAR (urg_node), and the gamepad (joy). It also published information via RS232 (rosserial) to an ATmega256. The microcontroller was also a node (rosserial_arduino). The master script used OpenCV, cv_bridge, image_transport, and sensor_msgs libraries in order to acquire and process the corresponding information. It receives information from the Nvidia Jetson AGX Xavier, and transforms this information into primitives for the actuators. For the training and test phases, a template was created. It retrieves and preprocesses information from the input nodes. The camera's images were switched from an RGB to BGR color palette, then they were resized and cropped. The LIDAR data were continuously compared with a safety factor; if the current measurement was within \(\pm 10\%\) of the safety factor, the vehicle would try to avoid the  
Figure 6: Test track satellite view. threat. However, if the measurement was not acceptable, the platform would stop and enter lock mode. The published data were sent using the RS232 communication protocol. The speed interval went from zero up to 30 km/h. It was normalized in a \(-4\) to 9 interval. This range was chosen according to the documentation of the modular platform. The sign of the integer determined the motion direction: negative backward and positive forward. According to the documentation, the steering values of the platform range from \(-20^{\circ}\) to \(20^{\circ}\). The microcontroller produces a Pulse-Width Modulation (PWM) signal, with a duty cycle that is proportional to the steering angle. The minimum value maps to the leftmost steering value (\(-20^{\circ}\)) with the value of 400, while the maximum is the rightmost, (\(20^{\circ}\)) with a value of 800. The brakes were activated with a Boolean. The data were gathered into a single string that contained the speed, steering, and braking setpoints. The microcontroller receives the string and parses it to acquire the desired setpoints. As the data were already in primitive values, the ATmega256 uses them as references for the open-loop or hysteresis control. For the training phase, synchronized data from each node were properly indexed and stored. This data was later used to train the CNN. The ROS low latency minimizes the time difference between samples coming from different devices. However, the process cannot be considered real-time. During the testing phase, data was added to the CNN and the output was published to the actuator. The trained model uses libraries for Python and C++ contained in Tensorflow and Keras [53]. The user supervises the proper performance of the system. A safety node was implemented using the gamepad, such that a button can be pressed to stop the software from executing and lock the modular platform. Figure 7 shows the overall ROS integrated system. The initial tests were performed with a high range computer with a Nvidia GPU. The ROS node integration worked smoothly.