B18 DESIGN REPORT

Aditya Purohit (u8536094) Linfan Huang (u8231161) Xinrui Wu (u8348474)

 [Link] Scope, Goals, and
Executive Summary Constraints ...........................................2
This report describes the design of an (i)Project Scope ....................................... 2
autonomous maze-navigating rover developed (ii)Project Goals ....................................... 2
by Group B18 for ENGN1211 following the (iii) Project Constraints ............................. 2
ANU Systems Engineering Process (ASEP). The 2. Design Requirements .......................2
rover was required to autonomously navigate
3. Conceptual Design and Evaluation .3
both known and unknown mazes within three
3a. Concept Generation ........................... 3
minutes, fit within a corridor width of 180–190 3b. Concept Evaluation and Final Selection
mm, and operate completely using onboard ................................................................ 3
battery power. The design process included
requirements analysis, conceptual design, 4. Preliminary Design ...........................4
4a. Design Criteria ................................... 4
preliminary design, and detailed design. Three
4b. Simulations, Prototypes and testing. ... 4
different concepts were considered before
selecting a two-wheel differential drive chassis 5. Evaluation of the Design Criteria ....5
with a front caster wheel. The rover also used a 5a. Description of tests ............................ 5
servo-mounted HC-SR04 ultrasonic sensor for 5b. Results and Analysis .......................... 5
obstacle detection and an Arduino Uno running a 5c. Summary of rover Performance against
Design Criteria. ........................................ 6
distance-based obstacle avoidance program.
5d. Recommendations ............................. 7
Under controlled testing conditions, the rover
5e. Summary of design criteria................. 7
met all nine design criteria. The rover achieved
an average straight-line deviation of 9 mm, an 6. Detailed description of all parts of
average turning accuracy of 89.4°, and a forward the final design. ....................................8
speed of 0.244 m/s. During the final maze test, 6a. Structure of the Rover ........................ 8
the rover scored 6/10 and successfully passed 6b. Electronics Layout and Wiring ............ 9
6c. Code Logic Used for Maze Solving... 10
the movement, object detection, and walled turn
6d. Final Arduino Code .......................... 12
sections. The main limitation of the rover was
6e. Bill of Materials (BOM) ..................... 12
the chassis length, which produced a turning
radius that was not suitable for completing the Conclusion ........................................ 13
entire maze consistently. Future improvements
could include reducing the chassis length to
below 90 mm, adding side-facing ultrasonic
sensors, and replacing the current time-based Introduction
motor control system with wheel encoders. This report explains the design process and
results of the B18 rover project. The purpose of
the report is to provide a technically literate
reader with an understanding of the design
Table of Contents decisions and enough background information to
continue developing the rover through later
Executive Summary ........................... 1
stages of the ASEP process. The report discusses
Introduction ........................................ 1 the project scope, objectives and constraints,
design requirements, conceptual design and
Body .................................................... 2
evaluation, preliminary design and testing,
design criteria evaluation, and a detailed Additional objectives include maintaining the
description of the final rover structure, stability of the rover's motion, improving the
electronics, and control logic. accuracy of turning, and ensuring the rover can
complete its maneuvers in the maze.

Body (iii) Project Constraints

