COM, DCOM y COM+

This section discusses the software interfaces between ROS and the sensing systems. Section 4.2.1 explains the Laser Range finder interface, section 4.2.2 discusses the Sensor Board interface and section 4.2.3 details the Kinect interface.

4.2.1

Laser Range Finder

As explained in section 3.1.2, MARVIN has inherited the Sick LMS100 laser rangefinder. This sensor communicates with with the NUC control computer using an Ethernet connection, via a USB to Ethernet adaptor. The lms1xx node [56] is utilised to interface the LMS100 with ROS to provide unprocessed LaserScan messages in the laser/scan/raw topic. This is shown by figure 4.3.

Due to the mounting position of the LiDAR, it can detect parts of MARVIN’s body. This results in false obstacles being detected, which prevents the navigation stack from operating correctly. To avoid this, the laser/scan/raw messages are first passed through a laser filter [57]. The configuration file for this filter is shown in figure 4.4.

scan_filter_chain: - name: laser_cutoff type: laser_filters/LaserScanAngularBoundsFilter params: lower_angle: -2.0 upper_angle: 2.0

Figure 4.4: The configuration (.yaml) file for the laser filter.

In this configuration the laser filter is set to a LaserScanAngularBoundsFilter, which removes all readings outside the angle range −2.0 to 2.0 radians. This removes the outer regions of the scan, which have detected MARVIN’s body.

Finally the laser/scan/filter marvin messages are passed through the ground - filter node, discussed in section 4.3, to account for the effect of the Segway’s pitch. These processed laser/scan/filter ground messages can then be used by the algorithms in the navigation stack, as explained in Chapter 5.

4.2.2

Sensor Interface Board

The whisker sensors, ultrasonic network and the Kinect’s tilt servo are all interfaced with ROS via the interface board mentioned in section 3.1.2. This sensor interface board processes the sensor data and transmits it to control NUC via serial communication. This process is shown be figure 4.5.

Figure 4.5: Block diagram of the sensor board’s software interface.

The interface board communicates with ROS by utilising the rosserial li- brary [58]. rosserial provides standardised methods for communicating through serial using ROS messages. The ultrasonic sensors’ and whisker sensors’ output pins are read by the Arduino, then processed with a rolling window filter to reduce noise. The processed data is converted to Laser- Scan messages and sent to ROS via the /ultrasonic network/scan/raw and /whisker sensor/scan topics. The /ultrasonic network/scan/raw messages are then further processed inside ROS by a ground filter node, as explained in section 4.3. These processed messages are then accessed by the navigation stack via the /ultrasonic network/scan/filter ground topic. The whisker sensor messages are used by both the movement control node and navigation stack, as explained in section 6.1 and Chapter 5 respectively.

The Kinect’s tilt servo is controlled using the Arduino servo library [59].This allows the Kinect to be tilted to 180 different positions and is set with 8-bit integers from the /sensor board/kinect tilt topic.

4.2.3

Kinect

As explained in section 3.2.1, the Microsoft Kinect V2 RGBD camera is used to meet the 3D sensor objective (1b). As Microsoft developed the Kinect to run on Xbox One consoles and Windows computers, there is no native support for Linux or ROS. In order to interface the Kinect with Linux the open source libfreenect2 driver [60] is utilised. This driver is bridged with ROS using the iai kinect2 package [61]. This package uses the OpenCL framework [62] to enable the connected computer’s GPU to process the Kinect data. Without OpenCL support the Kinect data is processed with the CPU. This causes it to run at low frame rates (less than

1 Hz) which renders the sensor unusable for obstacle detection purposes.

An open source implementation of the OpenCL specification, Beignet [63], was installed to enable the OpenCL libraries to run on the NUC’s integrated Intel GPU.

The kinect2 bridge node from the iai kinect2 package communicates with the Kinect and uses ROS image transport [64] messages to publish the depth and colour images. A depth image is a 2D grey scale image, where each pixel represents depth (the distance from the focal point of the camera to the measured point). The standard definition depth image (512×424) is the primary image used by MARVIN and is published to the /kinect2/sd/image - depth topic. This topic is subscribed to by the kinect pipeline node, as shown in figure 4.6.

Figure 4.6: Block diagram of the Kinects’s software interface.

The kinect pipeline node has three functions; it processes the depth images (explained in section 4.4.1); produces LaserScan messages for the navigation stack (also explained in section 4.4.1); and sends commands to the Sensor Interface Board to control the Kinect tilt servo.

As explained in section 4.2.2, the Kinect’s tilt servo is set with 8-bit integers. The kinect pipeline node receives angle requests from the /kinect2/angle topic, which are in degrees, and converts them into 8-bit tilt value using equation 4.1.

T = mangleθ + cangle (4.1)

where T is the tilt value and θ is the requested angle. The constants mangle

and cangleare calculated during the auto calibration process explained in