Elcano Project Wiki - User contributions [en]

Simulator

2020-07-29T19:00:00Z

Mblackb: /* Components */

= 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): ==
''' High Priority: '''
* Simulate gyro sensor
* Simulate accelerometer/magnetometer sensor
''' Medium Priority: '''
* Simulate ScanseSweep
* Implement receiver board
* Incorporate Elcano trike physics to simulated vehicle
''' Low Priority '''
* Simulate camera sensor

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

Simulator

2020-07-29T18:59:35Z

Mblackb: /* Elcano Carla Simulation External Specification */

= 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): ==
''' High Priority: '''
* Simulate gyro sensor
* Simulate accelerometer/magnetometer sensor
''' Medium Priority: '''
* Simulate ScanseSweep
* Implement receiver board
* Incorporate Elcano trike physics to simulated vehicle
''' Low Priority '''
* Simulate camera sensor

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

Simulator

2020-07-29T18:59:09Z

Mblackb: /* 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): ==
''' High Priority: '''
* Simulate gyro sensor
* Simulate accelerometer/magnetometer sensor
''' Medium Priority: '''
* Simulate ScanseSweep
* Implement receiver board
* Incorporate Elcano trike physics to simulated vehicle
''' Low Priority '''
* Simulate camera sensor

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

Simulator

2020-07-29T18:57:51Z

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

= 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): ==
''' High Priority: '''
* Simulate gyro sensor
* Simulate accelerometer/magnetometer sensor
''' Medium Priority: '''
* Simulate ScanseSweep
* Implement receiver board
* Incorporate Elcano trike physics to simulated vehicle
''' Low Priority '''
* Simulate camera sensor

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

Simulator

2020-07-29T18:57:23Z

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

= 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): ==
''' High Priority: '''
* Simulate gyro sensor
* Simulate accelerometer/magnetometer sensor.
''' Medium Priority: '''
* Simulate ScanseSweep.
* Implement receiver board when board is fully fixed.
* Incorporate Elcano trike physics to simulated vehicle.
''' Low Priority '''
* Simulate camera sensor.

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

Simulator

2020-07-29T18:54:25Z

Mblackb: /* Elcano Carla Simulation External Specification */

= 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): ==
''' High Priority: '''
* Simulate gyro sensor
* Simulate accelerometer/magnetometer sensor.
* Simulate wheel angle sensor.
''' Medium Priority: '''
* Simulate ScanseSweep.
* Implement receiver board when board is fully fixed.
* Incorporate Elcano trike physics to simulated vehicle.
''' Low Priority '''
* Simulate camera sensor.
== 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.

Simulator

2020-07-29T18:51:19Z

Mblackb: /* Other Elcano Bugs Found */

= 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): ==
''' High Priority: '''
* Simulate gyro sensor
* Simulate accelerometer/magnetometer sensor.
* Simulate wheel angle sensor.
* Implement steering actuation when low-level CAN processing of steering command is fixed.
* Initialize CAN with high-level board code and incorporate in demo instead of separate CAN transceiver.
''' Medium Priority: '''
* Simulate ScanseSweep.
* Implement receiver board when board is fully fixed.
* Incorporate Elcano trike physics to simulated vehicle.
''' Low Priority '''
* Simulate camera sensor.
== 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 will never 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.
== Other Elcano Bugs Found ==
* 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.

Simulator

2020-07-29T18:48:23Z

Mblackb: /* Elcano Carla Simulation External Specification */

= 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): ==
''' High Priority: '''
* Simulate gyro sensor
* Simulate accelerometer/magnetometer sensor.
* Simulate wheel angle sensor.
* Implement steering actuation when low-level CAN processing of steering command is fixed.
* Initialize CAN with high-level board code and incorporate in demo instead of separate CAN transceiver.
''' Medium Priority: '''
* Simulate ScanseSweep.
* Implement receiver board when board is fully fixed.
* Incorporate Elcano trike physics to simulated vehicle.
''' Low Priority '''
* Simulate camera sensor.
== 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 will never 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.
== 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.
* 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.
* Low-level processing of CAN messages for ID 0x350 is faulty. Bit shifting and produced output do not match the CAN guidelines on the wiki. This was fixed in the low-level code included in the simulator folder but not pushed to the Elcano Github repository.
== 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.

Simulator

2020-07-29T18:47:00Z

Mblackb: /* Elcano Carla Simulation External Specification */

= 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 benchmarking overall vehicle progress. The CARLA software can simulate a variety of road conditions such as traffic patterns, inclines, and weather as well as provide users control over vehicle parameters including weight, engine power, and aerodynamic properties.

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

