Hello, if you have any need, please feel free to consult us, this is my wechat: wx91due
Assignment 2 - UGV Assignment
MTRN3500 - UNSW School of Mechanical and Manufacturing Engineering
Alexander Cunio & Jay Katupitiya
October 10, 2024
1 Introduction
2 Learning Outcomes
A systems integration practical project with an Unmanned Ground Vehicle (UGV)
• To implement object-oriented programs using C++.• To create a multi-threaded program for concurrent activity.• To demonstrate inter-thread communication and thread management.• To interface with and process live streams of data from industrial sensors and to use them to assist in the tele-operation of a UGV.• To interface with existing software to leverage pre-existing functionality.
3 Your task
- a Thread 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 threads.
- a GNSS Module to interface to a data stream originating from a Novatel SMART-VI GNSS receiver and store the data appropriately for access by other threads.
- a Controller Module to read signals received from an x-box controller and store the data appropriately for access by other threads.
- a Vehicle Control Module to direct the controller signals to drive and steer 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.
- a Crash Avoidance Module to process in real-time the laser and controller data to avoid collisions of the UGV.
3.1 Part 1 - Thread Management Module
1. Set up shared memory. The shared memory module must have the capability to:
(a) Provide read/write access to Thread 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.
2. Start all other threads one by one in the most logical sequence suitable for tele-operation of the UGV.
3. Monitor the heartbeats of all the other threads.
4. Carry out a complete shutdown in the event the thread management thread detects the failure of a critically important thread.
5. Attempt to restart a failed non-critical thread.6. Carry out a routine shutdown of all the threads in response to pressing the ‘q’ key (within the thread management terminal window).7. Indicate to all the other modules that it (the thread management module) is alive and operational. If thread management fails all other threads should terminate.
Thread Management is the most important module and therefore will form a critical threads.
3.2 Part 2 - Laser Module
Incorporate mechanisms in the laser module to update its own heartbeat so that this is observable by the thread management module and for the laser threads to respond to shutdown commands form the thread management module.
The laser module will form the primary input for the UGV’s tele-operation and is thus a critical thread.
3.3 Part 3 - GNSS Module
In addition to the CRC recieved in the data packet, to verify the GNSS checksum when data is received, please use the functions provided in Appendix A as a base. You can then compare the CRC sent by the device and that calculated with this code.
Incorporate mechanisms in the GNSS module to enable the thread management module to detect the heartbeat of the GNSS thread and for the GNSS thread to respond to shutdown commands form the thread management thread.
The GNSS data is simulated on the physical UGV as it is located indoors and as such the northings and eastings both should look like a sinusoidal changing pair of values.
3.4 Part 4 - Controller Module
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 thread management thread to detect the heartbeat of the X-box thread and for the X-box thread to respond to shutdown commands form the thread management thread.
3.5 Part 5 - Vehicle Control Module
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 watchdog field <wdog> by 0 and 1 alternatingly to indicate you are actively controlling the vehicle (it should alternate in consecutive messages). The spaces and the # are required. The <wdog> signal may also be used to inhibit vehicle motion by setting it to be dormant at either 0 or 1. You may find a practical use of this signal when implementing Part 7 described below.
Incorporate mechanisms in the vehicle control module to enable the thread management thread to detect the heartbeat of the vehicle control thread and for the vehicle control thread to respond to shutdown commands form the thread management thread.
The vehicle control module is important in tele-operation thus forms a critical thread.
3.6 Part 6 - Display Module
To interface with the existing Matlab display engine, data must be published to a local TCP/IP connection. It will read this data continuously and plot it appropriately. The format of the message sent should be an array of raw Byte data, sending the Cartesian co-ordinates of the data points. This should have enough size to fit 361 laser data points. A code snippet has been provided in Appendix B to perform this task of sending the data.
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 thread.
3.7 Part 7 - Crash Avoidance Module
For this part of the assignment, marks will be awarded based on the sophistication you will incorporate into your software. For example, one may decide to activate motion inhibition based on obstacles straight ahead. Another option is to take the steering signal into account to detect obstacles in the direction the vehicle is steered. It can be further sophisticated by taking an approximate steered path or in the complete solution the exact steered path.
This task will also require you to modify/add to shared memory data structures so new information can be transferred between modules. Additionally, you will need to make sure you understand the format of the laser data in order to appropriately process it.
4 Software Architecture
For further information on working with classes and inheritance review the week 1 lecture.
5 Software Setup
The software for this system will exist within a single project within Visual Studio 2022. This means there will be a single main function that launches the first thread (Thread Management module) and from here all others should be created.
You have been provided with a Visual Studio solution on GitHub classroom. Below details the files that are already included in and linked to your project. Explore it before beginning your assignment (these files form part of the specification).
Project files:
Adding additional files can be done in the solution explorer as below:
- For header files this will be: right click on Header Files, select add->new item, create a header file of appropriate name and type, click add.
- For cpp files this will be: right click on Source Files, select add->new item, create a cpp file of appropriate name and type, click add.
The following table summarises the names that the required files should take. These should be used EXACTLY in your project.
|
Module |
Header |
Implementation |
|
Thread Management |
TMM.h |
TMM.cpp |
|
Laser |
Laser.h |
Laser.cpp |
|
GNSS |
GNSS.h |
GNSS.cpp |
|
Controller |
Controller.h |
Controller.cpp |
|
Vehicle Control |
VC.h |
VC.cpp |
|
Display |
Display.h |
Display.cpp |
|
Crash Avoidance |
CrashAvoidance.h |
CrashAvoidance.cpp |
Note: To help you get started a template TMM.h and TMM.cpp file has also been provided in the setup repository.
6 Using the simulator
To change between running code on the robot and the simulator requires one minor change. The only difference is the IP address it is running at (all ports and other connection information, including authentication) should be the same. In the networked_module.h header file, you will need to change WEEDER_ADDRESS to 127.0.0.1 when running on the simulator and 192.168.1.200 when running on the actual UGV (connect to via Wi-Fi in the lab).
If you believe you have found any bugs in it please let us know to review.
7 Software Considerations
When writing your software you MUST remember to be following good software development practices. Particularly, in this assignment you must be:
- Following the prescribed software architecture throughout all modules as outlined in section 4.
- Performing data validation when reading data from the sensors (Laser and GNSS) to ensure that it has been received correctly/fully and is valid.
- Undertaking appropriate exception handling to ensure safe program execution. This includes:
- Handling exceptions that you may expect to be thrown by code you have written.
- Utilising error codes to ensure appropriate code flow.
8 Git Usage
9 What to look at next?
Additionally, you should review all the starter code provided, particularly all the header files in the include folder. Note that, there are four files that you will need to interact with directly (SMObjects.h, UGVModule.h, NetworkedModule.h,and ControllerInterface.h).
10 Marking Criteria
Table 1: Mark allocation for assignment
|
Criteria |
Weighting |
Description |
|
Progress Check |
20 % |
As below in section 10.1 |
|
Final Demonstration |
80 % |
As below in section 10.2 |
Important note: None of the marks will be valid if plagiarism is detected in the submitted code or if you did not submit your entire source code by the deadline (see section 12).
All demonstrations of the required functionality can either be completed on your own computers or the lab computers connected to the physical Weeder.
10.1 Progress Check Requirements
The demonstration required is,
- Header files should be present for all modules.
- All classes should be created in their respective header file, inheriting from the correct location and over riding the appropriate functions.
- The data must be presented as the 361 concurrent data points converted to Cartesian coordinates (will be assessed for correct converted values).
- Data should be printed to the terminal in an easy-to-read fashion as pairs of x and y points.
3. The automatic shutdown of all other modules in response to a routine shutdown of the thread management thread. (2 marks)
- A routine shutdown of the thread management thread is ‘‘pressing the ‘q’ key’’.
You must get this marked during your allocated lab time in week 8. Late penalties per School policy applies.
10.2 Final Demonstration Requirements
- Correct plot should update at a reasonable rate with no significant delay from real-time.
- Printing should occur continuously (on each receipt of new data) at a reasonable rate.
- Data should include Northings, Eastings, height, recieved CRC (from the sent packet), and calculated CRC.
- Note: GNSS data is simulated due to being indoors and the Northings and Eastings should form a sinusoidal path
- Input should be taken from x-box controller.
- Appropriate inputs should result in correct movement of wheels on UGV.
- All threads should be individually shut down as well as the thread management module.
- Shutdown button on x-box controller should cause similar shutdown of all threads.
- Items placed in front of the vehicle when underway should cause it to stop immediately.
- Items placed to the side of the laser when turning should have a similar effect.
- These will test concepts about the UGV and its sensors as well as the code you have written.
8. Error handling and data validation throughout modules (4 marks)
- Data from sensors has been validated prior to use.
- Exceptions are handled to ensure safe thread execution and error codes used appropriately.
11 Early Submission and Bonus Marks
Submitting one week early (practical assessment in your week 10 lab class and final code submission by 11.59 pm of Friday of week 10) will grant one bonus mark. Submitting two weeks early (practical assessment in your week 9 lab class and final code submission by 11.59 pm of Friday of week 9) will grant two bonus marks.
12 Code Submission
You must submit to Moodle via the provided submission box a zip file named zXXXXXXX.zip with XXXXXXX replaced by your student number. This zip folder should ONLY contain all the .h and .cpp files you created for each module (two per module plus the main file). Submit your file by 11.59 pm of 22 November 2024. Failing to do this will apply late submission penalties to your full assignment marks.
13 Plagiarism
You could get zero marks for the assignment if you were found:
• Copying or submitting any other persons’ work, including code from previous students of this course (except general public open-source libraries/code). Please cite the source if you refer to open source code.
You will be notified and allowed to justify your case before such a penalty is applied.
Appendix A
Use the below code for calculating the CRC/Checksum of the GPS/GNSS and comparing it to that which is sent by the sensor itself.
unsigned char* ucBuffer);
int j;unsigned long ulCRC;ulCRC = i;for (j = 8; j > 0; j--){
if (ulCRC & 1)
ulCRC = (ulCRC >> 1) ˆ CRC32_POLYNOMIAL;
else
ulCRC >>= 1;
}return ulCRC;
unsigned long ulCount, /* Number of bytes in the data block */unsigned char* ucBuffer) /* Data block */
unsigned long ulTemp1;unsigned long ulTemp2;unsigned long ulCRC = 0;while (ulCount-- != 0)
{
ulTemp1 = (ulCRC >> 8) & 0x00FFFFFFL;ulTemp2 = CRC32Value(((int)ulCRC ˆ *ucBuffer++) & 0xff);ulCRC = ulTemp1 ˆ ulTemp2;
}
return(ulCRC);
Appendix B
The below function can be used within your display module for sending data to the Matlab display engine.
NetworkStreamˆ stream)
// Serialize the data arrays to a byte array//(format required for sending)array<Byte>ˆ dataX =
gcnew array<Byte>(xData->Length * sizeof(double));
Buffer::BlockCopy(xData, 0, dataX, 0, dataX->Length);array<Byte>ˆ dataY =
gcnew array<Byte>(yData->Length * sizeof(double));
Buffer::BlockCopy(yData, 0, dataY, 0, dataY->Length);// Send byte data over connectionStream->Write(dataX, 0, dataX->Length);Thread::Sleep(10);Stream->Write(dataY, 0, dataY->Length);