Assignment 3: SLAM and Waypoint Navigation on ArbiterROS

Go-to-Goal vs. Pure Pursuit — Group Exercise

Component: Assignment 3 of 3 (6 % of 20 % Assignment component) CLO: CLO2 (C5) Released: Week 10 — 15 June 2026 Due: Week 12 — 7 July 2026, 23:59 MYTType: Group assignment — groups of 3

Background

In Assignments 1 and 2 you worked in the mathematical / algorithmic layer. Assignment 3 brings everything into a running system: you will drive a simulated mobile robot through a real SLAM $\to$ mapping $\to$ waypoint- navigation pipeline on the ArbiterROS web platform (https://arbiter.txio.live), the same platform used in the Module 5 and 6 labs. You will produce a map of the 12-obstacle ArbiterROS environment using SLAM Toolbox, execute a six-waypoint mission loop, and compare two path-following strategies.

Learning Objectives

• Run a SLAM pipeline (SLAM Toolbox mode) on a ROS 2 web-based simulator
• Save and inspect an occupancy grid map produced by SLAM
• Define a multi-waypoint mission and execute it with an autonomous controller
• Use the ArbiterROS useAnalyticsEngine panel to record position, velocity, and error telemetry
• Quantitatively compare two path-following strategies on the same mission
• Communicate group engineering work as a coherent technical report

Platform Access

• URL: https://arbiter.txio.live (browser only, no installation)
• Fallback: local Docker via docker-compose up -d
• Architecture reference: Module-5/5.3-Platform Overview.pdf
• Connection mode: start in ROS 2 Virtual; switch to Hardware Pi 4B only if your group wants the hardware bonus

Part 1 — SLAM Mapping (25 %)

1. Open the ArbiterROS SLAM page (/slam-navigation) in ROS 2 Virtual mode.
2. Confirm rosbridge is connected (green indicator).
3. Manually teleoperate the robot through the 12-obstacle environment until the occupancy grid is complete and the drift is visually minimal.
4. Save the map. The primary deliverable is the occupancy grid PNG plus a screenshot of the ArbiterROS map-save confirmation (the platform save button triggers a browser download). If the platform also offers a serialised SLAM Toolbox file download, include that too — but the PNG + screenshot alone is sufficient if the serialised export is unavailable in browser mode.
5. Document at least two loop closures observed during mapping (SLAM Toolbox reports them in its console).

Part 2 — Waypoint Mission (25 %)

1. Using the map from Part 1, define six waypoints that form a closed loop visiting distinct regions. State them as a list of $(x,y,\theta )$ poses in your report.
2. Configure the waypoint navigator in the ArbiterROS web UI. The closed-loop trajectory runner lives on /figure-eight-nav (reference-path driver backed by useFigureEightNavigation.ts); use /control for ad-hoc waypoint goals against useControlAlgorithms.ts.
3. Execute the loop three times with the controller set to go-to-goal proportional.
4. Execute the loop three times with the controller set to Pure Pursuit (lookahead = 0.5 m recommended; justify any deviation).
5. For every run, start useAnalyticsEngine data collection before the mission and stop after. Export the CSV.

Reference: Module-5/5.4-Control Algorithms.tex §5.4.1 (go-to-goal proportional) and §5.4.3 (Pure Pursuit).

Part 3 — Comparative Analysis (30 %)

For each controller, compute:

Report the metrics as a table averaged over the three runs per controller, with standard deviations. Include at least two plots:

1. The robot trajectory overlaid on the map for one representative run per controller.
2. A box plot of per-waypoint position error comparing the two controllers.

Answer four questions in the discussion:

1. Which controller achieves lower position error, and why is that expected from Module 5.4 theory?
2. Where on the map does Pure Pursuit “cut corners” visibly? Give waypoint indices and the approximate undershoot in metres.
3. Using the differential-drive forward kinematics $\dot{q}=S(q)\nu$ with $\nu =[v,\omega {]}^{\top }$ from Module 1.3, explain mechanically why go-to-goal cannot achieve zero steady-state heading error while traversing a curved reference, whereas Pure Pursuit can. Tie the answer to which component of $\nu$ each controller actually regulates.
4. Is the completion-time difference statistically meaningful across only three runs? How would you design a better experiment?

Part 4 — Engineering Recommendation (15 %)

Recommend one controller for deployment in a hypothetical warehouse. Justify using your data, addressing:

• Positional accuracy required at workstations
• Throughput (mission time) expectations
• Robustness to small map errors

Part 5 — Group Coordination Appendix (5 %)

One-page appendix listing which group member did what, and any merge / coordination challenges. All group members must sign.

Deliverables

File name format: MEC781-A3-Group<N>-<Surnames>.pdf

Evaluation Criteria

Difficulty split: C3–C4 = 2 marks (33 %), C5–C6 = 4 marks (67 %) . Note: “marks” here refer to the 6-mark CO-PO scale; the percentages in the rubric above are internal marking weights and sum to 100 % independently.

Bonus (+1 mark) — Hardware Mode

Groups that successfully repeat Part 2 runs 1 and 2 on the Hardware Pi 4B (book hardware time from Week 9 onwards to secure a slot — late bookings in Weeks 11–12 are unlikely to be available) mode (not simulation) earn +1 bonus mark. Include a short note and one extra trajectory plot in the report. Book Pi 4B hardware time during lab slots.

Resources

• Module-5/5.1-SLAM Fundamentals.pdf
• Module-5/5.2-SLAM Practical.pdf
• Module-5/5.3-Platform Overview.pdf
• Module-5/5.4-Control Algorithms.pdf (and .tex)
• Module-5/5.5-Trajectory Navigation.pdf
• Module-6/6.3-Analytics and Latency.pdf
• Platform URL: https://arbiter.txio.live

Practical Guidance

• SLAM first, mission second. A bad map will make the mission metrics look bad and you will not know which side is at fault.
• Run all three SLAM sessions from the same starting pose so your map frames are comparable.
• Name CSVs immediately: Group<N>_<controller>_run<k>.csv. Unnamed files in a group of three will get mixed up.
• Read Module-6/6.3-Analytics and Latency.pdf §6.3.2 for statistical definitions of mean/p95/variance so your metrics match the platform’s.
• The bonus hardware run usually fails the first time due to latency — allocate a full lab slot. Book Pi 4B time from Week 9 onwards; hardware slots in Weeks 11–12 fill quickly.