Simulator

Elcano Carla Simulation External Specification

CARLA is an open-source driving simulator. During 2019-20 students develop3e a go-between circuit board to transfer data between CARLA simulation and the sensor slots of the Elcano hardware. The CARLA software allows users to emulate trike parameters under controlled conditions within a virtual world, providing an efficient system for testing sensor behavior, design implementation, and bench-marking overall vehicle progress. The CARLA software can simulate a variety of road conditions such as traffic patterns, inclines, and weather as well as provide users control over vehicle parameters including weight, engine power, and aerodynamic properties.

An Arduino Due serves as a router to transfer data from vehicle systems to CARLA under a variety of test conditions, enabling the software to replicate responses and return sensor data to be reevaluated for accuracy. The CARLA Micro-AV Bridge includes the Router, Sensor Hub and Drive-by-wire Arduinos. It permits testing the Elcano trike software, including camera, sonar, throttle, steering and brake systems. Simulation allows users to immediately see the results of adjustments to vehicle parameters and highlight physical aspects of the trike within the virtual environment. This project enables users to efficiently implement improvements and track the immediate effects of design changes without spending the time and resources it would take to transport or operate the trike in real world test scenarios. It enables developers to improve the software without needing to invest in a vehicle.

Purpose

The following is a generalized list of the desired functionality of the simulator.

• Simulate data for all sensors associated with Elcano Trike.
• Simulate Elcano behavior to throttle, brake, and steering.
• Have low and high-level boards function normally with the simulated sensor data without knowing data is being simulated.
• Allow low and high-level board interaction to be tested.
• Allow autonomous driving to be tested.

Components

Simulation Code to be executed by a computer that has access to a Carla server, either locally, or through a network. Controls all objects in Carla simulation. Retrieves sensor data from Carla, and sends router board. Also retrieves actuation instructions from the router board and sends to Carla.

Sensor Hub [aka High Level] Processor The same code is used for the virtual or physical vehicle, sending and receiving messages over the CAN Bus. The CARLA Bridge replaces sensor data that would normally come from instruments.

Drive-by-wire [aks C2 LowLevel] Processor Current Elcano Drive-by-wirel code. Actuator data is routed to CARLA.

Router Board Code is executed on the Arduino Due that functions as the router board. Routes commands from Drive-by-wire to Carla via Python scripts. Also routes sensor data from Carla to Sensor Hub processor.

Bugs Within Simulator

• Occasionally the simulator and router board will desync and the NMEA GPS messages received by the router board will be faulty. This is usually followed by a crash of simulator.py. If not, simply press Ctrl^C and restart simulator.py.
• If simulator.py unexpectedly terminates, the created actors and sensors in Carla will not be properly destroyed. This usually does not cause problems for the simulation but proper termination in the future would be safer. For now if it is causing problems, simply restart Carla.
• Carla does not stop outputting sensor data even if asked to stop. This is a bug with Carla and not in our scope.
• Most malfunctions can be temporarily fixed by restarting the simulator.py instance.
• While we were able to implement the code for the low-level CAN interpretation of the throttle and brake commands from high-level CAN messages, coding for PWM requires additional testing.

Additional Notes

• Currently, the order that you output data from the router board to the computer running simulator.py is non-trivial. Data is interpreted based on the order which it is received.
• Carla sensor listening was flawed at the time this was made; .stop() would not stop the sensor from executing its attached function at each tick of Carla. Therefore speed was implemented without the use of sensors, and instead uses a command that accesses the speed only when needed. This is the suggested method until sensors are fixed. Certain sensors such as NMEA GPS, however, are only implementable using Carla sensors. Additional information can be found on Carla Documentation.
• In PowerShell, in CarlaUE4 path, run Carla as: ***Start-Process CarlaUE4 -ArgumentList “—quality-level=Low”*** to lower gpu load.
• Headless mode can be enabled for complete removal of graphics rendering, however, visual debugging is extremely useful.

2026 Simulator

Changes

Overview

The 2026 simulator differs significantly from the original 2019–2020 CARLA-based simulator. While the original simulator focused on integrating the CARLA driving simulator with Elcano hardware through a Router Board, the 2026 effort focuses on lightweight vehicle simulation, hardware-in-the-loop testing, and future Jetson Nano integration.

Major Changes

2019–2020 Simulator	2026 Simulator
CARLA-based simulation environment	Lightweight custom vehicle simulator
Required CARLA server and high-performance computer	Runs on standard desktop hardware
Router Board translated data between CARLA and Elcano hardware	Arduino Due directly simulates vehicle sensors and responses
High-Level navigation executed on Arduino Due Sensor Hub	Planned migration to Jetson Nano navigation computer
Focused on CARLA sensor emulation (GPS, vehicle state, etc.)	Focused on vehicle dynamics, sensor emulation, and DBW testing
Required multiple Arduino boards and CARLA infrastructure	Can operate as a standalone desktop or hardware-in-the-loop simulator
Primarily demonstrated communication between CARLA and Elcano subsystems	Primarily validates DBW behavior and prepares for Jetson Nano integration

