Elcano Project Wiki - User contributions [en]

Main Page

2026-06-27T22:31:40Z

ShivBhatt: /* Welcome to the Elcano Project Wiki */

= Welcome to the Elcano Project Wiki =
As the title says, WELCOME TO THE ELCANO PROJECT! Over the past few years, many different teams have been working hard to create Cheap and Modular autonomy at the University of Washington Bothell. We have developed two prototype recumbent tricycles and also worked on an ELF tricycle. Using affordable microcontrollers such as the Arduino Due and Jetson Nano, CAN bus communication, and Pixhawk, we are working towards creating Autonomy for anyone to build anywhere, with electronics and software under $2000 and fully open-source. But we don't plan to stop there, no. That is just the first step toward our ultimate goal: making our systems applicable to any desired ground vehicle, such as cars. Autonomy is nothing new; in fact, it has been around for over 40 years. The difference is that now we can make it available for anyone who desires to further their knowledge or simply find a safer way to work.

Elcano Project Main Website: [//www.elcanoproject.org]

Visit our GitHub repositories: [https://github.com/elcano].

To '''edit articles''' or '''upload files''', please create an account and request editing rights from a [//www.elcanoproject.org/wiki/index.php?title=Special:ListUsers&group=bureaucrat member of the "bureaucrat" group].

For editing, help visit https://www.mediawiki.org/wiki/Help:Editing_pages or https://www.mediawiki.org/wiki/Help:Formatting.
--------
[[File:Catrikes.JPG|1000px]]
== [[ElcanoIntro | Overview]] ==
The basic concept of how the Elcano Project vehicle works.

== [[System Architecture]] ==
How processors connect to sensors, each other, actuators, and other hardware. Includes processor-to-processor communication protocol.

== [[Communication | Communication (CAN Bus)]] ==
How processors exchange data on the vehicle and a description of data packet contents.

== [[Power System]] ==
How different modules connect to the batteries or power subsystem hardware.

== [[Drive-By-Wire]] ==
How the version 5 Drive-By-Wire system (aka Low-Level) uses inputs to control actuators to steer, move, and stop the vehicle.

== [[Navigation Computer]] ==
How the system uses GNSS to formulate movement instructions sent to Drive-by-Wire.

== [[RemoteControl]] ==
A radio communication link allows human control. There are also onboard controls. The goal is to use neither and have control come from the Nav computer.

== [[ Simulator]] ==
Instead of the Drive-by-Wire board and navigation computer controlling the real trike, another Arduino routes their I/O to a virtual vehicle.

== [[SensorsPage]] ==

=== [[SteeringSensor]] ===
The front wheel angle detector. Sensors are mounted on the left steering column and/or right steering column. Sensors in use as of 2026 are analog. There are two varieties. Each is sensitive to 1/3 of a degree. The original is good for 360 degrees. Thus there are 1080 possible values. When these are spread over 3.3V, each step is 3 mV. Since the long wire from the sensor to the Arduino acts as an antenna, noise can be significant. There are two methods to reduce noise.

1) The present analog sensor is only good for 60 degrees, which is more than the +/- 25 degree maximum turn. This makes the minimum step 18 mV.

2) The ground signal on the sensor is sent back on either L_RTN (left steering column) or R_RTN (right steering column). Both the wires carrying the signal and the return wire are expected to pick up the same noise. A chip on the DBW board subtracts the two to get a value closer to the original.

Noise could be eliminated by using a digital signal. A future sensor might use SPI. Jumpers can be installed to replace the sensor signals with MOSI, SCK and CS. Another digital solution is to purchase a sensor that puts its information on the CAN bus.

=== Speedometer ===

There are two magnetic pickups on the wheel. One goes to a standard bicycle cyclometer which shows speed and distance. The other goes to DBW where the software interprets the once per revolution click. Speed resolution is limited by the wheel circumference and cannot detect very low speeds.

More accurate speed information could be obtained from the Hall sensor on the e-bike controller, but this has never been done.

=== GPS ===

The Pixhawk handles GPS. It includes inertial sensors and a Kalman filter and thus improves on raw GPS. Various sensors can be purchased. Some use Global Network Satellite Systems (GNSS) from other countries to improve on the US Global Positioning System.

== [[ActuatorPage]] ==

== [[Current Board Diagrams]] ==
Images of Elcano Project's printed circuit boards for reference. PCB source files and schematics are maintained and stored at [//github.com/elcano].

== Software development procedures ==

=== [[Software repositories]] ===
What's in each of our GitHub repositories.

Luke Kustra's repo: https://github.com/luke-kustra/JetHawk-LKustra.git

Luke's contribution was experimenting with the LiDAR sensor. He was able to get the LiDAR to deactivate and display information about its surroundings, including the number of objects and their distance from the LiDAR sensor. Of course, the sensor should never deactivate when in real use; however, this deactivation is proof that the LiDAR is ready to be utilized in a larger system such as a vehicle.

Henry Haight's repo: https://github.com/Autonomous-ATV-Capstone-Team-Sequence/-LIDAR

=== [[Arduino software]] ===
Getting started; references; development tools. Dealing with libraries and different parameters for each vehicle.

=== [[Using Git and GitHub]] ===
Practices for maintaining code and source files on Elcano Project's GitHub repositories.

= Archived material =

== [[Old Architecture]] ==

== [[ATV Power System]] ==

== [[Low Level]] ==

== [[High Level]] ==

== [[Old RemoteControl]] ==

== [[CARLA Simulator]] ==

== [[Old Sensors]] ==

== [[Old Actuators]] ==

== [[Board Diagrams]] ==

==[[FilesPage | Files]] ==
These are media files (pictures, videos, etc.) that are part of the project but are not maintained under version control.

Main Page

2026-06-27T22:30:57Z

ShivBhatt: /* Welcome to the Elcano Project Wiki */

= Welcome to the Elcano Project Wiki =
As the title says, WELCOME TO THE ELCANO PROJECT! Over the past few years, many different teams have been working hard to create Cheap and Modular autonomy at the University of Washington Bothell. We have developed two prototype recumbent tricycles and also worked on an ELF tricycle. With the use of affordable microcontrollers, such as the Arduino Due, Jetson Nano, and Pixhawk, we are working towards creating Autonomy for anyone to build anywhere, with electronics and software under $2000 and fully open-source. But we don't plan to stop there, no. That is just the first step in reaching our ultimate goal, which is making our systems applicable to any desired ground vehicles, such as cars and other vehicles. Autonomy is nothing new; in fact, it has been around for over 40 years. The difference is that now we can make it available for anyone who desires to further their knowledge or simply find a safer way to work.

Elcano Project Main Website: [//www.elcanoproject.org]

Visit our GitHub repositories: [https://github.com/elcano].

To '''edit articles''' or '''upload files''', please create an account and request editing rights from a [//www.elcanoproject.org/wiki/index.php?title=Special:ListUsers&group=bureaucrat member of the "bureaucrat" group].

For editing, help visit https://www.mediawiki.org/wiki/Help:Editing_pages or https://www.mediawiki.org/wiki/Help:Formatting.
--------
[[File:Catrikes.JPG|1000px]]
== [[ElcanoIntro | Overview]] ==
The basic concept of how the Elcano Project vehicle works.

== [[System Architecture]] ==
How processors connect to sensors, each other, actuators, and other hardware. Includes processor-to-processor communication protocol.

== [[Communication | Communication (CAN Bus)]] ==
How processors exchange data on the vehicle and a description of data packet contents.

== [[Power System]] ==
How different modules connect to the batteries or power subsystem hardware.

== [[Drive-By-Wire]] ==
How the version 5 Drive-By-Wire system (aka Low-Level) uses inputs to control actuators to steer, move, and stop the vehicle.

== [[Navigation Computer]] ==
How the system uses GNSS to formulate movement instructions sent to Drive-by-Wire.

== [[RemoteControl]] ==
A radio communication link allows human control. There are also onboard controls. The goal is to use neither and have control come from the Nav computer.

== [[ Simulator]] ==
Instead of the Drive-by-Wire board and navigation computer controlling the real trike, another Arduino routes their I/O to a virtual vehicle.

== [[SensorsPage]] ==

=== [[SteeringSensor]] ===
The front wheel angle detector. Sensors are mounted on the left steering column and/or right steering column. Sensors in use as of 2026 are analog. There are two varieties. Each is sensitive to 1/3 of a degree. The original is good for 360 degrees. Thus there are 1080 possible values. When these are spread over 3.3V, each step is 3 mV. Since the long wire from the sensor to the Arduino acts as an antenna, noise can be significant. There are two methods to reduce noise.

1) The present analog sensor is only good for 60 degrees, which is more than the +/- 25 degree maximum turn. This makes the minimum step 18 mV.

2) The ground signal on the sensor is sent back on either L_RTN (left steering column) or R_RTN (right steering column). Both the wires carrying the signal and the return wire are expected to pick up the same noise. A chip on the DBW board subtracts the two to get a value closer to the original.

Noise could be eliminated by using a digital signal. A future sensor might use SPI. Jumpers can be installed to replace the sensor signals with MOSI, SCK and CS. Another digital solution is to purchase a sensor that puts its information on the CAN bus.

=== Speedometer ===

There are two magnetic pickups on the wheel. One goes to a standard bicycle cyclometer which shows speed and distance. The other goes to DBW where the software interprets the once per revolution click. Speed resolution is limited by the wheel circumference and cannot detect very low speeds.

More accurate speed information could be obtained from the Hall sensor on the e-bike controller, but this has never been done.

=== GPS ===

The Pixhawk handles GPS. It includes inertial sensors and a Kalman filter and thus improves on raw GPS. Various sensors can be purchased. Some use Global Network Satellite Systems (GNSS) from other countries to improve on the US Global Positioning System.

== [[ActuatorPage]] ==

== [[Current Board Diagrams]] ==
Images of Elcano Project's printed circuit boards for reference. PCB source files and schematics are maintained and stored at [//github.com/elcano].

== Software development procedures ==

=== [[Software repositories]] ===
What's in each of our GitHub repositories.

Luke Kustra's repo: https://github.com/luke-kustra/JetHawk-LKustra.git

Luke's contribution was experimenting with the LiDAR sensor. He was able to get the LiDAR to deactivate and display information about its surroundings, including the number of objects and their distance from the LiDAR sensor. Of course, the sensor should never deactivate when in real use; however, this deactivation is proof that the LiDAR is ready to be utilized in a larger system such as a vehicle.

Henry Haight's repo: https://github.com/Autonomous-ATV-Capstone-Team-Sequence/-LIDAR

=== [[Arduino software]] ===
Getting started; references; development tools. Dealing with libraries and different parameters for each vehicle.

=== [[Using Git and GitHub]] ===
Practices for maintaining code and source files on Elcano Project's GitHub repositories.

= Archived material =

== [[Old Architecture]] ==

== [[ATV Power System]] ==

== [[Low Level]] ==

== [[High Level]] ==

== [[Old RemoteControl]] ==

== [[CARLA Simulator]] ==

== [[Old Sensors]] ==

== [[Old Actuators]] ==

== [[Board Diagrams]] ==

==[[FilesPage | Files]] ==
These are media files (pictures, videos, etc.) that are part of the project but are not maintained under version control.

Simulator

2026-06-06T22:22:25Z

ShivBhatt: /* Architecture */

= Elcano Carla Simulation External Specification =

[http://carla.org/ 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 [https://micro-av.com/store/ols/products/carla-bridge 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.

[[File:Architecture_CAN_Sim_7_7_20.png|1000px]]

== 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.

'''[https://micro-av.com/store/ols/products/carla-bridge 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.

[[File:RouterBoard2020A.jpg|800px|]]

[[File:RouterBoard2020B.jpg|800px|]]

== Current Functionality of Simulation ==
At the end our Autumn 2019 Capstone, we were able to deliver a demo that demonstrated communication between all components; high-level board (Arduino Due), low-level board (Arduino Mega 2560) with shield running low level code, router board (Arduino Due), and the instance of Carla. The instructions on how to reproduce the demo will be given later in this document. The primary roadblock that prevented further development into this project was the state of the CAN system of the Elcano trike (particularly the transceiver board which seems to have a flawed design). These are the current features of the simulator.
* Implementation of USB serial communication between router board and computer running simulator.py. Both entities (Computer and ArduinoDue) can send and receive data through USB connection.
* Implementation of a cyclometer. Router board can receive the current speed of the simulated vehicle in Carla and convert it into an interrupt-based cyclometer pulse, based on the wheel dimension of the Elcano. Also considers the random error of cyclometer present on the Elcano trike. This can be debugged with the built-in LED on the router board.
* Implementation of NMEA GPS sensor. Carla is able the output NMEA GPS data to the router board 10 times per second, effectively simulating the GPS sensor on the high-level board. Router board is successfully able to output it to UART serial which is how it is transmitted to the high-level board.
* Implementation of timing structure. Computer running simulator.py waits for data to be interpreted from the router board while the router board executes its update 10 times per second. This is the desired speed for both sensor data and actuation data to be updated.
* Implementation of vehicle control updaters through throttle, brake, and steering data. The computer running simulator.py can take desired throttle, brake, and steering and convert them into corresponding commands for Carla using Carla API. These commands move the vehicle within Carla. This is the primarily what the demo shows.

== Demo Guide (How to Set-Up) ==
The following is a guide to set up the Elcano simulator.

===''' Materials '''===
* 1 Assembled Elcano Simulator Printed Circuit Board (PCB)
* 2 Arduino Due
* 1 Arduino Mega 2560
* 1 Box (200 x 150 x 70 mm)
* 2 Voltage Level Converter (included w/Simulator PCB)
* 1 SD Card (w/map files)
* 1 USB AB Cable (for Arduino Mega)
* 1 USB Micro Cable (for Arduino Due)
* 1 computer capable of running Carla

===''' Pre-installation '''===
Use the following instructions to install the required software to run the simulation.

#''''' Python '''''
#* Install Python 3 (if not installed already)
#::-experiments used version 3.7.6
#* In a terminal, move to .\Simulation\
#* Run the command “pip3 install -r requirements.txt” to have pip install all the required python libraries for the simulator
#''''' CARLA '''''
#*Download [https://carla.org/2020/03/09/release-0.9.8/ CARLA (0.9.8)]
#*CARLA requirements: [[File:Carla_Requirements.jpg|500px|]]
#''''' Arduino Libraries ''''' Download these Arduino libraries prior to running the simulation:
#* [https://github.com/Seeed-Studio/CAN_BUS_Shield CAN_BUS_SHIELD by Seeed-Studio]
#* [https://github.com/br3ttb/Arduino-PID-Library PID by Brett Beauregard]
#* [https://github.com/NicoHood/PinChangeInterrupt Pin Change Interrupt by Nico Hood]
#* [https://github.com/SweBarre/MCP48x2 MCP48x2 DAC by Jonas Forsberg]
#* [https://github.com/ivanseidel/DueTimer Arduino Due Timer Interrupts by Ivan Seidel]
#* Previous version of [https://github.com/collin80/due_can Arduino Due CAN Bus library] is used but the necessary files are included within the repository.
#''''' Elcano Repositories ''''' The Elcano repositories are needed to run the simulation:
#*[https://github.com/elcano/HighLevel High Level]
#*[https://github.com/elcano/Simulator Simulator (Router Board & Simulator Script)]
#*[https://github.com/elcano/Drive-by-wire Drive-by-wire (Low Level)]
===''' Run Simulation '''===
Once all the requirements are installed, use the following instructions to run the simulation.
 [[File:Router_PCB_Connections.jpg|500px]]
 '''''Step 1: Program all Arduinos'''''
#Upload router_board_v1.ino to the router Arduino Due programming port
#Upload High_Level.ino to the high level Arduino Due programming port
#Upload Drive_By_Wire.ino to the low level Arduino Mega 2560
'''''Step 2: Run CARLA'''''
#Open a command prompt (type cmd in the windows search box)
#Go to the directory where CARLA is installed (CARLAUE4.exe)
#:<code>cd C:\Users\bobross\Documents\ElcanoInstaller\CARLA\WindowsNoEditor</code>
#::-You may have it saved to a different directory
#From the CARLA directory, type:
#:<code>CARLAUE4.exe</code>
#:Or, to run in low resolution mode:
#:<code>CARLAUE4.exe -ResX=720 -ResY=480 -quality-level=Low</code>
'''''Step 3: Run Simulation'''''
#Connect your PC to the native port on the Router Board Due
#Open a command prompt (type cmd in the windows search box)
#Go to the Simulation directory
#:<code>cd C:\Users\bobross\Documents\Simulator\Simulation</code>
#::-You may have it saved to a different directory
#From Simulation directory, start the Simulator UI
#:<code>.\Simulation\start.bat</code>
#By default, the Simulator UI will populate local running CARLA settings
#*For control via the router board, leave mode as Auto
#*To control via manual keyboard input, change mode to Manual.
#*If running a network-based CARLA server, enter IP and Port of CARLA into the respective boxes. (i.e. 192.168.1.1, 2010)
#Click "Connect to CARLA"
#*If Auto mode, it will pop up a selection of COM devices, select routerboard native port COM to begin and press go.
#*If Manual mode, client will start with keyboard controls (WASD)
#Observe behavior in simulator.
#If car gets stuck, kill current simulator.py process and restart.
===''' Debug/Logging '''===
*High Level uses the Programming Port to display debug messages over serial monitor
*Router Board uses the Programming Port to display debug messages over serial monitor

== Out of Scope Functionality Tested/Implemented ==
* Our project required us to delve into pieces of code within the Elcano project outside of our scope. Understanding of how sensors are read by the high and low-level boards is necessary for the simulation of the sensors. We were able to fix some issues regarding the CAN communication between the high and low-level boards. The modified low-level code was not pushed to the main low-level code folder in the repository on Github, however, it is included within the simulator documentation. The following were implemented.
* Unification of the proposed CAN message structure and the actual CAN message processing on the low-level code for CAN messages with ID 0x350 (High-level drive instructions). These are CAN messages the high-level will send to the low level to facilitate autonomy.
* Fixing the DAC output voltage by using the MCP48x2 library by Jonas Forsberg.
== To Do (Software): ==
'''

== 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 ===
{| class="wikitable"
! 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.

Simulator

2026-06-06T02:35:05Z

ShivBhatt: /* Purpose */

Simulator

2026-06-06T02:34:43Z

ShivBhatt: /* Purpose */

= Elcano Carla Simulation External Specification =

[http://carla.org/ 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 [https://micro-av.com/store/ols/products/carla-bridge 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.

[[File:Architecture_CAN_Sim_7_7_20.png|1000px]]

== 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.

'''[https://micro-av.com/store/ols/products/carla-bridge 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.

[[File:RouterBoard2020A.jpg|800px|]]

[[File:RouterBoard2020B.jpg|800px|]]

== Current Functionality of Simulation ==
At the end our Autumn 2019 Capstone, we were able to deliver a demo that demonstrated communication between all components; high-level board (Arduino Due), low-level board (Arduino Mega 2560) with shield running low level code, router board (Arduino Due), and the instance of Carla. The instructions on how to reproduce the demo will be given later in this document. The primary roadblock that prevented further development into this project was the state of the CAN system of the Elcano trike (particularly the transceiver board which seems to have a flawed design). These are the current features of the simulator.
* Implementation of USB serial communication between router board and computer running simulator.py. Both entities (Computer and ArduinoDue) can send and receive data through USB connection.
* Implementation of a cyclometer. Router board can receive the current speed of the simulated vehicle in Carla and convert it into an interrupt-based cyclometer pulse, based on the wheel dimension of the Elcano. Also considers the random error of cyclometer present on the Elcano trike. This can be debugged with the built-in LED on the router board.
* Implementation of NMEA GPS sensor. Carla is able the output NMEA GPS data to the router board 10 times per second, effectively simulating the GPS sensor on the high-level board. Router board is successfully able to output it to UART serial which is how it is transmitted to the high-level board.
* Implementation of timing structure. Computer running simulator.py waits for data to be interpreted from the router board while the router board executes its update 10 times per second. This is the desired speed for both sensor data and actuation data to be updated.
* Implementation of vehicle control updaters through throttle, brake, and steering data. The computer running simulator.py can take desired throttle, brake, and steering and convert them into corresponding commands for Carla using Carla API. These commands move the vehicle within Carla. This is the primarily what the demo shows.

== Demo Guide (How to Set-Up) ==
The following is a guide to set up the Elcano simulator.

===''' Materials '''===
* 1 Assembled Elcano Simulator Printed Circuit Board (PCB)
* 2 Arduino Due
* 1 Arduino Mega 2560
* 1 Box (200 x 150 x 70 mm)
* 2 Voltage Level Converter (included w/Simulator PCB)
* 1 SD Card (w/map files)
* 1 USB AB Cable (for Arduino Mega)
* 1 USB Micro Cable (for Arduino Due)
* 1 computer capable of running Carla

===''' Pre-installation '''===
Use the following instructions to install the required software to run the simulation.

#''''' Python '''''
#* Install Python 3 (if not installed already)
#::-experiments used version 3.7.6
#* In a terminal, move to .\Simulation\
#* Run the command “pip3 install -r requirements.txt” to have pip install all the required python libraries for the simulator
#''''' CARLA '''''
#*Download [https://carla.org/2020/03/09/release-0.9.8/ CARLA (0.9.8)]
#*CARLA requirements: [[File:Carla_Requirements.jpg|500px|]]
#''''' Arduino Libraries ''''' Download these Arduino libraries prior to running the simulation:
#* [https://github.com/Seeed-Studio/CAN_BUS_Shield CAN_BUS_SHIELD by Seeed-Studio]
#* [https://github.com/br3ttb/Arduino-PID-Library PID by Brett Beauregard]
#* [https://github.com/NicoHood/PinChangeInterrupt Pin Change Interrupt by Nico Hood]
#* [https://github.com/SweBarre/MCP48x2 MCP48x2 DAC by Jonas Forsberg]
#* [https://github.com/ivanseidel/DueTimer Arduino Due Timer Interrupts by Ivan Seidel]
#* Previous version of [https://github.com/collin80/due_can Arduino Due CAN Bus library] is used but the necessary files are included within the repository.
#''''' Elcano Repositories ''''' The Elcano repositories are needed to run the simulation:
#*[https://github.com/elcano/HighLevel High Level]
#*[https://github.com/elcano/Simulator Simulator (Router Board & Simulator Script)]
#*[https://github.com/elcano/Drive-by-wire Drive-by-wire (Low Level)]
===''' Run Simulation '''===
Once all the requirements are installed, use the following instructions to run the simulation.
 [[File:Router_PCB_Connections.jpg|500px]]
 '''''Step 1: Program all Arduinos'''''
#Upload router_board_v1.ino to the router Arduino Due programming port
#Upload High_Level.ino to the high level Arduino Due programming port
#Upload Drive_By_Wire.ino to the low level Arduino Mega 2560
'''''Step 2: Run CARLA'''''
#Open a command prompt (type cmd in the windows search box)
#Go to the directory where CARLA is installed (CARLAUE4.exe)
#:<code>cd C:\Users\bobross\Documents\ElcanoInstaller\CARLA\WindowsNoEditor</code>
#::-You may have it saved to a different directory
#From the CARLA directory, type:
#:<code>CARLAUE4.exe</code>
#:Or, to run in low resolution mode:
#:<code>CARLAUE4.exe -ResX=720 -ResY=480 -quality-level=Low</code>
'''''Step 3: Run Simulation'''''
#Connect your PC to the native port on the Router Board Due
#Open a command prompt (type cmd in the windows search box)
#Go to the Simulation directory
#:<code>cd C:\Users\bobross\Documents\Simulator\Simulation</code>
#::-You may have it saved to a different directory
#From Simulation directory, start the Simulator UI
#:<code>.\Simulation\start.bat</code>
#By default, the Simulator UI will populate local running CARLA settings
#*For control via the router board, leave mode as Auto
#*To control via manual keyboard input, change mode to Manual.
#*If running a network-based CARLA server, enter IP and Port of CARLA into the respective boxes. (i.e. 192.168.1.1, 2010)
#Click "Connect to CARLA"
#*If Auto mode, it will pop up a selection of COM devices, select routerboard native port COM to begin and press go.
#*If Manual mode, client will start with keyboard controls (WASD)
#Observe behavior in simulator.
#If car gets stuck, kill current simulator.py process and restart.
===''' Debug/Logging '''===
*High Level uses the Programming Port to display debug messages over serial monitor
*Router Board uses the Programming Port to display debug messages over serial monitor

== Out of Scope Functionality Tested/Implemented ==
* Our project required us to delve into pieces of code within the Elcano project outside of our scope. Understanding of how sensors are read by the high and low-level boards is necessary for the simulation of the sensors. We were able to fix some issues regarding the CAN communication between the high and low-level boards. The modified low-level code was not pushed to the main low-level code folder in the repository on Github, however, it is included within the simulator documentation. The following were implemented.
* Unification of the proposed CAN message structure and the actual CAN message processing on the low-level code for CAN messages with ID 0x350 (High-level drive instructions). These are CAN messages the high-level will send to the low level to facilitate autonomy.
* Fixing the DAC output voltage by using the MCP48x2 library by Jonas Forsberg.
== To Do (Software): ==
'''

== 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 ===
{| class="wikitable"
! 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==

Simulator

2026-06-05T22:54:30Z

ShivBhatt: /* Overview */

Simulator

2026-06-05T22:44:59Z

ShivBhatt: /* Changes */

= Elcano Carla Simulation External Specification =

[http://carla.org/ 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 [https://micro-av.com/store/ols/products/carla-bridge 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.

[[File:Architecture_CAN_Sim_7_7_20.png|1000px]]

== 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.

'''[https://micro-av.com/store/ols/products/carla-bridge 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.

[[File:RouterBoard2020A.jpg|800px|]]

[[File:RouterBoard2020B.jpg|800px|]]

== Current Functionality of Simulation ==
At the end our Autumn 2019 Capstone, we were able to deliver a demo that demonstrated communication between all components; high-level board (Arduino Due), low-level board (Arduino Mega 2560) with shield running low level code, router board (Arduino Due), and the instance of Carla. The instructions on how to reproduce the demo will be given later in this document. The primary roadblock that prevented further development into this project was the state of the CAN system of the Elcano trike (particularly the transceiver board which seems to have a flawed design). These are the current features of the simulator.
* Implementation of USB serial communication between router board and computer running simulator.py. Both entities (Computer and ArduinoDue) can send and receive data through USB connection.
* Implementation of a cyclometer. Router board can receive the current speed of the simulated vehicle in Carla and convert it into an interrupt-based cyclometer pulse, based on the wheel dimension of the Elcano. Also considers the random error of cyclometer present on the Elcano trike. This can be debugged with the built-in LED on the router board.
* Implementation of NMEA GPS sensor. Carla is able the output NMEA GPS data to the router board 10 times per second, effectively simulating the GPS sensor on the high-level board. Router board is successfully able to output it to UART serial which is how it is transmitted to the high-level board.
* Implementation of timing structure. Computer running simulator.py waits for data to be interpreted from the router board while the router board executes its update 10 times per second. This is the desired speed for both sensor data and actuation data to be updated.
* Implementation of vehicle control updaters through throttle, brake, and steering data. The computer running simulator.py can take desired throttle, brake, and steering and convert them into corresponding commands for Carla using Carla API. These commands move the vehicle within Carla. This is the primarily what the demo shows.

== Demo Guide (How to Set-Up) ==
The following is a guide to set up the Elcano simulator.

===''' Materials '''===
* 1 Assembled Elcano Simulator Printed Circuit Board (PCB)
* 2 Arduino Due
* 1 Arduino Mega 2560
* 1 Box (200 x 150 x 70 mm)
* 2 Voltage Level Converter (included w/Simulator PCB)
* 1 SD Card (w/map files)
* 1 USB AB Cable (for Arduino Mega)
* 1 USB Micro Cable (for Arduino Due)
* 1 computer capable of running Carla

===''' Pre-installation '''===
Use the following instructions to install the required software to run the simulation.

#''''' Python '''''
#* Install Python 3 (if not installed already)
#::-experiments used version 3.7.6
#* In a terminal, move to .\Simulation\
#* Run the command “pip3 install -r requirements.txt” to have pip install all the required python libraries for the simulator
#''''' CARLA '''''
#*Download [https://carla.org/2020/03/09/release-0.9.8/ CARLA (0.9.8)]
#*CARLA requirements: [[File:Carla_Requirements.jpg|500px|]]
#''''' Arduino Libraries ''''' Download these Arduino libraries prior to running the simulation:
#* [https://github.com/Seeed-Studio/CAN_BUS_Shield CAN_BUS_SHIELD by Seeed-Studio]
#* [https://github.com/br3ttb/Arduino-PID-Library PID by Brett Beauregard]
#* [https://github.com/NicoHood/PinChangeInterrupt Pin Change Interrupt by Nico Hood]
#* [https://github.com/SweBarre/MCP48x2 MCP48x2 DAC by Jonas Forsberg]
#* [https://github.com/ivanseidel/DueTimer Arduino Due Timer Interrupts by Ivan Seidel]
#* Previous version of [https://github.com/collin80/due_can Arduino Due CAN Bus library] is used but the necessary files are included within the repository.
#''''' Elcano Repositories ''''' The Elcano repositories are needed to run the simulation:
#*[https://github.com/elcano/HighLevel High Level]
#*[https://github.com/elcano/Simulator Simulator (Router Board & Simulator Script)]
#*[https://github.com/elcano/Drive-by-wire Drive-by-wire (Low Level)]
===''' Run Simulation '''===
Once all the requirements are installed, use the following instructions to run the simulation.
 [[File:Router_PCB_Connections.jpg|500px]]
 '''''Step 1: Program all Arduinos'''''
#Upload router_board_v1.ino to the router Arduino Due programming port
#Upload High_Level.ino to the high level Arduino Due programming port
#Upload Drive_By_Wire.ino to the low level Arduino Mega 2560
'''''Step 2: Run CARLA'''''
#Open a command prompt (type cmd in the windows search box)
#Go to the directory where CARLA is installed (CARLAUE4.exe)
#:<code>cd C:\Users\bobross\Documents\ElcanoInstaller\CARLA\WindowsNoEditor</code>
#::-You may have it saved to a different directory
#From the CARLA directory, type:
#:<code>CARLAUE4.exe</code>
#:Or, to run in low resolution mode:
#:<code>CARLAUE4.exe -ResX=720 -ResY=480 -quality-level=Low</code>
'''''Step 3: Run Simulation'''''
#Connect your PC to the native port on the Router Board Due
#Open a command prompt (type cmd in the windows search box)
#Go to the Simulation directory
#:<code>cd C:\Users\bobross\Documents\Simulator\Simulation</code>
#::-You may have it saved to a different directory
#From Simulation directory, start the Simulator UI
#:<code>.\Simulation\start.bat</code>
#By default, the Simulator UI will populate local running CARLA settings
#*For control via the router board, leave mode as Auto
#*To control via manual keyboard input, change mode to Manual.
#*If running a network-based CARLA server, enter IP and Port of CARLA into the respective boxes. (i.e. 192.168.1.1, 2010)
#Click "Connect to CARLA"
#*If Auto mode, it will pop up a selection of COM devices, select routerboard native port COM to begin and press go.
#*If Manual mode, client will start with keyboard controls (WASD)
#Observe behavior in simulator.
#If car gets stuck, kill current simulator.py process and restart.
===''' Debug/Logging '''===
*High Level uses the Programming Port to display debug messages over serial monitor
*Router Board uses the Programming Port to display debug messages over serial monitor

== Out of Scope Functionality Tested/Implemented ==
* Our project required us to delve into pieces of code within the Elcano project outside of our scope. Understanding of how sensors are read by the high and low-level boards is necessary for the simulation of the sensors. We were able to fix some issues regarding the CAN communication between the high and low-level boards. The modified low-level code was not pushed to the main low-level code folder in the repository on Github, however, it is included within the simulator documentation. The following were implemented.
* Unification of the proposed CAN message structure and the actual CAN message processing on the low-level code for CAN messages with ID 0x350 (High-level drive instructions). These are CAN messages the high-level will send to the low level to facilitate autonomy.
* Fixing the DAC output voltage by using the MCP48x2 library by Jonas Forsberg.
== To Do (Software): ==
'''

== 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 [Elcano Project Wiki](https://www.elcanoproject.org/wiki/Simulator) 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 ===
{| class="wikitable"
! 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==

==Architecture==

Simulator

2026-06-05T22:43:46Z

ShivBhatt: /* Changes */

= Elcano Carla Simulation External Specification =

[http://carla.org/ 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 [https://micro-av.com/store/ols/products/carla-bridge 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.

[[File:Architecture_CAN_Sim_7_7_20.png|1000px]]

== 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.

'''[https://micro-av.com/store/ols/products/carla-bridge 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.

[[File:RouterBoard2020A.jpg|800px|]]

[[File:RouterBoard2020B.jpg|800px|]]

== Current Functionality of Simulation ==
At the end our Autumn 2019 Capstone, we were able to deliver a demo that demonstrated communication between all components; high-level board (Arduino Due), low-level board (Arduino Mega 2560) with shield running low level code, router board (Arduino Due), and the instance of Carla. The instructions on how to reproduce the demo will be given later in this document. The primary roadblock that prevented further development into this project was the state of the CAN system of the Elcano trike (particularly the transceiver board which seems to have a flawed design). These are the current features of the simulator.
* Implementation of USB serial communication between router board and computer running simulator.py. Both entities (Computer and ArduinoDue) can send and receive data through USB connection.
* Implementation of a cyclometer. Router board can receive the current speed of the simulated vehicle in Carla and convert it into an interrupt-based cyclometer pulse, based on the wheel dimension of the Elcano. Also considers the random error of cyclometer present on the Elcano trike. This can be debugged with the built-in LED on the router board.
* Implementation of NMEA GPS sensor. Carla is able the output NMEA GPS data to the router board 10 times per second, effectively simulating the GPS sensor on the high-level board. Router board is successfully able to output it to UART serial which is how it is transmitted to the high-level board.
* Implementation of timing structure. Computer running simulator.py waits for data to be interpreted from the router board while the router board executes its update 10 times per second. This is the desired speed for both sensor data and actuation data to be updated.
* Implementation of vehicle control updaters through throttle, brake, and steering data. The computer running simulator.py can take desired throttle, brake, and steering and convert them into corresponding commands for Carla using Carla API. These commands move the vehicle within Carla. This is the primarily what the demo shows.

== Demo Guide (How to Set-Up) ==
The following is a guide to set up the Elcano simulator.

===''' Materials '''===
* 1 Assembled Elcano Simulator Printed Circuit Board (PCB)
* 2 Arduino Due
* 1 Arduino Mega 2560
* 1 Box (200 x 150 x 70 mm)
* 2 Voltage Level Converter (included w/Simulator PCB)
* 1 SD Card (w/map files)
* 1 USB AB Cable (for Arduino Mega)
* 1 USB Micro Cable (for Arduino Due)
* 1 computer capable of running Carla

===''' Pre-installation '''===
Use the following instructions to install the required software to run the simulation.

#''''' Python '''''
#* Install Python 3 (if not installed already)
#::-experiments used version 3.7.6
#* In a terminal, move to .\Simulation\
#* Run the command “pip3 install -r requirements.txt” to have pip install all the required python libraries for the simulator
#''''' CARLA '''''
#*Download [https://carla.org/2020/03/09/release-0.9.8/ CARLA (0.9.8)]
#*CARLA requirements: [[File:Carla_Requirements.jpg|500px|]]
#''''' Arduino Libraries ''''' Download these Arduino libraries prior to running the simulation:
#* [https://github.com/Seeed-Studio/CAN_BUS_Shield CAN_BUS_SHIELD by Seeed-Studio]
#* [https://github.com/br3ttb/Arduino-PID-Library PID by Brett Beauregard]
#* [https://github.com/NicoHood/PinChangeInterrupt Pin Change Interrupt by Nico Hood]
#* [https://github.com/SweBarre/MCP48x2 MCP48x2 DAC by Jonas Forsberg]
#* [https://github.com/ivanseidel/DueTimer Arduino Due Timer Interrupts by Ivan Seidel]
#* Previous version of [https://github.com/collin80/due_can Arduino Due CAN Bus library] is used but the necessary files are included within the repository.
#''''' Elcano Repositories ''''' The Elcano repositories are needed to run the simulation:
#*[https://github.com/elcano/HighLevel High Level]
#*[https://github.com/elcano/Simulator Simulator (Router Board & Simulator Script)]
#*[https://github.com/elcano/Drive-by-wire Drive-by-wire (Low Level)]
===''' Run Simulation '''===
Once all the requirements are installed, use the following instructions to run the simulation.
 [[File:Router_PCB_Connections.jpg|500px]]
 '''''Step 1: Program all Arduinos'''''
#Upload router_board_v1.ino to the router Arduino Due programming port
#Upload High_Level.ino to the high level Arduino Due programming port
#Upload Drive_By_Wire.ino to the low level Arduino Mega 2560
'''''Step 2: Run CARLA'''''
#Open a command prompt (type cmd in the windows search box)
#Go to the directory where CARLA is installed (CARLAUE4.exe)
#:<code>cd C:\Users\bobross\Documents\ElcanoInstaller\CARLA\WindowsNoEditor</code>
#::-You may have it saved to a different directory
#From the CARLA directory, type:
#:<code>CARLAUE4.exe</code>
#:Or, to run in low resolution mode:
#:<code>CARLAUE4.exe -ResX=720 -ResY=480 -quality-level=Low</code>
'''''Step 3: Run Simulation'''''
#Connect your PC to the native port on the Router Board Due
#Open a command prompt (type cmd in the windows search box)
#Go to the Simulation directory
#:<code>cd C:\Users\bobross\Documents\Simulator\Simulation</code>
#::-You may have it saved to a different directory
#From Simulation directory, start the Simulator UI
#:<code>.\Simulation\start.bat</code>
#By default, the Simulator UI will populate local running CARLA settings
#*For control via the router board, leave mode as Auto
#*To control via manual keyboard input, change mode to Manual.
#*If running a network-based CARLA server, enter IP and Port of CARLA into the respective boxes. (i.e. 192.168.1.1, 2010)
#Click "Connect to CARLA"
#*If Auto mode, it will pop up a selection of COM devices, select routerboard native port COM to begin and press go.
#*If Manual mode, client will start with keyboard controls (WASD)
#Observe behavior in simulator.
#If car gets stuck, kill current simulator.py process and restart.
===''' Debug/Logging '''===
*High Level uses the Programming Port to display debug messages over serial monitor
*Router Board uses the Programming Port to display debug messages over serial monitor

== Out of Scope Functionality Tested/Implemented ==
* Our project required us to delve into pieces of code within the Elcano project outside of our scope. Understanding of how sensors are read by the high and low-level boards is necessary for the simulation of the sensors. We were able to fix some issues regarding the CAN communication between the high and low-level boards. The modified low-level code was not pushed to the main low-level code folder in the repository on Github, however, it is included within the simulator documentation. The following were implemented.
* Unification of the proposed CAN message structure and the actual CAN message processing on the low-level code for CAN messages with ID 0x350 (High-level drive instructions). These are CAN messages the high-level will send to the low level to facilitate autonomy.
* Fixing the DAC output voltage by using the MCP48x2 library by Jonas Forsberg.
== To Do (Software): ==
'''

== 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 ===

{| class="wikitable"
! 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==

==Architecture==

Simulator

2026-06-05T22:42:37Z

ShivBhatt: /* Changes */

= Elcano Carla Simulation External Specification =

[http://carla.org/ 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 [https://micro-av.com/store/ols/products/carla-bridge 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.

[[File:Architecture_CAN_Sim_7_7_20.png|1000px]]

== 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.

'''[https://micro-av.com/store/ols/products/carla-bridge 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.

[[File:RouterBoard2020A.jpg|800px|]]

[[File:RouterBoard2020B.jpg|800px|]]

== Current Functionality of Simulation ==
At the end our Autumn 2019 Capstone, we were able to deliver a demo that demonstrated communication between all components; high-level board (Arduino Due), low-level board (Arduino Mega 2560) with shield running low level code, router board (Arduino Due), and the instance of Carla. The instructions on how to reproduce the demo will be given later in this document. The primary roadblock that prevented further development into this project was the state of the CAN system of the Elcano trike (particularly the transceiver board which seems to have a flawed design). These are the current features of the simulator.
* Implementation of USB serial communication between router board and computer running simulator.py. Both entities (Computer and ArduinoDue) can send and receive data through USB connection.
* Implementation of a cyclometer. Router board can receive the current speed of the simulated vehicle in Carla and convert it into an interrupt-based cyclometer pulse, based on the wheel dimension of the Elcano. Also considers the random error of cyclometer present on the Elcano trike. This can be debugged with the built-in LED on the router board.
* Implementation of NMEA GPS sensor. Carla is able the output NMEA GPS data to the router board 10 times per second, effectively simulating the GPS sensor on the high-level board. Router board is successfully able to output it to UART serial which is how it is transmitted to the high-level board.
* Implementation of timing structure. Computer running simulator.py waits for data to be interpreted from the router board while the router board executes its update 10 times per second. This is the desired speed for both sensor data and actuation data to be updated.
* Implementation of vehicle control updaters through throttle, brake, and steering data. The computer running simulator.py can take desired throttle, brake, and steering and convert them into corresponding commands for Carla using Carla API. These commands move the vehicle within Carla. This is the primarily what the demo shows.

== Demo Guide (How to Set-Up) ==
The following is a guide to set up the Elcano simulator.

===''' Materials '''===
* 1 Assembled Elcano Simulator Printed Circuit Board (PCB)
* 2 Arduino Due
* 1 Arduino Mega 2560
* 1 Box (200 x 150 x 70 mm)
* 2 Voltage Level Converter (included w/Simulator PCB)
* 1 SD Card (w/map files)
* 1 USB AB Cable (for Arduino Mega)
* 1 USB Micro Cable (for Arduino Due)
* 1 computer capable of running Carla

===''' Pre-installation '''===
Use the following instructions to install the required software to run the simulation.

#''''' Python '''''
#* Install Python 3 (if not installed already)
#::-experiments used version 3.7.6
#* In a terminal, move to .\Simulation\
#* Run the command “pip3 install -r requirements.txt” to have pip install all the required python libraries for the simulator
#''''' CARLA '''''
#*Download [https://carla.org/2020/03/09/release-0.9.8/ CARLA (0.9.8)]
#*CARLA requirements: [[File:Carla_Requirements.jpg|500px|]]
#''''' Arduino Libraries ''''' Download these Arduino libraries prior to running the simulation:
#* [https://github.com/Seeed-Studio/CAN_BUS_Shield CAN_BUS_SHIELD by Seeed-Studio]
#* [https://github.com/br3ttb/Arduino-PID-Library PID by Brett Beauregard]
#* [https://github.com/NicoHood/PinChangeInterrupt Pin Change Interrupt by Nico Hood]
#* [https://github.com/SweBarre/MCP48x2 MCP48x2 DAC by Jonas Forsberg]
#* [https://github.com/ivanseidel/DueTimer Arduino Due Timer Interrupts by Ivan Seidel]
#* Previous version of [https://github.com/collin80/due_can Arduino Due CAN Bus library] is used but the necessary files are included within the repository.
#''''' Elcano Repositories ''''' The Elcano repositories are needed to run the simulation:
#*[https://github.com/elcano/HighLevel High Level]
#*[https://github.com/elcano/Simulator Simulator (Router Board & Simulator Script)]
#*[https://github.com/elcano/Drive-by-wire Drive-by-wire (Low Level)]
===''' Run Simulation '''===
Once all the requirements are installed, use the following instructions to run the simulation.
 [[File:Router_PCB_Connections.jpg|500px]]
 '''''Step 1: Program all Arduinos'''''
#Upload router_board_v1.ino to the router Arduino Due programming port
#Upload High_Level.ino to the high level Arduino Due programming port
#Upload Drive_By_Wire.ino to the low level Arduino Mega 2560
'''''Step 2: Run CARLA'''''
#Open a command prompt (type cmd in the windows search box)
#Go to the directory where CARLA is installed (CARLAUE4.exe)
#:<code>cd C:\Users\bobross\Documents\ElcanoInstaller\CARLA\WindowsNoEditor</code>
#::-You may have it saved to a different directory
#From the CARLA directory, type:
#:<code>CARLAUE4.exe</code>
#:Or, to run in low resolution mode:
#:<code>CARLAUE4.exe -ResX=720 -ResY=480 -quality-level=Low</code>
'''''Step 3: Run Simulation'''''
#Connect your PC to the native port on the Router Board Due
#Open a command prompt (type cmd in the windows search box)
#Go to the Simulation directory
#:<code>cd C:\Users\bobross\Documents\Simulator\Simulation</code>
#::-You may have it saved to a different directory
#From Simulation directory, start the Simulator UI
#:<code>.\Simulation\start.bat</code>
#By default, the Simulator UI will populate local running CARLA settings
#*For control via the router board, leave mode as Auto
#*To control via manual keyboard input, change mode to Manual.
#*If running a network-based CARLA server, enter IP and Port of CARLA into the respective boxes. (i.e. 192.168.1.1, 2010)
#Click "Connect to CARLA"
#*If Auto mode, it will pop up a selection of COM devices, select routerboard native port COM to begin and press go.
#*If Manual mode, client will start with keyboard controls (WASD)
#Observe behavior in simulator.
#If car gets stuck, kill current simulator.py process and restart.
===''' Debug/Logging '''===
*High Level uses the Programming Port to display debug messages over serial monitor
*Router Board uses the Programming Port to display debug messages over serial monitor

== Out of Scope Functionality Tested/Implemented ==
* Our project required us to delve into pieces of code within the Elcano project outside of our scope. Understanding of how sensors are read by the high and low-level boards is necessary for the simulation of the sensors. We were able to fix some issues regarding the CAN communication between the high and low-level boards. The modified low-level code was not pushed to the main low-level code folder in the repository on Github, however, it is included within the simulator documentation. The following were implemented.
* Unification of the proposed CAN message structure and the actual CAN message processing on the low-level code for CAN messages with ID 0x350 (High-level drive instructions). These are CAN messages the high-level will send to the low level to facilitate autonomy.
* Fixing the DAC output voltage by using the MCP48x2 library by Jonas Forsberg.
== To Do (Software): ==
'''

== 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==

==Architecture==

Simulator

2026-06-05T22:41:59Z

ShivBhatt: /* Changes */

= Elcano Carla Simulation External Specification =

[http://carla.org/ 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 [https://micro-av.com/store/ols/products/carla-bridge 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.

[[File:Architecture_CAN_Sim_7_7_20.png|1000px]]

== 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.

'''[https://micro-av.com/store/ols/products/carla-bridge 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.

[[File:RouterBoard2020A.jpg|800px|]]

[[File:RouterBoard2020B.jpg|800px|]]

== Current Functionality of Simulation ==
At the end our Autumn 2019 Capstone, we were able to deliver a demo that demonstrated communication between all components; high-level board (Arduino Due), low-level board (Arduino Mega 2560) with shield running low level code, router board (Arduino Due), and the instance of Carla. The instructions on how to reproduce the demo will be given later in this document. The primary roadblock that prevented further development into this project was the state of the CAN system of the Elcano trike (particularly the transceiver board which seems to have a flawed design). These are the current features of the simulator.
* Implementation of USB serial communication between router board and computer running simulator.py. Both entities (Computer and ArduinoDue) can send and receive data through USB connection.
* Implementation of a cyclometer. Router board can receive the current speed of the simulated vehicle in Carla and convert it into an interrupt-based cyclometer pulse, based on the wheel dimension of the Elcano. Also considers the random error of cyclometer present on the Elcano trike. This can be debugged with the built-in LED on the router board.
* Implementation of NMEA GPS sensor. Carla is able the output NMEA GPS data to the router board 10 times per second, effectively simulating the GPS sensor on the high-level board. Router board is successfully able to output it to UART serial which is how it is transmitted to the high-level board.
* Implementation of timing structure. Computer running simulator.py waits for data to be interpreted from the router board while the router board executes its update 10 times per second. This is the desired speed for both sensor data and actuation data to be updated.
* Implementation of vehicle control updaters through throttle, brake, and steering data. The computer running simulator.py can take desired throttle, brake, and steering and convert them into corresponding commands for Carla using Carla API. These commands move the vehicle within Carla. This is the primarily what the demo shows.

== Demo Guide (How to Set-Up) ==
The following is a guide to set up the Elcano simulator.

===''' Materials '''===
* 1 Assembled Elcano Simulator Printed Circuit Board (PCB)
* 2 Arduino Due
* 1 Arduino Mega 2560
* 1 Box (200 x 150 x 70 mm)
* 2 Voltage Level Converter (included w/Simulator PCB)
* 1 SD Card (w/map files)
* 1 USB AB Cable (for Arduino Mega)
* 1 USB Micro Cable (for Arduino Due)
* 1 computer capable of running Carla

===''' Pre-installation '''===
Use the following instructions to install the required software to run the simulation.

#''''' Python '''''
#* Install Python 3 (if not installed already)
#::-experiments used version 3.7.6
#* In a terminal, move to .\Simulation\
#* Run the command “pip3 install -r requirements.txt” to have pip install all the required python libraries for the simulator
#''''' CARLA '''''
#*Download [https://carla.org/2020/03/09/release-0.9.8/ CARLA (0.9.8)]
#*CARLA requirements: [[File:Carla_Requirements.jpg|500px|]]
#''''' Arduino Libraries ''''' Download these Arduino libraries prior to running the simulation:
#* [https://github.com/Seeed-Studio/CAN_BUS_Shield CAN_BUS_SHIELD by Seeed-Studio]
#* [https://github.com/br3ttb/Arduino-PID-Library PID by Brett Beauregard]
#* [https://github.com/NicoHood/PinChangeInterrupt Pin Change Interrupt by Nico Hood]
#* [https://github.com/SweBarre/MCP48x2 MCP48x2 DAC by Jonas Forsberg]
#* [https://github.com/ivanseidel/DueTimer Arduino Due Timer Interrupts by Ivan Seidel]
#* Previous version of [https://github.com/collin80/due_can Arduino Due CAN Bus library] is used but the necessary files are included within the repository.
#''''' Elcano Repositories ''''' The Elcano repositories are needed to run the simulation:
#*[https://github.com/elcano/HighLevel High Level]
#*[https://github.com/elcano/Simulator Simulator (Router Board & Simulator Script)]
#*[https://github.com/elcano/Drive-by-wire Drive-by-wire (Low Level)]
===''' Run Simulation '''===
Once all the requirements are installed, use the following instructions to run the simulation.
 [[File:Router_PCB_Connections.jpg|500px]]
 '''''Step 1: Program all Arduinos'''''
#Upload router_board_v1.ino to the router Arduino Due programming port
#Upload High_Level.ino to the high level Arduino Due programming port
#Upload Drive_By_Wire.ino to the low level Arduino Mega 2560
'''''Step 2: Run CARLA'''''
#Open a command prompt (type cmd in the windows search box)
#Go to the directory where CARLA is installed (CARLAUE4.exe)
#:<code>cd C:\Users\bobross\Documents\ElcanoInstaller\CARLA\WindowsNoEditor</code>
#::-You may have it saved to a different directory
#From the CARLA directory, type:
#:<code>CARLAUE4.exe</code>
#:Or, to run in low resolution mode:
#:<code>CARLAUE4.exe -ResX=720 -ResY=480 -quality-level=Low</code>
'''''Step 3: Run Simulation'''''
#Connect your PC to the native port on the Router Board Due
#Open a command prompt (type cmd in the windows search box)
#Go to the Simulation directory
#:<code>cd C:\Users\bobross\Documents\Simulator\Simulation</code>
#::-You may have it saved to a different directory
#From Simulation directory, start the Simulator UI
#:<code>.\Simulation\start.bat</code>
#By default, the Simulator UI will populate local running CARLA settings
#*For control via the router board, leave mode as Auto
#*To control via manual keyboard input, change mode to Manual.
#*If running a network-based CARLA server, enter IP and Port of CARLA into the respective boxes. (i.e. 192.168.1.1, 2010)
#Click "Connect to CARLA"
#*If Auto mode, it will pop up a selection of COM devices, select routerboard native port COM to begin and press go.
#*If Manual mode, client will start with keyboard controls (WASD)
#Observe behavior in simulator.
#If car gets stuck, kill current simulator.py process and restart.
===''' Debug/Logging '''===
*High Level uses the Programming Port to display debug messages over serial monitor
*Router Board uses the Programming Port to display debug messages over serial monitor

== Out of Scope Functionality Tested/Implemented ==
* Our project required us to delve into pieces of code within the Elcano project outside of our scope. Understanding of how sensors are read by the high and low-level boards is necessary for the simulation of the sensors. We were able to fix some issues regarding the CAN communication between the high and low-level boards. The modified low-level code was not pushed to the main low-level code folder in the repository on Github, however, it is included within the simulator documentation. The following were implemented.
* Unification of the proposed CAN message structure and the actual CAN message processing on the low-level code for CAN messages with ID 0x350 (High-level drive instructions). These are CAN messages the high-level will send to the low level to facilitate autonomy.
* Fixing the DAC output voltage by using the MCP48x2 library by Jonas Forsberg.
== To Do (Software): ==
'''

== 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==

==Architecture==

Simulator

2026-06-05T22:40:41Z

ShivBhatt: /* Changes */

= Elcano Carla Simulation External Specification =

[http://carla.org/ 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 [https://micro-av.com/store/ols/products/carla-bridge 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.

[[File:Architecture_CAN_Sim_7_7_20.png|1000px]]

== 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.

'''[https://micro-av.com/store/ols/products/carla-bridge 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.

[[File:RouterBoard2020A.jpg|800px|]]

[[File:RouterBoard2020B.jpg|800px|]]

== Current Functionality of Simulation ==
At the end our Autumn 2019 Capstone, we were able to deliver a demo that demonstrated communication between all components; high-level board (Arduino Due), low-level board (Arduino Mega 2560) with shield running low level code, router board (Arduino Due), and the instance of Carla. The instructions on how to reproduce the demo will be given later in this document. The primary roadblock that prevented further development into this project was the state of the CAN system of the Elcano trike (particularly the transceiver board which seems to have a flawed design). These are the current features of the simulator.
* Implementation of USB serial communication between router board and computer running simulator.py. Both entities (Computer and ArduinoDue) can send and receive data through USB connection.
* Implementation of a cyclometer. Router board can receive the current speed of the simulated vehicle in Carla and convert it into an interrupt-based cyclometer pulse, based on the wheel dimension of the Elcano. Also considers the random error of cyclometer present on the Elcano trike. This can be debugged with the built-in LED on the router board.
* Implementation of NMEA GPS sensor. Carla is able the output NMEA GPS data to the router board 10 times per second, effectively simulating the GPS sensor on the high-level board. Router board is successfully able to output it to UART serial which is how it is transmitted to the high-level board.
* Implementation of timing structure. Computer running simulator.py waits for data to be interpreted from the router board while the router board executes its update 10 times per second. This is the desired speed for both sensor data and actuation data to be updated.
* Implementation of vehicle control updaters through throttle, brake, and steering data. The computer running simulator.py can take desired throttle, brake, and steering and convert them into corresponding commands for Carla using Carla API. These commands move the vehicle within Carla. This is the primarily what the demo shows.

== Demo Guide (How to Set-Up) ==
The following is a guide to set up the Elcano simulator.

===''' Materials '''===
* 1 Assembled Elcano Simulator Printed Circuit Board (PCB)
* 2 Arduino Due
* 1 Arduino Mega 2560
* 1 Box (200 x 150 x 70 mm)
* 2 Voltage Level Converter (included w/Simulator PCB)
* 1 SD Card (w/map files)
* 1 USB AB Cable (for Arduino Mega)
* 1 USB Micro Cable (for Arduino Due)
* 1 computer capable of running Carla

===''' Pre-installation '''===
Use the following instructions to install the required software to run the simulation.

#''''' Python '''''
#* Install Python 3 (if not installed already)
#::-experiments used version 3.7.6
#* In a terminal, move to .\Simulation\
#* Run the command “pip3 install -r requirements.txt” to have pip install all the required python libraries for the simulator
#''''' CARLA '''''
#*Download [https://carla.org/2020/03/09/release-0.9.8/ CARLA (0.9.8)]
#*CARLA requirements: [[File:Carla_Requirements.jpg|500px|]]
#''''' Arduino Libraries ''''' Download these Arduino libraries prior to running the simulation:
#* [https://github.com/Seeed-Studio/CAN_BUS_Shield CAN_BUS_SHIELD by Seeed-Studio]
#* [https://github.com/br3ttb/Arduino-PID-Library PID by Brett Beauregard]
#* [https://github.com/NicoHood/PinChangeInterrupt Pin Change Interrupt by Nico Hood]
#* [https://github.com/SweBarre/MCP48x2 MCP48x2 DAC by Jonas Forsberg]
#* [https://github.com/ivanseidel/DueTimer Arduino Due Timer Interrupts by Ivan Seidel]
#* Previous version of [https://github.com/collin80/due_can Arduino Due CAN Bus library] is used but the necessary files are included within the repository.
#''''' Elcano Repositories ''''' The Elcano repositories are needed to run the simulation:
#*[https://github.com/elcano/HighLevel High Level]
#*[https://github.com/elcano/Simulator Simulator (Router Board & Simulator Script)]
#*[https://github.com/elcano/Drive-by-wire Drive-by-wire (Low Level)]
===''' Run Simulation '''===
Once all the requirements are installed, use the following instructions to run the simulation.
 [[File:Router_PCB_Connections.jpg|500px]]
 '''''Step 1: Program all Arduinos'''''
#Upload router_board_v1.ino to the router Arduino Due programming port
#Upload High_Level.ino to the high level Arduino Due programming port
#Upload Drive_By_Wire.ino to the low level Arduino Mega 2560
'''''Step 2: Run CARLA'''''
#Open a command prompt (type cmd in the windows search box)
#Go to the directory where CARLA is installed (CARLAUE4.exe)
#:<code>cd C:\Users\bobross\Documents\ElcanoInstaller\CARLA\WindowsNoEditor</code>
#::-You may have it saved to a different directory
#From the CARLA directory, type:
#:<code>CARLAUE4.exe</code>
#:Or, to run in low resolution mode:
#:<code>CARLAUE4.exe -ResX=720 -ResY=480 -quality-level=Low</code>
'''''Step 3: Run Simulation'''''
#Connect your PC to the native port on the Router Board Due
#Open a command prompt (type cmd in the windows search box)
#Go to the Simulation directory
#:<code>cd C:\Users\bobross\Documents\Simulator\Simulation</code>
#::-You may have it saved to a different directory
#From Simulation directory, start the Simulator UI
#:<code>.\Simulation\start.bat</code>
#By default, the Simulator UI will populate local running CARLA settings
#*For control via the router board, leave mode as Auto
#*To control via manual keyboard input, change mode to Manual.
#*If running a network-based CARLA server, enter IP and Port of CARLA into the respective boxes. (i.e. 192.168.1.1, 2010)
#Click "Connect to CARLA"
#*If Auto mode, it will pop up a selection of COM devices, select routerboard native port COM to begin and press go.
#*If Manual mode, client will start with keyboard controls (WASD)
#Observe behavior in simulator.
#If car gets stuck, kill current simulator.py process and restart.
===''' Debug/Logging '''===
*High Level uses the Programming Port to display debug messages over serial monitor
*Router Board uses the Programming Port to display debug messages over serial monitor

== Out of Scope Functionality Tested/Implemented ==
* Our project required us to delve into pieces of code within the Elcano project outside of our scope. Understanding of how sensors are read by the high and low-level boards is necessary for the simulation of the sensors. We were able to fix some issues regarding the CAN communication between the high and low-level boards. The modified low-level code was not pushed to the main low-level code folder in the repository on Github, however, it is included within the simulator documentation. The following were implemented.
* Unification of the proposed CAN message structure and the actual CAN message processing on the low-level code for CAN messages with ID 0x350 (High-level drive instructions). These are CAN messages the high-level will send to the low level to facilitate autonomy.
* Fixing the DAC output voltage by using the MCP48x2 library by Jonas Forsberg.
== To Do (Software): ==
'''

== 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==

==Architecture==

Simulator

2026-06-05T22:38:07Z

ShivBhatt: /* 2026 Simulator */

Simulator

2026-06-05T22:29:27Z

ShivBhatt: /* Architecture */

Simulator

2026-06-05T22:29:16Z

ShivBhatt: /* Purpose */

Simulator

2026-06-05T22:29:07Z

ShivBhatt: /* 2026 Simulator */

Simulator

2026-06-05T22:28:42Z

ShivBhatt: /* 2026 Simulator */

Simulator

2026-06-05T22:28:15Z

ShivBhatt: /* 2026 Simulator */

Simulator

2026-06-05T22:27:43Z

ShivBhatt: /* 2026 Simulator */

Simulator

2026-06-05T22:27:20Z

ShivBhatt: /* 2026 Simulator */