1 Assignment Aims
A systems integration practical project with an Unmanned Ground Vehicle (UGV)
- To implement object-oriented programs using C++.
- To demonstrate interprocess communication and process management.
- To interface with live streams of data and to use them to assist in the tele-operation of a UGV.
- To interface with existing software to leverage pre-existing functionality.
Note: The word “module” is used to describe a piece of self-contained software. The word “process” is
used to describe a module that is running.
Often, in writing software for Mechatronic Systems, we need to integrate software modules that inter
act with sensors and actuators and software modules that carry out computational tasks, under the
supervision of a process management software module. Rather than building a monolithic applica
tion, a multi-process approach can be used to separate functional tasks and to simplify the software
development, upgrade and maintenance. Such an approach has the added benefit of limiting the
impact of software errors that may occur during operation, via process isolation (i.e., if there is an
error in one subsystem the rest are able to continue running normally). As such, we need to use
interprocess communication to allow for these specialised processes to communicate with each other.
3 What is Required of You
In this assignment, you are expected to write multiple independent modules that interact with each
other through shared memory. Your development should include the following software modules:
- a Process Management Module to set up shared memory and to startup, monitor and shutdown
the operation of all the modules listed below.
- a Laser Module to interface to a data stream originating from an LMS151 laser rangefinder and
store the data appropriately for access by other processes.
- a GNSS Module to interface to a data stream originating from an Novatel SMART-VI GNSS
receiver and store the data appropriately for access by other processes.
- a Controller Module to read signals coming from an x-box controller and store the data appro
priately for access by other processes.
- a Vehicle Control Module to direct the controller signals to the unmanned ground vehicle.
- a Display Module to graphically display the x-y data of the laser range finder and GNSS data in
a virtual world.
You are then required to (i). demonstrate receipt of Laser and GNSS data, (ii). demonstrate steering and propulsion control of the UGV and (iii). demonstrate the graphical display of laser and GNSS data. See from Section 4 onwards for the details. Start by completing Part I in Section 4 and then follow the other parts.
4 Part 1 – Process Management Module
The purpose of the process management module is to set up shared memory, start up all processes and monitor the operational health of all the processes and finally to shutdown all the processes.
Develop the process management module to:
- Set up shared memory. The shared memory module must have the capability to:
(a) Provide read/write access to Process Management data.
(b) Provide read/write access to Laser data.
(c) Provide read/write access to GNSS data.
(d) Provide read/write access to Vehicle Control data.
- Start all other processes one by one in the most logical sequence suitable for tele-operation of the UGV.
- Monitor the heartbeats of all the other processes.
- Carry out a complete shutdown in the event the process management process detects the failure of a critically important process.
- Attempt to restart a failed non-critical process.
- Carry out a routine shutdown of all the processes in response to a keypress event of your choosing (within the process management terminal window).
- Indicate to all the other modules that it is alive and operational. If process management fails all other processes should terminate.
Process Management is the most important module and therefore will form a critical process.
5 Part 2 – Laser Module
The UGV mentioned earlier will have its own server running onboard. The purpose of the server is to allow you to interact with the UGV. Therefore, in this part your first task is to establish a WiFi connection with this server over the wireless network (you should be able to do this from either your laptop or the lab computers). Use 192.168.1.200 as the IP address and 23000 as the port number to connect to and receive laser data (further information in service details document). After authentication, you will be allowed to connect to the laser rangefinder to enable you to collect laser range data. The most recent laser range data you collected must then be stored as an array of X, Y coordinates in the shared memory for other modules to use (an appropriate struct to hold the data is available within smstructs.h).
Incorporate mechanisms in the laser module to update its own heartbeat so that this is observable by the process management module and for the laser process to respond to shutdown commands form the process management module.
The laser module will form the primary input for the tele-operation of the UGV and is thus a critical process.
6 Part 3 – GNSS Module
Similar to the Laser, the GNSS runs on a server on the weeder thus requiring a Wi-Fi connection to the robot. The device will run at port 24000 to communicate via a TCP connection. The server does not need any authentication. As soon as you connect to the GNSS receiver it will allow you to get global position data records as a continuous stream of binary data. The arrangement of this binary data can be inspected within the GNSS manual extracts document. Process the binary data to obtain the X, Y position in UTM coordinates and height in meters, and make them available in the shared memory for other modules to use. In addition, this module should print on the screen, Northing,Easting and Height in meters + the CRC value (a value that indicates data integrity).
Incorporate mechanisms in the GNSS module to enable the process management module to detect the heartbeat of the GNSS process and for the GNSS process to respond to shutdown commands form the process management process.
The GNSS module provides secondary input information to the driver who can continue without this and is thus a non-critical process.
7 Part 4 – Controller Module
You will use an X-box controller to provide control input to the tele-operation system. The speed of the the robot will be controlled by the right and left triggers (right for forwards motion and left for reverse). The steering should be controlled by the x-axis of the right joystick. You will be provided with a controller for testing within the laboratory sessions. Make the speed and steering commands generated this way available to the vehicle control module through shared memory. In addition,program one of the X-box buttons to indicate to the process management process to shutdown all modules at the end of your tele-operation.
For you to more easily interface with the controller, an interface class has been written. The available data structures and functions are available in the controllerInterface.h header file. You should not change this file at all. Note, it is a C++ class (not CLR) when you include it in your project.
This will provide you a means of connecting to a controller, getting the state of the controller, checking connection, and other useful functionality. At the top there is a #define defining the type of control input so you can change it between controller input and keyboard input. This can be used so that you are able to test your code at home where you might not have an X-box controller available.
Incorporate mechanisms in the X-box module to enable the process management process to detect the heartbeat of the X-box process and for the X-box process to respond to shutdown commands form the process management process.
Note: If X-box is disconnected or turned off, set the speed and steering to zero!
This forms a critical process for tele-operation.
8 Part 5 – Vehicle Control Module
The purpose of the vehicle control module is to send control commands to the UGV. As this is running on a server on the UGV, first establish a Wi-Fi connection with the onboard server to communicate via port 25000 with TCP. After authentication, you must send the UGV commands in the form of the following ASCII string to make it move.
# <steer> <speed> <flag> #
Replace the field <steer> by a numerical value between ±40◦ as the required steering angle and,<speed> by a numerical value between ±1m/s as the required speed. These values should be based on your control input coming from the controller module (values available via shared memory).
Replace the <flag> field by 0 and 1 alternatingly to indicate you are actively controlling the vehicle(it should alternate every message). the spaces and the # are required.
Incorporate mechanisms in the vehicle control module to enable the process management process to detect the heartbeat of the vehicle control process and for the vehicle control process to respond to shutdown commands form the process management process.
The vehicle control module is important in tele-operation thus forms a critical process.
9 Part 6 – Display Module
The display module is a means of providing a useful way to display collected sensor information to the user. Particularly, it should be able to portray the Laser and GNSS data in some appropriate and meaningful manner (representing the true data). All data should be plotted relative the the vehicle base frame. To write this, you will be using an API interface provided with MATLAB. An example file that explores how to form a connection with MATLAB and send commands has been provided in the starter code, which we will explore during the week 8 tutorial.
Further information on having the interface appropriately setup has been provided in a separate MATLAB interfacing document.
Similar to other modules, the display module will require access to the shared memory to collect data,modify heartbeats appropriately, and respond to shutdown commands.
The display module provides all the collected information to the user as a first person view, who would otherwise be driving blind, thus forms a critical process.