Review Robotaxi Lidar Architecture

Design a robotaxi sensor architecture with redundancy and safe fallback.

Introduction

30 Second Summary

A robotaxi can look capable on a clear afternoon. The real test begins when glare or road grime makes the street harder to read.

In this project, you will build an engineering review board for a fictional driverless urban taxi in Excalidraw. You will use failure scenarios to decide when roof-mounted lidar earns its extra cost.

What You'll Build

You will use one review board to trace an ordinary pedestrian crossing to controlled braking or a degraded sensing case to a defined safe stop.

By the end of this project, you'll have:

A review-ready Automated Driving System pipeline that lets you trace sensing, perception, prediction, planning, control, and fallback from one board.
A declared Operational Design Domain that makes roads, geography, lighting, weather, and operating limits visible before sensor choices are judged.
An evidence-backed trade-off matrix comparing a camera-led architecture with a multimodal sensor fusion design. A compact decision record will show why the chosen design wins for the declared operating domain.
Secret Mission: Inject a lidar failure. Show how the system detects the fault. Route the robotaxi to degraded operation or a Minimal-Risk Condition.

Are there any prerequisites?

You need the Excalidraw browser editor on a Mac plus basic familiarity with system-design diagrams. No account, installation, coding experience, or automotive experience is required.

Before We Start

A clear design question keeps every later diagram focused on how a driverless urban robotaxi detects road users under uncertainty. Before the hands-on work begins, you are committing to a fictional service that must reach a safe state without an in-vehicle fallback driver.

Set Up the Design Review Board

Your robotaxi design question now has a safety focus. A structured review board keeps its requirements tied to the architecture.

The same board gives failure evidence a direct path into the final decision. In this step, you will use Excalidraw to create that shared review surface.

In this step, get ready to:

Create the review board with a clear title.
Create the five labeled work areas.
Fit the complete layout on screen.

Create the review board title

The core Excalidraw editor is free to use without an account. A clear title keeps every later diagram tied to the same design review.

Visit https://excalidraw.com/ in your Mac browser.
Select the text control in the top toolbar.
Click near the top center of the canvas.
Type Robotaxi Sensor Architecture Review.
Press Esc to finish the title.

Good start. Your canvas now has a clear engineering question at its center.

Build the five work areas

Rectangles create visible boundaries between parts of the review. This structure stops the final decision from becoming detached from its supporting evidence.

Press R to activate the rectangle tool.
Drag a wide rectangle beneath the title.
Press Enter to enter text for the selected rectangle.
Type Operating Domain.
Press Esc to finish the label.

Why use separate work areas?

Each work area gives one review question a visible home. That prevents the final recommendation from floating away from the evidence.

The layout also lets reviewers trace each claim back to its supporting evidence.

Repeat the rectangle-label sequence with Candidate A: Camera-Led.
Repeat the rectangle-label sequence with Failure Test.
Repeat the rectangle-label sequence with Candidate B: Multimodal.
Repeat the rectangle-label sequence with Decision.
Resize each rectangle to leave space for several diagram elements.
Move the rectangles apart to leave clear paths for arrows.
Keep blank space inside each area for short evidence notes.

You should now see five distinct work areas. Each label should sit inside its rectangle.

Fit the full board on screen

Zoom-to-fit is the board-level layout check. It reveals cramped areas before the architecture fills the canvas.

Before you fit the board to the screen, which work area do you expect to need the most room?

Press Shift+1 to zoom to fit all elements.

You should see the title plus all five labeled work areas on one screen. Each area should still have blank space for the diagrams that follow.

Board not fitting cleanly?

Move overlapping rectangles farther apart.
Resize any cramped rectangle to restore blank space.
Press Shift+1 again to repeat the check.

Help me fix my Excalidraw board layout.

✔️ The full board fits on screen

That is the foundation complete. Your review board can now hold the full architecture discussion on one canvas.

ⓧ I'd like to double check the full board

Compare your canvas with this checkpoint.

Confirm the board title is Robotaxi Sensor Architecture Review.
Confirm the Operating Domain work area exists.
Confirm the Candidate A: Camera-Led work area exists.
Confirm the Failure Test work area exists.
Confirm the Candidate B: Multimodal work area exists.
Confirm the Decision work area exists.
Press Shift+1.
Confirm the full board fits on screen with room for arrows and short evidence notes.