* Budget Maximum of $20 for the additional
[Link] Scope, Goals, and components
Constraints * Chassis must be self-manufactured
* Components: only supplied electrical
(i)Project Scope components could be used
*Autonomy: rover could not be hard coded for a
The goal of this project was to create an
single maze
autonomous vehicle capable of navigating
*Time limit: maze completion required within 3
mazes, possessing its own independent system,
minutes
and not relying on external control. The vehicle
* Power: rover must use onboard battery power
also needed to have sufficient electronic
only
components and sensors to automatically control
its movement, detect obstacles, and make 2. Design Requirements
judgments. The entire development process
followed the ANU systems engineering To ensure that rover could meet the project's
workflow, successively completing requirements objectives, several quantifiable and independent
of analysis, conceptual design, and preliminary specific design requirements were defined
design, culminating in the creation of a during the conceptual design phase.
prototype. 1. The maximum width of the rover should be
less than 180 mm to ensure compatibility with
(ii)Project Goals the maze corridors.
2. The maximum length of the rover should be
The major goals of the rover project were:
less than 200 mm to allow effective navigation
（1） Enable the rover to have forward and
in confined spaces.
backward alignment as well as left and right 3. The rover should be capable of travelling in
turning capabilities. a straight line with a positional error within
（2） Develop a collision avoidance system 20mm.
using ultrasonic sensors. 4. 4. The rover should be capable of
performing approximately 90-degree turns in a
（3） Develop a rover capable of autonomous
maze environment.
navigation in both known and unknown mazes. 5. The minimum speed of the rover under
（4） Design a fully self-contained system normal conditions must be greater than 0.1 m/s.
powered by an onboard battery. 6. The rover can detect obstacles within 3 cm
to 30 cm using ultrasonic sensors.
（5） Achieve reliable and repeatable motion
7. The rover can respond to sensor input within
performance during testing. 0.5 seconds to ensure reliable autonomous
operation.
 8. The rover remains stable during movement This design employs a combination structure
and will not tilt or roll over. supported by two main drive wheels and a rear-
9. All electronic components and wiring of the mounted omnidirectional wheel. An ultrasonic
rover must be firmly fixed to prevent loosening sensor is mounted at the front of the rover to
during movement. detect obstacles. The rover uses the right-hand
10. The rover should avoid exposed wiring or rule for maze navigation. While this design is
sharp edges to ensure safe handling during simple, lightweight, and easy to implement, its
testing and operation. stability is lower compared to other concepts.
11. The rover must be constructed using only Concept 2: Four-Wheel Stability Configuration
the provided materials and electronic This concept used four wheels to improve
components. stability and movement consistency. Ultrasonic
12. The rover must be able to operate sensors are used for obstacle detection, and a
completely autonomously during maze left-hand rule is used for maze navigation. While
navigation without external control. this concept improves balance and control
performance, it also increases the complexity of
the mechanical structure and program control.
3. Conceptual Design and
Evaluation Concept 3: Hybrid Sensor Configuration
The third concept combines ultrasonic and
3a. Concept Generation infrared sensors to improve environmental
awareness. A simple exploration algorithm was
Before finalizing the design, the team proposed
proposed for navigation. Although this design
and evaluated several conceptual designs for the
provided better detection capability, it
rover. These designs mainly revolved around
introduced significant implementation
three core functions: chassis structure, obstacle
complexity within the available project
detection, and maze solving strategy.
timeframe.
Function Option 1 Option Option 3
2 3b. Concept Evaluation and Final
Selection
Chassis 2-wheel + 4- Flat The concepts were evaluated against criteria
caster wheel rectangular including simplicity, stability, detection
drive base capability, and feasibility.

Object Ultrasonic IR Combined

Detection sensor sensor sensors

