Documentation for the Validation and Verification of the OSMOSIS experiment using GenoM3 and various V&V tools/framework.
Below is a drawing of the robot setup. Most of the GenoM components are available as sub-projects.
Most components are common to both simulation and the real robot, even if some are on the robot only.
Navigation is in charge of the waypoints navigation of the robot. Given a graph of positions x,y,z, (even if z is ignored) with their connectivity, the module is able to produce a sequence of targets in the
targetport, the robot must reach to get to the final position.
RWLSensor is a mokup of a module used to check the airport RunWay light.
PotentialField produces a speed reference (vx,wz) to
try to reach the
target port (from Navigation), avoiding obstacles found in a Scan (a PointCloud from velodyne in
this experiment, or a LaserScan for other experiments). This implementation is heavily inspired from the following
paper (and the matlab code provided by the authors): Avoiding local minima in the potential field method using
input-to-state stability, 10.1016/j.conengprac.2016.07.008. The module figures out which of
Scan to use
according to which port is available. In the OSMOSIS experiment, it uses the scan from an Hokuyo LRF, with Minnie it
takes the Point Cloud from a Velodyne. It builds a "discretized"
OccupancyGrid and figure out where are the contiguous
obstacles. It produces a repulsive force, an attractive one and a V force (see the paper) and execute the result after
adding them all.
joystick publishes the status of the joystick buttons and axes. These are used both by rmp440 and SafetyPilot to take control of the robot.
SafetyPilot is getting the speed produced by PotentialField and is responsible to stop the robot in case, despite PotentialField avoiding obstacles, it is getting too close to an obstacle. Moreover, it reads (at all time) the joystick port so that the user can take control and override the PotentialField
PFCmdspeed. In fact, if the robot gets too close to an obstacle and stop, the joystick is the only solution to get the robot away from it. It produces a speed reference which is usually tracked by rmp440 (or RobotDriver in the OSMOSIS experiment).
RobotDriver we do not have the Robotnik source to fully implement this component. For now it is a proxy to get the
/odomtopic from the real robot controler (and copy them in the proper
Poseport), and provides the
/summit_xl_control/cmd_veltopic to the real controller from the SafetyPilot
LaserDriver tested with an Hokuyo UTM-30LX at LAAS and on the real robot. The simulator version (git branch
proxy_simu) will grab and copy the
sensor_msgs/LaserScantopics from Gazebo, and write it in the
GPSDriver, even if GPS driver was initially developped for this module (inspired by the same componend developped at ONERA) we would now use the one developped at LAAS, which is more versatile: gps. It publishes a gps
Poseposition. With an rtk base, it provides a very accurate position.
IMUDriver publishes the angular velocity and acceleration. This can be used by pom.
The figure below show all the components as well as their ports (produced by the component they are attached to, and
read by the component(s) with an arrow pointing to the port). For example the
pose port is produced by pom and read
by Navigation, RWLSensor and PotentialField.
There is also a simulation setup which can be used (instructions on how to install it can be found here ). It has less functional modules (as some of them are handled by the Gazebo simulator).