Differences

This shows you the differences between two versions of the page.

--- en:safeav:handson:uc:shuttle [2026/04/29 16:53] – raivo.sell
+++ en:safeav:handson:uc:shuttle [2026/04/29 17:02] (current) – raivo.sell
@@ Line 1: / Line 1: @@
+====== Use Case #1 AV Shuttle ======
+<note>Initial description and text. can be removed after new content is here.</note>
+The **TalTech iseAuto AV shuttle** is Estonia’s first self-driving vehicle developed as an academic–industry collaboration led by Tallinn University of Technology. TalTech iseAuto operates as a fully electric vehicle with a top speed of approximately 25 km/h and a capacity of up to eight passengers. It can run for around eight hours on a single charge, making it well-suited for short urban routes and campus loops. The shuttle is equipped with a comprehensive perception system that includes three LiDAR sensors and five cameras, providing 360-degree environmental awareness. Navigation is based on pre-mapped routes, while a remote control room enables teleoperation and system monitoring when necessary. Within TalTech, iseAuto serves as a research and educational platform that bridges theoretical learning and real-world experimentation in autonomous driving. The shuttle integrates with the Autoware open-source software stack for perception, planning, and control, and it supports a digital twin simulation environment that allows testing of algorithms in virtual conditions before deploying them on the physical vehicle. This approach has made iseAuto an essential testbed for validating autonomous vehicle safety, sensor fusion, and human–machine interaction.
+The focus on developing a simulation-based use case that supports education, prototyping, and pre-deployment testing. The requirements reflect both academic and technical needs, guiding the selection of suitable V&V tools and simulation environments.
+- **Multi-level simulation**: The V&V setup must support both low-fidelity and high-fidelity 3D simulation tools, enabling validation across different abstraction levels.
+- **Scenario testing**: The environment should support OpenSCENARIO-based scenario definitions to allow testing of complex multi-agent interactions, traffic behaviors, and reproducible validation sequences.
+- **Autoware compatibility**: All V&V tools must integrate smoothly with Autoware.Universe, allowing validation of core modules such as localization, planning, and control within the same architecture.
+- **Evaluation metrics**: Tools must enable automated analysis of safety metrics such as collisions, mission completion, traffic rule violations, and behavioral KPIs, suitable for both assessment and comparison.
+- **Containerized deployment**: All software should support Docker-based environments for consistent, platform-independent deployment across student and research systems.
+- **Educational accessibility**: Tools must be open-source, Linux-compatible, and well-documented, with a gentle learning curve suitable for university-level instruction in robotics and autonomy.
+- **Iterative development**: The system should allow for quick modifications and testing of nodes or logic, supporting hands-on experimentation and frequent updates in a classroom setting.
+- **Sustainability**: Tools and content must be maintainable post-project, avoiding dependencies on commercial services or non-portable infrastructure to ensure long-term use.
+The AV Shuttle use case requires a flexible and scalable V&V setup that supports both low- and high-fidelity simulations, OpenSCENARIO-based scenario testing, and full integration with Autoware.Universe stack. The environment must enable automated safety and performance evaluation, containerized deployment, and open-source accessibility suitable for higher education. It emphasizes iterative, hands-on experimentation and long-term sustainability without reliance on commercial tools.
+<note>Cuts from main book - in the book i do not want to have use case specific material</note>
+===== Case Study and Safety Argumentation =====
+On the TalTech iseAuto shuttle, the digital twin (vehicle model, sensor suite, and campus environment) is integrated with LGSVL/Autoware through a ROS bridge so that “photons-to-torque” loops are exercised under realistic scenes before any track test. Scenarios are distributed over the campus xodr network using Scenic/ M-SDL; multiple events can be chained within a scenario to probe planner behaviors around parked vehicles, slow movers, or oncoming traffic. Logging is aligned to the KPIs above so outcomes are comparable across LF/HF layers and re-runnable when planner or control parameters change.
+In practice, this has yielded a concise, defensible narrative for planning & control safety: (1) what was tested (formalized scenarios across a structured parameter space); (2) how it was tested (two-layer simulation with a calibrated digital twin and, when necessary, track execution); (3) what happened (mission success, DTC minima, TTC profiles, braking/steering transients, localization drift); and (4) why it matters (evidence that tuning or algorithmic changes move the decision–execution loop toward or away from safety). The same framework has been used to analyze adversarial stresses on rule-based local planners, reinforcing that planning validation must include robustness to distribution shifts and targeted perturbations.
+As a closing reflection, the approach acknowledges that simulation is not the world—so it measures the gap. By transporting formally generated cases to the track and comparing time-series behaviors, the program both validates planning/control logic and calibrates the digital twin itself, using discrepancies to guide model updates and ODD limits. That is the hallmark of modern control & planning V&V: scenario-driven, digitally twinned, formally grounded, and relentlessly comparative to reality.
+===== Case Study and Safety Argumentation =====
+On the TalTech iseAuto shuttle, the digital twin (vehicle model, sensor suite, and campus environment) is integrated with LGSVL/Autoware through a ROS bridge so that “photons-to-torque” loops are exercised under realistic scenes before any track test. Scenarios are distributed over the campus xodr network using Scenic/M-SDL; multiple events can be chained within a scenario to probe planner behaviors around parked vehicles, slow movers, or oncoming traffic. Logging is aligned to the KPIs above so outcomes are comparable across LF/HF layers and re-runnable when planner or control parameters change.
+In practice, this has yielded a concise, defensible narrative for planning & control safety: (1) what was tested (formalized scenarios across a structured parameter space); (2) how it was tested (two-layer simulation with a calibrated digital twin and, when necessary, track execution); (3) what happened (mission success, DTC minima, TTC profiles, braking/steering transients, localization drift); and (4) why it matters (evidence that tuning or algorithmic changes move the decision–execution loop toward or away from safety). The same framework has been used to analyze adversarial stresses on rule-based local planners, reinforcing that planning validation must include robustness to distribution shifts and targeted perturbations.
+As a closing reflection, the approach acknowledges that simulation is not the world—so it measures the gap. By transporting formally generated cases to the track and comparing time-series behaviors, the program both validates planning/control logic and calibrates the digital twin itself, using discrepancies to guide model updates and ODD limits. That is the hallmark of modern control & planning V&V: scenario-driven, digitally twinned, formally grounded, and relentlessly comparative to reality.