Your review board now keeps every design question inside one visible structure. Next, you will define the operating domain and draw the camera-led baseline.

Draw the Camera-Led Baseline

Your Excalidraw review board is ready. The next goal is to give it a complete driving path that reviewers can follow.

A camera-led perception pipeline gives you a visible baseline for an ordinary pedestrian crossing. However, this baseline has not yet proven how it handles degraded visibility or safe fallback.

In this step, get ready to:

Define the operating boundaries for the fictional driverless service.
Connect the complete camera-led driving pipeline.
Trace a daylight pedestrian crossing to a controlled stop.

Define the operating domain

An Operational Design Domain defines where an Automated Driving System is designed to operate. It gives every later sensor decision a clear boundary.

Add geofenced urban streets as the geography note inside Operating Domain.
Add daytime and nighttime operation as the lighting note.
Add clear weather and light rain as the weather note.
Add mixed traffic as the traffic note.
Add vulnerable road users as the road-user note.
Add no in-vehicle fallback driver as the operating constraint.

You should now see six operating boundaries inside Operating Domain. Together they describe where the fictional service is expected to drive.

Why the Driver Constraint Matters

With no in-vehicle fallback driver, the Automated Driving System must handle conditions beyond its operating limits itself. A minimal-risk condition gives later failure tests a required safe endpoint.

Connect the camera-led pipeline

The baseline turns camera observations into physical vehicle movement. Each box represents one responsibility in that flow.

Add seven equal boxes in one horizontal row inside the Candidate A: Camera-Led area from earlier.
Label the boxes from left to right as Surround Cameras, Perception, Scene Model, Prediction, Planning, Control, and Steering and Braking.

You should see all seven stages in one readable sequence. The row should leave enough space for connectors between neighboring boxes.

Draw one right-facing arrow between each pair of neighboring boxes.
Point every arrowhead toward Steering and Braking.

You should now see one uninterrupted path from Surround Cameras to Steering and Braking.

How Does the Pipeline Flow?

Surround Cameras capture image evidence around the vehicle.
Perception identifies relevant objects from the sensor input.
The Scene Model organizes the system's current understanding of the road.
Prediction estimates how nearby road users may move.
Planning selects the driving response.
Control converts the plan into vehicle commands.
Steering and Braking apply those commands to the vehicle.

Trace the daylight crossing

A scenario trace tests whether the architecture can carry one concrete event through every stage. This daylight crossing provides the baseline case that later failure tests can challenge.

Add a small token to the left of Surround Cameras.
Label the token Pedestrian crossing in daylight.

You should see the pedestrian scenario positioned as an input to the camera-led pipeline.

Choose a green fill for the scenario token from the color controls.
Draw a green trace from the token through each pipeline box.

The green trace should pass through all seven stages without jumping over a box.

Add an outcome note labeled Controlled stop before the crosswalk after Steering and Braking.
Extend the green trace from Steering and Braking to the outcome note.

Before the final check, make a quick prediction about whether the green scenario reaches the stopping outcome without skipping a stage.

Fit the full board on screen by pressing Shift+1.
Trace the green scenario from Surround Cameras to Steering and Braking.

You should see the title plus all five work areas on screen. Every arrow should reach a visible next stage before the green trace ends at Controlled stop before the crosswalk.

That gives you a reviewable baseline. The pedestrian scenario now links sensing to a controlled stop.

Does the Trace Skip a Stage?

Move any arrow endpoint that stops short of its neighboring box.
Move the green trace so it touches every stage in the pipeline.

Ask for help if a connection still looks unclear: help me find the broken connection in my Excalidraw camera-led pipeline.

Your camera-led baseline now traces an ordinary daylight crossing. Next, you will test whether that clean path survives conditions that weaken its evidence.

Expose the Baseline Failures

Your Excalidraw board now carries a green pedestrian trace through the camera-led baseline to a controlled stop. The ideal path looks complete.

A complete-looking pipeline can still hide weak evidence during degraded visibility. It can also hide the absence of safe behavior when confidence falls.

Your Operational Design Domain leaves no in-vehicle driver available for fallback. This step forces each uncertainty trace to a visible endpoint.

In this step, get ready to:

Inject a degraded-visibility scenario into Perception.
Expose missing independent range evidence before Planning.
Mark the absent fallback as a blocked review.

Inject degraded camera visibility

Sensor inputs can lose confidence before the rest of the perception pipeline notices. A red trace lets you test where the current design explicitly reacts.

