EECE 5554
Robotics Sensing and Navigation
Lecture 11: System Design Exercise
Design a complete sensing and navigation system, on your own
Dr. Xian Li
Assistant Teaching Professor
Department of Electrical and Computer Engineering
Why a system design exercise
In the labs: one sensor at a time
Lab 1
A GNSS driver, and how far off a fix can be
Lab 2
RTK: centimeters outdoors, when the sky allows
Lab 3
IMU noise you can measure and predict
In a robot: everything at once
Sensors, software, power, and the world meet. Most failures happen at the seams between them:
- a time stamp that is 80 ms late
- a fix that quietly drops to float
- a battery that is older than you planned for
- a person who steps out from behind a car
This exercise gives you a way of thinking you can reuse: which questions to ask, in which order, and how to answer each one with numbers.
What you will do
Design
One scenario, chosen from twelve.
On paper, and on your own.
Requirements, architecture, sensors, localization, integration, and failures.
Report
Six sections, 8 to 12 pages.
Plus the tools you used, an AI use log, and your calculations.
Presentation
Five slides, five minutes.
Then about three minutes of questions, answered without notes.
Worth 10 percent of your grade. It is a warm up for the final project: the same discipline, a smaller scope.
The method: six steps, in order
What must it do, where, and how well?
What are the parts, and how does data flow?
Which sensors, and why these?
How well will it know where it is?
Will it all fit together?
How does it fail, and then what?
Expect at least two loops. Write each one down: what failed, what you changed, and why.
Four habits
Numbers before names
Write what a sensor must do, its range, rate, accuracy, and field of view, before you name a product.
A unit, a source, a confidence level
For every number. A source is a datasheet, your lab data, a notebook tool, or a cited reference.
Precision is not accuracy
The Lab 2 rule again. An error budget needs accuracy, so label which one each number is.
Design for the bad day
Rain, a GNSS outage, a person stepping out, an old battery on a cold morning. These drive the design.
Confidence level: how sure a number is, such as 1σ (one standard deviation) or a 95 percent bound. Precision: how tightly repeated measurements cluster around their own average. Accuracy: how close they are to the truth.
Choose a scenario
Featureless corridors, glass, which floor?
No GNSS inside, look-alike columns
Multipath, curbs, crowds, rain
The canopy blocks GNSS; rows look alike
Water multipath and a rolling boat
No GNSS, steel, tight mass and power
Smoke blinds cameras and lidar
Snow hides edges; ice; cold batteries
Body-worn sensors, a human in the loop
No GNSS, no compass, harsh shadows
The map changes daily; 2 cm registration
Narrow doors, a passenger on board
S13, your own scenario: allowed with approval. Send one paragraph with the mission, the setting, and four given requirements with numbers. It needs at least one hard sensing condition, such as a GNSS-denied segment, poor visibility, or a moving platform.
One student per scenario, first come, first served. Sign up on the scenario sign-up form.
Each scenario fixes four requirements
The worked example: a robotic lawn mower
Mows a 500 m² suburban lawn for one house, with no boundary wire.
- G1. Mow at least 95 percent of the lawn each session.
- G2. No part of the mower more than 0.10 m outside the boundary, 95 percent of the time.
- G3. No buried boundary wire.
- G4. Stop at least 0.15 m short of a child, a pet, or any object 0.3 m tall or more.
- G5. Work through the 15 m long, 1.2 m wide side passage.
- G6. Sensing and computing parts cost at most $1,000 per mower.
- G7. The blade stops within 1 s when the mower is lifted or tilted beyond 30°.
Your scenario's client gives four, G1 to G4. This one gave seven. You may not relax any of them.
Everything else is yours to decide and to justify, including the requirements you derive from these.
Where the description is silent, state an assumption and move on.
Given requirement: one the client fixed. Derived requirement: one you work out from a given one, with the math shown. Here, G2 becomes R4 after the error budget: localization error at most 0.035 m (1σ).
Example: the yard and its stakeholders
Part 1: Problem definition
Operational concept
- Users and stakeholders, and what each cares about
- One normal mission, from start to finish
- The operating envelope
- At least two off-nominal events, and what the system should do in each
- Scope: what you leave out
A requirement is a testable promise
- What, not how: detect a 0.3 m object at 0.6 m, not use a lidar
- One idea each
- A number, a unit, and a condition: 95 percent of passes, on wet grass
- Verifiable by test, analysis, inspection, or demonstration
- Traceable: given, or derived with the math shown
Operational concept: a short story of how the system is used. Operating envelope: the conditions it must work in, such as light, weather, and speed. Off-nominal event: anything worse than normal, such as rain or a failed sensor.
A requirements table, with numbers
| ID | Requirement | Value | Type | Source | Verification |
|---|---|---|---|---|---|
| R1 | Body stays inside the lawn boundary | at most 0.10 m outside, 95 percent | Given | Client | 20 laps of a taped boundary |
| R4 | Cross-track localization error | at most 0.035 m, 1σ | Derived from R1 | Error budget, Tool 6 | Analysis, then the R1 test |
| R6 | Detect a 0.3 m tall object ahead | at 0.6 m or more | Derived from R5 | Stopping distance, Tool 1 | 20 trials with a foam block |
| R7 | Mowing time per charge, aged pack | at least 60 min | Derived from R2 | 108 min of mowing in two charges | Runtime test |
Write at least eight: the four given ones, and at least three derived ones. Each derived one shows the math that produced it, and each one names how it will be checked.
Cross-track error: how far the robot is to the side of its planned path. 1σ: one standard deviation; about two thirds of errors are smaller than this.
From safety to sensor range
How far it travels before it stops
dstop = v t + v² / 2a
v is the speed, t the reaction time, and a the braking deceleration on the worst surface.
range ≥ dstop + margin
The mower's reaction time: 350 ms
At 0.5 m/s on wet grass, 0.5 m/s²: 0.425 m to stop, plus a 0.15 m margin, is 0.575 m. So R6 asks for 0.6 m or more.
A sensor that sees only 0.4 m allows at most 0.35 m/s.
Reaction time (latency): the delay from something happening to the robot responding. In the worst case the object appears just after a sensor frame, so a full sensor period is lost before anything else starts.
Part 2: System architecture
Your pipeline figure shows every sensor, every processing step, the rate of each data flow, and where the safe stop lives. It becomes Slide 2 of your presentation.
Your modes: normal, at least one degraded mode, and a safe stop, each with a number that says when to enter it and when to leave.
Degraded mode: the robot keeps working with less, for example more slowly, when a sensor gets worse. Safe stop: the state it falls back to when it cannot go on safely.
Part 3: Numbers before names
| Sensing need | From | Quantity | Value |
|---|---|---|---|
| See a 0.3 m object in the path | R5, Tool 1 | detection range | 0.6 m or more |
| Cover the full width of the path | R5, Tool 2 | horizontal field of view | 64° or more |
| Absolute position on boundary passes | R4 | 1σ error | 0.035 m or less |
| Heading through a 15 m gap in GNSS | R8, Tools 4 and 5 | gyro N and B | VN-100 class or better |
Pair different physics
Two sensors that fail under the same condition give you no protection against it. Two cameras in fog are still blind.
The notebook's sensor table lists how each kind degrades.
Only after this table is written do you name products. The trade study then picks among them.
Field of view: the angle a sensor can see. Blind zone: the region near the robot that a sensor cannot see from where it is mounted (Tool 2). N and B: the gyro noise parameters from your Lab 3 Allan deviation.
Trade study (Tool 3)
- Candidates: at least three, from different physics
- Must-meet screen, straight from your requirements
- Weights, each with a reason, written before scoring
- Scores: 0 at the threshold, 1 at your goal
- Sensitivity check on the weights
- Decide, and name the runner-up
The mower's obstacle detection
The camera wins in 85 percent of 5,000 random changes to the weights, so it is a clear choice. The bumper stays in the design anyway, as the last layer.
Must-meet threshold: a value a candidate has to pass to stay in the study. Sensitivity check: the weights are changed at random thousands of times; a clear winner keeps winning, about 70 percent of the time or more.
Part 4: Drift between fixes
Between fixes, the error grows
| Heading error at the start | grows like t |
| Gyro noise, N | grows like t1.5 |
| Gyro bias left after calibration, B | grows like t² |
Short gaps: the starting heading dominates. Long gaps: the bias always wins. N and B come from your Lab 3 results.
Wheels and gyro through a 15 m gap in GNSS: 0.108 m at 95 percent, against a 0.25 m limit (Tool 5).
The same IMU with no wheels and no GNSS: past 1 m in 3.5 s. Tilt error lets gravity leak in (Tool 4).
How far apart may fixes be? On the open lawn, 10 s still meets R4; 20 s fails. That is a derived requirement.
Absolute fix: a position from outside the robot, such as RTK GNSS. Dead reckoning: adding up wheel and gyro motion between fixes; its error grows with time. Bias: a small constant offset in a sensor; integrated over time, it becomes a large error.
The error budget (Tool 6)
Add every independent error
Not only the sensor: localization, the map, path tracking, calibration, and time stamps.
σtotal = √(σ1² + σ2² + …)
95 percent bound = 1.96 σtotal
Run it backwards to get a derived requirement: the most that one entry may contribute.
Mower boundary passes: share of the error
0.073 m at 95 percent, against 0.10 m required. The biggest lever is path tracking, not the sensor.
95 percent bound: 95 of 100 errors are smaller than this; on one axis it is 1.96 times 1σ. Root sum square: square each error, add them, and take the square root. It is valid when the errors are independent.
Part 5: Will it all fit together?
Frames and calibration
A TF tree, map, odom, base_link, then each sensor, with the source of every number in it.
Time
One clock for every stamp. A 10 ms time error at 2 m/s is a 2 cm position error.
Data rates (Tool 7)
The mower logging raw depth at 15 Hz: 68.2 GB per 2 h session. A 1 Hz copy of the depth: 6.3 GB.
Power and runtime (Tool 8)
A 5 Ah pack gave 58 min once aged, under the 60 min required. A 7.5 Ah pack gives 87 min.
TF tree: the ROS 2 tree of coordinate frames and the transforms between them. Aged pack: a battery that has lost capacity with use; Lecture 06 designs for 80 percent. C-rate: current divided by capacity; at 2C a pack empties in half an hour.
Traceability (Tool 10)
| R1 | R2 | R4 | R6 | R11 | |
|---|---|---|---|---|---|
| RTK receiver | ● | ● | |||
| IMU | ● | ||||
| Depth camera | ● | ||||
| Coverage planner | ● | ● | |||
| Magnetometer | |||||
| Test | T1 | T2 | T1 | T3 | none |
Every requirement needs a part that meets it and a test that checks it.
Every part needs a requirement, or it is cost with no reason.
The check found two problems in the example: R11 had no test, and no requirement needed the magnetometer. Both are typical.
For each test, say whether you could run it in the final project with course hardware.
Traceability: being able to follow each requirement to the parts that meet it and the tests that check it, and back.
Part 6: How does it fail?
| Guide word | Ask of every block in your pipeline |
|---|---|
| None | What if it gives no output at all? |
| Stuck | What if it keeps repeating the last value? |
| Biased | What if it is wrong but plausible? |
| Noisy | What if the noise is ten times the datasheet value? |
| Late | What if it arrives 200 ms late, or out of order? |
| Intermittent | What if it drops out for 2 s every minute? |
| Wrong frame or units | What if degrees arrive as radians? |
Biased is the dangerous one
Nothing looks broken. The labs have already shown you several:
- an RTK solution read as fixed when it was float
- time stamps that are arrival times
- a magnetometer next to a motor
- voltage sag that resets a sensor
Include power, computing, the network, the map, people, and the environment as blocks too.
Rank them: S, O, D, and RPN
How bad is the effect?
How often does it happen?
How likely is it to go unnoticed?
A high D is bad: it means the failure slips past you.
RPN = S × O × D the risk priority number, from 1 to 1,000. Rank by it, then apply two rules:
- Every severity 9 or 10 gets an action, whatever its RPN.
- A detection must not rely on the part that failed: a crashed computer cannot report its own crash.
FMEA: failure modes and effects analysis, a table of what can fail, what happens next, and how you would know. The three scores are ranks on a 1 to 10 scale, not measurements, so their product can hide a rare but serious failure.
Why severity beats RPN
| Failure mode | S | O | D | RPN |
|---|---|---|---|---|
| Magnetometer heading bent by the motors | 5 | 8 | 7 | 280 |
| GNSS stamped on arrival, 80 ms late | 4 | 8 | 7 | 224 |
| Camera blinded by low sun or a wet lens | 9 | 4 | 6 | 216 |
| Boundary map wrong after the teach-in walk | 6 | 5 | 6 | 180 |
| Pet approaches from the side, in the blind zone | 9 | 3 | 6 | 162 |
| ⋮ five more rows | ||||
| Mower lifted with the blade spinning | 10 | 3 | 2 | 60 |
The lift case ties for eleventh of fifteen by RPN.
Yet it is the only failure that can injure someone without warning.
Its action: a hardware interlock on blade power, tested at every start. It works even when the main computer does not.
Expect to loop
An 18 V, 5 Ah pack: 58 min on an aged pack, under the 60 min required, and 2.78C at peak
A 7.5 Ah pack: 87 min aged, 1.85C peak
The boundary budget under the tree: RTK float gives 0.787 m at 95 percent, against 0.10 m
A planner rule: boundary passes run at most 8 m past the last fixed solution
The camera can be blinded by low sun or water, at severity 9, and nothing else would notice the dog
Three ultrasonic sensors with different physics, and a hardware blade cutoff
A design with no loops usually means a check was skipped. Put a short table of your loops right after the summary of your report.
Presentation: five slides, five minutes
Setting, the 3 to 5 driving requirements, what success means
The pipeline with rates, the main ROS 2 nodes, the safe stop
Trade study result and runner-up, placement, parts list
One figure that proves accuracy, and the runtime
Top three failures, the first prototype test, tools used
Rules
Exactly five slides: no title slide, no backup slides. Each title states a claim. A figure or table on every slide; text 18 pt or larger.
Timing
Aim for 5:00; the presentation is stopped at 5:30. About three minutes of questions follow, answered without notes.
Claim title: a sentence that states what the slide shows, such as A depth camera finds pets in grass, instead of a topic word such as Sensors.
Three items appear twice
| Item | In the report | In the presentation |
|---|---|---|
| The pipeline | Section 2 figure, with rates | Slide 2 |
| Prototype components | Section 3 parts list, Tool 9 | Slide 3 |
| Tools used | Appendix A | One line on Slide 5 |
Plan a cheap prototype
List what you could build in the final project. Course hardware costs you nothing: the TurtleBot 4, the RTK mosaic-X5 receivers, and the VN-100 IMUs.
The mower's prototype costs $87.70 out of pocket.
AI tools: you are the designer
Answer the questions in design_journal.md, sketch, and run the tools. Then commit.
Now an AI tool may review your work. Log what you asked and what you changed.
Learning a concept, finding a datasheet, explaining an error in your code, grammar of text you wrote
Reviewing your requirements, trade study, or failure list; checking a calculation
Choosing your scenario, writing any section or slide, drawing your figures, help during the questions
The commit time in your repository is your evidence that the thinking came first. Work with no Pass 1 behind it earns no process points.
Ask for questions, not answers
Prompts that keep you thinking
Act as a design reviewer. Ask me five questions about my requirements table, one at a time, without suggesting answers.
Here is my stopping-distance calculation. Point to any error, without changing my design.
Verify every number
AI tools state wrong numbers with confidence: mixed-up specifications, part numbers that do not exist, old prices, and ROS 1 packages.
In the worked example, an AI tool gave the OAK-D Lite's field of view as 81°. That is the color camera's diagonal. The stereo pair is 73° horizontal.
Disclosed use costs you nothing. Undisclosed use, or anything in the not-allowed list, is an academic integrity matter.
What to submit
On Canvas
- Your report, one PDF
- Your slides, one PDF, before your presentation
In your repository
The folder on the right, committed as you go.
EECE5554/SDE/ ├── README.md your scenario, one paragraph ├── design_journal.md Pass 1 notes, committed first ├── analysis/ │ ├── sde_analysis.ipynb your copy of the notebook │ └── figures/ ├── report/ source and PDF └── slides/ the slides PDF
You create every file in this folder yourself; none of them comes with the course. The notebook copy starts from EECE5554_SDE_instructions.ipynb, and the report starts from EECE5554_SDE_report_template.md.
Assessment: 100 points
The presentation
Required content 8, clarity 4, timing 3, and questions 5. The questions test whether you can explain your own design.
The process
Tools used 2, AI use log 3, design journal and notebook 3, and report quality 2.
One deduction, as in Lab 2: treating a precision number as an accuracy number in the error budget costs 2 points.
Start today
- Sign up for a scenario on the scenario sign-up form
- Read the worked example once, then put it away. Reuse its structure, not its reasoning
- Copy the notebook and the template into your repository
- Answer the Part 1 questions in your journal, and commit
cd ~/5554-F26 && git pull mkdir -p ~/EECE5554/SDE/analysis/figures ~/EECE5554/SDE/report ~/EECE5554/SDE/slides cp SDE/EECE5554_SDE_instructions.ipynb ~/EECE5554/SDE/analysis/sde_analysis.ipynb cp SDE/EECE5554_SDE_report_template.md ~/EECE5554/SDE/report/ touch ~/EECE5554/SDE/design_journal.md