Skip to the lesson
FixTheRobot Explore Robotics / Navigation / M10 Capstone: The Shift / M10-T1

Navigation · Theory · M10

M10-T1 — Designing a Navigation System

A navigation system is not a planner plus a controller. It is a set of promises, a division of labour, numbers with reasons, and a plan to find out whether the promises hold.

  • Lesson 1 of 2
  • Module 10: Capstone: The Shift
  • Theory
  • About 10 minutes to read

The labs of this track each fix one piece. A real project starts earlier and ends later: what must Scout do on a shift, which part is responsible for each promise, where does every number come from, and how will anyone know it works? This lesson turns the whole track into one design process.

Learning objectives

After this lesson, you should be able to:

  • Write navigation requirements that are measurable and can be checked by a named test.
  • Allocate requirements to an architecture of planner, speed policy, safety layer and recovery.
  • Derive parameters from requirements and physical limits instead of tuning them by feel.
  • Plan validation with acceptance criteria and a count of trials that can support a claim.

The intuition

Imagine handing Scout to a night nurse. You would not say “it navigates”. You would say how fast it goes, which doors it can pass, what it does when somebody steps in front of it, when it gives up and calls for help, and what it cannot do (it cannot see glass). That list is the requirements. Who answers for each item is the architecture. The numbers behind each item are the parameter plan, and the evidence you would show the nurse is the validation plan.

Designing is going from the list to the evidence on purpose. If you tune parameters first and write the requirements afterwards, the requirements will describe what the robot happened to do. The track teaches the engineering concepts for each step. It does not replace the safety process that a real product in a real hospital must follow (lesson M10-T2).

From requirements to validationFour boxes in a row: requirements, architecture, parameter plan and validation plan. Arrows go left to right, and a return arrow below carries what validation finds back to the requirements.RequirementsArchitectureParameter planValidation plan what must be truewho does whatnumbers with reasonsevidence it holds What validation finds goes back to the requirements, not only to the parameters. Meridian General, day shift: six deliveries, one door, one glass wall, one corridor crossing
The design loop: requirements, architecture, parameter plan, validation plan, and the return path for what the evidence shows.

The mathematics

1. Requirements

A good requirement says what, how much, under which conditions, and how it will be checked. “Avoid people” cannot be tested. “Stop with at least 0.30 m between robot and person when a person appears 1.5 m or more ahead at speeds up to the zone limit” can.

IDRequirementWhyChecked by
R1At least 5 of 6 deliveries on time; urgent ones alwaysMedicines have deadlinesHidden-shift simulation, field log
R2Zero contact with people or fixed obstaclesHarm to people is not traded for timeSimulation, bench stop tests, field trial
R3Stop within the free distance at any speed the system allowsLatency and braking are physicalStopping-distance test on the real robot
R4Never wait for an obstacle that cannot clear; ask for help in 40 sA stuck robot blocks a corridorRecovery table review, scripted blockages
R5Return to the dock with at least 10 per cent batteryA dead robot is an obstacleEnergy budget, shift log

2. Architecture

Give every promise one owner and one interface, so that when a test fails you know which part to open.

PartOwnsInterfaceTypical failure it must contain
DispatchOrder of stops, deadlines, battery planList of stops in, ordered list outUrgent delivery served last
Global plannerRoute on the mapStart, goal, grid in; cells outRoute through a closed door
Speed and controlSpeed from free distance and zoneDistance and limit in; speed outToo fast to stop
Safety layerStop on contact or violationIndependent of the plannerPlanner fault turning into motion
RecoveryWhat to do when blockedReason, time waited, detour in; action outWaiting for glass forever
Costmaps and perceptionWhat is whereSensor data in; layers outGhost obstacle, invisible glass

3. Parameter plan

Every parameter gets a value, a source and a check. Many follow from physics. With reaction time tr, deceleration a and margin m, the speed at which the robot can stop in a free distance d is:

