The problem
End-to-end driving networks can steer well in conditions they have seen, but they fail unpredictably out of distribution and are hard to verify against ISO 26262 or SOTIF. A practical route is to pair the network with a monitor that bounds its outputs and hands over to a verified fallback. Quantifying the trade-off between intervention rate and safety is the research problem.
Objectives
- Collect driving data in CARLA and train an image-to-steering network.
- Characterise performance and failure modes in and out of the training distribution.
- Design a safety envelope combining output bounds, uncertainty and geometric checks.
- Implement a runtime monitor and fallback controller and evaluate closed-loop safety.
- Study the trade-off between intervention rate and lane departures or collisions.
What you need
Tools and toolboxes
- CARLA — Data collection, training environments and closed-loop evaluation across towns and weather.
- Python — Data pipelines, training, monitor logic and analysis.
- PyTorch — Training the steering network and ensembles for uncertainty.
- OpenCV — Image preprocessing and visualisation.
- ONNX and TensorRT (optional) — Exporting the network to measure real-time inference on an embedded GPU.
Software
- CARLA simulator with its Python API
- Python 3 with PyTorch, NumPy and OpenCV
Extra parts and data
- GPU workstation — CARLA rendering and network training both need a capable GPU.
Key concepts
- Behaviour cloning
- Training a network to imitate expert actions from recorded observations. It suffers from compounding errors because training data rarely shows recoveries from mistakes.
- Safety envelope
- A set of conditions on outputs and states, such as steering limits, lateral offset bounds and uncertainty thresholds, within which the learned controller is allowed to act.
- Runtime monitor and fallback
- A simple, verifiable component that checks the envelope every cycle and switches to a fallback controller, such as a geometric lane follower, when it is violated.
- Out-of-distribution detection
- Recognising inputs unlike the training data, using ensemble disagreement, feature-space distances or reconstruction error.
Step-by-step guide
- 1
Set questions and ODD
Review end-to-end driving, behaviour cloning, uncertainty estimation and runtime assurance (simplex architecture) literature. Frame questions: how well does monitor-guarded steering preserve safety under distribution shift, and at what intervention cost? Define the ODD for training, such as specific CARLA towns in clear weather, and the shifted conditions for testing, such as new towns, rain and night. Fix the routes and seeds for each condition now so later comparisons use identical tests.
Checkpoint: A proposal with research questions, ODD and shift conditions defined.
- 2
Collect training data
Use CARLA's autopilot or a rule-based expert to drive in the training towns while recording front-camera images, steering, speed and lane geometry at 10 to 20 Hz. Add left and right offset cameras with corrected steering labels to provide recovery examples, and inject small steering noise during collection so the expert demonstrates recoveries. Store data by route and split by route for training and validation.
Checkpoint: A dataset of several hours with balanced turning and straight driving and documented splits.
- 3
Train the steering network
Train a convolutional network, such as a compact ResNet variant, mapping a cropped image and optionally speed to steering angle with a smooth L1 loss. Balance the dataset so straight driving does not dominate. Train several networks with different seeds to form an ensemble for uncertainty. Track validation error, and check prediction smoothness over sequences rather than per frame only.
Checkpoint: Validation steering error and smoothness metrics for each ensemble member.
- 4
Evaluate open- and closed-loop
Run the network in closed loop in training towns and shifted conditions with a fixed speed controller. Measure lane departures, collisions, route completion and mean offset per kilometre. Compare open-loop validation error with closed-loop results to show where they disagree. Collect clips of failure modes such as junctions, shadows and unusual road textures. Run each route several times with different traffic seeds and report mean and spread rather than a single run.
Checkpoint: Closed-loop metrics per condition and a catalogue of failure clips.
- 5
Design the safety envelope
Define envelope conditions: steering and steering-rate bounds as a function of speed; a lateral offset bound from an independent lane estimate; a heading-error bound; and an uncertainty bound from ensemble variance. Choose thresholds with validation data. Formalise the envelope so it can be argued separately from the network, and list which conditions catch which observed failure modes. Keep the envelope logic independent of the network's internals so it can be reviewed separately.
Checkpoint: A documented envelope with thresholds and a mapping to failure modes.
- 6
Implement monitor and fallback
Implement the monitor as a small, deterministic Python module, checked every cycle. When violated, switch to a fallback controller such as Stanley on map-based lane geometry, or a minimal-risk manoeuvre of slowing in lane. Add hysteresis for returning control to the network. Log every intervention with its cause and duration. Measure the switching delay from violation to fallback action, and check that the fallback controller alone can drive every route safely in the ODD, since the whole argument depends on it.
Checkpoint: Scripted tests trigger each envelope condition and show correct switching to the fallback.
- 7
Evaluate guarded driving
Re-run all closed-loop tests with the monitor active. Measure lane departures, collisions, intervention rate per kilometre, time under fallback and route completion. Sweep the uncertainty threshold to draw a curve of safety against intervention rate. Compare with the unguarded network and with the fallback alone. Use the same routes, weather and seeds as the unguarded runs. Report how many departures still occurred with the monitor active and what caused each one, because these residual failures are the most important finding for the safety argument.
Checkpoint: Safety-versus-intervention curves for each test condition.
- 8
Study detection quality
Evaluate how well the uncertainty signal predicts upcoming errors: compute the area under the ROC curve for detecting frames where offset will exceed a bound within the next second. Compare ensemble variance with alternatives such as Monte Carlo dropout or feature-distance methods. Identify failure modes the envelope misses, which are the most important result for safety argumentation. Report the lead time between the alarm and the error for each method.
Checkpoint: ROC curves for error prediction and a list of missed failure modes.
- 9
Connect to safety standards
Write a short safety argument structured around ISO 26262 and ISO 21448 concepts: the network as a non-verified component, the monitor and fallback as the elements carrying the safety requirement, and the triggering conditions found. Discuss what evidence would still be needed, such as coverage of the ODD and monitor verification. Keep the argument short and honest, and list clearly which claims are supported by your simulation evidence and which remain open.
Checkpoint: A safety argument outline with identified evidence gaps.
- 10
Write and publish
Write the thesis chapters: data, model, closed-loop results, envelope design, monitor evaluation and safety argument. Release the data collection and evaluation scripts so results can be reproduced. Present results with confidence intervals over seeds and routes. Be explicit that all tests are in simulation and that real-world transfer is future work. Include the envelope thresholds, network architecture and training settings in an appendix, and archive the exact CARLA version used.
Checkpoint: Thesis chapters and paper draft with reproducible code.
Testing & validation
- Lane departures, collisions and route completion with and without the monitor.
- Intervention rate and time under fallback per kilometre.
- ROC performance of the uncertainty signal for error prediction.
- Results across training and shifted conditions with confidence intervals.
Expected results
An end-to-end steering network with a runtime safety envelope and fallback, evaluated in CARLA with quantified safety-versus-intervention trade-offs and documented gaps in the monitoring.
Research angle for your PhD
Research questions: can a runtime monitor based on uncertainty and geometric checks keep a learned steering policy safe under distribution shift, and what intervention rate does that cost? Metrics: departures and collisions per kilometre, intervention rate, error-prediction AUROC, route completion. A contribution combining a reproducible CARLA benchmark, a monitor design and a safety argument tied to ISO 21448 is suitable for venues on autonomous systems and safety assurance.
Take it further
- Learn the envelope thresholds from data with conformal prediction.
- Include longitudinal control and traffic interaction.
- Test sim-to-real transfer on recorded real driving data offline.
Viva and review questions
Why add offset cameras during data collection?
Pure expert driving rarely shows recovery from drift; offset views with corrected labels teach the network how to steer back to the lane centre.
Why is the monitor easier to verify than the network?
It is a small deterministic set of rules on measurable signals, which can be reviewed, tested exhaustively and analysed under ISO 26262, unlike millions of learned weights.
What does the safety-versus-intervention curve show?
How many interventions are needed to reach a given safety level; a better monitor achieves fewer departures for the same intervention rate.
Learn it at DIYguru
These DIYguru courses and programmes teach what this project needs.