Intel NUC

The Intel NUC is best suited to carry out the majority of the heavy processing, achieved through the aforementioned RDE called ROS. The HADES ROS nodes is written to achieve functionality for basic operation.

Figure 8.1 ROS node initialisation and main loop

A standard ROS node initialisation is carried out as per [113], seen on line 159 in Figure 8.1. The node constructor shown in Figure 8.2, instantiates and assigns data and variables, sets

142 initial actuator positions and creates the appropriate publishers and subscribers. The constructor then jumps to mainLoop, displayed in Figure 8.1 above. The main loop maintains a constant refresh rate of 10 Hz using the Rate function to synchronise with all other nodes through spinOnce and to regularly publish messages.

Figure 8.2: HADES node constructor

The ‘joy’ node is a pre-made package which runs on the operator’s laptop. The message it publishes to the joy topic contains information from the Xbox controller: Boolean data for buttons and Floats for the analog stick axes (between -1 and 1), shown in Figure 8.3. The HADES node subscribes to the joy topic. When a joy message is received, the callback function (Figure 8.4) stores this information in variables and calculates the pulse-width that should be sent to each motor. Buttons are processed first, they have three events: held,

143

Figure 8.3: Xbox Controller Button Assignment

The analog sticks are sensitive to movement making it difficult to gain fine control over HADES’ speed. To solve this, the maximum pulse-width is scaled by the LB and RB button. It begins between 1450 and 1650 μs long pulses (1500 μs is stopped/neutral) and can be increased and decreased by 25 μs to a maximum range of 1000 to 2000 μs. These buttons are

pressed and therefore require event handlers which monitor the previous button value to

detect a rising edge.

144 Each wheel should be controlled independently, as opposite sides are required to rotate in different directions (see Section 4.2.4). Additionally, HADES should be capable of reverse and rotating on the spot (zero turn-radius). This is achieved by rotating wheels on either side in opposite directions, realized in code with direction modifiers, see Figure 8.5. The brake, spin and reverse buttons all affect the direction modifiers. In order to rotate on the spot, the X or B button is held, depending on rotation direction. The reverse button is pressed and therefore also requires a similar event handler to LB and RB.

Figure 8.5: Spin and reverse logic

As a safety measure, the brake button should override control of the motors as displayed in Figure 8.6. This is implemented with an if-else statement than either assigns the calculated pulse-width or overrides it with 1500 μs. The pulse-width values are then published to the

Operate topic which the embedded controller subscribes to over Rosserial. A custom

145

Figure 8.6: Brake override and PWM signal calculation

Most of the internal and external sensor data such as temperature, pressure or gas concentration do not change at a fast rate. Therefore, the microcontrollers should only poll them once a second to prevent processing overload. As a result, the HADES node does not require a stream of sensor data. To allow the HADES node to request sensor data when it is needed, the operate message also includes flags. Internal monitoring, external environment and IMU sensors all provide a large amount of data which do not fit standard ROS message types. Three custom messages are created to handle this data: environment, imu, internal. They are published to the imu_data, environment_data and internal_data topics. When new data is required from a topic, the respective flag gets set high and the embedded controller publishes a message to the respective topic with the latest sensor data.

Before the webcams were removed from HADES, the libuvc camera ROS package was used as an interface [114]. Prior to the Kinect’s replacement, the iai_kinect2 ROS package provided drivers and software [115]. Both of these packages are no longer used. As Intel are providing direct support for ROS with the RealSense, a ROS package is available for integration and provides all the necessary functionality [116]

8.1.3 Laptop

A generic laptop connected to an Xbox controller is needed to operate HADES. As most of the processing is carried out on the NUC the laptop does not need special consideration and should be capable of running a simple ROS node and displaying a 720p video file.

146 Interfacing with and control of human-robot coordination is an established issue as identified by [72] and [2]. It is also illustrated in Section 5.1 with the ‘keyhole problem’. Implementing an effective interface for HADES is beyond the scope of this project but suggestions for future work can be found in Section 10.2.4.

Only a single node runs on the operator laptop, the joy node. This node uses Linux’s joystick drivers to interface with the Xbox controller. It then publishes the Boolean button and the Float analog stick data to the joy topic. For an operator to view the sensor data published to the internal, environment and imu topics, an additional node is not required. Instead sensor data can be printed in a terminal using ROS’ built in command: ‘rostopic echo topicname’. Additionally, the ‘image_view’ command can be used to display the video feeds.

8.2 Central Unit

Low level control is distributed across three intercommunicating microcontrollers, however only the central unit interfaces with ROS. The other two microcontrollers only interface with ROS by communicating information through the I2C master.

8.2.1 ROS Communication

The integration of the Rosserial C++ library through ros.h is required for the embedded controller to communicate with ROS. This library includes the functions to set up a node, publish and subscribe to topics as well as integrate custom ROS message types. A nodehandler and initialisation are both required during setup of the ATmega, as seen in Figure 8.7. C++ objects are created for each of the custom message types required. Publishers and subscribers are both initialised with their respective topics.

147

Figure 8.7: Central unit setup code

8.2.2 I

_{C Communication}

In order for the microcontrollers to communicate with each other and to allow power management and motor control to be carried out by the NUC, I2C communication is required as discussed in Section 7.3.1. To simplify this task, the ‘Wire’ C++ library is employed to carry out the I2_{C protocol at the hardware level [117]. The central unit is the I}2_{C master (no}

I2C address), as discussed in Section 7.3.2. The motor control and the power management ATmegas are the slaves (I2_{C addresses 0x03 and 0x04 respectively). In order for the NUC to}

manage power and control the motors over I2_{C, a slave instruction set is required, displayed}

in Table 8.1.

Table 8.1: Slave Instruction Byte Value (Hex) Task

0x02 Set Motor Position 0x04 Set Motor Velocity

0x06 Request Motor Temperature 0x08 Request Motor Position 0x0A Request Motor Velocity

0x0C Request Diagnostic Information 0x0E Set Diagnostic Information

148 The instruction is the first data byte written to the I2C bus by the master, which orders the slave to carry out a particular task (discussed in more detail in Section 7.3.2). A typical set function is displayed in Figure 8.8. The beginTransmission function allows selection of a slave by its address as an argument. The write function is used to queue a byte for transmission to the slave. When endTransmission is called the queues bytes are transmitted.

Figure 8.8: Typical set function (motor speed)

An instruction is also required for the slave to know which data to send. The master first sends an instruction, then reads sensor data by performing a request. A typical request function is shown in Figure 8.9. It begins similarly to the set function in Figure 8.8. Once the instruction is sent, the requestFrom function is called, specifying the slave address and number of data bytes requested. The number of bytes to be read is returned by available, called in a loop to ensure all bytes are processed. To transfer bytes from the I2C buffer, read is called.

149

8.3 Motor Control