Simulator - Revision history

Elcanoadmin: /* 2026 Simulation */

2026-05-18T23:33:44Z

‎2026 Simulation

Elcanoadmin: /* Additional Notes */

2026-05-18T23:32:57Z

‎Additional Notes

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

2026-05-18T23:29:57Z

‎To Do (Software):

Mblackb: /* Components */

2020-07-29T19:00:00Z

‎Components

Mblackb: /* Elcano Carla Simulation External Specification */

2020-07-29T18:59:35Z

‎Elcano Carla Simulation External Specification

Mblackb: /* Purpose: */

2020-07-29T18:59:09Z

‎Purpose:

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

2020-07-29T18:57:51Z

‎To Do (Software):

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

2020-07-29T18:57:23Z

‎To Do (Software):

Mblackb: /* Elcano Carla Simulation External Specification */

2020-07-29T18:54:25Z

‎Elcano Carla Simulation External Specification

Mblackb: /* Other Elcano Bugs Found */

2020-07-29T18:51:19Z

‎Other Elcano Bugs Found

← Older revision		Revision as of 23:33, 18 May 2026
Line 137:		Line 137:
	* Headless mode can be enabled for complete removal of graphics rendering, however, visual debugging is extremely useful.		* Headless mode can be enabled for complete removal of graphics rendering, however, visual debugging is extremely useful.

−	= 2026 ~~Simulation~~ =	+	= 2026 Simulator =

← Older revision		Revision as of 23:32, 18 May 2026
Line 136:		Line 136:
	* In PowerShell, in CarlaUE4 path, run Carla as: *Start-Process CarlaUE4 -ArgumentList “—quality-level=Low”* to lower gpu load.		* 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.		* Headless mode can be enabled for complete removal of graphics rendering, however, visual debugging is extremely useful.
		+
		+	= 2026 Simulation =

@@ Line 121: / Line 121: @@
 * Fixing the DAC output voltage by using the MCP48x2 library by Jonas Forsberg.
 == To Do (Software): ==
-''' High Priority: '''
+'''
 == Bugs Within Simulator ==

@@ Line 28: / Line 28: @@
 Current Elcano Drive-by-wirel code. Actuator data is routed to CARLA.
-'''[https://micro-av.com/store/ols/products/carla-bridge Router Board]:'''
+'''[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.

@@ Line 18: / Line 18: @@
 * Allow autonomous driving to be tested.
-== Components: ==
+== Components ==
-''' Simulation:'''
+''' 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.
@@ Line 35: / Line 35: @@
 [[File:RouterBoard2020B.jpg|800px|]]
-==  Current Functionality of Simulation: ==
+==  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.

@@ Line 10: / Line 10: @@
-== Purpose: ==
+== Purpose ==
 The following is a generalized list of the desired functionality of the simulator.
 * Simulate data for all sensors associated with Elcano Trike.

@@ Line 123: / Line 123: @@
 ''' High Priority: '''
 * Simulate gyro sensor
-* Simulate accelerometer/magnetometer sensor.
+* Simulate accelerometer/magnetometer sensor
 ''' Medium Priority: '''
-* Simulate ScanseSweep.
+* Simulate ScanseSweep
-* Implement receiver board when board is fully fixed.
+* Implement receiver board
-* Incorporate Elcano trike physics to simulated vehicle.
+* Incorporate Elcano trike physics to simulated vehicle
 ''' Low Priority '''
-* Simulate camera sensor.
+* Simulate camera sensor
 == Bugs Within Simulator ==

@@ Line 125: / Line 125: @@
 * Simulate accelerometer/magnetometer sensor.
 * Simulate wheel angle sensor.
 ''' Medium Priority: '''
 * Simulate ScanseSweep.
@@ Line 135: / Line 133: @@
 == 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.
+* 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 will never stop outputting sensor data even if asked to stop.  This is a bug with Carla and not in our scope.
+* 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 ==

@@ Line 139: / Line 139: @@
 * Most malfunctions can be temporarily fixed by restarting the simulator.py instance.
 == Other Elcano Bugs Found ==
-* While we were able to fix the code for the low-level CAN interpretation of the throttle and brake commands from high-level CAN messages, the PWM steering response was not fully tested.  We were unable to get the low-level board to output the correct PWM for the sent CAN messages and this needs more testing.
+* 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.
-* The receiver board cannot get CAN to initialize.  Voltage testing confirmed that the CAN components (MCP2515 and MCP 2550) are receiving the correct operating voltages (5v).  Also, multiple CAN libraries besides the suggested Seeed Studio library were tested with no success (SparkFun CAN library was one of the tested libraries).  Possible problem is incompatibility between the 5v CAN components and the 3.3V SAMD21 board.  Another possible problem is design flaw of pcb.
 == 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.