Add the text Direct glare plus road grime near the left side of Failure Test.
Select the new failure label.
Choose red from the color palette above the canvas.
Add a second label named Reduced camera confidence beneath the first label.
Set the second label to red.
Connect Direct glare plus road grime to Reduced camera confidence with a red arrow.

Before you continue the trace, where do you think reduced camera confidence will reach a defined response?

Connect Reduced camera confidence into the existing Perception stage with a red arrow.
Extend the red trace from Perception toward Scene Model.

The red trace reaches Perception. The current board supplies no confidence-handling rule.

The board also supplies no fallback destination. This is the intended review failure.

Place a red Unresolved marker at the end of the trace.

You have made the first hidden assumption visible. Reduced camera confidence now stops at a named gap.

What does Unresolved mean?

The Unresolved marker records a missing design response in this fictional candidate. It keeps the review focused on an explicit gap.

The baseline cannot yet justify a safe action for this scenario. The finding applies to this draft architecture within its declared operating domain.

Test range confidence before planning

Planning needs enough range confidence to choose braking distance. Independent evidence would let a reviewer compare the estimate with another sensing source.

Add the text Pedestrian range uncertain beneath the first failure trace in Failure Test.
Set the new failure label to red.

Before you trace this case, do you expect the baseline to show an independent range check before Planning?

Draw a red trace from Pedestrian range uncertain toward the section between Scene Model and Planning.
Inspect Candidate A: Camera-Led for another sensing path that independently checks pedestrian range.

Candidate A shows Surround Cameras as its only sensing input. The board contains no independent range measurement before Planning.

Add a red note named No independent range evidence beside the trace before Planning.
Terminate the second red trace with another Unresolved marker.

That second failure is now concrete. The review can point to the missing evidence before debating sensor choices.

Block the review at the missing fallback

In a driverless service, unresolved uncertainty needs a defined path to a Minimal-Risk Condition. A safe-stop behavior must be reachable without driver intervention.

Draw a short red connector from the first Unresolved marker toward a shared note position.
Draw a short red connector from the second Unresolved marker toward the same note position.
Add the note Review blocked: failure is not contained beside the two connectors.

Before you zoom out, do you expect either red trace to reach a defined safe action?

Press Shift+1 to fit the full board on screen.
Follow the first red trace from Direct glare plus road grime to its endpoint.
Follow the second red trace from Pedestrian range uncertain to its endpoint.

You should see both red traces terminate at Unresolved before any safe action. The shared note should read Review blocked: failure is not contained.

The full board should fit on screen. The two red paths now make the missing fallback visible.

✔️ My failure test is complete

Your board preserves the green success case while showing two red unresolved failures. The final note blocks approval until the architecture contains each failure.

ⓧ I'd like to double check my board

Confirm the title reads Robotaxi Sensor Architecture Review.
Confirm the board contains Operating Domain, Candidate A: Camera-Led, Failure Test, Candidate B: Multimodal, and Decision.
Confirm Operating Domain lists geofenced urban streets, daytime operation, nighttime operation, clear weather, light rain, mixed traffic, vulnerable road users, and no in-vehicle fallback driver.
Confirm Candidate A: Camera-Led connects Surround Cameras, Perception, Scene Model, Prediction, Planning, Control, and Steering and Braking in that order.

These elements preserve the review context you already built.

Confirm the green Pedestrian crossing in daylight token reaches a controlled stop before the crosswalk.
Confirm a red trace carries Direct glare plus road grime through Reduced camera confidence into Perception.
Confirm a red trace carries Pedestrian range uncertain to the missing independent range evidence before Planning.
Confirm both low-confidence traces terminate at red Unresolved markers.
Confirm the shared note reads Review blocked: failure is not contained.
Confirm the full board fits on screen after pressing Shift+1.

Your baseline now fails visibly for two specific reasons. Next, you will redesign the architecture so uncertainty reaches a confidence-checked plan or a safe fallback.

Design Multimodal Redundancy

Your Excalidraw review board now exposes two unresolved paths. Both stop before the system can justify a driving response or a safe fallback.

The second candidate adds complementary evidence through sensor fusion. A confidence gate sends uncertainty toward a checked plan or a minimal-risk condition.

This structure gives every uncertain case a named destination.

In this step, get ready to:

Create three complementary sensor inputs that converge through time alignment and fusion.
Extend the fused scene model through prediction, planning, control, and actuation.
Add a confidence gate with explicit planning and safe-stop paths.

Add complementary sensor evidence

Each modality observes a different property. Cameras provide semantic detail.

Lidar contributes 3D distance. Radar contributes distance plus velocity.

Return to the Candidate B: Multimodal area on your review board.
Use the rectangle plus text workflow from earlier for every new box in this area.
Add a box labeled Cameras: semantic detail on the left side.
Add a box labeled Lidar: 3D distance below the camera box.
Add a box labeled Radar: distance and velocity below the lidar box.
Add a box labeled Time Alignment and Calibration to the right of the three inputs.
Add a box labeled Sensor Fusion to the right of Time Alignment and Calibration.

You should now see three distinct evidence sources beside two shared processing stages.

Draw an arrow from Cameras: semantic detail to Time Alignment and Calibration.
Draw an arrow from Lidar: 3D distance to Time Alignment and Calibration.
Draw an arrow from Radar: distance and velocity to Time Alignment and Calibration.
Draw an arrow from Time Alignment and Calibration to Sensor Fusion.

You should see all three inputs converge before fusion creates a shared interpretation.

What Does Each Input Contribute?

Cameras: semantic detail supplies visual meaning such as signs or traffic-light states.
Lidar: 3D distance supplies independent range measurements.
Radar: distance and velocity adds distance evidence plus object motion.
Time Alignment and Calibration prepares the measurements for Sensor Fusion.

Are the input arrows hard to follow?

Increase the vertical space between the three sensor boxes.
Move Time Alignment and Calibration farther to the right if the arrows overlap.
Keep every arrowhead pointed toward Sensor Fusion.

Help me untangle the sensor input arrows on my Excalidraw architecture board.

Build the shared driving pipeline

Fusion only helps when downstream components consume a shared scene model. Sensor health monitoring makes degraded inputs visible to the architecture.

Add a box labeled Scene Model to the right of Sensor Fusion.
Add a box labeled Prediction to the right of Scene Model.
Add a box labeled Planning to the right of Prediction.
Add a box labeled Control to the right of Planning.
Add a box labeled Steering and Braking to the right of Control.
Add a box labeled Sensor Health Monitor beside the three sensor inputs.

The full processing chain is now visible beside the sensor inputs.

Connect Sensor Fusion to Scene Model.
Connect Scene Model to Prediction.
Connect Prediction to Planning.
Connect Planning to Control.
Connect Control to Steering and Braking.

You should see one uninterrupted route from Sensor Fusion to Steering and Braking.

What Does the Health Monitor Do?

The Sensor Health Monitor reports degraded or missing inputs. The confidence gate uses that status alongside scene evidence.

Does the pipeline look disconnected?

Check that each arrowhead points from sensing toward vehicle control.
Check that Scene Model appears only once in Candidate B.
Move Sensor Health Monitor beside the inputs if it interrupts the main pipeline.

Help me check the direction of my multimodal robotaxi pipeline.

Route uncertainty to a safe fallback

A complete pipeline needs a policy for uncertainty. The gate turns evidence quality into an explicit route.

Select the direct arrow from Prediction to Planning.
Remove the direct arrow.
Add a box labeled Confidence Gate between Prediction and Planning.
Connect Prediction to Confidence Gate.
Connect Confidence Gate to Planning.
Label the path into Planning as Sufficient evidence.

You should see an evidence check between prediction and planning.

Draw a lower branch from Confidence Gate.
Label the lower branch Insufficient or conflicting evidence.
Add a box labeled Minimal-Risk Condition at the end of the lower branch.
Add a box labeled controlled safe-stop path after Minimal-Risk Condition.
Connect Minimal-Risk Condition to controlled safe-stop path.

The gate now has one route for continued operation and one route for a controlled fallback.

Why End at a Minimal-Risk Condition?

A minimal-risk condition gives the Automated Driving System a defined state when current conditions no longer support continued operation inside the Operational Design Domain.

This service has no in-vehicle fallback driver. The board therefore ends the fallback path at a controlled safe stop.

The gate becomes reviewable when the earlier failures reach it. Candidate A stays unchanged so the board preserves the evidence that motivated the redesign.

