SolarCarECU

UVA Solar Car Team Electrical Team - Embedded System Subgroup

The embedded system sub-group focuses on developing the embedded system for the solar car that controls the CAN bus, driver interface and BPS (Battery Management System). This repository contains all of the design files necessary to implement the electrical control systems necessary for the Solar Car project.

ECU

The ECU is the primary controller for the majority of systems, including motor control, battery monitoring, driver interface, and MPPT interface. The PCB contains circuitry for interfacing buttons and switches on driver interface, high-current lights and horn, as well as

!important! Not all pins are 12V or even 5V compatible. Certain pins connect directly to the teensy with no protection.

• signal: name of IO signal in Eeschema (may or may not also be the net name)
• voltage: the voltages the pin is designed for
• direction: The direction of the signal relative to the ECU
• description: description of the signal

User interface input (control)

These pins are used for allowing the driver to command the vehicle. All but the UART pins are 12V logic. To reduce the number of pins required on the MCU, we chose to wire 3 way position switches such that the end contacts connect to the rails and the center contact floats with a resistor divider to ensure the voltage is approximately VCC/2 when the switch is in the middle position.

Serial interface IO

These pins are used for communicating with various peripherals, components, and subsystems within the car. CAN0 is reserved for the BMS, while CAN1 is used for all less critical systems. UART pins are for future use.

Lights and Horn

These pins are capable of high currents (up to 5A distributed among the 4 outputs)

Motor control

The motor can be interfaced via UART, CAN, and GPIO. As of now, we do not have any API or knowledge of how to interface the motor over UART, as it is not documented. However it is possible to decompile the android app and reverse engineer whatever the app implements. For now, we are using CAN to retrieve important parameters from the motor such as voltage, current, RPM, throttle, and error codes. The motor only outputs messages over CAN, and does not interpret them.

The table below holds true for both MOTOR_R* and MOTOR_L* signals. NOTE: all node names in the table below are preceded with MOTOR_R* and MOTOR_L*!

Software

At the moment we have bits and pieces of code written but no unified project as of yet. The CAN repository contains experemantal code for interfacing the CAN peripherals on the Teensy as well as development towards a motor driver. The completed motor driver will eventually be refactored into this repo.