[[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): ==
''' High Priority: '''
* Simulate gyro sensor
* Simulate accelerometer/magnetometer sensor.
* Simulate wheel angle sensor.
* Implement steering actuation when low-level CAN processing of steering command is fixed.
* Initialize CAN with high-level board code and incorporate in demo instead of separate CAN transceiver.
''' Medium Priority: '''
* Simulate ScanseSweep.
* Implement receiver board when board is fully fixed.
* Incorporate Elcano trike physics to simulated vehicle.
''' Low Priority '''
* Simulate camera sensor.
== 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 will never 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.
== 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.
* 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.
* Low-level processing of CAN messages for ID 0x350 is faulty. Bit shifting and produced output do not match the CAN guidelines on the wiki. This was fixed in the low-level code included in the simulator folder but not pushed to the Elcano Github repository.
== 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.

Simulator

2020-07-29T18:46:45Z

Mblackb: /* Elcano Carla Simulation External Specification */

= 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 benchmarking overall vehicle progress. The CARLA software can simulate a variety of road conditions such as traffic patterns, inclines, and weather as well as provide users control over vehicle parameters including weight, engine power, and aerodynamic properties.

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

[[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): ==
''' High Priority: '''
* Simulate gyro sensor
* Simulate accelerometer/magnetometer sensor.
* Simulate wheel angle sensor.
* Implement steering actuation when low-level CAN processing of steering command is fixed.
* Initialize CAN with high-level board code and incorporate in demo instead of separate CAN transceiver.
''' Medium Priority: '''
* Simulate ScanseSweep.
* Implement receiver board when board is fully fixed.
* Incorporate Elcano trike physics to simulated vehicle.
''' Low Priority '''
* Simulate camera sensor.
== 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 will never 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.
== 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.
* 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.
* Low-level processing of CAN messages for ID 0x350 is faulty. Bit shifting and produced output do not match the CAN guidelines on the wiki. This was fixed in the low-level code included in the simulator folder but not pushed to the Elcano Github repository.
== 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.

Simulator

2020-07-29T18:42:12Z

Mblackb: /* Components: */

= Elcano Carla Simulation External Specification =

CARLA <http://carla.org/> 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 benchmarking overall vehicle progress. The CARLA software can simulate a variety of road conditions such as traffic patterns, inclines, and weather as well as provide users control over vehicle parameters including weight, engine power, and aerodynamic properties.

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

[[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): ==
''' High Priority: '''
* Simulate gyro sensor
* Simulate accelerometer/magnetometer sensor.
* Simulate wheel angle sensor.
* Implement steering actuation when low-level CAN processing of steering command is fixed.
* Initialize CAN with high-level board code and incorporate in demo instead of separate CAN transceiver.
''' Medium Priority: '''
* Simulate ScanseSweep.
* Implement receiver board when board is fully fixed.
* Incorporate Elcano trike physics to simulated vehicle.
''' Low Priority '''
* Simulate camera sensor.
== 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 will never 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.
== 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.
* 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.
* Low-level processing of CAN messages for ID 0x350 is faulty. Bit shifting and produced output do not match the CAN guidelines on the wiki. This was fixed in the low-level code included in the simulator folder but not pushed to the Elcano Github repository.
== 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.

Simulator

2020-07-29T18:41:51Z

Mblackb: /* Components: */

= Elcano Carla Simulation External Specification =

CARLA <http://carla.org/> 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 benchmarking overall vehicle progress. The CARLA software can simulate a variety of road conditions such as traffic patterns, inclines, and weather as well as provide users control over vehicle parameters including weight, engine power, and aerodynamic properties.

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

[[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): ==
''' High Priority: '''
* Simulate gyro sensor
* Simulate accelerometer/magnetometer sensor.
* Simulate wheel angle sensor.
* Implement steering actuation when low-level CAN processing of steering command is fixed.
* Initialize CAN with high-level board code and incorporate in demo instead of separate CAN transceiver.
''' Medium Priority: '''
* Simulate ScanseSweep.
* Implement receiver board when board is fully fixed.
* Incorporate Elcano trike physics to simulated vehicle.
''' Low Priority '''
* Simulate camera sensor.
== 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 will never 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.
== 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.
* 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.
* Low-level processing of CAN messages for ID 0x350 is faulty. Bit shifting and produced output do not match the CAN guidelines on the wiki. This was fixed in the low-level code included in the simulator folder but not pushed to the Elcano Github repository.
== 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.

Simulator

2020-07-29T18:41:27Z

Mblackb: /* Components: */

= Elcano Carla Simulation External Specification =

CARLA <http://carla.org/> 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 benchmarking overall vehicle progress. The CARLA software can simulate a variety of road conditions such as traffic patterns, inclines, and weather as well as provide users control over vehicle parameters including weight, engine power, and aerodynamic properties.

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

[[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): ==
''' High Priority: '''
* Simulate gyro sensor
* Simulate accelerometer/magnetometer sensor.
* Simulate wheel angle sensor.
* Implement steering actuation when low-level CAN processing of steering command is fixed.
* Initialize CAN with high-level board code and incorporate in demo instead of separate CAN transceiver.
''' Medium Priority: '''
* Simulate ScanseSweep.
* Implement receiver board when board is fully fixed.
* Incorporate Elcano trike physics to simulated vehicle.
''' Low Priority '''
* Simulate camera sensor.
== 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 will never 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.
== 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.
* 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.
* Low-level processing of CAN messages for ID 0x350 is faulty. Bit shifting and produced output do not match the CAN guidelines on the wiki. This was fixed in the low-level code included in the simulator folder but not pushed to the Elcano Github repository.
== 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.

File:Router PCB Connections.jpg

2020-06-06T03:44:18Z

Mblackb: Mblackb uploaded a new version of File:Router PCB Connections.jpg

Simulator

2020-06-06T03:24:43Z

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

= Elcano Carla Simulation External Specification =

CARLA <http://carla.org/> is an open-source driving simulator. During Q4 2019 we will be developing 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 benchmarking overall vehicle progression. 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.

A go-between circuit board will 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. Connecting the simulation software to components on both the high and low level boards of the Elcano trike including lidar, sonar, throttle, and brake systems, will allow users to immediately see the results of adjustments to vehicle parameters and highlight physical aspects of the trike within the virtual simulation. This project will enable 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:Full_Block_Diagram_V2.jpg|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.

'''High Level CAN Demo'''
Simple demo code for high-level board that sends drive CAN messages repeatedly to the CAN Bus.

'''Elcano C2 LowLevel'''
Current Elcano low-level code with minor adjustments. Adjustments discussed in detail later in doc.

'''Router Board:'''
Code to be executed on the Arduino Due that functions as the router board. Routes drive commands from low-level to Carla. Also routes sensor data from Carla to high/low-level boards.

[[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): ==
''' High Priority: '''
* Simulate gyro sensor
* Simulate accelerometer/magnetometer sensor.
* Simulate wheel angle sensor.
* Implement steering actuation when low-level CAN processing of steering command is fixed.
* Initialize CAN with high-level board code and incorporate in demo instead of separate CAN transceiver.
''' Medium Priority: '''
* Simulate ScanseSweep.
* Implement receiver board when board is fully fixed.
* Incorporate Elcano trike physics to simulated vehicle.
''' Low Priority '''
* Simulate camera sensor.
== 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 will never 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.
== 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.
* 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.
* Low-level processing of CAN messages for ID 0x350 is faulty. Bit shifting and produced output do not match the CAN guidelines on the wiki. This was fixed in the low-level code included in the simulator folder but not pushed to the Elcano Github repository.
== 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.

File:Router PCB Connections.jpg

2020-06-06T02:52:53Z

Mblackb:

File:Carla Requirements.jpg

2020-06-06T02:49:19Z

Mblackb:

Simulator

2020-06-06T01:42:11Z

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

= Elcano Carla Simulation External Specification =

CARLA <http://carla.org/> is an open-source driving simulator. During Q4 2019 we will be developing 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 benchmarking overall vehicle progression. 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.

A go-between circuit board will 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. Connecting the simulation software to components on both the high and low level boards of the Elcano trike including lidar, sonar, throttle, and brake systems, will allow users to immediately see the results of adjustments to vehicle parameters and highlight physical aspects of the trike within the virtual simulation. This project will enable 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:Full_Block_Diagram_V2.jpg|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.

'''High Level CAN Demo'''
Simple demo code for high-level board that sends drive CAN messages repeatedly to the CAN Bus.

'''Elcano C2 LowLevel'''
Current Elcano low-level code with minor adjustments. Adjustments discussed in detail later in doc.

'''Router Board:'''
Code to be executed on the Arduino Due that functions as the router board. Routes drive commands from low-level to Carla. Also routes sensor data from Carla to high/low-level boards.

[[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
''' Setup: '''
* Firstly get everything connected. Use the USB cables to connect all your Arduinos to your computer. Make sure one Arduino (router board) has both programming and native ports connected to the computer if you wish to debug.
* Programming port is used to upload code and communicate with the router board, native port is used to debug to serial com.
* Screw in 3 wires for CAN hi, lo, and ground for the low-level board. Also connect the DB15 ribbon cable to the low level board.
* On the ribbon cable, attach a wire to the middle pin on the row with less pins. This connection will route to pin A1 on the router board. This is the throttle controller.
* On the low-level board, attach a wire to pin 37. This connection will route to pin 9 on the router board. This is the brake controller.
* Put your can transceiver in the breadboard and make sure it receives the proper voltage (Due has 3.3 and 5 V ports).
* Using the breadboard, connect the CAN hi, lo, and ground of the low-level board and the CAN transceiver.
* Using the Arduino IDE, find out which COM is associated with the router board.
* Run the ipconfig command through cmd on the windows computer running Carla.
* Replace the ip address and serial COM settings in the simulator.py file with the values just found.
* Make sure you have the following libraries installed for Arduino.
* CAN_BUS_SHIELD by Seeed-Studio
* [https://github.com/Seeed-Studio/CAN_BUS_Shield](https://github.com/Seeed-Studio/CAN_BUS_Shield)
* PID by Brett Beauregard
* [https://github.com/br3ttb/Arduino-PID-Library](https://github.com/br3ttb/Arduino-PID-Library)
* Pin Change Interrupt by Nico Hood
* [https://github.com/NicoHood/PinChangeInterrupt](https://github.com/NicoHood/PinChangeInterrupt)
* MCP48x2 DAC by Jonas Forsberg
* [https://github.com/SweBarre/MCP48x2](https://github.com/SweBarre/MCP48x2).
* Arduino Due Timer Interrupts by Ivan Seidel
* [https://github.com/ivanseidel/DueTimer](https://github.com/ivanseidel/DueTimer)
* Previous version of an Arduino Due CAN Bus library from [https://github.com/collin80/due_can](https://github.com/collin80/due_can) is used but the necessary files are included within the repository.
* Upload all codes to their corresponding Arduinos. The low-level code used for this demo is included in the repository. The high level board should be uploaded with the High_level_CAN_DEMO code. Before uploading high-level code, hardcode the CAN message you want being sent. CAN message structure can be found here; [https://www.elcanoproject.org/wiki/Communication](https://www.elcanoproject.org/wiki/Communication). The message being sent in the demo are drive instructions with CANID 0x350.
* Observe behavior in simulator. To change drive instructions in real-time, simply reupload high-level code with a new command and it should be reflected in the simulation.
* If car gets stuck, kill current simulator.py process and restart.

== 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): ==
''' High Priority: '''
* Simulate gyro sensor
* Simulate accelerometer/magnetometer sensor.
* Simulate wheel angle sensor.
* Implement steering actuation when low-level CAN processing of steering command is fixed.
* Initialize CAN with high-level board code and incorporate in demo instead of separate CAN transceiver.
''' Medium Priority: '''
* Simulate ScanseSweep.
* Implement receiver board when board is fully fixed.
* Incorporate Elcano trike physics to simulated vehicle.
''' Low Priority '''
* Simulate camera sensor.
== 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 will never 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.
== 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.
* 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.
* Low-level processing of CAN messages for ID 0x350 is faulty. Bit shifting and produced output do not match the CAN guidelines on the wiki. This was fixed in the low-level code included in the simulator folder but not pushed to the Elcano Github repository.
== 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.

Simulator

2020-06-06T00:45:15Z

Mblackb: Updating full block diagram to clarify fuzzy images and titles

= Elcano Carla Simulation External Specification =

CARLA <http://carla.org/> is an open-source driving simulator. During Q4 2019 we will be developing 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 benchmarking overall vehicle progression. 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.

A go-between circuit board will 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. Connecting the simulation software to components on both the high and low level boards of the Elcano trike including lidar, sonar, throttle, and brake systems, will allow users to immediately see the results of adjustments to vehicle parameters and highlight physical aspects of the trike within the virtual simulation. This project will enable 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:Full_Block_Diagram_V2.jpg|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.

'''High Level CAN Demo'''
Simple demo code for high-level board that sends drive CAN messages repeatedly to the CAN Bus.

'''Elcano C2 LowLevel'''
Current Elcano low-level code with minor adjustments. Adjustments discussed in detail later in doc.

'''Router Board:'''
Code to be executed on the Arduino Due that functions as the router board. Routes drive commands from low-level to Carla. Also routes sensor data from Carla to high/low-level boards.

[[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: '''
* 2 Arduino Due.
* 1 low-level board with Arduino Mega 2560.
* 1 male to female DB15 ribbon cable.
* 2 USB A male to USB Micro B male cables.
* 1 USB A male to B male cable.
* 1 computer capable of running Carla (only tested with Windows 10).
* 1 laptop/computer to interface between Carla and router board (optional, if computer can handle Carla easily you may want to just run this code on the same computer). Only tested with Windows 10.
* 1 CAN Transceiver board (MCP2550 3.3V preferred, not tested with 5V). Component used for demo; Waveshare SN65HVD230 CAN Board ([https://www.amazon.com/gp/product/B00KM6XMXO/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1](https://www.amazon.com/gp/product/B00KM6XMXO/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1)).
* 1 breadboard.
* 1 male to female wire, 10+ male to male wires.
''' Setup: '''
* Firstly get everything connected. Use the USB cables to connect all your Arduinos to your computer. Make sure one Arduino (router board) has both programming and native ports connected to the computer if you wish to debug.
* Programming port is used to upload code and communicate with the router board, native port is used to debug to serial com.
* Screw in 3 wires for CAN hi, lo, and ground for the low-level board. Also connect the DB15 ribbon cable to the low level board.
* On the ribbon cable, attach a wire to the middle pin on the row with less pins. This connection will route to pin A1 on the router board. This is the throttle controller.
* On the low-level board, attach a wire to pin 37. This connection will route to pin 9 on the router board. This is the brake controller.
* Put your can transceiver in the breadboard and make sure it receives the proper voltage (Due has 3.3 and 5 V ports).
* Using the breadboard, connect the CAN hi, lo, and ground of the low-level board and the CAN transceiver.
* Using the Arduino IDE, find out which COM is associated with the router board.
* Run the ipconfig command through cmd on the windows computer running Carla.
* Replace the ip address and serial COM settings in the simulator.py file with the values just found.
* Make sure you have the following libraries installed for Arduino.
* CAN_BUS_SHIELD by Seeed-Studio
* [https://github.com/Seeed-Studio/CAN_BUS_Shield](https://github.com/Seeed-Studio/CAN_BUS_Shield)
* PID by Brett Beauregard
* [https://github.com/br3ttb/Arduino-PID-Library](https://github.com/br3ttb/Arduino-PID-Library)
* Pin Change Interrupt by Nico Hood
* [https://github.com/NicoHood/PinChangeInterrupt](https://github.com/NicoHood/PinChangeInterrupt)
* MCP48x2 DAC by Jonas Forsberg
* [https://github.com/SweBarre/MCP48x2](https://github.com/SweBarre/MCP48x2).
* Arduino Due Timer Interrupts by Ivan Seidel
* [https://github.com/ivanseidel/DueTimer](https://github.com/ivanseidel/DueTimer)
* Previous version of an Arduino Due CAN Bus library from [https://github.com/collin80/due_can](https://github.com/collin80/due_can) is used but the necessary files are included within the repository.
* Upload all codes to their corresponding Arduinos. The low-level code used for this demo is included in the repository. The high level board should be uploaded with the High_level_CAN_DEMO code. Before uploading high-level code, hardcode the CAN message you want being sent. CAN message structure can be found here; [https://www.elcanoproject.org/wiki/Communication](https://www.elcanoproject.org/wiki/Communication). The message being sent in the demo are drive instructions with CANID 0x350.
* Observe behavior in simulator. To change drive instructions in real-time, simply reupload high-level code with a new command and it should be reflected in the simulation.
* If car gets stuck, kill current simulator.py process and restart.

== 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): ==
''' High Priority: '''
* Simulate gyro sensor
* Simulate accelerometer/magnetometer sensor.
* Simulate wheel angle sensor.
* Implement steering actuation when low-level CAN processing of steering command is fixed.
* Initialize CAN with high-level board code and incorporate in demo instead of separate CAN transceiver.
''' Medium Priority: '''
* Simulate ScanseSweep.
* Implement receiver board when board is fully fixed.
* Incorporate Elcano trike physics to simulated vehicle.
''' Low Priority '''
* Simulate camera sensor.
== 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 will never 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.
== 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.
* 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.
* Low-level processing of CAN messages for ID 0x350 is faulty. Bit shifting and produced output do not match the CAN guidelines on the wiki. This was fixed in the low-level code included in the simulator folder but not pushed to the Elcano Github repository.
== 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.

File:Full Block Diagram V2.jpg

2020-06-06T00:43:31Z

Mblackb:

Simulator

2020-05-28T05:05:07Z

Mblackb: /* Components: */

= Elcano Carla Simulation External Specification =

CARLA <http://carla.org/> is an open-source driving simulator. During Q4 2019 we will be developing 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 benchmarking overall vehicle progression. 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.

A go-between circuit board will 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. Connecting the simulation software to components on both the high and low level boards of the Elcano trike including lidar, sonar, throttle, and brake systems, will allow users to immediately see the results of adjustments to vehicle parameters and highlight physical aspects of the trike within the virtual simulation. This project will enable 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:Full_Block_Diagram.JPG|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.

'''High Level CAN Demo'''
Simple demo code for high-level board that sends drive CAN messages repeatedly to the CAN Bus.

'''Elcano C2 LowLevel'''
Current Elcano low-level code with minor adjustments. Adjustments discussed in detail later in doc.

'''Router Board:'''
Code to be executed on the Arduino Due that functions as the router board. Routes drive commands from low-level to Carla. Also routes sensor data from Carla to high/low-level boards.

[[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: '''
* 2 Arduino Due.
* 1 low-level board with Arduino Mega 2560.
* 1 male to female DB15 ribbon cable.
* 2 USB A male to USB Micro B male cables.
* 1 USB A male to B male cable.
* 1 computer capable of running Carla (only tested with Windows 10).
* 1 laptop/computer to interface between Carla and router board (optional, if computer can handle Carla easily you may want to just run this code on the same computer). Only tested with Windows 10.
* 1 CAN Transceiver board (MCP2550 3.3V preferred, not tested with 5V). Component used for demo; Waveshare SN65HVD230 CAN Board ([https://www.amazon.com/gp/product/B00KM6XMXO/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1](https://www.amazon.com/gp/product/B00KM6XMXO/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1)).
* 1 breadboard.
* 1 male to female wire, 10+ male to male wires.
''' Setup: '''
* Firstly get everything connected. Use the USB cables to connect all your Arduinos to your computer. Make sure one Arduino (router board) has both programming and native ports connected to the computer if you wish to debug.
* Programming port is used to upload code and communicate with the router board, native port is used to debug to serial com.
* Screw in 3 wires for CAN hi, lo, and ground for the low-level board. Also connect the DB15 ribbon cable to the low level board.
* On the ribbon cable, attach a wire to the middle pin on the row with less pins. This connection will route to pin A1 on the router board. This is the throttle controller.
* On the low-level board, attach a wire to pin 37. This connection will route to pin 9 on the router board. This is the brake controller.
* Put your can transceiver in the breadboard and make sure it receives the proper voltage (Due has 3.3 and 5 V ports).
* Using the breadboard, connect the CAN hi, lo, and ground of the low-level board and the CAN transceiver.
* Using the Arduino IDE, find out which COM is associated with the router board.
* Run the ipconfig command through cmd on the windows computer running Carla.
* Replace the ip address and serial COM settings in the simulator.py file with the values just found.
* Make sure you have the following libraries installed for Arduino.
* CAN_BUS_SHIELD by Seeed-Studio
* [https://github.com/Seeed-Studio/CAN_BUS_Shield](https://github.com/Seeed-Studio/CAN_BUS_Shield)
* PID by Brett Beauregard
* [https://github.com/br3ttb/Arduino-PID-Library](https://github.com/br3ttb/Arduino-PID-Library)
* Pin Change Interrupt by Nico Hood
* [https://github.com/NicoHood/PinChangeInterrupt](https://github.com/NicoHood/PinChangeInterrupt)
* MCP48x2 DAC by Jonas Forsberg
* [https://github.com/SweBarre/MCP48x2](https://github.com/SweBarre/MCP48x2).
* Arduino Due Timer Interrupts by Ivan Seidel
* [https://github.com/ivanseidel/DueTimer](https://github.com/ivanseidel/DueTimer)
* Previous version of an Arduino Due CAN Bus library from [https://github.com/collin80/due_can](https://github.com/collin80/due_can) is used but the necessary files are included within the repository.
* Upload all codes to their corresponding Arduinos. The low-level code used for this demo is included in the repository. The high level board should be uploaded with the High_level_CAN_DEMO code. Before uploading high-level code, hardcode the CAN message you want being sent. CAN message structure can be found here; [https://www.elcanoproject.org/wiki/Communication](https://www.elcanoproject.org/wiki/Communication). The message being sent in the demo are drive instructions with CANID 0x350.
* Observe behavior in simulator. To change drive instructions in real-time, simply reupload high-level code with a new command and it should be reflected in the simulation.
* If car gets stuck, kill current simulator.py process and restart.

== 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): ==
''' High Priority: '''
* Simulate gyro sensor
* Simulate accelerometer/magnetometer sensor.
* Simulate wheel angle sensor.
* Implement steering actuation when low-level CAN processing of steering command is fixed.
* Initialize CAN with high-level board code and incorporate in demo instead of separate CAN transceiver.
''' Medium Priority: '''
* Simulate ScanseSweep.
* Implement receiver board when board is fully fixed.
* Incorporate Elcano trike physics to simulated vehicle.
''' Low Priority '''
* Simulate camera sensor.
== 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 will never 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.
== 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.
* 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.
* Low-level processing of CAN messages for ID 0x350 is faulty. Bit shifting and produced output do not match the CAN guidelines on the wiki. This was fixed in the low-level code included in the simulator folder but not pushed to the Elcano Github repository.
== 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.

Simulator

2020-05-28T05:03:03Z

Mblackb: /* Components: */

= Elcano Carla Simulation External Specification =

CARLA <http://carla.org/> is an open-source driving simulator. During Q4 2019 we will be developing 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 benchmarking overall vehicle progression. 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.

A go-between circuit board will 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. Connecting the simulation software to components on both the high and low level boards of the Elcano trike including lidar, sonar, throttle, and brake systems, will allow users to immediately see the results of adjustments to vehicle parameters and highlight physical aspects of the trike within the virtual simulation. This project will enable 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:Full_Block_Diagram.JPG|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.

'''High Level CAN Demo'''
Simple demo code for high-level board that sends drive CAN messages repeatedly to the CAN Bus.

'''Elcano C2 LowLevel'''
Current Elcano low-level code with minor adjustments. Adjustments discussed in detail later in doc.

'''Router Board:'''
Code to be executed on the Arduino Due that functions as the router board. Routes drive commands from low-level to Carla. Also routes sensor data from Carla to high/low-level boards.

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

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

== 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: '''
* 2 Arduino Due.
* 1 low-level board with Arduino Mega 2560.
* 1 male to female DB15 ribbon cable.
* 2 USB A male to USB Micro B male cables.
* 1 USB A male to B male cable.
* 1 computer capable of running Carla (only tested with Windows 10).
* 1 laptop/computer to interface between Carla and router board (optional, if computer can handle Carla easily you may want to just run this code on the same computer). Only tested with Windows 10.
* 1 CAN Transceiver board (MCP2550 3.3V preferred, not tested with 5V). Component used for demo; Waveshare SN65HVD230 CAN Board ([https://www.amazon.com/gp/product/B00KM6XMXO/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1](https://www.amazon.com/gp/product/B00KM6XMXO/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&psc=1)).
* 1 breadboard.
* 1 male to female wire, 10+ male to male wires.
''' Setup: '''
* Firstly get everything connected. Use the USB cables to connect all your Arduinos to your computer. Make sure one Arduino (router board) has both programming and native ports connected to the computer if you wish to debug.
* Programming port is used to upload code and communicate with the router board, native port is used to debug to serial com.
* Screw in 3 wires for CAN hi, lo, and ground for the low-level board. Also connect the DB15 ribbon cable to the low level board.
* On the ribbon cable, attach a wire to the middle pin on the row with less pins. This connection will route to pin A1 on the router board. This is the throttle controller.
* On the low-level board, attach a wire to pin 37. This connection will route to pin 9 on the router board. This is the brake controller.
* Put your can transceiver in the breadboard and make sure it receives the proper voltage (Due has 3.3 and 5 V ports).
* Using the breadboard, connect the CAN hi, lo, and ground of the low-level board and the CAN transceiver.
* Using the Arduino IDE, find out which COM is associated with the router board.
* Run the ipconfig command through cmd on the windows computer running Carla.
* Replace the ip address and serial COM settings in the simulator.py file with the values just found.
* Make sure you have the following libraries installed for Arduino.
* CAN_BUS_SHIELD by Seeed-Studio
* [https://github.com/Seeed-Studio/CAN_BUS_Shield](https://github.com/Seeed-Studio/CAN_BUS_Shield)
* PID by Brett Beauregard
* [https://github.com/br3ttb/Arduino-PID-Library](https://github.com/br3ttb/Arduino-PID-Library)
* Pin Change Interrupt by Nico Hood
* [https://github.com/NicoHood/PinChangeInterrupt](https://github.com/NicoHood/PinChangeInterrupt)
* MCP48x2 DAC by Jonas Forsberg
* [https://github.com/SweBarre/MCP48x2](https://github.com/SweBarre/MCP48x2).
* Arduino Due Timer Interrupts by Ivan Seidel
* [https://github.com/ivanseidel/DueTimer](https://github.com/ivanseidel/DueTimer)
* Previous version of an Arduino Due CAN Bus library from [https://github.com/collin80/due_can](https://github.com/collin80/due_can) is used but the necessary files are included within the repository.
* Upload all codes to their corresponding Arduinos. The low-level code used for this demo is included in the repository. The high level board should be uploaded with the High_level_CAN_DEMO code. Before uploading high-level code, hardcode the CAN message you want being sent. CAN message structure can be found here; [https://www.elcanoproject.org/wiki/Communication](https://www.elcanoproject.org/wiki/Communication). The message being sent in the demo are drive instructions with CANID 0x350.
* Observe behavior in simulator. To change drive instructions in real-time, simply reupload high-level code with a new command and it should be reflected in the simulation.
* If car gets stuck, kill current simulator.py process and restart.

== 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): ==
''' High Priority: '''
* Simulate gyro sensor
* Simulate accelerometer/magnetometer sensor.
* Simulate wheel angle sensor.
* Implement steering actuation when low-level CAN processing of steering command is fixed.
* Initialize CAN with high-level board code and incorporate in demo instead of separate CAN transceiver.
''' Medium Priority: '''
* Simulate ScanseSweep.
* Implement receiver board when board is fully fixed.
* Incorporate Elcano trike physics to simulated vehicle.
''' Low Priority '''
* Simulate camera sensor.
== 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 will never 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.
== 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.
* 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.
* Low-level processing of CAN messages for ID 0x350 is faulty. Bit shifting and produced output do not match the CAN guidelines on the wiki. This was fixed in the low-level code included in the simulator folder but not pushed to the Elcano Github repository.
== 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.

File:RouterBoard2020B.jpg

2020-05-28T05:02:24Z

Mblackb:

File:RouterBoard2020A.jpg

2020-05-28T05:02:22Z

Mblackb:

Low Level

2020-05-27T23:30:23Z

Mblackb: /* LowLevel v3.1 PCB */

=LowLevel v3.1 PCB =

==Functionality: ==

* The LowLevel Board (LLB) is a daughter board (shield) for an Arduino Mega microcontroller. It implements drive-by-wire, turning a trike into a CAN-bus based vehicle compatible with commercial self-driving equipment. The LLB communicates over the CAN bus with the higher-level autonomous system or manual control from the receiver system. It directly manages the actuators: the throttle to the motor, the turning servo, and the brakes.

* Motion directives are received on a CAN bus interface, processed, and articulated.
* System status (turn angle, wheel linear velocity) is reported back to CAN bus.

* LLB v3.x has the following interfaces:
** One CANbus channel on two connectors; a DB9-M and a three-pin screw terminal. The board includes a 120 ohm terminating resistor.
** X3 Motor (DB-15M): Interface to E-bike controller
*** Analog voltage (approximately 0v to 4v) output to hub motor throttle
*** Digital outputs for activating reverse and regenerative braking.
*** PWM output for PWM-operated braking (no longer used)
*** Analog inputs for hall sensor feedback from motor controllers supporting this feature. These inputs are NOT 5V SAFE. They absolutely require external supporting circuitry.
*** A few spare connections for future expandability, such as a second DAC output and one digital GPIO.

DETAILS > [[DB15M]]

** Steering Header (RJ45):
*** Two sets of pins to support analog potentiometers (5v, signal input, ground) giving angle of front wheels
*** One PWM output (with its own ground) to drive the steering actuator.
*** This cable is broken out into its component signals using an RJ45 patch jack, mounted near the steering actuator.
** X4 (ODO): Cyclometer (reed switch) input jack. This is pulled high by default, and brought low when the magnet passes the sensor.
** High current pluggable terminal for solenoid brakes:
*** Connections for ground, 12v, and 24v.
*** Two relay outputs to solenoids: on/off and 12/24V.

* The LowLevel runs on 5V power, and provides outputs for sensors. Note that the Arduino Mega 2560's regulator has a fairly low current limit, and should not be used for any significant current supply. The Arduino's DC input jack accepts 12V, and its USB port may be connected to a typical USB power supply. The 12V is provided by a DC-DC converter from the main battery (36 to 50V).

==Image: [[File:LowLevel.JPG|1000px]] ==

NEXT > [[High Level]]

=LowLevel v2.1 PCB =

==Functionality: ==

* Version 2.1 used UART serial connections to other boards instead of the CAN bus. It interprets messages from higher-level autonomous systems or manual controls (RC, joystick). It directly manages the state of the actuators; the hub motor, the turning servo, and the brakes.

* Depending on the current firmware or operating mode, motion directives are received on one of three interfaces;
** [[ElcanoSerial]] from the combined [[PilotPage | C3]]/[[PlannerPage | C4]]/[[NavigatorPage | C6]] High Level board
** RC receiver
** Manual Joystick

* LLB v2.x has the following low-level interfaces:
** X2 Cruise (DB-25F) - [[ElcanoSerial]] messages from High Level.
** X3 Motor ([[DB15M | DB-15M]]): Analog voltage (0,4v) output hub motor.
** X1/X5 Turn Sensors (RJ45): SPI wheel angle sensor digital inputs. (Digital urn sensors were never implemented.)
** X4 (ODO): Cyclometer (reed switch) input jack. Board layout was incorrect. This signal needs to be jumpered to Arduino pin D2.
** JP9 (8 pin): Joystick analog input signals.
** JP12 (3 pin): Pulse output signal to steer.
** JP11 (3 pin): Pulse output signal to apply main brakes. (No longer used)
** JP5 (4 pin): Left wheel angle sensor analog input. (Little used since it covers 360 degrees and is less accurate)
** JP6 (4 pin): Right wheel angle sensor analog input. (Trike prefer this, since it is +/- 30 degrees, and more accurate)

* LLB v3.x makes significant wiring changes:
** Removes the ElcanoSerial connection and the DB-25F.
** Removes JP9, joystick analog inputs.
** Removes headers used to interface the RC receiver.
** Adds one CANbus interface on a DE-9F socket. For legacy compatibility UART serial is be available on this interface as well.

=LowLevel v1.0 PCB =

* The first version of the LLB was called MegaShieldDB. It had similar functionality, but different connectors. It had five DB connectors.

NEXT > [[High Level]]

Low Level

2020-05-27T23:30:05Z

Mblackb: /* LowLevel v3.1 PCB */

=LowLevel v3.1 PCB =
.

==Functionality: ==

* The LowLevel Board (LLB) is a daughter board (shield) for an Arduino Mega microcontroller. It implements drive-by-wire, turning a trike into a CAN-bus based vehicle compatible with commercial self-driving equipment. The LLB communicates over the CAN bus with the higher-level autonomous system or manual control from the receiver system. It directly manages the actuators: the throttle to the motor, the turning servo, and the brakes.

* Motion directives are received on a CAN bus interface, processed, and articulated.
* System status (turn angle, wheel linear velocity) is reported back to CAN bus.

* LLB v3.x has the following interfaces:
** One CANbus channel on two connectors; a DB9-M and a three-pin screw terminal. The board includes a 120 ohm terminating resistor.
** X3 Motor (DB-15M): Interface to E-bike controller
*** Analog voltage (approximately 0v to 4v) output to hub motor throttle
*** Digital outputs for activating reverse and regenerative braking.
*** PWM output for PWM-operated braking (no longer used)
*** Analog inputs for hall sensor feedback from motor controllers supporting this feature. These inputs are NOT 5V SAFE. They absolutely require external supporting circuitry.
*** A few spare connections for future expandability, such as a second DAC output and one digital GPIO.

DETAILS > [[DB15M]]

** Steering Header (RJ45):
*** Two sets of pins to support analog potentiometers (5v, signal input, ground) giving angle of front wheels
*** One PWM output (with its own ground) to drive the steering actuator.
*** This cable is broken out into its component signals using an RJ45 patch jack, mounted near the steering actuator.
** X4 (ODO): Cyclometer (reed switch) input jack. This is pulled high by default, and brought low when the magnet passes the sensor.
** High current pluggable terminal for solenoid brakes:
*** Connections for ground, 12v, and 24v.
*** Two relay outputs to solenoids: on/off and 12/24V.

* The LowLevel runs on 5V power, and provides outputs for sensors. Note that the Arduino Mega 2560's regulator has a fairly low current limit, and should not be used for any significant current supply. The Arduino's DC input jack accepts 12V, and its USB port may be connected to a typical USB power supply. The 12V is provided by a DC-DC converter from the main battery (36 to 50V).

==Image: [[File:LowLevel.JPG|1000px]] ==

NEXT > [[High Level]]

=LowLevel v2.1 PCB =

==Functionality: ==

* Version 2.1 used UART serial connections to other boards instead of the CAN bus. It interprets messages from higher-level autonomous systems or manual controls (RC, joystick). It directly manages the state of the actuators; the hub motor, the turning servo, and the brakes.

* Depending on the current firmware or operating mode, motion directives are received on one of three interfaces;
** [[ElcanoSerial]] from the combined [[PilotPage | C3]]/[[PlannerPage | C4]]/[[NavigatorPage | C6]] High Level board
** RC receiver
** Manual Joystick

* LLB v2.x has the following low-level interfaces:
** X2 Cruise (DB-25F) - [[ElcanoSerial]] messages from High Level.
** X3 Motor ([[DB15M | DB-15M]]): Analog voltage (0,4v) output hub motor.
** X1/X5 Turn Sensors (RJ45): SPI wheel angle sensor digital inputs. (Digital urn sensors were never implemented.)
** X4 (ODO): Cyclometer (reed switch) input jack. Board layout was incorrect. This signal needs to be jumpered to Arduino pin D2.
** JP9 (8 pin): Joystick analog input signals.
** JP12 (3 pin): Pulse output signal to steer.
** JP11 (3 pin): Pulse output signal to apply main brakes. (No longer used)
** JP5 (4 pin): Left wheel angle sensor analog input. (Little used since it covers 360 degrees and is less accurate)
** JP6 (4 pin): Right wheel angle sensor analog input. (Trike prefer this, since it is +/- 30 degrees, and more accurate)

* LLB v3.x makes significant wiring changes:
** Removes the ElcanoSerial connection and the DB-25F.
** Removes JP9, joystick analog inputs.
** Removes headers used to interface the RC receiver.
** Adds one CANbus interface on a DE-9F socket. For legacy compatibility UART serial is be available on this interface as well.

=LowLevel v1.0 PCB =

* The first version of the LLB was called MegaShieldDB. It had similar functionality, but different connectors. It had five DB connectors.

NEXT > [[High Level]]

Main Page

2020-04-07T00:18:16Z

Mblackb: /* Using Git and GitHub */

= 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 are currently working on our first two prototypes which are now in the form of tricycles. With the use of affordable microcontrollers, such as the Arduino Mega 2560 and Raspberry PI, we are working towards creating Autonomy for anyone to rebuild anywhere, and that 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 have the ability to make it available for anyone who desires furthering their knowledge or simply finding a safer way to work.

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

== [[Low Level]] ==
How the Low Level system uses inputs to control actuators to steer, move, and stop the vehicle.

== [[High Level]] ==
How the High Level system uses stored maps and inputs from navigational sensors to formulate movement instructions sent to Low Level.

== [[RemoteControl]] ==
Human control of trike movements through Low Level using hardware connected to Low Level by a radio communication link (drive by radio). Includes on-board controls (drive by wire).

== [[ Simulator]] ==
Using Open-source CARLA platform with a go-between board allows simulation.

== [[SensorsPage]] ==

=== [[SteeringSensor]] ===
The front wheel angle detector.

=== [[Sonar]] ===
How the sonar subsystem connected to High Level works.

=== [[Lidar]] ===
How the lidar subsystem connected to High Level works.

=== [[ Camera]] ===
How the camera and vision subsystem connected to High Level works.

== [[ActuatorPage]] ==

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

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

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

== Elcano Project Main Website ==
* [//www.elcanoproject.org]

Main Page

2020-04-07T00:18:09Z

Mblackb: /* Using Git and GitHub */

= 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 are currently working on our first two prototypes which are now in the form of tricycles. With the use of affordable microcontrollers, such as the Arduino Mega 2560 and Raspberry PI, we are working towards creating Autonomy for anyone to rebuild anywhere, and that 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 have the ability to make it available for anyone who desires furthering their knowledge or simply finding a safer way to work.

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

== [[Low Level]] ==
How the Low Level system uses inputs to control actuators to steer, move, and stop the vehicle.

== [[High Level]] ==
How the High Level system uses stored maps and inputs from navigational sensors to formulate movement instructions sent to Low Level.

== [[RemoteControl]] ==
Human control of trike movements through Low Level using hardware connected to Low Level by a radio communication link (drive by radio). Includes on-board controls (drive by wire).

== [[ Simulator]] ==
Using Open-source CARLA platform with a go-between board allows simulation.

== [[SensorsPage]] ==

=== [[SteeringSensor]] ===
The front wheel angle detector.

=== [[Sonar]] ===
How the sonar subsystem connected to High Level works.

=== [[Lidar]] ===
How the lidar subsystem connected to High Level works.

=== [[ Camera]] ===
How the camera and vision subsystem connected to High Level works.

== [[ActuatorPage]] ==

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

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

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

== Elcano Project Main Website ==
* [//www.elcanoproject.org]