Keep both original Unresolved markers visible in Candidate A.
Keep the note Review blocked: failure is not contained visible beside Candidate A.
Extend a red trace from Direct glare plus road grime to Cameras: semantic detail in Candidate B.
Continue that red trace through Time Alignment and Calibration, Sensor Fusion, the shared Scene Model, Prediction, and Confidence Gate.
Extend a red trace from Pedestrian range uncertain toward the lidar and radar inputs in Candidate B.
Continue that red trace through fusion to Confidence Gate.

Before you trace the outcomes, consider which route each scenario is most likely to take when the remaining evidence agrees.

Follow the Direct glare plus road grime trace from the sensor inputs to Confidence Gate.
Follow the Pedestrian range uncertain trace from the range inputs to Confidence Gate.
Press Shift+1 to fit the full review board on screen.

You should see sufficient remaining evidence reach Planning through the labeled upper path. Insufficient or conflicting evidence reaches Minimal-Risk Condition through the lower path.

Candidate A's original Unresolved markers remain visible. Candidate B's red traces now reach a defined driving or fallback outcome.

That closes the review gap. Your redesign now gives uncertainty a visible route and endpoint.

Do the red traces still stop early?

Check that each Candidate B trace reaches Confidence Gate.
Check that Sufficient evidence ends at Planning.
Check that Insufficient or conflicting evidence ends at Minimal-Risk Condition.

Help me find the missing connection in my Candidate B failure traces.

Your multimodal architecture now combines complementary sensing with health monitoring and a defined fallback. Next, you will compare both candidates and defend the roof-mounted lidar decision.

Make the Architecture Decision

The multimodal redesign on your Excalidraw board now contains the failures that blocked the camera-led baseline. You have complementary evidence plus a controlled safe-stop path.

A review still needs a decision tied to the declared Operational Design Domain. Real-world evidence must support the recommendation.

The final recommendation must also acknowledge the cost of lidar. It must explain whether roof mounting helps the vehicle meet its sensing requirements.

In this step, get ready to:

Compare both candidates across eight review criteria.
Anchor the recommendation with evidence from Waymo plus Tesla.
Write an architecture decision record that explains the roof-mounted lidar choice.

Compare the candidates

A trade-off matrix makes the safety benefits visible beside the implementation burden. The meaning of each rating depends on whether the row measures a benefit or a burden.

How to read the ratings

Read the first three rows as benefits. High means the architecture offers more of that benefit.

Read the final five rows as burdens. High means the architecture demands more effort or cost.

Column labels: Criterion. Candidate A: Camera-Led. Candidate B: Multimodal.
ODD coverage: Candidate A is Medium. Candidate B is High.
Independent evidence: Candidate A is Low. Candidate B is High.
Failure containment: Candidate A is Low. Candidate B is High.
Compute and bandwidth: Candidate A is Low. Candidate B is High.
Hardware cost: Candidate A is Low. Candidate B is High.
Cleaning and maintenance: Candidate A is Medium. Candidate B is High.
Packaging: Candidate A is Low. Candidate B is High.
Validation complexity: Candidate A is Medium. Candidate B is High.

Draw a three-column comparison inside Decision.
Copy the three column labels from the rating reference into the comparison.

You should now see one column for each candidate beside a shared criteria column.

Copy all eight rated rows from the reference into the comparison.

You should now see Candidate B score higher on the three benefits. Its five burden ratings also expose the price of that capability.

Add the evidence cards

The matrix records your engineering judgment. Evidence cards keep that judgment connected to documented examples without turning either vendor into a universal answer.

Draw the first evidence card inside Decision.
Enter Waymo documents a 6th-generation multimodal suite with cameras, lidar, and radar in the first card.

You should now see one documented example of a multimodal sensing suite beside your comparison.

Draw the second evidence card inside Decision.
Enter Tesla's current Cybercab guide documents eight exterior-facing cameras. in the second card.

You should now see a documented camera count beside the multimodal example.

Enter A product guide's camera list alone does not prove a complete sensor architecture or the absence of another modality. beneath the evidence cards.

The caution now limits the conclusion to what the cited product guide supports.

What the evidence proves

The Waymo sixth-generation article supports the multimodal example. It documents cameras plus lidar plus radar working as a unified system.

The Cybercab guide supports the exterior-camera count. The complete sensor architecture remains outside this evidence card's scope.

Record the decision

An architecture decision record captures the recommendation beside its reasoning. It also preserves the consequences that future reviewers must accept.

Decision record reference