Desktop Vehicle Simulator

A new Python-based simulator was developed using Pygame. New functionality includes:

• Real-time vehicle visualization
• Vehicle position tracking
• Heading estimation
• Steering angle simulation
• Throttle delay modeling
• Momentum and friction modeling
• Brake simulation
• CSV data logging

This simulator provides a simple environment for validating vehicle motion without requiring CARLA.

Arduino Due Hardware Simulator

A new Arduino Due simulator was developed to emulate physical vehicle sensors. Features include:

• Simulated wheel speed pulses
• Simulated steering sensor outputs
• Vehicle position estimation
• Throttle response modeling
• SD card and serial logging
• Integer-only arithmetic for compatibility with project requirements

The simulator allows the Drive-By-Wire system to operate as though it were connected to a physical trike.

Jetson Nano Integration Path

The original simulator architecture relied on the Sensor Hub Arduino for navigation functions. The 2026 architecture is designed to support:

• Jetson Nano waypoint processing
• CAN-based communication with Drive-By-Wire
• Hardware-in-the-loop testing using simulated sensor data
• Future replacement of Sensor Hub navigation functionality

This allows navigation software to be developed and tested before deployment onto physical vehicles.

Benefits

The updated simulator architecture provides:

• Reduced hardware requirements
• Faster development cycles
• Lower risk of vehicle damage
• Easier debugging and testing
• Direct support for future Jetson Nano development
• Improved support for CAN-based hardware-in-the-loop testing

Purpose

The 2026 simulator effort consists of two complementary systems: a desktop vehicle simulator and an Arduino Due hardware simulator. Together, these systems provide a safe and repeatable environment for developing, testing, and validating Elcano software without requiring a physical trike.

Desktop Vehicle Simulator

The desktop simulator provides a graphical representation of vehicle behavior using a simplified vehicle dynamics model. Its primary purpose is to:

• Visualize vehicle motion in real time.
• Demonstrate the effects of throttle, steering, and braking inputs.
• Validate vehicle motion algorithms before deployment to hardware.
• Generate logged data for analysis and debugging.
• Provide a lightweight alternative to CARLA for rapid software testing.

By simulating vehicle position, heading, speed, and steering behavior, developers can quickly evaluate software changes without requiring specialized hardware.

Arduino Due Hardware Simulator

The Arduino Due simulator functions as a hardware-in-the-loop testing platform. Rather than visualizing the vehicle, it emulates the sensors and feedback signals that would normally be produced by a physical trike.

Its primary purpose is to:

• Simulate wheel speed sensor outputs.
• Simulate steering sensor readings.
• Generate vehicle position and heading estimates.
• Allow Drive-By-Wire (DBW) software to operate as if connected to a real vehicle.
• Support CAN communication testing between vehicle subsystems.
• Enable bench testing without risk of damage to physical hardware.

This allows developers to observe how the Drive-By-Wire system responds to simulated vehicle behavior before testing on a physical platform.

Combined Purpose

Together, the desktop simulator and Arduino Due simulator reduce development risk, accelerate testing, and provide a foundation for future Jetson Nano integration. The simulator architecture enables software validation, CAN communication testing, and hardware-in-the-loop experimentation while minimizing the need for physical vehicle operation.

Architecture

The 2026 simulator architecture consists of two independent but complementary systems: a desktop vehicle simulator and an Arduino Due hardware simulator.

Desktop Vehicle Simulator

The desktop simulator is implemented in Python and uses the Pygame library for graphics and user interaction.

The simulator contains:

• A vehicle dynamics model that estimates position, heading, speed, and steering behavior.
• A graphical user interface that visualizes vehicle movement in real time.
• Keyboard-based control inputs for throttle, steering, and braking.
• CSV logging for recording vehicle state information during testing.

Vehicle state is updated at fixed intervals and displayed graphically, allowing developers to observe the effects of control inputs and verify simulator behavior.

Arduino Due Hardware Simulator

The hardware simulator is designed as a hardware-in-the-loop testing platform. It consists of a central CAN bus network connecting one or more Arduino Due boards that emulate vehicle subsystems.

Typical configuration:

• Central CAN bus communication network.
• One to three Arduino Due boards depending on testing requirements.
• Simulated sensor outputs including wheel speed and steering position.
• Drive-By-Wire (DBW) interface connections.
• Data logging through Serial or SD card storage.

The Arduino Due simulator generates the same types of signals that would normally be produced by a physical vehicle, allowing other Elcano subsystems to operate without modification.

System Integration

The simulator architecture is designed to support future Jetson Nano integration.

The intended communication path is:

Jetson Nano → CAN Bus → Drive-By-Wire (DBW) → Simulated Vehicle

In this configuration:

• The Jetson Nano performs navigation and waypoint processing.
• CAN Bus provides communication between subsystems.
• Drive-By-Wire interprets vehicle control commands.
• The simulator emulates vehicle sensors and responses.

This architecture allows software developed for the simulator to be transferred to the physical trike with minimal changes.