Lab 3: Control Strategy Comparison on ArbiterROS

Proportional, PID, Pure Pursuit, State Machine

Component: Case Study / Labs 3 of 3 (10 % of 30 %) CLO: CLO3 (P5) Released: Week 9 — 8 June 2026 Due: Week 11 — 26 June 2026, 23:59 MYTType: Individual lab report

Adapted from the 202521 Assignment 3 (“Material Handling System — Control Strategy Simulation”). Scenario and methodology kept; platform is now ArbiterROS and the reference is the useControlAlgorithms.ts composable documented in Module-5/5.4-Control Algorithms.pdf.

Objective

Design, run, and analyse a set of experiments that exposes the practical differences between four classical control strategies for mobile-robot path following, using the exact useControlAlgorithms composable shipped with ArbiterROS. You will tune, test, and benchmark each controller; pick the right one for each scenario; and justify your choice with measured data.

Learning Objectives

• Understand the four control strategies implemented in useControlAlgorithms.ts
• Tune each controller’s key parameters for three distinct scenarios
• Collect performance telemetry via the useAnalyticsEngine composable
• Compute standard control-performance metrics and compare controllers quantitatively
• Justify an industrial-deployment decision with measured evidence

Theoretical Background

Reference: Module-5/5.4-Control Algorithms.pdf §5.4.1–§5.4.5.

Lab Setup

• Platform: ArbiterROS (https://arbiter.txio.live)
• Page: /material-handling for the warehouse task harness; /figure-eight-nav for continuous path following; /control for ad-hoc waypoint missions
• Underlying composable: frontend/composables/Robot/useControlAlgorithms.ts (the four strategies) and useAnalyticsEngine.ts (CSV export)
• Connection: ROS 2 Virtual mode
• Reference file: Module-5/5.4-Control Algorithms.tex

Important: unlike the old lab, you do not need to edit HTML files or comment out a velocitySmoother. The ArbiterROS useControlAlgorithms composable exposes the same parameters directly in the web UI — change them from the control panel at runtime.

Task 1 — Parameter Baseline (15 %)

1. Set all four controllers to the default parameters listed in Module-5/5.4-Control Algorithms.tex §5.4.1:

- Proportional: `kp_linear=0.6, kp_angular=2.0`

- PID: `kp_linear=0.8, ki_linear=0.05, kd_linear=0.15, kp_angular=2.5, ki_angular=0.03, kd_angular=0.2, integral_limit=0.5`

- Pure Pursuit: `lookahead_distance=0.5, kp_linear=0.6`

- State Machine: `arrival_tolerance=0.15, heading_tolerance=0.12`

2. Run each controller once on a simple straight-line mission and confirm it works.
3. Record screenshots of the control panel for your report.

Task 2 — Tuning (20 %)

Tune at least two of the four controllers to better fit a specific behaviour. Document:

1. Which controllers you picked and why.
2. Parameter values tried and what you observed.
3. Final tuned parameters, justified in terms of Module 5.4 theory.

Parameter record (mandatory): append a one-page table to your report listing the final tuned parameters from Task 2 for every controller. These values must remain identical across all Task 3 scenarios. Marks will be deducted if different parameter sets appear across scenarios, or if the table is absent.

Task 3 — Three Test Scenarios (25 %)

Create three distinct scenarios and run every controller on each.

Scenario 1 — Precision test. Point-to-point move $(0,0)\to (2,2)$. Metrics: final position error, settling time, overshoot.

Scenario 2 — Multi-point navigation. Waypoints: Home $\to$ Storage A $\to$ Workstation $\to$ Storage B $\to$ Home. Metrics: total time, path length, smoothness.

Scenario 3 — Obstacle-rich path. Start inside the 12-obstacle environment; goal is the opposite corner. Metrics: success rate, minimum obstacle clearance.

Run each scenario two times per controller (8 total runs per scenario, 24 runs across the study). Export a useAnalyticsEngine CSV for every individual run before averaging.

Task 4 — Analysis (25 %)

For each exported dataset compute:

Primary metrics:

• Average linear velocity (m/s)
• Peak linear velocity (m/s)
• Final position error (m)
• Settling time (s) — time to reach within $0.1$ m of target
• Path efficiency — straight-line distance / actual path length

Advanced metrics:

• Velocity standard deviation (smoothness)
• Heading error RMS
• Energy proxy — mean of $v^2+{\omega }^2$

Produce a summary table covering all $4\times 3$ cells, plus:

• One trajectory overlay plot per scenario (all 4 controllers)
• One bar chart of position error per controller per scenario

Task 5 — Engineering Recommendation (15 %)

Recommend a controller for each of these applications. Justify with your data:

1. Amazon-style fulfilment centre
2. Precision manufacturing assembly
3. Hospital logistics robot
4. Warehouse inventory management

Deliverables

File name format: MEC781-Lab3-<StudentID>-<Surname>.{pdf,zip}

Evaluation Criteria

Resources

• Module-5/5.4-Control Algorithms.pdf (and .tex)
• Module-6/6.3-Analytics and Latency.pdf
• Platform URL: https://arbiter.txio.live
• Archived 202521 Assignment 3: Assessments/_archive_202521/18062025-MEC781-Assignment-3.pdf (reference only)

Practical Guidance

• Use the same starting pose across all runs in a scenario so comparisons are fair.
• Do not tune the controllers for each scenario separately — tune once in Task 2, keep parameters fixed for Task 3. The mandatory parameter record table (see above) is the evidence of compliance; reports without it will be penalised.
• If a controller fails on Scenario 3, that is a valid data point — record it as a success rate, not an error.
• The State Machine controller will feel slow. That is the point — its strength shows up in Scenario 1 (precision), not Scenario 2 (throughput).