Generalization of the ExSce Management

ExSce Workbench

The scenario specification and acceptance criteria using the Behaviour Driven Development (BDD) tools in the workbench are compatible with the ExSce Management approach and tools. As mentioned in the Scenario Specification, the only thing that is required is a transformation from the specification format to PROV, which in the case of the BDD tools, are the transformation of the instantiated scenarios into the scenario PROV and the oracle configuration. Figure 1 shows how this process for the BDD specification. The BDD fluents and constraints should be reflected in the implementation of the monitors, that is, the output metrics should be collected conforming to the BDD scenario description by (over)writing the metric methods in RobotMetrics and MissionMetrics as described in the Tutorial.

Figure 1: Transformations of the BDD tools in the ExSce Worbench (in blue) for the ExSce Management approach

The ExSce Management has been fully integrated with the Floorplan DSL. Scenarios in this deliverable use the occupancy grids and gazebo models generated from the DSL. Furthermore, the examples for scenario_a and scenario_b employ tasks generated by the Floorplan DSL. This integration opens the door to creating new scenarios based on environmental variations, such as the open/closed status of doors and the location of obstacles in the environment. Similarly, if available, the ExSce Management can exploit semantic information for the metamorphic relations, e.g. the estimates we make in the absence of baseline data look for poses in the same room or area.

Simulation-based testing

Fuzzing approaches presented in D6.2 are input transformations which could be composed into a metamorphic relation, e.g., so that we validate whether or not safety violations occurr in a simulation-based test. Fuzzed tests could, in general, use the safety invariant relationships to ensure that corner cases do not result in undesired or unexpected behavior. For performance metrics, a careful consideration of the effects of the fuzzing operation would be required and, most likely, both monitors and estimates would need to be adapted.

Generalizing to other use cases

As mentioned in the Scenario Specification, abstracting the task specification allows us to reuse some of the scenario transformations to other domains or applications. For the Autonomous Pest Management use case, this means that how their tasks are specified (e.g., using formats of commercial software or custom specifications, such as the Plan from QGroundControl or the routes that can be exported/imported into the Ground Station Software from UgCS, the optimization parameters for the sensor fusion drone, etc.). For example, this means that we could easily specify a multi-UAV data collection as shown below:

Listing 1: An example of a data collection scenario with a sensor fusion drone for the Autonomous Pest Management use case

id: viti_data_collection_a
mission:
  id: viti_data_collection_mission_a
  type: parallel
  allocation:
    - robot: uav1
      pkg: viticulture_tasks
      file_path: tasks/data_collection_dkox.json
    - robot: uav2
      pkg: viticulture_tasks
      file_path: tasks/follow_data_uav_params.json
environment:
  id: dkox-vineyard-001
  robots:
    uav1:
      start_pose:
        id: home_pose-w001
        x: 11.7211
        y: 53.5011
        z: 0.0
        roll: 0.0
        pitch: 0.0
        yaw: 0.0
    uav2:
      start_pose:
        id: home_pose-w002
        x: 12.6870
        y: 55.1296
        z: 0.0
        roll: 0.0
        pitch: 0.0
        yaw: 0.0
robots:
  - robot_id: uav1
    robot_namespace: uav1
    robot_type: matrice_600
  - robot_id: uav2
    robot_namespace: uav2
    robot_type: matrice_210

A spraying task could be specified similarly, as shown in Listing 2.

Listing 2: An example of a spraying scenario with a sensor fusion drone for the Autonomous Pest Management use case

id: viti_spraying_a
mission:
  id: viti_spraying_mission_a
  type: parallel
  allocation:
    - robot: uav3
      pkg: viticulture_tasks
      file_path: tasks/spraying_route_a.json
    - robot: uav2
      pkg: viticulture_tasks
      file_path: tasks/follow_spraying_uav_params.json
environment:
  id: dkox-vineyard-001
  robots:
    uav3:
      start_pose:
        id: home_pose-w001
        x: 11.7211
        y: 53.5011
        z: 0.0
        roll: 0.0
        pitch: 0.0
        yaw: 0.0
    uav2:
      start_pose:
        id: home_pose-w002
        x: 12.6870
        y: 55.1296
        z: 0.0
        roll: 0.0
        pitch: 0.0
        yaw: 0.0
robots:
  - robot_id: uav3
    robot_namespace: uav3
    robot_type: agv2
  - robot_id: uav2
    robot_namespace: uav2
    robot_type: matrice_210

Note that these two scenarios are ROS-independent, and transformations, such as replace_robot to test different drone models would still apply. However, this still requires modifications to both adapt the methodology to non-ROS systems and to incorporate the domain specific knowledge of the task specifications, e.g. to properly invert the waypoints in a task, one must understand the semantics of the Ardupilot commands, and the specific syntax used by the software of these new SUTs.