Robot Operating System (ROS)

The INS sensor routine output is directly fed to the on-board computer via serial com-munication, where the Linux machine running Ubuntu 18.04 hosts the Robot Operating System (ROS), where the main stages of data processing take place.

ROS is an open-source, meta-operating system for robot software development;

consists in a collection of tools, libraries, and conventions that aim to simplify the task of creating complex and robust robot behaviour, across a wide variety of robotic platforms. It provides the general kind of services expected from a standard operating system, including hardware abstraction, low-level device control, implementation of commonly used functionalities, message-passing between processes, and package man-agement. Differently from a standard operating system it is extremely light-weight, and is oriented to rapid-prototyping of software components and software develop-ment. It is considered as a robotic middleware, so a software that connects different software-components and applications [40].

For its flexible characteristics and focus on collaborative robotics software develop-ment, ROS has become over the last 10 year a standard for robot programming, and it

Table 3.1: Retained ROS topics and ROS message types.

ROS topic ROS message type Message content

/imu/data sensor msgs/Imu IMU measurements from INS data

/imu/nav sat fix sensor msgs/NavSatFix Raw GPS data from GNSS receiver /imu/velocity geometry msgs/TwistStamped Linear and angular twist from INS data /imu/pos ecef geometry msgs/PointStamped ECEF position from INS data

/odometry nav msgs/Odometry ECEF pose and orientation

/odometry/gps nav msgs/Odometry GPS pose and orientation

/odometry/filtered nav msgs/Odometry Filtered pose and orientation /accel/filtered geometry msgs/AccelWithCovarianceStamped Filtered acceleration

is very interesting also for autonomous driving software development. The open-source collections of libraries and tools, together with its ecosystem and community, are at the base of the success of ROS as university-level autonomous driving framework and for the same reasons, it has been chosen for the deployment of the autonomous system under investigation.

For what concerns the localization stack, the fundamental data processing and filtering operations are performed by software components developed in ROS, called

“ROS nodes”. In ROS, the nodes communicate through “topics” on which each node can publish “messages”: ROS messages are predefined structures in which the data coming from a node is stored, and different data types can be carried by the same message. ROS messages contain different meta-data and information on their content, depending on the type of message. The ROS messages types considered in this section, are listed in Table 3.1.

When dealing with different sensors’ measurements as in the case of localization, ROS environment is also used as source of synchronization. ROS messages carry among their meta-data, the time stamp of the message in ROS time, which is associated to the CPU timing of the Linux machine. This time signal does not correspond to the time at which measurements take place, but it is the time at which the message is processed by the hardware driver. The time stamps of the messages coming from the INS sensor, are directly corrected by the sbg driver used in ROS, when an external timing signal is used. In the case of the localization pipeline, the external reference is represented by the GNSS timing. Through the GNSS antenna in fact, the sensor receives the time reference from the satellites and the CPU time is synchronized accordingly.

Synchronization is fundamental when dealing with information coming from differ-ent sources, and is at the base of the working principle of the transformation

conven-tions used in ROS for reference frames. In the following discussion, the term frame and frame-transformation will be introduced: in ROS, reference frames represent the moving objects at machine-level, so all the information needed to locate the chassis of the vehicle and the position of the IMU, can be retrieved by analysing the “TF tree”

or “transformation tree” message.

In the case of localization, the transformation tree is reported in Figure 3.11, and represents the three frames considered. The map and odom frames are created by the filters and represent the fixed frames, originating in the point in which the first measurement is acquired. GNSS positioning information must be transformed from absolute coordinates into the coordinates of the map and odom frames. The base link frame is the standard frame representing in ROS the chassis of the vehicle: it is obtained by the combining the knowledge of the IMU placement and the centre of motion of the vehicle. The frame associated to the IMU, is one of the information published by the INS routine and is called “UTC | SYNCH”, because is the frame associated to the synchronization of the sensor’s GNSS with the Coordinated Universal Time (UTC). In our case, this frame is processed by the odometry publisher node (3.3.2), and is not present in the complete TF tree of the system.

Figure 3.11: TF tree of the pipeline, from the fixed map frame to the body frame of the INS.