Maze Right- Left- Random Concept 1 was initially attractive due to its
Solving hand Rule hand exploration simple structure and high feasibility. However,
rule testing and early prototype development
revealed that stability was crucial for achieving
Concept 1: Two-Wheel with Caster accurate steering and consistent motion. While
Configuration
Concept 3 offered enhanced sensing capabilities,
its complexity was prohibitive given the Power Continuous >5min
available time and resources. Therefore, the final performance operating
design combined some features of Concepts 1 time
and 2. The final rover employed a relatively
simple dual-motor differential drive system with These standards ensure that the rover can
ultrasonic sensing, combined with improved perform navigation tasks in a controlled and
stability and motion control schemes developed reliable manner, while also making it easier to
during subsequent prototype testing. Ultrasonic quantitatively compare test data with project
sensors were chosen because they maximize requirements.
obstacle avoidance while maintaining low cost The initial rover design consists of an Arduino
and ease of integration. Furthermore, the team Uno controller, an L293D motor driver module,
adopted a rule-based navigation algorithm, two DC motors, and an onboard battery. The
which was simpler and more reliable than Arduino controls the speed and direction of the
random exploration within the project's two motors via PWM and direction signals. The
constraints. rover uses a time-based control strategy for
motion control. Straight-line motion is achieved
4. Preliminary Design by simultaneously driving both motors forward,
while steering is achieved by rotating the two
4a. Design Criteria motors in opposite directions. Our team
continuously adjusted the steering timing
To evaluate rover performance during
parameters through experimentation to achieve a
development and testing, several quantified
near 90° turn.
design criteria were established.
4b. Simulations, Prototypes and
Criteria Description Target
testing.
Straight-line Maximum <20mm
In the initial design phase, our team conducted
Accuracy lateral
multiple prototyping and testing processes to
deviation
improve the rover's motion performance and
Turning Deviation <5° stability. Our primary goal at this stage was to
accuracy from 90° turn ensure the rover could achieve straight-line
motion, approximately 90° turns, and stable,
Speed Foward >0.1m/s repeatable rectangular path movements. The
velocity rover prototype consisted of an Arduino Uno
Repeatability Ability to >3 controller, an L293D motor driver module, two
repeat successful DC motors, and an onboard battery, allowing the
rectangular cycles system to operate independently without an
path external power source or computer connection.
The team employed a time-based motion control
Stability Smoothness No major strategy, where straight-line motion was
of movement oscillations achieved by the two motors moving forward
simultaneously, while turning was achieved by
the two motors rotating in opposite directions.
The team continuously adjusted the turning
timing through experimentation to achieve a
near 90° turn. To test the rover's performance, During the straight-line test, the rover was put at
the team conducted multiple tests, including defined start point and then moved forward in a
straight-line tests to measure motion offset and straight line for one meter. One meter of tape
turning tests to improve directional accuracy. was placed parallel to the start position to be
The team also adjusted the motor PWM used for lateral deviation measurements. The
parameters to reduce motion offset and improve deviation was measured at the end with a ruler
operational consistency. Additional testing (measuring between tape and the final position
focused primarily on circuit reliability and of the rover). This test verified design
battery power stability. In the early development requirement 1 (less than 20mm of positional
phase, we also created cardboard prototype error). Trials before side-to-side motor speed
models to determine the optimal mounting compensation changes to code showed a
positions for key components such as the significant amount of drift to the unequal power
Arduino, motors, battery, and sensors. Tinker produced by the motors. The code was adjusted
CAD circuit planning and iterative physical to correct for this with final adjusted values for
prototyping were used to assist in the entire the PWM value of the left motor being 200 and
design process. Test results show that the rover the right motor being 188. The official trials
can achieve controlled forward movement and were run after calibration.
repeatable steering behavior, but the system still Test 2: Turning Accuracy
has some errors due to variations in battery The turning accuracy was tested similarly to the
voltage and differences in ground friction straight-line test with the use of tape to indicate
initial and final positions. Upon completion of
5. Evaluation of the Design the turn the rovers final heading was measured
Criteria relative to the initial position. This test verified
design requirement 2 (< 5-degree deviation from
5a. Description of tests 90 degree). The pre-test calibrations resulted in
the turn timing parameter (TURN_90_MS) to be
The rover’s performance against the design
calibrated 1925 milliseconds.
criteria was tested against three of the most
Test 3: Forward speed
important criteria. The straight-line accuracy,
This test used a stopwatch to measure time taken
turning accuracy and forward speed. These were
to travel one meter with start and end positions
chosen because they are the fundamental
marked with tape. Speed was calculated as
functionality requirements of the rover. Each test
Speed = Distance/Time and thus verified third
was conducted in the same conditions;
design requirement of greater than 0.1m/s.
consistently flat, hard surface with no external
effects (wind, vibration, etc). 5 trials of each of 5b. Results and Analysis
the criteria test were performed to allow for
statistical analysis and to also help reduce Test 1 Results:
influence of random error. Results were Trial Lateral Deviation
manually recorded with subsequent code (mm)
calibrations occurring between testing sessions 1 8
(not between individual trials). 2 11
3 9
Test 1: Straight line accuracy 4 7
5 10
 Mean 9 Std Dev - 0.15 0.009
