Simulator - Revision history

Elcanoadmin: /* Overview */

2026-06-12T01:17:29Z

‎Overview

Elcanoadmin: /* Additional Notes */

2026-06-12T01:13:55Z

‎Additional Notes

Elcanoadmin: /* Bugs Within Simulator */

2026-06-12T01:11:09Z

‎Bugs Within Simulator

Elcanoadmin: /* To Do (Software): */

2026-06-12T01:08:54Z

‎To Do (Software):

Elcanoadmin: /* Out of Scope Functionality Tested/Implemented */

2026-06-12T01:08:26Z

‎Out of Scope Functionality Tested/Implemented

Elcanoadmin: /* Demo Guide (How to Set-Up) */

2026-06-12T01:06:15Z

‎Demo Guide (How to Set-Up)

Elcanoadmin: /* Current Functionality of Simulation */

2026-06-12T01:04:03Z

‎Current Functionality of Simulation

ShivBhatt: /* Architecture */

2026-06-06T22:22:25Z

‎Architecture

ShivBhatt: /* Purpose */

2026-06-06T02:35:05Z

‎Purpose

ShivBhatt: /* Purpose */

2026-06-06T02:34:43Z

‎Purpose

@@ Line 41: / Line 41: @@
 === 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 ===

← Older revision		Revision as of 01:13, 12 June 2026
Line 34:		Line 34:

	[[File:RouterBoard2020B.jpg\|800px\|]]		[[File:RouterBoard2020B.jpg\|800px\|]]
−
−	~~== 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 =		= 2026 Simulator =

← Older revision		Revision as of 01:11, 12 June 2026
Line 34:		Line 34:

	[[File:RouterBoard2020B.jpg\|800px\|]]		[[File:RouterBoard2020B.jpg\|800px\|]]
−
−	~~== 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 ==		== Additional Notes ==

← Older revision		Revision as of 01:08, 12 June 2026
Line 34:		Line 34:

	[[File:RouterBoard2020B.jpg\|800px\|]]		[[File:RouterBoard2020B.jpg\|800px\|]]
−
−	~~== To Do (Software): ==~~
−	~~'''~~

	== Bugs Within Simulator ==		== Bugs Within Simulator ==

@@ Line 35: / Line 35: @@
 [[File:RouterBoard2020B.jpg|800px|]]
 == To Do (Software): ==
 '''

← Older revision		Revision as of 01:06, 12 June 2026
Line 34:		Line 34:

	[[File:RouterBoard2020B.jpg\|800px\|]]		[[File:RouterBoard2020B.jpg\|800px\|]]
−
−	~~== 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.~~
−
−	~~#<u>''''' Python '''''</u>~~
−	~~#* 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~~
−	~~#<u>''''' CARLA '''''</u>~~
−	~~#*Download [https://carla.org/2020/03/09/release-0.9.8/ CARLA (0.9.8)]~~
−	~~#*CARLA requirements:<br />[[File:Carla_Requirements.jpg\|500px\|]]~~
−	~~#<u>''''' Arduino Libraries '''''</u><br />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.~~
−	~~#<u>''''' Elcano Repositories '''''</u><br />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.~~
−	~~<br />[[File:Router_PCB_Connections.jpg\|500px]]~~
−	~~<br /><br />'''''Step 1: Program all Arduinos'''''~~
−	~~#Upload <b>router_board_v1.ino</b> to the router Arduino Due programming port~~
−	~~#Upload <b>High_Level.ino</b> to the high level Arduino Due programming port~~
−	~~#Upload <b>Drive_By_Wire.ino</b> 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 ==		== Out of Scope Functionality Tested/Implemented ==

← Older revision		Revision as of 01:04, 12 June 2026
Line 34:		Line 34:

	[[File:RouterBoard2020B.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) ==		== Demo Guide (How to Set-Up) ==

← Older revision		Revision as of 22:22, 6 June 2026
Line 255:		Line 255:
	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.		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==	+	== 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.

@@ Line 220: / Line 220: @@
 * Improved support for CAN-based hardware-in-the-loop testing
-=== Purpose ===
+== 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.