//"0..*" cardinalities on relation destinations are left implicit 3D_simulation_of_an_SR-AS_and_its_environment_for_a_mission //"SR-AS": Search&Rescue Autonomous Systems /^ (3D_simulation /^ Process), //A direct supertype and an indirect one object: 1..* SR-AS, //SR-AS is detailed in Section 2 during: (Disaster_rescue_team_deployment time: "first hours after a disaster" ), //"...": informal representation part of: (Finding_a_best_design_and_configuration_of_an_SR-AS_for_a_mission part of: (Elaborating_a_disaster-recovery-management_strategy part of: (Disaster-recovery_management /^ Process) ) (Re-acquiring_knowledge_on_an_area_that_had_environmental_alterations part of: Elaborating_a_disaster-recovery-management_strategy ), result: (Assessment_of_an_SR-AS_for_a_mission_or_of_a_strategy_for_this_mission /^ Description_instrument-or-result-or-container, \. Best_design_and_configuration_of_an_SR-AS_for_a_mission Assessment_of_the_configuration_of_an_SR-AS_for_a_mission Assessment_of_a_disaster-recovery-mission_success_expectancy Assessment_of_how_much_time_or_the_SR-AS_saves_for_the_rescue_team Assessment_of_the_autonomous-system_survival_probability, example: "by properly modelling the light, it is possible to derive a different position of LIDARs with respect to the chassis of the rover depending by the time of the day, and thus estimate whether the LIDARs of the rover will suffer from the light" ) input: Representation_of_the_environment_of_an_area //cf. end of Section 2 (Objectives_of_the_Search-and-Rescue_mission /^ State, part: Disaster-result_state Disaster-victim-location_state ), instrument: (Software_for_simulating_an_autonomous-system_and_its_environment \. (3D_simulation_system /^ Description_instrument-or-result-or-container, \. (Gazebo-3D description: "graphic engine including a physical engine such as ODE; able to perform 3D physical simulations while displacing a rover within a surrounding virtual world, hence allowing to test algorithms, design robots and simulate their behavior; models are expressed with a XML-like syntax following SDF specifications", part: (Physics_engine \. Open_Dynamics_engine, part: Mathematical Engine, input: Scenario ) Open-gestures_recognition_engine Terrain-data_generating_engine (Graphic_rendering_engine input: Texture Light Shadow) ) (Robot_Operating_System description: "software usable for the communication between robot parts. E.g., during the movement, the rover acquires pictures through a camera, which are sent through this ROS to a node that analyses them through the instruments given by OpenCV libraries. Depending on features such as the size and the properties of the wheels or the mass center of the rover, debris or rocks can modify the linear path of the robot. This can lead the rover to acquire blurry pictures, crooked pictures or pictures that are useless wrt. the target recognizing algorithm" part: (RViz description: "3D visualization environment for ROS") ) ), part: (Terrain_generation_and_modelling output: (Digital-Elevation-Model_of_the_terrain /^ (Digital-Elevation-Model /^ Description_instrument-or-result-or-container), part: (Final_Digital-Elevation-Model_of_the_terrain part: First_Digital-Elevation-Model_of_the_terrain ) ), part: (First_phase_of_terrain_acquisition_for_terrain_generation_and_modelling input: (Terrain_description /^ Description_instrument-or-result-or-container, \. Geographical-Information-System_data, result of: (Terrain_surveying_or_mapping \. Photogrammetry Land_surveying, instrument: //the next type is defined in Section 2 Sensor_artefact_that_can_be_used_as_terrain_mapping_instrument ) ), output: First_Digital-Elevation-Model_of_the_terrain ) (Integrating_objects_and_characteristics_to_the_simulated_terrain_to_enhance_its_realism input: First_Digital-Elevation-Model_of_the_terrain, parameter: Physical_property, //cf. end of Section 2 part: Analysis_of_properties_of_the_terrain_eg_roughness_density_bounciness_stiffness Generating_random_variations_of_terrain_properties_eg_via_Monte-Carlo_distribution Adding_real_obstacles_gathered_from_low-altitude-drone_flight, //rocks, rubble, ... output: (Final_Digital-Elevation-Model_of_the_terrain description: "this includes a 3D CAD design, ground parameters (bounciness, friction, stiffness, ...), existents data, characteristics features of rigid bodies, kinematics laws, coefficients that describe an impact, ...") ) ) (Robot_designing input: (Robot_design_description annotation: "description of the architecture (shape and geometry, e.g. via 3D CAD), physical_properties, behavior, sensors and actuators" ) ) (Environment_parameterization_in_the_3D_simulation input: Representation_of_the_environment_of_an_area ). //cf. end of Section 2