Std Dev 1.6 The rover exceeded the minimum speed
requirement of 0.1 m/s in all trials with an
All trials were within the 20 mm target. The average 0.244 m/s. The variation was limited
mean lateral deviation of 9mm shows the (standard deviation of 0.009 m/s), thus showing
calibration was effective in correcting the side- the high consistency of the result.
to-side imbalances. The relatively low standard
deviation of 1.6mm shows that these results are 5c. Summary of rover
repeatable and consistent across trials. The Performance against Design
standard deviation is likely due to minor Criteria.
irregularities in the surface and random human
Criteri Target Measured Status
error in measurement.
a Result (met/unm
Test 2 Results:
et)
Trial Measured Deviation
Straight <20 mm The rover Met
Turn Angle from 90° (°)
Line lateral after
(°)
accurac deviatio calibration
1 86 4
y n was on
2 91 1
average 9-
3 88 2
millimeter
4 93 3 deviated
5 89 1 after 1
Mean 89.4 2.2 meter of
Std Dev 2.7 - travel.
Turning < 5° Rover Met
All trials had turns within 4° of the 90° target, accurac deviatio consistentl
well within the 5° design criteria. The mean y n from y showed
angle being 89.4° suggests a slight under 90° less than 4°
rotation, however such changes were present deviation
(either or under rotation) regardless of from 90°
calibration. The 1925ms timing parameter’s with an
reliability was confirmed by the low spread average
across the trials however this accuracy was angle of
shown on highly consistent surfaces which was 89.4°
not the cases in the maze. Forwar >0.1 m/s Rover Met
Test 3 Results: d speed moved at
Trial Distance Time Speed 0.244m/s
(m) (s) (m/s) on average
1 1 4.2 0.238 Sonar Detectio HC-SR04 Met
2 1 3.9 0.256 Detecti n reliably
3 1 4.1 0.244 on between detected
4 1 4 0.25 Range 3-30cm walls at
5 1 4.3 0.233 distance
Mean - 4.1 0.244 between
 and length of the rover (12.5cm) causing a large
