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 the robot must reach to get to the final position. In case the obstacle avoidance gets the robot to far from its track and close to another node, it restarts the navigation from this node.

PotentialField produces a speed reference (vx,wz) to try to reach a target (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).

The module figures out which of PCL or 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" occupancy grid 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 of adding them all.

SafetyPilot is getting the speed produced by PotentialField and is responsible to stop the robot in case, despite PotentialField, it is getting too close to an obstacle. Moreover, it reads (at all time) the joystick commands and as such the user car take control and override the PotentialField speed. 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 Osomosi experiment).

rmp440 is the basic component in charge of the low level hardware robot controller. For historical reasons, it also includes a gyro (which could be deployed in a separate module). It tracks a speed port (usually the one produced by SafetyPilot) and send this linear.x angular.z speeds to the robot controller. The Gyro angle, and angular speed are produced in a or_pose_estimator for pom to integrate. There is also a JoyStick mode to move the robot around when rmp440 is not tracking a speed ref.

velodyne is based on the version used in the infuse project. However, it has been quite extensively modified. It is now implemented with 3 GenoM tasks: acquisition (grab the packets from UDP); pose, which collect subsequent pose from the robot (from pom); and scan which build a PCL scan with the packets properly re positioned with the closest pom pose collected. Note that the module produces 2 PCL GenoM ports, one inspired from the original ASN one (and this is the one used by PotentialField and SafetyPilot), and one which is a masquerade of ROS PointCloud2. So we can display this one in rviz, when the modules is using the ROS middleware.

joystick publishes the status of the joystick buttons and axes. These are used both by rmp440 and SafetyPilot to take control of the robot. The original module is here.

GPS publishes a gps position. With an rtk base, it provides a very accurate position. For the BIP experiment, we had to slightly modify the specification to cope with a BIP model pitfall. The FIACRE version uses the original module specification which is here.

IMUDriver publishes the angular velocity and acceleration. This can be used by pom.

pom provides an UKF filtered position from various state estimators. In this case, x, y and z are provided by gps; yaw, vx and wz by rmp440; and angular vel and linear acc by IMU . The original module is here.

tf2 is a module which was started as a bridge between GenoM or_pose_estimator and ROS tf2…​ and now publish various openrobot data structure (forces, speeds) in similar ROS standard topics. This allow then the user to display them in rviz and follow the experiment as it unfolds. It has now evolved to publish OccupancyGrid, Wrench, Twist, etc.