A Modular Platooning and Vehicle Coordination Simulator for Research and Education

A Modular Platooning and V ehicle Coordination Simulator f or Resear ch and Education K evin Jamsahar , Adrian W iltz, Maria Charitidou and Dimos V . Dimarogonas Abstract — This work pr esents a modular , Python-based sim- ulator that simplifies the evaluation of novel v ehicle con- trol and coordination algorithms in complex traffic scenarios while keeping the implementation overhead lo w . It allows resear chers to focus primarily on developing the control and coordination strategies themselves, while the simulator manages the setup of complex road networks, v ehicle configuration, execution of the simulation and the generation of video vi- sualizations of the results. It is thereby also well-suited to support control education by allowing instructors to create interactive exercises providing students with direct visual feedback. Thanks to its modular architecture, the simulator remains easily customizable and extensible, lo wering the barrier for conducting adv anced simulation studies in vehicle and traffic control r esearch. GitHub: https://github.com/ KTH- DHSG/Platooning_Simulator , Y outube: https:// www.youtube.com/watch?v=7Ef_6DNhcoE I . I N T RO D U C T I O N Recent advances in intelligent transport systems have led to the dev elopment of new mobility paradigms that aim to transform transportation at both indi vidual and so- cietal le vels. One such paradigm is v ehicle platooning. Platooning enables vehicles to trav el in close proximity , potentially reducing fuel consumption, CO 2 emissions, and trav el time, while increasing traffic throughput and passenger comfort [1]. Despite these advantages, deploying large fleets of vehicles in real traf fic en vironments remains challenging due to the highly dynamic nature of the environment and the complex interactions among multiple agents. This highlights the need for extensi ve simulation and testing frameworks that expose vehicles to di verse traffic scenarios and enable systematic ev aluation of their robustness, efficienc y , and safety under disturbances. In the conte xt of control, sev eral simulation en viron- ments ha ve been designed over the years of fering po wer- ful simulation and visualization capabilities for intelligent transportation applications. Among the most widely used ones is CARLA [2], an open source simulator for high- fidelity 3D simulation of autonomous driving applications. CARLA provides a variety of vehicles, actors and environ- ments for extensiv e testing of various driving tasks using a This work was supported by the ERC Consolidator Grant LEAFHOUND, the Swedish Research Council, and the Knut and Alice W allenberg Foun- dation. K. Jamsahar, A. W iltz and D. V . Dimarogonas (corresponding author) are with the Division of Decision and Control Systems, KTH Royal Institute of T echnology , SE-100 44 Stockholm, Sweden {kevinja,wiltz,dimos}@kth.se . Maria Charitidou is with the Institute for Systems Research, University of Maryland, College Park, 20742 MD, USA mchar@umd.edu . Corresponding author: Dimos V . Dimarogonas. rich sensor suite that includes v arious sensing models for cameras, LiD AR and radars. Although CARLA allows for highly realistic simulations, it does not allo w for the testing of distributed control methods limiting its applicability for platoon coordination. SUMO [3] on the other hand allows for simulation of lar ge-scale networks of vehicles providing a realistic testbed for message passing and traffic realization allowing to consider traffic lights and various types of road en vironments. Nev ertheless, its architecture does not allow to consider desired dynamic models and control methods prohibiting its immediate use for control and planning. Com- monRoad [4] allows the user to interactively choose among existing vehicle dynamic models, various types of obstacles and initial conditions. It offers a large set of predefined road scenarios but also giv es users the opportunity to design their own road network. Nevertheless, it does not support a plug-and-play integration of various controllers or vehicle dynamics limiting its flexibility and modularity . Motiv ated by multi-vehicle coordination problems [5] and multi-platoon coordination challenges [6], which require the simulation of complex nonlinear dynamics and the integra- tion of advanced control methodologies, this work presents an open-source Python-based simulator . The framew ork en- ables engineers and practitioners to easily implement and ev aluate a wide range of dynamic vehicle models and control strategies on arbitrary road networks with low implemen- tation ov erhead. More specifically , the simulator supports the definition of various road segments, including straight, curved, and intersection segments, which can be composed into complete road networks. It further allo ws users to integrate custom vehicle dynamics and control algorithms. A dedicated visualization module enables rendering of sim- ulation results as videos. The proposed architecture is built on modular , interchangeable components, enabling plug-and- play integration of different system elements without requir- ing additional modifications. As such, it provides a flexible framew ork for testing and benchmarking complex control and planning algorithms against state-of-the-art approaches. In the context of control engineering education, the simulator enables instructors to create traf fic en vironments in which students can implement and test their o wn control algorithms, while receiving immediate visual feedback. Fig. 1: Recap – Associations in UML Fig. 2: Class diagram of the simulator’ s core components. I I . I N S I D E T H E S I M U L A T O R - T H E M O D U L A R S T RU C T U R E In this section, we present our Python-based simulator and its features. T o formally illustrate its modular structure, we employ the Unified Modeling Language [7], [8] as an established formalism. An overvie w of the most important associations in UML is provided in Fig. 1. A. Overview of System Modules The SimulationProject class is the entry point for running simulations. It instantiates the TrafficEnviron - ment and manages the simulation loop by incrementing the simulation time, updating vehicles and roads at each time step, logging data for later analysis and recording a video through the Visualization class. The actual simulation of the vehicles in the road network is carried out by the TrafficEnvironment , which acts as the central integration layer for two of the most important managing classes: the RoadSegmentManager , which allows for the construction of the road network by composing it out of standardized road segments and managing it during sim- ulation, and the VehicleManager for configuring and simulating the individual vehicles. The interdependencies of the classes are shown in Fig. 2. Both manager classes bundle functionality provided through supporting modules presented next. B. Road Segment Manager The RoadSegmentManager provides road segments for straight roads, curves and intersections as sho wn in Fig. 3, which can be assembled blockwise to a road network using functions create_road_segment() and connect_road_segments() . While running the simulation, the manager supplies the vehicles in the VehicleManager with information about the road net- work, allowing to imitate the perception of the road through their sensors. Moreover , the vehicles and their control algo- rithms can query , if required, the RoadSegmentManager to determine speed limits, lane boundaries and lane width, or access the center of the current lane in form of a trajectory . The RoadSegmentManager is complemented Fig. 3: (a) Straight, (b) curved, and (c) intersection segment with respectiv e connection points (red dots). Lanes are num- bered as indicated, and the blue lines mark the lane centers. Fig. 4: Class diagram illustrating the relationship between the abstract RoadSegment superclass and its subclasses. by a VirtualParkingLot receiving those vehicles that leav e the road network at open ends and feeding them back into the simulation according to certain patterns as detailed further below . Another function allows for the automatic generation of road segments connecting two user specified open ends in the road network, thereby simplifying its setup. In the following, we elaborate on each of these features. 1) Road Segments: The various road se gments are represented by the classes StraightRoad , CurvedRoad and IntersectionRoad , each implementing the RoadSegment interface allo wing for a unified handling through the RoadSegmentManager , see Fig. 4. While the overall road network is represented in the global world coordinate frame W , each of the road segments possesses at least one local coordinate frame as shown in Fig. 3. The straight and the curved road segments possess one local coordinate system each, whereas the intersection segment is composed out of four straight subsegments and the intersection itself, moti vating the definition of more than one local coordinate system. Each road segment is defined by a segment_id , its length and orientation , the number of lanes , the lane_width and the placement of its local_origin in global coordinates. By con vention, the lanes are numbered starting from 1 and increase as indicated in Fig. 3. The center of each lane, indicated by the blue lines, is defined as a trajectory and can be queried by the vehicles as reference trajectory (see below). In order to construct a road network from the separate road segments, the segments must be connected via their ConnectionPoint s, illustrated by the red dots in Fig. 3. T wo road segments can be connected to each other if they are compatible, meaning that their number of lanes and lane_width coincide. In that case, any road segment can be connected at a user-specified ConnectionPoint to one of the Fig. 5: Class diagram RoadSegmentManager . Fig. 6: Automatic generation of road segments to comple- ment the road network by using create_connection() . ConnectionPoint s of another compatible road segment through the function connect_road_segments() . The alignment of the two segments is automatically handled by updating the local_origin and orientation of the segment to be connected. T o preserve consistency and av oid ambiguity , any ConnectionPoint can be connected to at most one other ConnectionPoint , which is internally checked upon connection. The functions for instantiating and connecting road segments are implemented in the classes RoadSegmentFactory and SegmentConnectionManager , see Fig. 5. 2) Automatic Road Gener ation: T o facilitate the cre- ation of road networks, the simulator provides an op- tion to automatically generate road segments that connect two open ends in the existing road netw ork with each other , see Fig. 6. T o this end, the user selects two road segments, specifies an unconnected ConnectionPoint on each, and applies the create_connection() method of the RoadSegmentManager ; if any of the ConnectionPoint s is already connected, an error is raised. The automatic road generation is based on Du- bin’ s path [9] and generates a curve-straight-curve (CSC) sequence of road se gments connecting the two selected ConnectionPoint s. In degenerate cases, where one or more of the road segments in the sequence would take a vanishing size, not all of these road segments are practically instantiated. For a more detailed discussion of the connection algorithm, we refer to [10]. 3) V irtual P arking Lot and Re-entry P oints: For han- dling all vehicles that leave the road network through one of its open ends, the simulator provides the pos- sibility to add a VirtualParkingLot using the method create_virtual_parking_lot() of the RoadSegmentManager . The parking lot does not act as a road segment itself, but is a purely virtual con- struct that collects the vehicles leaving the road network, collecting them into platoons of a fixed, user-specified length ( platoon_size ), and releases them once com- plete with a normally distributed departure time and gi ven Fig. 7: Illustration of the virtual parking lot handling vehicles that leav e the road network through its open ends. Fig. 8: Road network and its graph representation. mean ( time_mean ) and variance ( time_variance ) to the network. The platoon enters the road network through an entry point randomly chosen from a list defined as exit_points of the virtual parking lot. Each entry in exit_points is a tuple of a road se gment-id and a ConnectionPoint of the respectiv e segment. Of course, by setting the platoon_size to one, the road net- work can be also configured such that all vehicles in the VirtualParkingLot randomly re-enter the road- network individually through any of the configured re-entry points. 4) Graph-Based Road Network Repr esentation: The simulator maintains in the RoadSegmentManager a graph-based representation of the road network as a MultiDiGraph from the NetworkX library [11]. Its nodes correspond to the ConnectionPoint s of the segments, and the edges to the RoadSegment s. It forms the basis for performing v arious of the aforementioned operations on the road network. The graph representation can be plotted with visualize_road_network() facilitating the road network construction by visualizing the already created and connected road segments including their names, see Fig. 8. C. V ehicle Manager The simulator’ s vehicle system is centered around the VehicleManager , which manages the life cycle and co- ordination of all vehicles in the en vironment. It maintains a registry of all vehicles in self.vehicles , and together Fig. 9: Class diagram of the VehicleManager . Fig. 10: Class diagram of the Vehicle . The longitudinal and lateral controller can be alternati vely replaced by a single unified controller . with its associated components it is responsible for creating, placing, updating, and tracking each vehicle throughout the simulation’ s runtime. The VehicleManager holds a ref- erence to the RoadSegmentManager in its attributes, as well as to the ReferenceTrajectoryGenerator , the RoutePlanner , and the TrajectoryPreprocessor , see Fig. 9. 1) V ehicles: During the initialization of the VehicleManager , v ehicles are created as instances of the class Vehicle by calling the method create_vehicle() in the manager class. A vehicle is defined in terms of its dynamics, a controller (implemented either as a CombinedController or split up into a LongitudinalController and a LateralController ), a Perception module and a reference Trajectory . The class diagram of the Vehicle class is giv en in Fig. 10. During simulation, the VehicleManager continuously determines if the vehicle is moving within the lane boundaries or is about to leave them, and sets the vehicle.status correspondingly as "active" or "crashed" ; the status is visualized in the simulation video as shown in Fig. 11. V ehicles that transition to the VirtualParkingLot are assigned the status "parked" . 2) V ehicle Dynamics: The dynamics of a vehicle need to be defined in classes that implement the VehicleState interface and the VehicleDynamicsInterface . In this way , any dynamics can be considered that take the form 9 x “ f p x, u, t q , x p 0 q “ x 0 , Fig. 11: V isualization of vehicle.status in the simula- tion video: (a) "active" , (b) "crashed" . where x P R denotes the vehicle state, u P R m the control input, t P R ě 0 the simulation time, and x 0 the vehicle’ s state upon initialization. The simula- tor exemplarily defines the kinematic bicycle model [12] in the class BicycleDynamics . Upon simulation, the VehicleSimulator simulates each vehicle o ver one time step ∆ t by calling Vehicle.update() , solving the dy- namics with odeint() . 3) P er ception and Sensors: The Sensor of a vehicle abstracts the on-board sensing and determines the relativ e position, relative velocity , distance and lane association of neighboring vehicles within a configurable field-of-view and range. The Perception module organizes the sensor out- put into a PerceptionData class, transformed into the vehicle’ s body frame, which is then av ailable to the con- troller . An optional noise can be added to the measurements. 4) Reference T rajectory: The simulator provides the pos- sibility to generate a reference trajectory based on high- lev el route instructions giv en by a fictitious driv er or a route planner . Such high-level route instructions are for- mulated as a list of primitives "straight" for follow- ing the current lane, "left_turn" and "right_turn" for turning to the left or the right at intersections, as well as "left" and "right" for moving to the lane to the left or right of the current lane in driving di- rection. The reference trajectories are based on the lane centers (marked blue in Fig. 12) and possibly span mul- tiple road segments. They can be accessed through the attribute current_trajectory of an instance of the class Trajectory . The TrajectoryPreprocessor allows to shorten the reference trajectory such that it only contains points lying ahead of the vehicle by call- ing preprocess() . The route instruction primitives are ev aluated segment-wise (one primitive is ex ecuted per road segment). Route instructions can be updated via the RoutePlanner . The reference trajectory simplifies the integration of high-level route instructions into the controller implementation and renders the vehicle coordination simu- lation more realistic. W e point out that upon lane change (primitiv e "left" or "right" ) the reference trajectory is discontinuous and the actual lane change is executed by the low-le vel controllers following the route instructions while accounting for inter -vehicle coordination. Reference trajectories are given in global coordinates. It is visualized in the simulation video by a red line, see Fig. 12. Fig. 12: V isualization of lane center and reference trajectory in the simulation video. Fig. 13: Closed-loop control system. 5) Contr oller: The controller of the v ehicles is implemented either as CombinedController computing all control inputs together , or by splitting the controller into a LateralController and a LongitudinalController computing steering angle and velocity/acceleration separately , see Fig. 12. The controllers can access PerceptionData and the reference trajectory for the control input computation. Exemplary control objectiv es can be lane tracking, adaptiv e cruise control (ACC), platoon merging and splitting, and inter-v ehicle coordination upon lane change, b ut also advanced control objectiv es such as vehicle coordination at intersections, traffic-flow enhancement, leader -follower cooperation, and many more. 6) Simulation: At each simulation step, ev ery vehicle ex- ecutes the following update steps: first, the route instructions are updated and the reference trajectory generated; secondly , PerceptionData is updated; thirdly , the control inputs are computed by ev aluating the controller; at last, the vehicle state is updated by integrating the vehicle dynamics over one time step ∆ t . D. V isualization The simulation results can be visualized as a video using the Visualization class. T o enable this feature, it is sufficient to set SAVE_VIDEO = True in the config.py file; all other steps are handled internally by the simulator . The centering of the road network in the video is adjusted automatically . The Visualization class is implemented using the Pygame package. An example of the resulting visualization can be found on Y outube (see link in abstract). I I I . U S I N G T H E S I M U L A T O R - A P R A C T I T I O N E R G U I D E T o facilitate the setup of new simulation studies, the simulator comes along with a folder structure that can be taken as a starting point for the implementation. W e suggest to proceed as follows. A. Entry point for running simulations Once the simulation study has been set up, it can be ex ecuted via main.py , which calls the modules used to configure the simulation scenario described in the following sections. B. Setup of the Road Network Navigate to toolbox/initialization/road_ setup.py and define the necessary road segments using the create_road_segment() method from TrafficEnvironment . For example, e n v i r o n m e n t . c r e a t e _ r o a d _ s e g m e n t ( s e g m e n t _ t y p e = 1 , l e n g t h = 1 0 0 . 0 , o r i e n t a t i o n = 0 . 0 , l a n e _ w i d t h = 5 0 , l a n e s = 2 , s p e e d _ l i m i t = 5 0 ) Here, segment_type = 1 represents a straight road, while 2 and 3 correspond to a curved road and an intersection, respectiv ely . The exact arguments for create_road_segment() may vary slightly depending on the selected segment_type . For assembling the created road segments to a road network, navigate to connection_setup.py . Use the connect_road_segments() method to link the segments together . For example, to connect the "start" of segment 2 to the "end" of segment 1, call e n v i r o n m e n t . c o n n e c t _ r o a d _ s e g m e n t s ( f i x e d _ s e g m e n t _ i n d e x = 1 , c o n n e c t i o n _ p o i n t _ 1 = " e n d " , m o v i n g _ s e g m e n t _ i n d e x = 2 , c o n n e c t i o n _ p o i n t _ 2 = " s t a r t " ) The segment designated as the moving segment is thereby automatically aligned with the fixed segment by adjust- ing its position and orientation accordingly . T o connect open ends in the resulting road network, navigate to open_end_automatic_connection.py and call e n v i r o n m e n t . a u t o m a t i c a l l y _ g e n e r a t e _ r o a d _ t o _ c o n n e c t _ o p e n _ e n d _ s e g m e n t s ( . . . ) Finally , configure the virtual parking lot in virtual_ parking_lot_setup.py , for example, as follows: e n v i r o n m e n t . c r e a t e _ v i r t u a l _ p a r k i n g _ l o t ( p l a t o o n _ s i z e = 2 , e x i t _ p o i n t s = [ { ’ s e g m e n t _ i d ’ : " 2 _ s t a r t " , ’ c o n n e c t i o n _ p o i n t ’ : ’ s t a r t ’ } , ] , t i m e _ s e q u e n c e _ i n t e r v a l = 4 , t i m e _ m e a n = 5 , t i m e _ v a r i a n c e = 0 ) This configuration defines the platoon size of vehicles re- entering the road network, the re-entry locations specified in exit_points , the time interv al between consecutiv e vehicle releases within a platoon, and the mean and variance gov erning the delay before a completed platoon is reintro- duced into the network. C. V ehicle Cr eation and Controller Implementation Begin by implementing the controller either as a unified controller using the CombinedController Fig. 14: Getting started – two distinct ex emplary simulation studies are provided along with the simulator framew ork. interface, or as separate lateral and longitudinal components using the LateralController and LongitudinalController interfaces, respecti vely . These can be defined in toolbox/vehicles/ controllers.py , which also contains example implementations based on the bicycle kinematic model. Similarly , vehicle dynamics can be implemented in dynamics.py by defining a class that implements the VehicleDynamicsInterface . A kinematic bicycle model is provided as a reference implementation. Based on these components, indi vidual vehicles are defined in toolbox/initialization/vehicle_creation.py via the following method d e f c r e a t e _ v e h i c l e ( s e l f , v e h i c l e _ i d : i n t , d y n a m i c _ m o d e l : V e h i c l e D y n a m i c s I n t e r f a c e , c o n t r o l l e r : C o m b i n e d C o n t r o l l e r = N o ne , l a t e r a l _ c o n t r o l l e r : L a t e r a l C o n t r o l l e r = N o n e , l o n g i t u d i n a l _ c o n t r o l l e r : L o n g i t u d i n a l C o n t r o l l e r = N o n e ) V ehicles can be placed in vehicle_placement.py by calling the method add_vehicle_to_segment() . D. General Configurations For general simulation settings, navig ate to toolbox/ config/config.py . Here, global configuration variables can be adjusted to define the simulation TIME_STEP and the SIMULATION_DURATION , as well as to enable the generation of simulation videos. In vehicle_data_logging.py , it can be configured which data is logged during the simulation for later analysis. For example the vehicle positions, velocities or control inputs can be logged over specified time intervals and sampling rates. I V . G E T T I N G S TA RT E D - E X E M P L A RY S I M U L A T I O N S T U D I E S The simulator framework comes along with two simu- lation studies on different road networks with increasing complexity , which can be used as a starting point for implementing ne w simulation scenarios. The implemented controllers account for lane tracking, adaptiv e cruise control, lane changing as well as the merging and splitting of platoons. Screenshots from the simulation are presented in Fig. 14 showing the two different considered road networks. By running main.py in the initial configuration starts the simulation of the second simulation scenario. The saved simulation results, including videos, can be found in the folder simulation_projects . V . D I S C U S S I O N & C O N C L U S I O N The presented simulator is designed to support research and education on platooning, vehicle coordination, and (dis- tributed) control. By providing a unified simulation frame- work, it lowers the implementation ov erhead for nov el con- trol and coordination algorithms in complex traffic scenarios and to visualize the simulation results. Owing to its modular python implementation, it is both straightforward to use and highly customizable, allowing for various extensions. In particular , the framework can be expanded to incorporate explicit inter-vehicle communication, integration with IoT infrastructure, and human interaction, thereby enabling inter- activ e studies in mixed traffic environments inv olving both autonomous and human-operated vehicles. At an educational lev el, students can implement their own control algorithms and directly receive visual feedback by running their solution in a traffic environment pre-configured by the instructor . R E F E R E N C E S [1] T . C. Botelho, S. P . Duarte, M. C. Ferreira, S. Ferreira, and A. Lobo, “Simulator and on-road testing of truck platooning: a systematic revie w , ” Eur opean T ransport Research Review , vol. 17, no. 1, p. 4, 2025. [2] A. Dosovitskiy , G. Ros, F . Code villa, A. Lopez, and V . Koltun, “CARLA: An open urban driving simulator , ” in Pr oceedings of the 1st Annual Confer ence on Robot Learning , 2017, pp. 1–16. [3] P . A. Lopez, M. Behrisch, L. Bieker-W alz, J. Erdmann, Y .-P . Flötteröd, R. Hilbrich, L. Lücken, J. Rummel, P . W agner, and E. Wiessner , “Mi- croscopic traffic simulation using sumo, ” in 2018 21st International Confer ence on Intelligent T ransportation Systems (ITSC) , 2018, pp. 2575–2582. [4] M. Althoff, M. Koschi, and S. Manzinger, “Commonroad: Composable benchmarks for motion planning on roads, ” in 2017 IEEE Intelligent V ehicles Symposium (IV) , 2017, pp. 719–726. [5] A. Frauenfelder , A. Wiltz, and D. V . Dimarogonas, “Decentralized vehicle coordination and lane switching without switching of con- trollers, ” IF AC-P apersOnLine , vol. 56, no. 2, pp. 3334–3339, 2023. [6] M. Charitidou and D. V . Dimarogonas, “Splitting and merging control of multiple platoons with signal temporal logic, ” in 2022 IEEE Confer ence on Contr ol T echnology and Applications (CCT A) , 2022, pp. 1031–1036. [7] Object Management Group, OMG Unified Modeling Language , 2017. [Online]. A vailable: https://www .omg.org/spec/UML/2.5.1/PDF [8] M. Fo wler, UML distilled : a brief guide to the standard object modeling language , 3rd ed., ser . Addison-W esley object technology series. Boston, Mass: Addison-W esley , 2004. [9] L. E. Dubins, “On curves of minimal length with a constraint on av erage curvature, and with prescribed initial and terminal positions and tangents, ” American Journal of Mathematics , vol. 79, no. 3, pp. 497–516, 1957. [10] K. Jamsahar, “Design of a modular platooning and traffic coordination simulator , ” Master’ s thesis, KTH Royal Institute of T echnology , 2025, supervised by Adrian Wiltz and Maria Charitidou. [11] A. Hagberg, P . J. Swart, and D. A. Schult, “Exploring network structure, dynamics, and function using networkx. ” Los Alamos National Laboratory (LANL), 01 2008. [12] D. W ang and F . Qi, “T rajectory planning for a four-wheel-steering vehicle, ” in Pr oceedings 2001 ICRA. IEEE International Conference on Robotics and Automation , vol. 4, 2001, pp. 3320–3325.