include 3 turning radius incompatible in the corridor width
and 30cm. of 18-19cm. During the right-hand turn test, the
Sonar 40- Sensor was Met rover’s turning radius was too large to
mounti 60mm mounted at consistently complete 90° turns within the
ng above ~50mm corridor without contacting the wall. A reduced
height ground above length to less than 9cm would provide a good
ground amount of clearance to improve the ability of the
Sonar >90° Servo Met rover to navigate through the maze. This is the
scan sweep coded to highest priority recommendation as it was the
angle rotate major bottleneck that prevent further progress to
approximat the known and unknown maze sections in the
ely final test.
between The current sensor configuration used only one
40° and ultrasonic sensor mounted to a servo. However,
140°, adding fixed side facing ultrasonic sensors
providing would allow the rover to detect and respond to
about 100° lateral walls in real time during forward travel
of scan instead of once it has already detected something
range. in front. This would allow for more complex
Wall <50mm Rover Met maze solving algorithms. The current obstacle
Stop consistentl avoidance algorithm selects directions based on
distance y stopped a single left and right scan. A more sophisticated
approximat algorithm such as a flood fill algorithm or wall
ely 10 mm following (which would be possible with side
before sonars) would significantly improve the rovers
contact. navigational capabilities in the mazes and would
Sonar <= +- Repeated Met also be highly plausible with the current
reading 10 mm readings of hardware (Bouhal & Paraskevopoulos 2023).
Stabilit variatio fix wall Furthermore, the current system uses time-based
y n for showed motor control for the straight-line motion and
same variation turning. However, this system is highly
distance of ~+-8mm depended on the variation in the battery voltage,
Batter >5 Rover Met surface friction and other inconsistencies of
enduran minutes operated which there were many in the maze. The
ce continuo for over 10 addition of wheel encoders would allow Arduino
us minutes to measure the wheels rotation and apply a more
operatio without complex feedback system, thus allowing for
n power loss more accurate and repeatable straight and turned
travel regardless of external conditions.
5d. Recommendations
5e. Summary of design criteria
A highly impactful limitation of the design that
was identified during final testing was the excess Level 1 was achieved with the rover
demonstrating forward travel, stopping,
reversing and rectangular path travel in both Loose wiring may become a problem that
clockwise and anticlockwise directions. This significantly affects reliability and safety;
confirmed the design criteria for straight line therefore, the proper fastening of the breadboard
accuracy (<20 mm lateral deviation) and turning became an integral part of the final assembly.
accuracy (< 5° deviation from 90°) . Level 2 was
also successfully achieved with the rover Two DC motors are installed on the left and
correctly avoiding the wall in front and at 45 right sides towards the chassis’ rear, while the
degrees without colliding thus validating the 3D-printed design has a cylindrical holder
stopping distance, sonar detection range and slightly larger than the motor. This allows for
sonar reading stability under practical testing adequate space while holding the motor when
conditions (<50mm stopping distance, Detection the glue dries. This configuration fits the
between 3-30cm and <= +- 10 mm variation for differential drive approach, in which two motors
same distance respectively). Furthermore, level provide motion control in the forward direction
3 was also passed with the rover success and turning. Any small misalignment directly
demonstrating its ability to perform a right and affected the rover’s turning accuracy and
left hand turn in maze like conditions (18-19cm straight-line movement when performing a turn
width). This practically validated the servo scan at 90 degrees.
range criteria of >90° sweep.
The Arduino board and battery pack were close
Although all nine design criteria were met under to the rover's rear. The rear vertical support was
controlled testing, the length of the chassis and
printed as part of the main chassis structure. The
various issues in code logic led the rover’s battery holder was supported by the rear vertical
incapability to solve the mazes. section of the chassis. The battery pack
connection within this frame was taped. This
6. Detailed description of all placement ensured that the heavier battery pack
parts of the final design. was placed toward the back to balance the front
sensor assembly and reduce interference with
6a. Structure of the Rover the wiring by keeping the pack away from the
The resultant rover has a 3D-printed chassis moving servo at the front.
designed with a flat base and a raised rear
supporting section that holds the main A small, separate, 3D-printed bracket holds the
components. This configuration avoids servo motor at the rover's front. This bracket was
excessive width or length that could hinder the glued into place at the chassis’ front end. The
rover's operation in a maze, a crucial aspect of ultrasonic sensor mounting is above the servo
one of the design requirements. Besides, it motor so that it rotates and scans the space in
allows stable movement within the maze front of the rover. The ultrasonic sensor's
corridor. matching size was cut from stiff cardboard and
used as a simple mounting plate. The sensor was
The lower base is recessed for the breadboard, then attached to the cardboard and secured using
which keeps it in place without slippage during tape. While this may not have appeared to be the
testing, as it has been glued in. It also assists best method, it was the most practical under the
with wiring management, ensuring that only a available time and materials conditions.
few jumper wires are visible around the
Arduino, motor driver, and sensor connections.
This front sensor arrangement was used because
the rover needed to detect obstacles ahead and
compare the available space on both sides of the
maze. The sonar is positioned in front of the
rover, where it had a clearer field of view, and
the rover better detects walls and obstacles
ahead of it. The servo allows the sensor to scan
different sectors rather than be restricted to
measuring directly ahead only.
Figure 6.1: Final rover assembly with rear battery
The significant mechanical components of the mounting
rover thus became two large side wheels driven
by the DC motors and a small caster wheel 6b. Electronics Layout and Wiring
under the front section. The caster wheel is The rover’s electronics were primarily based on
provided in our material kit, we measured its an Arduino Uno, which acted as the main
size and set aside a specific groove on the controller for rover movement and obstacle
reverse side of the basis, fixed by glue, to make detection. Most of the wiring connections were
sure they are stable. In detail, this caster wheel completed on the breadboard mounted inside the
supports the rover's front section yet continues recessed section of the chassis. This helped keep
to allow it to turn. Using the caster wheel most of the jumper wires near the center of the
underneath the front section simplified the rover and reduced unnecessary cable movement
mechanical design, reduced the number of during testing. It also made the overall wiring
motors, and allowed the rover to move forward arrangement easier when connecting the
and backward and turn left and right. Arduino, motor driver and sensors together.

