AUTO · Group Project · 2026 S1
Five tasks.One robot.Real time.
A QBot Platform that follows a line, reads traffic signals, avoids obstacles, builds a live occupancy map, and stops at a coloured target — all driven by a Simulink behaviour-arbitration model on real hardware.
01 / THE PROBLEM
Five tasks to completein three minutes.
The course requires sequential autonomous operation through five distinct phases — from initial line detection through to target acquisition. All within a hard 3-minute run cap.
Demo course — top-down view
Blue Line Follow
Detect the blue floor strip with the downward camera and follow it onto the course using proportional centroid control.
Build a Map
Fuse RealSense depth point clouds into a persistent 501×501 uint8 occupancy grid as the robot navigates.
Traffic Compliance
Detect red (stop) and yellow (slow) traffic signals with the forward RGB camera and respond with the correct motion command.
Obstacle Avoidance
Detect and avoid obstacles using depth imagery — with a 0.8-second reverse-escape manoeuvre for cornered situations.
Target Approach & Stop
Detect the pink target, approach it proportionally, and stop precisely when target area exceeds 1500 px².
02 / SYSTEM ARCHITECTURE
Four sensors.Five behaviours.One arbiter.
Every control tick, each behaviour module produces a wheel-velocity vector and a status flag. The arbiter selects exactly one winner and drives the motors. No behaviour holds the motors directly.
Sensors
Behaviour Modules
Arbiter → Motors
S2 == 2 (pink goal reached) sits above all flags — it fires a hard stop before any other behaviour can respond.
Priority-based arbitration is deterministic and transparent — exactly one behaviour wins every tick with no ambiguous transitions. Easier to debug and tune than a state machine with explicit transition guards.
Motor commands run at the QBot step size. Perception, mapping, and the arbiter run at 10× slower. Rate Transitions bridge the boundary — fast enough for smooth control, slow enough for vision processing.
LIDAR data is logged to workspace via To Workspace blocks but not used for navigation. Deliberate choice: the RealSense depth gives forward-facing obstacle data sufficient for the course, and fusing LIDAR mid-semester would have introduced more integration risk than gain.
03 / KINEMATICS & ODOMETRY
From encoder pulsesto world-frame pose.
Wheel encoder readings are zeroed at startup, scaled to arc lengths, smoothed by a 2nd-order low-pass filter, differenced to extract Δr and Δθ, then integrated into a continuous (x, y, θ) pose estimate.
Processing pipeline
- 1Wheel EncodersPosition pair, zeroed at t = 0 via sample-and-hold
- 2× Wheel Radiusr_wheel = 0.04445 m (Quanser spec) → arc lengths
- 32nd-Order LPFSmooths quantisation noise independently on each wheel
- 4RL2CentreDifferential drive geometry → Δr (linear), Δθ (heading)
- 5IntegrateThree integrators → x, y, θ in world frame
Top-down — wheel separation visible
Isometric — drive train geometry
v = ω × r
v_c = (v_R + v_L) / 2
Δθ = (v_R − v_L) / L
x += v_c cos θ · Δt y += v_c sin θ · Δt
A 2nd-order discrete low-pass filter on each raw wheel velocity removes encoder quantisation spikes. Without it, the heading integrator accumulates micro-steps of noise that manifest as visible map drift after 2–3 m of travel.
04 / PERCEPTION PIPELINE
Same recipe for every colour.One map from depth.
All four colour behaviours share an identical 3-stage pipeline. The depth camera runs a parallel path that converts each frame into a local point cloud and fuses it into the persistent global grid.
Standard RGB is sensitive to lighting changes — a well-lit pink card and a shadowed pink card have different R,G,B values. Chromaticity divides each channel by the total intensity, leaving only the colour ratio. The result is near-invariant to illumination, which was critical when the course lighting changed between calibration and demo day.
total = R + G + B + ε r = R / total g = G / total b = B / total
The RealSense D435 depth stream is reprojected into a local 3D point cloud each frame, then fused into the persistent 501×501 uint8 occupancy grid. New observations are blended with weight w = 0.01 to prevent single noisy frames from corrupting the map.
When the pink target is visible on both sides, left/right oscillation can occur. A 0.3 s hold on the last steering command prevents the robot from flipping direction every tick.
05 / BEHAVIOUR ARBITRATION
One priority function.No ambiguity.
Every tick, the arbiter receives nine inputs — five velocity vectors, four status flags. Six lines of MATLAB select one winner. Priority is fixed: safety first, task second, nominal cruise as fallback.
When an obstacle is too close to turn around, the controller enters reverseMode. It backs up for 0.8 s, choosing direction based on which side has more clearance, then resumes forward navigation.
The blue line follower uses a BlueLock flag and last_turn memory to handle intersections and momentary line loss. Once locked onto the line, it stays committed until task completion.
Obstacle avoidance sits at priority 3, below pink approach (priority 2). This means a pink target approaching from the side can interrupt an avoidance manoeuvre. Deliberate choice: if the robot is already close enough to see pink, it is past the obstacle that triggered avoidance, so task completion wins.
06 / PARAMETER JUSTIFICATION
Every number has a reason.
These are not defaults. Each value was taken from the Quanser hardware specification or tuned through iterative lab testing. The rationale column records what we tried first.
| Parameter | Value | Unit | Description | Category |
|---|---|---|---|---|
| r_wheel | 0.04445 | m | Wheel radius — encoder pulse → arc length. Quanser QBot Platform spec, verified by square-path test. | Platform |
| L_wheel | 0.3928 | m | Wheel base — arc → heading change in RL2Centre differential drive model. | Platform |
| v_cruise | 4 | rad/s | Default cruise speed (V5). Balance of run time vs odometry accuracy — 6 rad/s increased mapping artefacts noticeably. | Control |
| w_localmap | 0.01 | — | Map update weight. Low weight prevents one noisy frame corrupting the grid. 0.2 caused severe artefacts in W12 lab. | Mapping |
| wall_pad | 5×5 | px | Neighbourhood thickening on each occupied cell. Robot is ~4.5 px wide at 4 cm/px — 5×5 ensures planner clearance. | Mapping |
| map_size | 501×501 | px | Occupancy grid dimensions. Covers 20×20 m at 4 cm/px resolution. | Mapping |
| d_close | 0.5 | m | Close obstacle threshold — triggers reverse-escape. Within braking distance at cruise speed. | Behaviour |
| d_far | 0.8 | m | Far obstacle threshold — triggers steer-around. 1.0 m steered too early and caused overcorrection on the wide course. | Behaviour |
| t_reverse | 0.8 | s | Reverse-escape duration. Long enough to back out of a box corner at cruise speed. 0.5 s re-detected the same obstacle. | Behaviour |
| t_stopflips | 0.3 | s | StopFlips hysteresis. Holds last steering command before allowing a left↔right flip. Eliminates oscillation on centre obstacles. | Behaviour |
| A_goal_pink | 1500 | px² | Pink target area stop threshold. ~0.5 m standoff at typical target size. 800 → too far; 2000 → too close. | Colour |
| A_min_pink | 50 | px² | Minimum pink area for confident detection. Below this, centroid is unreliable. | Colour |
| A_min_blue | 570 | px² | Blue line minimum area before line-loss recovery. 300 triggered recovery too often on faded floor markings. | Colour |
| blue_deadzone | ±5 | px | Centroid deadzone before proportional correction activates. ±5 px ≈ 3° heading error. ±2 caused snaking. | Colour |
| r_pink | [0.40–0.49] | — | Pink chromaticity r-channel range. | Colour |
| r_red | [0.78–0.95] | — | Red (stop signal) chromaticity r-channel range. | Colour |
| r_yellow | [0.47–0.60] | — | Yellow (slow signal) chromaticity r-channel range. | Colour |
| blue_intensity | [80–180] | — | Blue line raw intensity threshold (not chromaticity). Downward camera channel. | Colour |
18 of 18 parameters shown
07 / RESULTS & IMPROVEMENTS
What worked.What didn't.What's next.
Results will be updated after the Week 14 demo run. Task scorecard, timing, and map screenshots are placeholders pending the live evaluation.
Task Scorecard
| Task | Metric | Result | Status |
|---|---|---|---|
| Blue Line Follow | Line acquired + followed | TBD | TBD |
| Occupancy Mapping | Grid populated, no artefacts | TBD | TBD |
| Traffic Compliance | Stop on red, slow on yellow | TBD | TBD |
| Obstacle Avoidance | No contact with obstacles | TBD | TBD |
| Target Approach & Stop | Stop ≤ 0.5 m from pink | TBD | TBD |
Timing Breakdown
A map update weight of 0.01 sounds tiny but accumulates reliably over multiple passes — starting at 0.2 was our biggest early mistake.
The StopFlips hysteresis was not in the original design. One lab run revealed left-right oscillation so severe the robot barely moved. 0.3 s fixed it immediately.
LIDAR is already wired — we just don't fuse it. Every future team should fuse it from day one for full 360° awareness.
Chromaticity is genuinely robust to lighting. We tested under three different lab lighting conditions and the same thresholds worked each time.
The reverse-escape direction lock (escapeDir chosen once on entry) is critical. Without it, the robot re-evaluates each tick and spins in place rather than escaping.