Assignment 2 - Specification
MTRN2500 - UNSW School of Mechanical and Manufacturing Engineering
Alexander Cunio
November 15, 2024
Changelog
•28/10/24: Initial release
•29/10/24: Update mark weighting in marking criteria
•31/10/24: Fix wall follow distance to be 0.25 m
•04/11/24: Changed 1 m requirements to 0.5 m alongside previous change
Contents
1 Introduction2
2 Learning Outcomes2
3 Task overview2
3.1 Part A: Basic task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
3.2 Part B: Advanced task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
3.3 Part C: Extension task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
4 Detailed Requirements5
4.1 Controller logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
4.2 Environment layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
4.3 Software architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
4.4 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
4.5 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
4.6 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
4.7 Robot Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.7.1 Robot 1: Khepera4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.7.2 Robot 2: Rosbot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.8 Sensors and Actuators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.8.1 Distance Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.8.2 Lidar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.8.3 Compass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.8.4 GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.8.5 Position Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.8.6 Motor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.9 Keyboard Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5 Supplied Code and File Structure13
6 Compiling14
7 Version Control14
8 Marking Criteria15
9 Submission15
10Late Penalty16
1
11Plagiarism16
1 Introduction
Mechatronics engineering is based on the intersection of multiple disciplines. These include, software engineer-
ing, electrical engineering, and mechanical engineering. As we have been learning about developing more complex
software, it is important to link this back to the foundation and apply it to hardware.
In this assignment, you are going to be using a robotics simulation software, Webots, to write code to control robots
in a virtual environment.
In applications such as autonomous search and rescue operations, fleets of robots may be deployed to inspect an
environment and collect valuable reports on the targets and conditions. Based on requirements, different robots with
different features may be employed and this needs to be accounted for when writing controllers.
This assignment simulates such a scenario, where multiple robots are tasked with searching for a target within a
premises and reporting back when this has been found. Your task is to develop multiple controllers using C++ to
enable these robots to autonomously locate and navigate within the environment.
2 Learning Outcomes
The purpose of this assignment is to consolidate the C++ concepts taught throughout the term. The main learning
outcomes are:
•Demonstrate effective use of CPP programming to solve problems in relation to Mechatronic applications.
•Recognise and follow modern best practices in CPP programming.
•Explain the concepts within Object-Oriented Programming and apply these concepts to C++ program design.
3 Task overview
The task has been split up into three components which are each worth a subset of the total assignment marks. Note
that the later sections become more difficult.
3.1 Part A: Basic task
Multiple robots are located in an unknown environment where each is placed next to a path of walls. These walls
continue for an unknown distance and include a random assortment of turns. The wall layout is limited such that
it always follows a grid pattern (i.e., any turns are 90 degrees and the length of any wall segment is always 0.5 m).
More details on the map layout can be seen in section 4.2.
The task of each robot is to follow the walls by using a wall following algorithm (see section 4.1). The program must
first detect the walls location (i.e, whether the wall is on the robot’s left or right) and then commence following the
detected walls. When following the wall arrangement, the robot must maintain a distance of approximately 0.25 m
from the walls (this is the distance from the centre of the robot to the wall, noting that each individual grid square is
0.5 m x 0.5 m). A robot will be considered beyond a reasonable distance if any part of it ventures outside of the grid
square adjacent to the current wall segment.
There will be two different robots each with a different assortment of motors and sensors (see further details in section
4.7) that must complete this task. Each robot (programmed with its own controller) will be placed next to a separate
path of walls.
Both robots should continue until one of two conditions is met:
2
•It finds the end zone indicated by a location with walls on three sides of the robot.
•It receives a message from another robot that it has found the end zone (further communication information in
section 4.6.
Upon reaching this end condition, the robot controller should terminate.
An example of a basic task map with an end zone can be seen in figure 1.
Figure 1: Example of basic layout with two robots and end zone marked
Alongside following the wall, the robot must also continually form a log of its environment (see section 4.5). As part of
this for (approximately) every 0.5 m travelled the robot must record information about its surrounds and orientation.
This should be stored in the software until termination when it is outputted to a file.
Additionally, the robot should be able to be put into keyboard control mode (more details in section 4.9). When this is
enabled through a configuration file, the robot motion is controlled by the W, A, S, and D keys on the keyboard (i.e.,
while the key is held down the robot continues to move and when it is released the robot should stop).
3.2 Part B: Advanced task
The advanced task will extend on the basic task, having all the same initial requirements explained in section 3.1).
In addition to this, once the target is found by one robot, all of them must return to their initial position before the
program is terminated. While returning to their initial location they should NOT continue logging information. The
means of completing this and route that is taken is left up to the individual.
For this task, walls are not going to uniquely exist on only one side of the robot (i.e., there may be ones present on
both the left and right at different times). At the beginning of the program, there will always be a wall on only one
side, however at any time later a wall may appear on the opposing side and similarly walls may disappear from one
side. In particular, if a layout could exist where the robot is following a wall on its left, then a second wall could
3
appear on the right and it must follow between the two, then the original left-side wall could disappear and the robot
must continue following on the right. An example of an advanced task map can be seen in figure 2.
Figure 2: Example of partial advanced layout (only showing a single robot)
If choosing to complete the advanced task, a blank file calledadvancedTask.txtshould be included in the base
code directory (see section 5). If this is not present, the advanced task will not be assessed.
3.3 Part C: Extension task
The extension task extends the previous components, having the same basic requirements as the basic task (in
section 3.1) and the advanced task (in section 3.2).
In addition to these, you are no longer able to assume that the walls will follow a grid layout. As such, the angles
between segments are not limited to zero degrees and 90 degrees, but rather may also occur at any other angle. An
example of an extension task map can be seen in figure 3.
Figure 3: Example of partial extension layout (only showing a single robot)
If choosing to complete the extension task, an additional blank file calledextensionTask.txtshould be included
in the base code directory (see section 5). If this is not present, the extension task will not be assessed.
4
4 Detailed Requirements
4.1 Controller logic
Below defines the general tasks that each of the robot controllers must complete:
•Identify wall on one side of robot
•Follow wall through unknown map
•Log basic information about robot state at every metre travelled
•Listen for other robot(s) finding end zone and terminate on discovery
•Identify end zone (for found target) and communicate back to robot
•Save log info to file on termination
In addition for the advanced task:
•Return robot to its starting location on termination
4.2 Environment layout
The environment (world) will be laid out such that it contains two or more disjointed map layouts. Each map will
contain a series of walls that must be traversed and a robot next to the starting position. The exact layout of walls
can be random and is unknown at the start of execution.
At the end of one of the map segments will be an end zone. This will be indicated by walls on three sides of the robot.
This means that if a robot is following a wall and it finds itself in a position with walls on three sides (front, left, and
right) it knows that it is at the end point.
For the basic task, the walls will always be aligned with the floor grid layout (as seen in figure 4). Each segment will
be of length 0.5 m (the grid size) and any turns that the walls make will be 90 degrees in either direction. As a result,
this can be used to simplify your controller for these tasks knowing distances that the robot must move and angles
around which it must turn at any time to remain at a constant distance (0.25 m) from the wall.
Figure 4: Example environment for basic task with robot at start position (left) and end position (right) with the path
taken
In the advanced task, the wall restrictions from the basic task still remain. However, while following the wall on
one side, a wall may at any time appear on the other side (the distance between these walls will always be 0.5 m).
Additionally, when there are walls on both sides, one side may disappear at any time and the robot will need to
continue following the wall on the side that is remaining. An example is in figure 5 where the robot initially has a
5
wall on its left and about halfway through the route walls appear on both sides and then the left wall disappears and
the robot must continue to follow walls on the right.
A video has been provided of the robot completing the sample advanced map and can be found on Moodle under the
assignment.
Note: for the advanced task, there will be no ambiguous situations where the robot cannot easily decide from its current
position which direction to continue. An example of this (which will not occur) can be seen in figure 6 where as the robot
continues through the passageway without more advanced processing not expected in this task it cannot see whether
the wall continues left or right.
Figure 5: Example environment for advanced task with robot at start position (left) and end position (right) with the
path taken
Figure 6: Ambiguous layout that will not be assessed in advanced task
In the extension task the wall angles and lengths can no longer be assumed and as such a more complex wall following
algorithm will be required for the robot to remain approximately 0.25 m from the wall at all times as seen in figure 3).
6
4.3 Software architecture
You are required to write code that is adaptable to more than one robot model. That is, the same core logic (described
in section 4.1) will be utilised for different prescribed robots which have varied features (motor drives, sensors). In
order to complete this, software inheritance will be used, permitting the reuse of code components.
All functionalities that must be performed by the robots will be defined within a common parent class called called
RobotInterface. Functions will be declared within this in one of two ways:
•As pure virtual functions in the parent that must be defined in EACH of the child classes.
•As functions in the parent that are defined within this class (the common logic).
This will make the parent class abstract. The header fileRobotInterface.hppand some initial partial implemen-
tations have been provided. Particularly, as communication methods are common to all robots, these are defined
here in the parent (see section 4.6). An outline of the required functions are provided in table 1. Note that you are
free to add any additional functions (either implemented in the parent class or declared as pure virtual in the parent
to implement in the child classes) as you see fit however you MUST still use all the functions provided.
7
Table 1: RobotInterface functions
MethodDescription
RobotInterface()
A constructor that initialises the class
and any sensors common to all robots.
virtual ̃RobotInterface()
Destructor
virtual void moveRobot(Movement mov, Turn dir) = 0;
A pure virtual function. Sub-classes
will have to implement this member
function. Makes the robot move in the
direction specified.Note: Movement
and Turn are enumerations defined in
Constants.hpp.
virtual bool checkWall(Direction dir) = 0;
A pure virtual function. Subclasses will
have to implement this member func-
tion.Checks whether there is cur-
rently a wall present on the side spec-
ified (front, left, right).This is de-
fined as having an obstacle within 0.25
m of the robot’s centre.Note: Di-
rection is an enumeration defined in
Constants.hpp.
virtual double distanceToWall(Direction dir) = 0;
A pure virtual function. Subclasses
will have to implement this mem-
ber function.Gets the distance
to the wall on the side specified
(front, left, right).Returns infinity
(std::numeric_limits
::infinity()) if there is no wall.
Note:Direction is an enumeration
defined inConstants.hpp.
void run();
This function is called from the main
to run the primary program loop for
the controller and choose between key-
board mode and autonomous mode.
void followWall();
A function which performs the au-
tonomous wall following functionality.
void keyboardControl();
A function which allows a robot to be
controlled by using WASD on a key-
board. The robot should only move
when the respective key is pressed
down.
void addToLog(LogInfo log);
Adds the specified information to the
log that is stored in the controller.
Note: LogInfo is a struct defined in
Constants.hpp.
void outputLog();
Outputs the stored log to a file.
void sendMessage(const std::string &data);
(PROVIDED) Used to broadcast a mes-
sage to all other robots
std::string receiveMessage();
(PROVIDED) Used to check if a message
has been received and get its informa-
tion.
Each child class will represent a type of robots and implement the same pure virtual functions as described in the
previous table. These can each be seen in section 4.7.
8
4.4 Constants
To define custom types and global constants an additional fileConstants.hpphas been provided in the RobotIn-
terface directory. Within this there are a series of enumerations that define different robot directions and behaviours
to be used as arguments for functions and additional global definitions (Webots time step).
4.5 Logging
Alongside the autonomous navigation of the robot, you are also required to log information as it moves through the
environment. For approximately every 0.5 m that the robot travels, it should log a set of information. At each interval
two things should be done; the information should be printed to the console and it should be stored in a log within
the software. To store this you will need to use an appropriate STL container.
Once the controller completes and terminates, this log should all be outputted to a file calledoutput_
at once (where
file does not exist, it should be created and if one already exists it should be cleared before the information is stored.
The file should be created/located in the same directory as the given robot’s controller.
The data that should be logged will include:
•The current simulation time (seconds, 2dp)
•The robot name (name assigned in the specific robot in the world file)
•The presence of walls on any side, relative to the robot’s frame of reference (1/0 if a wall is detected on each
side)
•The current bearing of the robot in degrees, relative to the world coordinate frame (double in range [0,360))
Each line outputted should be in the form as below, where\tis a tab character (note: new lines should not be
included within a single output):
Walls: F:
Bearing:
For example for a robot 10 seconds into its simulation named ‘robot0’ having currently walls on its front and left and
facing north in the simulation, this would look like:
10.00-robot0\tWalls: F: 1, L: 1, R: 0\tBearing: 0
The presence of walls is defined as an absolute position relative to a robot’s direction of motion (left, right, front). A
wall is considered detected on any side if it is within 0.25 m of the detecting sensor (see section 4.8 for information
on sensors).
Note: even though walls may take arbitrary angles during the extension task, the detection should be measured in the
same way which may result in the same wall segment being detected in multiple directions at the same time (i.e., both
in front and to the left). This is considered valid for the extension task.
4.6 Communication
In order to tell each other when the target has been found, the robots have to be able to communicate wirelessly.
The communication interface has been provided for you in the RobotInterface starter code. The primary use of these
functions is to enable a robot to transmit a message when it has found the target and for all other robots to receive
this message and know when to stop.
9
There are two functions that offer a straightforward interface, allowing one robot to broadcast a message to all other
robots. You can call the ‘ReceiveMessage‘ function at any time to check if there is a waiting incoming message. It will
either return to you a sent message or an empty string to indicate that there is nothing incoming.
4.7 Robot Types
There are two robot types that may be employed to navigate the environment. These provide different capabilities and
also have differing motor and sensor arrangements that must be accounted for. In this assignment we will be dealing
with two different types of robots. The features of each robot are described in the sections below.
For each robot type you will need to implement a separate robot controller. Each of these will derive from the same
parent interface described within section 4.3. They must therefore implement the same pure-virtual functions defined
there.
4.7.1 Robot 1: Khepera4
This is a two-wheeled robot as depicted in figure 7. It is equipped with five side-facing ultrasonic distance sensors
and 8 side-facing infra-red distance sensors (specs defined in section 4.8.1). The location of each of these sensors
can be found on the spec page.
Figure 7: Image of Khepera robot
The query parameters that should be used for each of the sensors and motors on this robot are as in table 2.
Table 2: Khepera parameters
DescriptionQuery ID
left motor‘‘left wheel motor’’
right motor‘‘right wheel motor’’
left motor sensor‘‘left wheel sensor’’
right motor sensor‘‘right wheel sensor’’
left facing ultrasonic sensor‘‘left ultrasonic sensor’’
forward-left facing ultrasonic sensor‘‘front left ultrasonic sensor’’
forward facing ultrasonic sensor‘‘front ultrasonic sensor’’
forward-right facing ultrasonic sensor‘‘front right ultrasonic sensor’’
right facing ultrasonic sensor‘‘right ultrasonic sensor’’
left facing infrared sensor‘‘left infrared sensor’’
forward-left facing infrared sensor‘‘front left infrared sensor’’
forward facing infrared sensor‘‘front infrared sensor’’
forward-right facing infrared sensor‘‘front right infrared sensor’’
right facing infrared sensor‘‘right infrared sensor’’
backward-right facing infrared sensor‘‘rear right infrared sensor’’
backward facing infrared sensor‘‘rear infrared sensor’’
backward-left facing infrared sensor‘‘rear left infrared sensor’’
compass‘‘compass’’
GPS‘‘gps’’
10
Additional robot specifications can also be seen in table 3.
Table 3: Khepera robot specs
ParameterValue
Wheel radius0.021 m
Wheel width0.003 m
Wheel offset (distance from center of robot to wheel)0.0527 m
4.7.2 Robot 2: Rosbot
This is a four-wheeled robot as depicted in figure 8. It is equipped with a 360 degree lidar sensor (specs defined in
section 4.8.2).
Figure 8: Image of Rosbot robot
The query parameters that should be used for each of the sensors and motors on this robot are as in table 4.
Table 4: Rosbot parameters
DescriptionQuery ID
front left motor‘‘front left wheel motor’’
front right motor‘‘front right wheel motor’’
rear left motor‘‘rear left wheel motor’’
rear right motor‘‘rear right wheel motor’’
front left motor sensor‘‘front left wheel motor sensor’’
front right motor sensor‘‘front right wheel motor sensor’’
rear left motor sensor‘‘rear left wheel motor sensor’’
rear right motor sensor‘‘rear right wheel motor sensor’’
lidar‘‘lidar’’
compass‘‘compass’’
GPS‘‘gps’’
Additional robot specifications can also be seen in table 5.
Table 5: Rosbot robot specs
ParameterValue
Wheel radius0.043 m
Wheel width0.035 m
Wheel offset (distance from center of robot to wheel)0.11 m
4.8 Sensors and Actuators
There are a variety of sensors that are located on the robots. Note that not all sensors are located on all robots (see
section 4.7). Additionally, you are ONLY permitted to use the sensors outlined in section 4.7 even if additional ones
11
exist on the robot. However, you are not required to use every one of these sensors if your solution does not require
it. Details about those present for you to use are as below.
4.8.1 Distance Sensor
A distance sensor provides the distance of any obstacle from the sensor in the direction facing. The specifications
for the two types of distance sensors available in the given robots for this assignment are as in table 6 and table 7.
Detailed instructions on accessing the data source is available in the following resource:
•Distance Sensor: https://cyberbotics.com/doc/reference/distancesensor
Table 6: Ultrasonic distance sensor parameters
ParameterValue
minRange0.0 m
maxRange2.0 m
typesonar
Table 7: InfraRed distance sensor parameters
ParameterValue
minRange0.0 m
maxRange0.2 m
typeinfra-red
4.8.2 Lidar
The specifications of the 2D LiDar used can be found below (see Table 8). This gives the relative location of objects at
any point around the robot.
•Lidar: https://cyberbotics.com/doc/reference/lidar
Table 8: Lidar parameters
ParameterValue
minRange0.12 m
maxRange3.5 m
field of view360 degrees
Resolution360 points
4.8.3 Compass
The Compass can be used to determine the current heading of the robot (its rotation about its z-axis). Detailed
instructions on accessing the data source is available in the following resource:
•Compass: https://cyberbotics.com/doc/reference/compass
4.8.4 GPS
The GPS system offers accurate X and Y coordinates for tracking the robot’s location. Detailed instructions on
accessing the data source is available in the following resource:
•GPS: https://cyberbotics.com/doc/reference/gps
4.8.5 Position Sensor
Each position sensor provides the current rotation of a given wheel axis (relative to the position when the simulation
started). Detailed instructions on accessing the data source is available in the following resource:
12
•Position Sensor: https://cyberbotics.com/doc/reference/positionsensor
4.8.6 Motor
Each wheel will contain a motor that is controllable by position (set it to move to a certain rotation) or velocity (set it
to move at a constant speed). Detailed instructions on using the motor are available in the following resource:
•Motor: https://cyberbotics.com/doc/reference/motor
4.9 Keyboard Control
A ‘config.txt’ file should be placed inside each controller directory. On robot construction this file should be loaded
in. The command ‘keyboardControl=true’ will allow the user to command current robot with keyboard controls,
while ‘keyboardControl=false’ will cause the program to operate autonomously (as previously described). In
keyboard control mode, the ‘w/W’ and ‘s/S’ keys will move the robot forward and backward, respectively, while ‘a/A’
and ‘d/D’ keys will turn it on the spot left and right. The robot should only move if the respective key is pressed down
(i.e., while the key is held down the robot continues to move and when it is released the robot should stop). It does
not need to account for multiple keys being pressed at the same time.
You may assume that the configuration file is always present and valid (i.e., contains one of the stated commands).
5 Supplied Code and File Structure
You are already provided with a Webots project set up with aRobotInterfaceheader file and partial implementation
already provided (including code for communication). You can get access to this from the course’s GitHub classroom
which will create you a private GitHub repository.
Your file structure should followexactlythe one detailed below (wherez1234567is replaced with your own zID).
z1234567
advancedTask.txt (If attempting advanced task, see section 3.2)
extensionTask.txt (If attempting extension task, see section 3.3)
controllers
RobotInterface
RobotInterface.hpp
RobotInterface.cpp
Constants.hpp
RosbotController
Rosbot.hpp
Rosbot.cpp
RosbotController.cpp
config.txt
Makefile
KheperaController
Khepera.hpp
Khepera.cpp
KheperaController.cpp
config.txt
Makefile
Any additional files should not be included in your solution. Any helper functions required should be added within
the appropriate class (i.e., helper functions related to all robots should be included withinRobotInterfaceand
those only needed by a single robot should be withinKhepheraorRosbot).
13
6 Compiling
All code must be able to be compiled in Webots 2023a running either on Windows 11 or MacOS (separate submission
portals will be available depending on your OS of use).
You must ensure that your program is able to successfully compile with the flagsCFLAGS = -std=c++14 -Wall -Werror
enabled within your makefile.
7 Version Control
As part of this assignment, you will be required to use GitHub classroom. A repository has been established for all
students and the starter code has been placed within this (it will NOT be released on Moodle). You will be expected
to meaningfully use this version control platform as it is widely used in industry and provides a means of retrieving
code in case of computer issues or getting old revisions of your work.
In order to clone your git repository to your local desktop it is recommended that you use GitHub Desktop. You will
be able to log in to your account, clone the required repository and make any necessary actions (commit, push, pull).
A version of this is installed on the lab machines for you to use called Git Gui.
SEE NEXT PAGE
14
8 Marking Criteria
This assignment is worth 33 % of the total course mark. The breakdown of marks for this assignment is described in
table 9.
Marking will be carried out by running the developed solution against a series of basic, advanced, and extension
maps. Note that advanced tasks will only be assessed if theadvancedTask.txtfile is included in the submission
and the extension tasks will only be assessed if theextensionTask.txtfile is included in the submission. These
will have unknown map layouts and each robot will be assigned to an appropriate controller (i.e., Khephera4 robots
will be given a Khephera4 controller and Rosbot robots will be given a Rosbot controller) before it is run to termination.
The paths followed and output files will be observed.
Table 9: Mark allocation for assignment
CriteriaWeighting (/33)Description
Basic task- Autonomous wall follow9 marksEach robot is able to autonomously
follow the wall.
Basic task- Find target and com-
municate
3 marksThe robot finds the target and com-
municates to all others that it has
been found and all other robots
stop.
Basic task- Continuous logging3 marksThe robot logs the required infor-
mation about its environment while
driving and stores it within the con-
troller then outputs it to a file on
termination.
Basic task- Keyboard control3 marksIf"keyboardControl=true"is
set in ‘‘config.txt’’ within the con-
troller folder, the robot can be con-
trolled using the WASD keys.
Advanced task- Variable walls3 marksThe robots are able to follow walls
which can appear and disappear as
required by the advanced task.
Advanced task- Return to home3 marksAll robots return to their starting lo-
cation once the target is found.
Extension task- Angled walls2 marksThe robots are able to follow walls
which can turn at any angle as re-
quired by the extension task.
Solution quality7 marksThe program adheres to the func-
tion definitions and course style
guide. Regular progress commits
have been pushed to your private
GitHub repository.
9 Submission
This assignment is due by 13:00 on Monday of Week 12 (25/11/24). It should be submitted via the submission box
provided on Moodle under the ‘‘Assessments Hub’’ section.
You should zip your Webots project, name it as
z1234567.zip
where z1234567 is replaced with your zID. It should contain only the files specified in section 5 following this layout
exactly.
DO NOT submit any other files from your Webots project. Submission of incorrect or additional files may incur a
mark penalty. You will only be permitted one submission, please ensure that your submitted code is final and you
submit the correct files.
15
10 Late Penalty
UNSW has a standard late submission penalty of: 5% per day, for all assessments where a penalty applies, capped
at five days (120 hours) from the assessment deadline, after which a student cannot submit an assessment.
11 Plagiarism
If you are unclear about the definition of plagiarism, please refer to What is Plagiarism? | UNSW Current Students.
You could get zero marks for the assignment if you were found:
•Knowingly providing your work to anyone and it was subsequently submitted (by anyone), or
•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.
16
