## 4 Testing of the Solution
### Testing Activities with NI RoboRIO  
The testbed used for this activity is a hardware environment that replicates the communication with the Naiad AUV and the proposed middleware. Naiad is a custom-built system designed and manufactured by students and researchers at Malardalen University since 2013 [38]. The Naiad project aims at developing a fully autonomous system with advanced data processing capabilities on board including stereo vision using a dedicated FPGA. The current Naiad system is powered by NI RoboRIO [39; 40]. The rationale behind assuming powerful computing units in the design is related to the limitations found in underwater communications. Since the environment where AUVs are deployed is hostile in terms of power consumption and unreliability of the transmission medium, it is hypothesized that computing power is essential for a fully autonomous system in such an environment in order to collect and pre-process data, infer knowledge from them and finally take decisions similar to a human, i.e., when support from the outside world is absent. The low level components of the middleware are installed on the ODROID Xu4 external device [41]. Its general appearance has been displayed in Figure 7.  
Figure 7: ODROID appearance and interfaces, as depicted in [36]. Beforehand the environment on the ODROID was setup with ROS [42] and OpenSplice DDS [36], which is the C++-based version of DDS that had been tested previously in terms of compatibility: The system on the RoboRIO is being developed using LabVIEW. The communication between the components will use the TCPROS protocol [42], which is a TCP layer specifically developed for services and messages based on ROS. The overall appearance of the components installed was as shown in Figure 8.  
Preliminary tests simulate such communication scheme using a LabVIEW system installed on a Windows machine. Specifically, testing has been carried out with the low-level middleware continuously publishing data to the LabVIEW system, while simultaneously subscribes to data produced by the latter. The tests are run for 30 min. The round trip time for the transmission of the packets is calculated using Wireshark [43]. It can be seen in Figure 9 how messages were published at a high rate by the ODROID system, which acts as the AUV in a real scenario publishing information about the required features. Specifically, 15 data packets were published every second, which gives an idea of the publishing capabilities of the system. These tests were useful to show that the Publish/Subscribe mechanisms that have been created are way more robust than the message load they are expected to face. Higher transmission rates were achieved during the testing activities in the demonstrator. Figure 8: Middleware components used in the tests done with Windows Labview and Odroid. Figure 9: ODROID packet publication, as represented by Wireshark. Furthermore, if the roles are inverted, and the LabVIEW Windows system (which represents the CCS in the Publish/Subscribe communications) is the one publishing messages, its capabilities are the same than the ones that had been previously shown by the ODROID-based system, that is to say, 15 messages were measured as the ones transmitted through the network. The small variations in messages published can be regarded as insignificant due to the fact that the system is capable of publish more amount of information than the one that is expected to be present in an actual deployment. These results have been portrayed in Figure 10.  
Lastly, measurements were taken regarding the Round Trip Time (RTT) that would take for a message to be delivered and sent back.