aUToronto Simulation Suite: V2X Messaging and Emergency Vehicle Yielding
Today we are joined by guest bloggers Yijie Wang and Sarah Xu from the University of Toronto’s SAE AutoDrive team.
aUToronto is the University of Toronto’s self-driving car team, bringing home multiple awards in the AutoDrive Challenge II, including first place in the Year 4 Competition’s MathWorks Simulation Challenge. This blog post aims to showcase how aUToronto’s Simulation team creatively applies MathWorks tools to simulate V2X messaging and uses the modeled message to test behavior when yielding to an emergency vehicle. Integral to the team’s success is the versatility of MathWorks tools, connecting message emulation to vehicle dynamics simulations. We’ll describe the motivation behind the team’s work, our methodology, and results. Happy reading!
Motivation
Simulation is crucial to development because it provides a safe, cost-effective, and scalable way to test complex traffic scenarios that may be challenging to replicate in the real world. The Simulation team at aUToronto builds a comprehensive set of tools to support developers in rapidly prototyping and validating algorithms, prioritizing safety as we strive towards a real-world Level 4 autonomous vehicle.
This work on V2X messaging and emergency vehicle yielding was undertaken as part of the MathWorks Simulation Challenge. While the challenge provided the initial framework, our goal extended beyond simply completing it. We aimed to develop solutions with relevance to real-world autonomous driving and Level 4 autonomy, where safely detecting and yielding to emergency vehicles is critical. A modern solution is to rely on V2X (Vehicle-to-Everything) communication, which allows vehicles to exchange information wirelessly with other vehicles and infrastructure. We saw it as an opportunity to enhance our simulation toolbox and support emergency vehicle behaviour testing in a virtual environment.
To achieve this, we not only focused on emulating V2X messages to test our planning algorithm, but also challenged ourselves to follow a model-based design approach, aligning with MathWorks’ emphasis on industry best practices. With MathWorks simulation toolboxes, we can model network communications, prototype V2X algorithms, and evaluate planning performance across different scenarios.
Methodology
Simulation Pipeline
Following a model-based design approach allowed us to structure the system, simulate behaviour, and validate planning output responses in a systematic and repeatable way. The emergency vehicle testing framework is structured around modular components that represent the key elements of in-vehicle communication. An overview of the system is shown in *Figure 1* below:
Figure 1. Overall system architecture
We started by designing RoadRunner scenarios that simulated an ego vehicle and an emergency vehicle. Using scenario construction and modification tools, the team modified parameters and simulated various scenarios to ensure comprehensive testing. Examples of scenarios are included in *Figure 2*.
Figure 2. Scenarios modelled, including speed and scenario variations
Then, we modelled a V2X message emulator in Simulink, as shown in *Figure 3*. As per the SAE J2735 standard, vehicle position and velocity information were used to populate an Emergency Vehicle Alert (EVA) message. We ensured our simulation ran production-level software by packaging the messages as Ethernet frames and injecting them into our system. By using the Simulink Real-Time / IP toolbox, we were able to send data at different layers of the network protocol, such as raw Ethernet and User Datagram Protocol (UDP).
Figure 3. EVA message simulation
Through the use of a Terminal Access Point (TAP) interface, we mimicked the behaviour of an on-board unit (OBU) in the vehicle. The next step of the pipeline was to communicate with dynamic components of our team’s software stack, which includes the UDP monitor node, V2X decoder, and the planner. These components are tested within our simulation system to ensure fidelity before they are implemented on our actual vehicle, the GM Chevrolet Bolt EUV.
To close the simulation loop, we connected the V2X pipeline with aUToBridge, our customized vehicle dynamics model that includes a framework inspired by the MathWorks Trajectory Follower example. aUToBridge facilitates communication between the team’s planning/control algorithms and RoadRunner, updating various vehicle parameters such as position and velocity in simulation.
Fault Injection and Failure Modeling
To further bridge the gap with real-world behaviour, we modelled V2X communication failures. Specifically, we emulated packet loss and out-of-order packets, which was done easily thanks to Simulink’s SimEvents toolbox. The various tools provided allowed us to visualize messages, events, and entities, giving us finer control over fault injection. From *Figure 4*, we were able to plot the number of lost packets during the simulation; the periods of plateau indicate no packet losses occurring. From *Figure 5*, we can visualize the order of packets sent, thus confirming that out-of-order packets were simulated correctly. The packets were transmitted through a first-in-first-out (FIFO) queue in Simulink. In the Sequence Viewer, we can observe that packet number 3 was briefly delayed before passing through the FIFO queue, as highlighted by the yellow arrows. Meanwhile, the subsequent packets were published normally, simulating the out-of-order packet delivery.
Figure 4. Packet loss modeling and visualization
Figure 5. Out-of-order packet modeling and Sequence Viewer visualization
Sim-to-Real Evaluation
Our team was also interested in evaluating the sim-to-real gap to understand the reliability of our simulation-based assessments. To achieve this, we collected real-world data from our vehicle as it drove along the same route modeled in simulation (*Figure 6*). This data was then used to represent the emergency vehicle information, which was injected back into the simulation in place of a simulated emergency vehicle, to observe the planner’s behavior and assess the sim-to-real gap. Comparison results are shown below in the results and validation section.
Figure 6. The same route was used in simulation and real life
Validation and Results
Planner Improvements
Owing to our simulation system, we were able to improve the planner through multiple iterations. Our updated planner demonstrated noticeable improvements in yielding to emergency vehicles, leading to a smoother and safer maneuver (*Figure 7*).
Figure 7. Four iterations of planner improvements
Simulation plays a crucial role in validation of systems through its repeatability and its ability to cover wide breadth of scenarios. We used this to our advantage to validate the performance of our planner by evaluating against a set of predefined metrics in our designed scenarios (*Figure 8*). These metrics included the minimum distance maintained between the emergency vehicle (EV) and the ego vehicle during yielding, the overall time required to complete the maneuver, and the duration of idle time introduced. Together, these measures allowed us to quantify both the safety and efficiency of the planner’s behavior. The following results present the measurements from the final version of the planner. Out of 20 trials, only one failed the maneuver, corresponding to a 95% success rate. The relative distance to the emergency vehicle was safe at 28 m, the stopping time was about 40s, and the idle time was about 15s. Our simulation pipeline provided insights into the reliability of our system.
Figure 8: Collected measurements of the planner
Fault Injection Results
We also stress-tested the planner under V2X communication failure scenarios and visualized the resulting behavior, as shown in *Figure 9* below.
Figure 9. Visualization of behaviour under communication failures
By applying the same planner metrics, we were able to quantify its performance under challenging conditions, as seen in *Figure 10*. The numbers were averaged across multiple trials. The results showed that communication disruptions such as packet loss and out-of-order packets had only a marginal effect on our system’s overall performance. The yielding distance to the emergency vehicle remained consistent across all cases, varying by less than 2m. Maneuver times were also stable with only minor fluctuations, and idle time stayed close to 10s in all scenarios. This suggested that our dynamic components and current strategies to handle failure situations were sufficiently robust to tolerate minor communication failures without compromising to safety or efficiency.
Figure 10. Comparison of planner metrics under normal conditions and communication failure scenarios
Sim-to-Real Results
Finally, to complete our discussion on simulation results, we also visualized our vehicle’s behaviour in simulation and real life. Through *Figure 11*, it is clearly observed that the emergency vehicle motion was more uneven and jerky using real-world data as compared to simulated data.
Figure 11. Vehicle behaviour with real-world versus simulated data
Using the metrics, we can see that the distance to EV and idle time of the ego vehicle were about the same using simulated data and real-world data playback (*Figure 12*). The main discrepancy was maneuver time, with execution against real-world data playback being slower. This highlights areas where the simulation might have simplified the vehicle dynamics of the EV and suggests areas of further improvement.
Figure 12. Comparison of planner metrics with real-world and simulated data
Conclusion
We hope that you, as the reader, learned as much as we did about MathWorks tools, V2X messaging and failures, and simulation integration. Through this challenge, we developed skills in designing meaningful scenarios, emphasizing breadth and variety to stress test our system.
Our team spent countless hours researching and understanding the SAE standards, the workings of Ethernet protocols, and the TAP interface, to ensure simulated behaviour was realistic and generated value and understanding. Putting our creativity to the test, we considered potential failures in a V2X communication network that could compromise the safety of all road users. We then assessed the viability of our algorithms in such situations. In tandem, we applied engineering design principles to define metrics for results validation. It was also crucial for our team to learn how to bridge the gaps between different systems, from the Roadrunner interface to our planning and controls algorithm, and to our vehicle simulator in Simulink. On the same note, we really enjoyed learning about Simulink’s Ethernet blocks and exploring their capabilities. In fact, as we wrapped up our work on this challenge, we realized how valuable extended support for Ethernet protocols in Simulink would be. We’d love to see more examples of it!
We are eager to incorporate our work into the Year 5 challenge, not only our Ethernet simulations, but also the knowledge gained about the engineering design process, failure modalities, and scenario design. Finally, the entire Simulation team would like to thank our fantastic MathWorks mentors, Seo-Wook and Akshra, whose invaluable guidance and insights were crucial to our success.
- Category:
- Automotive,
- Simulink
Comments
To leave a comment, please click here to sign in to your MathWorks Account or create a new one.