stop distance
s(v)=v⋅tr+v22as(v)=v\cdot t_{r}+\frac{v^{2}}{2a}
safe speed
v≤a⋅(−tr+tr2+2(d−m)a)v\le a\cdot (-t_{r}+\sqrt{t_{r}^{2}+\frac{2(d-m)}{a}})
capped by
v≤vmax⁡ and v≤zone limitv\le v_{\max}\,\text{and}\,v\le \text{zone limit}
tr
time from detecting an obstacle to the brakes taking hold, in seconds.
a
deceleration the brakes can reliably deliver, in m/s².
m
margin kept between the robot and the obstacle after stopping.
d
free distance the sensors can vouch for, in metres.
ParameterValueSourceVerified by
Inscribed radius0.22 mFootprint plus localisation error (lesson M2-T3)Costmap picture, door pass test
vmax, a, tr, m1.2 m/s, 0.8 m/s², 0.3 s, 0.3 mDatasheet, bench measurementBench stop test
Zone limits0.6 m/s junction, 0.5 m/s glass atriumSensor range (0.8 m sonar for glass)Stop test at the limit
Wait before detourby cost: detour time vs time leftDoor cycle 30 s, detour speed 0.8 m/sScripted door cycle

4. Validation plan

  1. Unit tests for pure functions: planner optimality, safe speed, recovery decisions. Cheap and exact (labs M10-L1 stages 1 to 3).
  2. Simulation on hidden shifts with timings you did not tune on. Tells you about interaction between parts (stage 4).
  3. Bench and track tests that measure what the simulation assumes: stopping distance, sensor range, latency.
  4. Field trial in the real building, with a person responsible and a plan for stopping.

Acceptance criteria are fixed before the runs. For rare failures, the number of trials matters: with zero failures in n independent trials, the 95 per cent upper bound on the failure rate is about 3/n (the “rule of three”).

A worked example

Stopping distance. With tr = 0.3 s, a = 0.8 m/s² and m = 0.3 m:

Stopping distances
v=1.2 m/s: s=0.36+0.90=1.26 mv=1.2\,\mathrm{m}/\mathrm{s}:\,s=0.36+0.90=1.26\,\mathrm{m}
1.56 m with margin
v=0.6 m/s: s=0.18+0.225=0.405 m(0.705 m with margin)v=0.6\,\mathrm{m}/\mathrm{s}:\,s=0.18+0.225=0.405\,\mathrm{m}(0.705\,\mathrm{m}\,\text{with margin})
v=0.5 m/s: s=0.15+0.156=0.306 m(0.606 m with margin)v=0.5\,\mathrm{m}/\mathrm{s}:\,s=0.15+0.156=0.306\,\mathrm{m}(0.606\,\mathrm{m}\,\text{with margin})

The laser vouches for 4 m, so 1.2 m/s is acceptable in an open corridor. A sonar that sees glass only at 0.8 m allows v = 0.8 × (−0.3 + √(0.09 + 2 × 0.5 / 0.8)) = 0.69 m/s at most, so the atrium zone limit of 0.5 m/s has a margin of 0.69 − 0.5. That is a requirement-to-parameter derivation.

Shift budget. Suppose the requirement is 40 deliveries in an 8-hour shift on legs of 90 m, with out and back, 30 s at each handover and an allowance of 20 s per delivery for blockages.

Shift budget
travel=2×90 m0.75 m/s=240 s\text{travel}=\frac{2\times 90\,\mathrm{m}}{0.75\,\mathrm{m}/\mathrm{s}}=240\,\mathrm{s}
cycle=240+30+20=290 s\text{cycle}=240+30+20=290\,\mathrm{s}
shift=40×290 s=11 600 s=3.2 h\text{shift}=40\times 290\,\mathrm{s}=11\,600\,\mathrm{s}=3.2\,\mathrm{h}
40 per cent of 8 h
energy=40 W×240 s+15 W×50 s=10.35 kJ per delivery\text{energy}=40\,\mathrm{W}\times 240\,\mathrm{s}+15\,\mathrm{W}\times 50\,\mathrm{s}=10.35\,\mathrm{kJ}\,\text{per delivery}
=40×10.35 kJ=414 kJ=115 Wh=40\times 10.35\,\mathrm{kJ}=414\,\mathrm{kJ}=115\,\mathrm{Wh}
battery=200 Wh×80 per cent usable=160 Wh\text{battery}=200\,\mathrm{Wh}\times 80\,\text{per cent usable}=160\,\mathrm{Wh}
margin 28 per cent

If the speed policy cut the mean speed to 0.6 m/s, travel becomes 300 s, the cycle 350 s and the shift 3.9 h; energy grows to 142 Wh and the margin to 11 per cent. Slowing down for safety is paid for in margin, which is why the zone limits apply only where the reasoning says they are needed.

