## 4 Experiment
### Evaluation of the Web of Things Approach  
The experiment described in the previous section focused on the validation of ASAWoO opportunistic communication capabilities, whereas the Web of Things aspect could not be tested at that time. WoT modules were nonetheless still validated in the later stages of ASAWoO development in another experiment, which is briefly presented in this subsection. During the Montoldre experiment, ASAWoO middleware mainly consisted of the Avatar core, the functionalities management and registry features (i.e., functionalities were advertised as RESTful services) as well as the opportunistic communication module. The second experiment was run in Bordeaux, France. It introduced the device manager and the semantic reasoning features to instantiate capabilities, simple and composite functionalities, as well as the WoT Application module. Unlike the farm experiment, which spanned over four months, this one lasted only one day. Since the communication module had already been validated in the long-run experiment, the goal was to validate ASAWoO final stage, particularly the WoT related modules (e.g., WoTApp manager, automatic instantiation of functionalities from device configurations and semantic repositories, etc.). This experiment was based on the same data collection WoTApp and the same hardware kits. Although the Raspberry Pi-based kits (with GPS module and Wi-Fi interface) were reused, this time the data mule was a robot, the Jackal all-terrain mobile platform ([[https://www.clearpathrobotics.com/jackal-small-unmanned-ground-vehicle/](https://www.clearpathrobotics.com/jackal-small-unmanned-ground-vehicle/)]([https://www.clearpathrobotics.com/jackal-small-unmanned-ground-vehicle/](https://www.clearpathrobotics.com/jackal-small-unmanned-ground-vehicle/))), on which was deployed an instance of ASAWoO hosting its own Avatar. Figure 10 shows a picture of the robot and the packaged base station kit on the experimentation field. In addition to its navigation capabilities, a camera was mounted on the platform. A ROS (Robot Operating System: [[http://www.ros.org/](http://www.ros.org/)]([http://www.ros.org/](http://www.ros.org/))) bridge interoperability module was developed for ASAWoO to expose these capabilities, which in turn enabled higher level functionalities such as person detection and video surveillance. The video surveillance and the navigation functionalities were then combined to provide a patrol functionality. The scenario written for this experiment consisted in making the robot patrol from sensor to sensor to collect data as long as it did not encounter a person. If the video surveillance functionality triggered an alarm, the reasoning module would give priority to the patrol functionality and use the navigation functionality to go back to a rallying point. This scenario is illustrated on ASAWoO code repository homepage ([[https://asawoo.gitlab.io/](https://asawoo.gitlab.io/)]([https://asawoo.gitlab.io/](https://asawoo.gitlab.io/))). During the experiment, all devices hosting an ASAWoO platform were accessible through their second Wi-Fi interface set on access point mode. When connecting to a device's main WoTApp, we could navigate through its neighbors and query their functionalities. Figure 11 presents a screenshot of the main WoTApp hosted on the robot. It features system functionalities (e.g., functionalities registry, neighborhood, device configuration and WoTApp deployment), as well as other Avatars whose remote functionalities can be reached through multi-hop asynchronous DTN RESTful requests. The screenshotshows a JSON-formatted GPS position in response to a GET request sent to a sensor's LocationService functionality. The retrieved sensor data were also displayed on the data collection WoTApp. It is worth noting that, although this paper mainly focuses on sensing functionalities, ASAWoO also supports actuators and the conclusions that we drew also apply to this class of devices.