General impressions of the final assembly

include simplicity, compactness, easy mounting,
and, in some practical cases, such as the sonar
mount and battery attachment, instead of
attempting to mount more complex printed
attachments like tape and glue. This, of course,
contributed somewhat to the lack of finesse in
the design but allowed the rover to be finished
within the project's timeframe set for trials. Figure 6.2: Final electronics wiring layout of the
rover system created in TinkerCAD
As shown in Figure 6.2, the rover used a 3D
The DC motors were controlled using an L293D
printed chassis with the battery mounted at the
rear section. motor driver connected to the Arduino. The left
motor used pins 2 and 3 for direction control and
pin 5 for speed control, while the right motor
used pins 4 and 7 for direction control and pin 6
for speed control. This allowed both wheels to
operate independently during forward
movement, reversing and turning. The
differential drive system was important because One issue occurred when the servo motor was
the rover relied on separate wheel movement to not mounted securely enough. During early
complete 90-degree turns inside the maze. obstacle testing, the rover collided with a wall
and the ultrasonic sensor assembly fell from the
An HC-SR04 ultrasonic sensor was mounted at servo mount. Additional glue and tape were later
the front of the rover for obstacle detection. The applied to improve the stability of the front
sensor used separate TRIG and ECHO signal sensor structure.
connections to communicate with the Arduino.
The TRIG pin was connected to digital pin 12, Some instability also occurred with the
while the ECHO pin was connected to digital breadboard wiring connections. At one stage, the
pin 11. This setup allowed the rover to left motor stopped working because one of the
continuously measure the distance between itself motor wires became loose after the motor had
and nearby walls or obstacles while moving been fixed into the chassis. The wire was
through the maze. reconnected and secured more carefully
afterwards. These issues showed the importance
A micro servo motor was mounted underneath of stable wiring connections and secure
the ultrasonic sensor and connected to digital pin component mounting when building an
9 on the Arduino. During operation, the servo autonomous rover system.
rotated the ultrasonic sensor left and right so the
rover could compare the available space on both Therefore, the final electronics layout focused
sides before deciding which direction to turn. mainly on reliable operation and practical
Both the servo motor and ultrasonic sensor were assembly rather than appearance. Although some
powered through the breadboard power rails. sections of the wiring arrangement were not
particularly neat, all major components operated
Power was supplied using a battery pack successfully during movement and obstacle
mounted at the rear of the rover. The battery avoidance testing.
holder was attached to the vertical rear support
using tape. Placing the battery pack at the rear 6c. Code Logic Used for Maze
helped balance the front sensor assembly and
Solving
reduced interference between the battery and the
moving servo motor at the front of the rover. The final rover code was fully autonomous, and
This arrangement also reduced congestion the rover operated without any remote control or
around the front wiring area. manual input during testing. Instead, the
Arduino controlled the motors, the servo motor,
Several wiring and assembly issues occurred and the ultrasonic sensor through the distance
during testing. At the beginning of the project, readings received from the sensor.
some parts were attached using double-sided
tape because the group was unsure whether the Most of the program logic was about avoiding
first assembled version of the rover would obstacles. While driving the rover forward, the
function correctly. After confirming that the ultrasonic sensor continuously measured the
chassis layout and electronics were operating distance in front of the rover. The distance being
properly, stronger glue was used for the final greater than the stopping distance was the
assembly. condition for the rover to continue driving
forward. Once the wall or obstacle came within
the set stopping distance, based on the sensor Figure 6.5: Servo scanning logic used to compare the
input, the rover would stop first before making available space on the left and right sides.
the next movement decision.

Figure 6.6: Direction selection logic based on the

comparison between left and right distance readings.
Figure 6.3: Ultrasonic distance measurement
function used by the rover The function was broken down into smaller
sections: moving forward, moving backward,
Start ↓ Move Forward ↓ Measure Distance ↓ turning left, turning right, and stopping. This
Obstacle Detected? ↓ No → Continue Forward ↓ made modifying code during testing easier. For
Yes Stop Rover ↓ Scan Left and Right ↓ example, the turning time was controlled with a
Compare Distances ↓ Turn Toward Larger Space calibrated timing value adjusted multiple times
↓ Move Forward Again to allow the rover to turn closer to 90 degrees.