How many trials? To support “fewer than 1 contact per 1000 deliveries” with 95 per cent confidence and zero observed, you need about 3 / 0.001 = 3000 failure-free deliveries. Simulation counts only as far as the simulator is believed (lesson M10-T2).

Engineering implications and limitations

Trace every number

Keep a table from requirement to parameter to test, and keep it in the same repository as the configuration. When a test fails, the table tells you which requirement is at risk. When a parameter changes, it tells you which tests to repeat.

One configuration, versioned

The footprint, the limits and the thresholds should live in one versioned file read by every component, with a hash in the logs. Many “mysterious” field failures are two components running different values (lesson M2-T3).

Do not tune on the test set

If you adjust parameters until the hidden shifts pass, they are no longer hidden. Keep a set of timings you do not look at until the end, and generate new ones when you have looked.

Plan the unknowns

A design should say what it assumes (the map matches the building, doors cycle, people walk), what it does not handle (glass the sonar misses in the dark, a stuck brake), and what the robot does when an assumption fails. The last part is recovery, and it deserves as much design as the happy path.

Monitor after launch

Count blockages by cause, help calls, near misses and late deliveries. A requirement that was true on the day of the trial may drift as the hospital changes.

Common misconceptions

“Requirements are paperwork written after the system works.”

Written afterwards they describe the system you built. Written first they decide which tests you need and which parameters you may not trade away.

“Good tuning replaces a validation plan.”

Tuning finds numbers that pass the cases you looked at. Validation asks whether they pass cases you did not choose, and how many.

“A passing simulation shows the robot is safe.”

It shows the code behaves as intended in the simulator’s world. The world, the sensor models and the people are all assumptions that need their own evidence.

“Slower is always safer.”

Slower reduces stopping distance, but it also lengthens exposure, makes deadlines miss and drains the battery. Limits belong where the hazard is.

Engineering takeaways

  1. Write requirements that state a quantity, a condition and a check.
  2. Give every promise exactly one owner in the architecture, with a narrow interface.
  3. Derive parameters from physics and sensor limits, and record the source of each.
  4. Decide acceptance criteria before running, and count the trials a claim needs.
  5. This track teaches engineering concepts; it does not replace the safety process of a real product.

References and further reading

The Nav2 documentation and the standards that frame safety requirements for mobile robots, cited by title only.

  • S. Macenski, F. Martín, R. White and J. Ginés Clavero, “The Marathon 2: A Navigation System”, IEEE/RSJ IROS, 2020.
  • Nav2 documentation, “Navigation Concepts”, “Configuration Guide” and “Tuning Guide”, docs.nav2.org.
  • ISO 3691-4, “Industrial trucks: Safety requirements and verification: Part 4: Driverless industrial trucks and their systems”.
  • ISO 13482, “Robots and robotic devices: Safety requirements for personal care robots”.

Knowledge check

Three conceptual questions. Write an answer, then reveal the explanation. Your answers stay in your browser.

Question 1

A robot has tr = 0.3 s and a = 0.8 m/s². How far does it travel while stopping from 1.0 m/s, and how much free distance does it need with a 0.3 m margin?

Explanation

Reaction: 1.0 × 0.3 = 0.30 m. Braking: 1.0² / (2 × 0.8) = 0.625 m. Total 0.925 m, and 1.225 m with the margin.

Question 2

Why is “the robot shall avoid people” a poor requirement, and how would you rewrite it?

Explanation

It has no quantity, condition or check. Rewrite it with a distance, a speed range and a test, for example: “stop with at least 0.30 m to a person who appears 1.5 m or more ahead, at any speed up to the zone limit, verified by a bench stop test.”

Question 3

A field trial of 600 deliveries shows no contact with a person. What failure rate can you claim at 95 per cent confidence?

Explanation

About 3 / 600 = 0.5 per cent (one in 200) as an upper bound, assuming independent trials. It does not support a claim of one in 1000.

What’s next

Next: how to argue for the design, with evidence, and how to state what it does not cover.

Next lesson

M10-T2 — Engineering Trade-offs and Safety Cases

Argue for a design with evidence, and state its limits and residual risks plainly.

Nothing below is required to finish this lesson.