Context: The declared ODD includes nighttime operation. It includes light rain. Vulnerable road users share the road. No in-vehicle fallback driver is available.
Decision: Choose Candidate B: Multimodal for this ODD. Require lidar-derived 3D range. Use roof mounting only when it satisfies vehicle-integration requirements.
Why: Independent range evidence addresses the uncertain-distance gap. Complementary sensing addresses limited camera visibility. The confidence gate contains residual uncertainty.
Consequences: Compute and bandwidth are High. Hardware cost is High. Cleaning and maintenance are High. Packaging is High. Validation complexity is High.
Rejected Alternative: Reject Candidate A in its current form. It leaves independent range evidence unresolved. It leaves failure containment unresolved.

Draw a compact decision card inside Decision.
Add the five field labels from the decision record reference.

You should now see a compact structure for the recommendation beside the comparison.

Fill the five fields with the text from the decision record reference.

The recommendation now connects the selected architecture to the declared ODD. It also records the burden that comes with the choice.

Add a terminology note titled Correction: spinning camera beneath the decision record.
Enter Lidar actively measures 3D range. The visible roof package reflects placement and integration choices. The complete driving system defines the robotaxi. in the note.

Your board now separates the sensing requirement from the visible shape of the sensor package.

Before you rehearse, do you think every major claim can be supported by pointing to one visible part of the board?

Begin a two-minute walkthrough at Operating Domain.
Explain the active 3D range contribution at Lidar: 3D distance.
Trace Pedestrian range uncertain through the multimodal architecture.
Summarize the architectural burden shown in the comparison.
Finish at the decision record with the reason Candidate A lost.
Press Shift+1 in Excalidraw to fit the complete board on screen.

What should you hear?

The roof unit contributes active 3D range evidence.
Independent evidence addresses the uncertain-range failure.
The confidence gate contains any remaining uncertainty through a controlled safe stop.
The comparison exposes higher compute plus hardware cost plus integration complexity.
Candidate A loses because its current evidence gaps remain unresolved.

You should see the title plus all five labeled work areas fit on screen. Every major recommendation should have a visible piece of supporting evidence.

That closes the design review. Your recommendation now connects the operating domain to failure evidence plus architectural consequences.

Secret mission

Survive a Lidar Failure

Inject a lidar failure into the review board. Make every continuation decision pass explicit checks before the robotaxi moves in a degraded state. Route failed checks to a controlled safe stop with a clear status notification.

Clean Up Your Resources

Your robotaxi review board is stored locally in Excalidraw's browser storage. No paid resource means no charges continue after this project.

Resources you used:

The browser scene containing your complete Robotaxi Sensor Architecture Review board.
Any file or image copy you chose to save.

Keep everything running

No action is required while you are still refining or presenting the robotaxi review board.

Keep the current Excalidraw browser scene for future design-review practice.
Save a file copy of the complete Robotaxi Sensor Architecture Review board as a backup.
Use the board to rehearse your architecture decision walkthrough.

Pause - I'll come back to this later

Pausing preserves a portable copy. No service continues running after you close the tab.

Save a file copy of the complete review board.
Close the Excalidraw browser tab.
Return later by loading your saved file copy in Excalidraw.

Delete - I don't want to use this again

Deletion is permanent. Choose this option only when you no longer need the board or its saved copies.

Switch back to the Excalidraw tab from earlier.
Drag a selection box around the complete review board.
Delete the selected board elements.
Confirm the canvas no longer shows the title or any of the five work areas.
Delete each file or image copy from the location where you chose to save it.
Close the Excalidraw browser tab.

Nice Work!

You did it! You completed a presentation-ready robotaxi architecture review in Excalidraw.

You've learned how to:

Defined an Operational Design Domain for the fictional taxi service. Traced the Automated Driving System from sensing to a controlled stop.
Broke the camera-led baseline with degraded visibility. Exposed its missing independent range evidence. Rebuilt the design around sensor fusion. Added sensor health monitoring. Routed uncertainty to a Minimal-Risk Condition.
Built an evidence-backed trade-off matrix for both candidates. Wrote an architecture decision that explains when roof-mounted lidar earns its cost and complexity.
Completed the Secret Mission by injecting the Lidar unavailable fault. Designed conditional degraded operation around the declared ODD. Routed failed assumptions to a controlled safe stop. Added a status notification for riders or remote assistance.

Ready to quiz yourself?