Figure 6.4: Logic flowchart showing the autonomous The code required multiple calibrations during
obstacle avoidance behaviour used by the rover testing because the actual assembled rover was
not so well put together initially. For instance,
After stopping, the servo motor turned the the wheels and motors were not fastened tightly
ultrasonic sensor to scan left and right, compare at one point, causing the wheels to sit slightly
the two distance values, and then continue angled. This produced different behaviors in the
driving in the direction with more space. It thus rover's turning, even though the unchanged code
avoided simple frontal obstacles and selected a controlled the turning. Once the wheels and
direction based on the measured obstacle motors were better secured, the turning behavior
distance on each side rather than continuing to became more repeatable and stable.
turn in a fixed direction.
This walled turn task was also challenging
because the 3D-printed chassis was relatively
large. During right turns, the right wheel would
sometimes miscalculate and not clear the wall.
To overcome this, the code was modified not to
have the rover always attempt the entire turn in
one movement. First, the rover turned about 45
degrees, moved forward a short distance,
detected the wall again, scanned left and right,
and then made another turn toward the side with
more space. This compensated for the enlarged
chassis size and significantly assisted in L293D 1 Provide Controls
correctly completing the walled turn segment. Motor d in kit the
Driver direction
Overall, the final code was a rather simple and speed
autonomous obstacle avoidance. It was not a of the DC
sophisticated algorithm for solving mazes, but it motors
allowed the rover to pass the first three levels of
the test: movement, object detection, and walled DC 2 Provide Drives the
turns. The final score of the testing for the rover Motors d in kit left and
was 6/10. This meant that the basic movement right
and sensing logic worked successfully, although wheels
the rover still had limitations related to its HC-SR04 1 Provide Detects
mechanical size, turning inaccuracies and Ultrasonic d in kit walls and
physical assembly. Sensor nearby
obstacles
6d. Final Arduino Code
Micro 1 Provide Rotates the
The final Arduino program used for autonomous Servo d in kit ultrasonic
obstacle avoidance and rover movement is Motor sensor for
included in Appendix A. obstacle
scanning
6e. Bill of Materials (BOM)
Breadboar 1 Provide Provides
Table 6.1 shows the main components and
d d in kit temporary
materials used during the construction and
wiring
testing of the rover.
connection
Some additional materials such as cardboard, s between
glue and tape were used during assembly and component
testing to improve component stability and s
mounting. Jumper Multipl Provide Connects
Wires e d in kit the
Componen Quantit Approx. Function
electronic
t y Cost
component
(AUD)
s together
Arduino 1 Provide Main
Battery 1 Provide Supplies
Uno d in kit controller
Pack d in kit power to
for rover
the rover
movement
electronics
and
and motors
obstacle
detection Wheels 2 Provide Allows
d in kit rover
movement
 Caster 1 Provide Supports the 180–190 mm corridors. Future
Wheel d in kit the front improvements will focus on reducing chassis
section and length, adding side ultrasonic sensors to support
improves more advanced navigation methods, and
turning replacing the current time-based motor control
system with encoder feedback for more
3D Printed 1 Approx. Main consistent movement on different surfaces.
Chassis $4.00 structural Overall, the rover’s hardware and software
body of the system provides a practical starting point for
rover further development of autonomous maze
Cardboard 1 Approx. Supports navigation.
Sensor $0.50 the
Mount ultrasonic
sensor
assembly

Glue and Multipl Approx. Used to

Tape e $2.00 secure
component
s during
assembly
and testing

Most electronic components were supplied as

part of the rover kit. Only consumable materials
and 3D printing costs were estimated separately.