SR-AS = Search-and-rescue_autonomous-system, /^ Artefact, interest: "can reach locations unattainable or dangerous for humans", \. (Ground-based_SR-AS \. (ArcTurius_Rover annotation: "created by the LTCI laboratory of Tél&eacutre;com Paris", part: (Hokuyo_UTM-30LX_Scanning_Laser_Rangefinder_LIDAR annotation: "chosen for ArcTurius_Rover because this LIDAR supports the Robot_Operating_System (ROS) communication system" ) ) ), part: //there are many kinds of parts; below are examples (SR-AS_joint /^ (Joint /^ Concrete_spatial-entity_playing_a_role), \. (SR-AS_fixed_joint annotation: "no degrees of freedom") (SR-AS_hinge_joint annotation: "rotates along the axis and has a limited range specified by the upper and lower limits; can for example be used to describe the movement of a wheel with respect to the chassis to which it is attached"), annotation: "The modelling of joints (e.g. maximum efforts+velocity they can endure) is very important since i) this permits the integration of many physical parameters, and ii) they play a key-role in the physical integrity of the SR-AS after a collision" ) Actuator_artefact_that_can_be_a_useful_part_of_an_SR-AS Sensor_artefact_that_can_be_a_useful_part_of_an_SR-AS. //defined below Sensor_artefact /^ Artefact Sensor, \. (Sensor_artefact_that_can_be_a_useful_part_of_an_SR-AS \. (Distance_sensor_artefact \. Ultrasonic_sensor Micro-wave_sensor LIDAR Camera) (Location-and-attitude_sensor_artefact \. Inertial-measurement-unit_based_sensor_artefact) Odometer_artefact (Radar \. Ground_penetration_radar), annotation: "It is important to precisely model the sensors of an SR-AS (shape, size, mass, relative position wrt collision domain of the rover, ...), e.g. evaluating the positioning of a LIDAR in order to minimize the impact of external noise. With respect to sensor modelling, some parameters to be taken into account while modelling a laser sensor include: i) physical shape, ii) relative poses with respect to SR-AS components, iii) number of samples per unit of time, iv) angular resolution, v) minimum and maximum distance, and vi) interferences and noise (since sensors are sensitive to noise). For this last point, a Gaussian distribution with a moment parameterization (i.e., given the mean and covariance of the distribution) can be used." ), \. (Sensor_artefact_that_can_be_used_as_terrain_mapping_instrument \. (Satellite \. terraSAR) Drone (Radar \. InSAR) (LIDAR \. Hokuyo_UTM-30LX_Scanning_Laser_Rangefinder_LIDAR) ). Physical_property /^ Characteristic_or_dimension_or_measure, description: "e.g. one of the characteristics features of rigid bodies: mass, inertia, the respect of kinematics laws, any kind of friction, coefficients that describe the reaction to an impact, etc.". Representation_of_the_environment_of_an_area /^ Description_instrument-or-result-or-container, \. Representation_of_the_environment_of_a_disaster_area, description of: (Environment_situation /^ Situation, \. Weather Fire Season, attribute: Temperature Humidity Magnetic_fied Pressure Luminosity (Elevation \. Depth) ).