Conclusion
The B18 rover project successfully designed and
built a fully autonomous differential-drive
vehicle capable of obstacle detection and maze
navigation. Iterative prototyping and testing
were carried out following the ASEP framework,
which helped refine the design and allowed all
nine design criteria to be achieved under
controlled conditions. The rover achieved a
score of 6/10 in the final maze test,
demonstrating that the main movement and
sensing systems operated successfully. The main
limitation preventing the rover from consistently
completing the entire maze was the 125 mm
chassis length, which created a turning radius
that was too large for reliable movement within
 pinMode(R_IN1, OUTPUT);
References
pinMode(R_IN2, OUTPUT);
[Link], R & Paraskevopoulos, N 2023, Maze
Solving using Flood Fill Algorithm: Introduction pinMode(TRIG_PIN, OUTPUT);
to Micromouse.
pinMode(ECHO_PIN, INPUT);
Appendix A – Final Arduino
[Link](SERVO_PIN);
Code
[Link](90);
#include <Servo.h>
delay(1000);
const int L_EN = 5;

setSpeed(DRIVE_SPEED);
const int L_IN1 = 2;

}
const int L_IN2 = 3;

void loop() {
const int R_EN = 6;

[Link](90);
const int R_IN1 = 4;

delay(200);
const int R_IN2 = 7;

moveForward();
const int TRIG_PIN = 12;

int frontDist = pingCm();

const int ECHO_PIN = 11;

if (frontDist <= STOP_DIST) {

const int SERVO_PIN = 9;

stopMotors();
const int DRIVE_SPEED = 170;

delay(300);
const int TURN_90_MS = 1925;

[Link](140);
const int STOP_DIST = 10;

delay(750);
const int REVERSE_MS = 300;

int leftSpace = pingCm();

Servo scanServo;

[Link](40);
void setup() {

delay(850);
pinMode(L_EN, OUTPUT);

int rightSpace = pingCm();

pinMode(L_IN1, OUTPUT);

// Return servo to centre

pinMode(L_IN2, OUTPUT);

[Link](90);
pinMode(R_EN, OUTPUT);
delay(500); delayMicroseconds(10);

// Reverse slightly digitalWrite(TRIG_PIN, LOW);

moveBackward(); long duration = pulseIn(ECHO_PIN, HIGH,

30000);
delay(REVERSE_MS);
// No echo detected
stopMotors();
if (duration == 0) {
delay(200);
return 999;
if (leftSpace > rightSpace) {
}
turnLeft();
return duration / 58;
delay(TURN_90_MS);
}
}
void setSpeed(int s) {
else {
analogWrite(L_EN, s);
turnRight();
analogWrite(R_EN, s);
delay(TURN_90_MS);
}
}
void moveForward() {
stopMotors();
digitalWrite(L_IN1, LOW);
delay(750);
digitalWrite(L_IN2, HIGH);
moveForward();
digitalWrite(R_IN1, LOW);
delay(200);
digitalWrite(R_IN2, HIGH);
}
}
delay(30);
void moveBackward() {
}
digitalWrite(L_IN1, HIGH);
int pingCm() {
digitalWrite(L_IN2, LOW);
digitalWrite(TRIG_PIN, LOW);
digitalWrite(R_IN1, HIGH);
delayMicroseconds(2);
digitalWrite(R_IN2, LOW);
digitalWrite(TRIG_PIN, HIGH);
}
void turnRight() {

digitalWrite(L_IN1, LOW);

digitalWrite(L_IN2, HIGH);

digitalWrite(R_IN1, HIGH);

digitalWrite(R_IN2, LOW);

void turnLeft() {

digitalWrite(L_IN1, HIGH);

digitalWrite(L_IN2, LOW);

digitalWrite(R_IN1, LOW);

digitalWrite(R_IN2, HIGH);

void stopMotors() {

digitalWrite(L_IN1, LOW);

digitalWrite(L_IN2, LOW);

digitalWrite(R_IN1, LOW);

digitalWrite(R_IN2, LOW);

AI Assistance Statement
AI tools were used to assist with grammar
checking, wording improvements, and sentence
clarity during the preparation of this report. It
was also used during coding to logic testing and
help with fixing errors. All engineering
decisions, testing, and final technical content
were completed and reviewed by the project
group members.