Vehicle Control Unit (VCU)
Status | Firmware validation |
Owner | @Jacob Guidry @Tony Chen |
|---|---|
Approver | @Ravi Shah |
Due date | May 17, 2025 |
GitHub | |
BOM | TBD |
Timeline:
Requirements/Considerations - 4/7/2025
Component Selection - 4/12/2025
Initial Schematic - 4/16/2025
Initial Layout - 4/23/2025
Rev. A Ordered - 4/26/2025
Firmware/Testing - idk
Active Precharge Testing w/ Bulk Cap next workday
All enable out, precharge ready inputs and sense inputs work
Description/Purpose
controls the vehicle…
Requirements
Contactor Control
Array/Array Precharge → BPS Leader (in BB)
Separate board sends isolated, LV signals with comparison values (taps) for precharge resistor
Motor/Motor Precharge → VCU (in PDE)
Separate board sends isolated, LV signals with comparison values (taps) for precharge resistor
Fail open - AND gate between software/hardware comparison
Hardware - current op-amp comparison
Software - isolated ADC
Precharge threshold at 91%, lower threshold of 81% for hysteresis
Integration with driver controls
Motor Control
Bridge between CarCAN & MotorCAN
Translate pedal state, gear state to drive commands
Pedal board on CarCAN, display on CarCAN
Moore FSM for motor control, regen, cruise
VCU will run this FSM
Regen
What to expect from driver?
Selection of regen amount
Based on empirical testing
As a function of current speed/conditions
Regen at setpoint (ideally 100%) when accelerator/brake aren’t pressed
At low speeds → will not regen, driver must brake mechanically
Send display message when regen is ineffective (need testing data)
When brake is pressed - keep regen enabled? will just be less effective since no line lock
What edge cases + how to handle?
BPS close to charging temp threshold → depends on current
SoC too high - 95% (dependent on conditions)
Messages BPS ↔︎ VCU
BPS sends regen_disable message, if VCU doesn’t ACK, BPS trip
VCU sends global regen_state message, if regen_state still on after BPS sends disable + delay, BPS trip
If we continue regen past a certain point (97%), BPS sends regen_disable → must wait for SoC <95% to regen again
Ignition Sequence
Off, Motor, Array states
Controls Leader waits until IGN switch is back to OFF state before broadcasting array or motor
Prevents starting in motor/array state
Debugging
For both BPS Leader and VCU - ESP32 connected to LSOM UART for necessary debug messages
Wifi for connection - test with actual enclosures for signal
Electrical
LSOM - what peripherals/pins needed?
two CANs
UART
GPIO
Motor Drive
Motor Sense
Motor Precharge Drive
Motor Precharge Sense
Motor Precharge Ready
Additional ICs/circuits for anything?
On precharge boards (2x) isolated ADCs
Mechanical
Packaging
small
more square is better - spread out around LSOM
black, gold plated, high def silks
no monkey bullshit
Power Distribution Enclosure (PDE)
sizing/space??
Connections
CarCAN In/Out, MotorCAN Out (terminating end)
Signals from precharge board
Two ADC outputs
Signal from hardware comparator output
12V - use 12V tolerant ICs
one connector on board
Two contactor 4 pin
drive+, drive-, sense+, sense-
Application Note
how does this board integrate with others + any harnessing/bringup considerations. anyone should be able to read this and integrate this board into the electrical system
Context
Location of the board: Power Distribution Enclosure (vertically behind driver)
Connection List
# | Name | Type | Ideal Voltage |
|---|
# | Name | Type | Ideal Voltage |
|---|---|---|---|
J1 |
|
|
|
J2 |
|
|
|
J3 |
|
|
|
J4 |
|
|
|
J5 |
|
|
|
Main
Schematics
every subsheet here
Circuit Components
all uniques (non-passives) in BOM + rationale for selection
Layout
PCB
3D Model
Firmware
Drivers
High-Level (Block Diagram)
Test Plan
Solder on connectors
Verify components are properly soldered
blinky for every led one at a time
enable disable contactor signal
able to read adc
Test RPP
input 0-32v to test full range of RPP
0-22v UV (theres no UV lockout, just testing it)
yeah nothing happens
22-29 operating
29+ OV
Test ESP
power over usb and test flashing
ravi flashed a blinky
test bluetooth (to be developed by dylan )
send uart over esp and bluetooth (to be developed by dylan)
uart broken out through logic analyzer connector
Test contactors
open and close contactors, monitor sense signals
simulate precharge thresholds
simulate precharge thresholds using precharge board (perhaps also bomb board)
send receive CAN
get dummy board to send controls can messages
send car state and contactor messages
FSM works for simulated can messages
integrate FSM and precharge firmware
testbench testing
connect to moco interface
connect to moco as well
motor spin
Meetings:
Attendees: @Lakshay Gupta @Ravi Shah @Oscar Portillo @Akshay Gaitonde @Madeleine Lee @Adiv Padgilwar @Matthew King @Tony Chen @Mikail Sadic @Frank Li @Parthiv Shah @connor
Current FSM accounts for basic HV control + cruise. Need a new FSM for regen.
Suggested Implementation (Lakshay): BPS has a regen state message. VCU constantly sends its own state message. If the two conflict for an extended period of time, fault the car.
Regen can cause bad things to happen when switching from charge to discharge at low SoC.
We should slowly ramp up current rating for regen when foot is off pedal.
Jackstand detection: Sasha (the goat) said that if we regen on jackstands, we will break a bunch of stuff.
Detection should account for speed of motor and current used on MoCo. If speed is high and current is low, stop
Ride height sensor? @Matthew King and @Parthiv Shah to confirm with Dynamics on plans for that / neccesity
Hardware switch + software support for profinity stuff
Motor Interface Board:
Cooling for MoCo + temp sensing
Power Regulation + protection
Regen Characterization:
Characterization on Daybreak is not terribly helpful given how different Solar McQueen will be.
Wiring of 3 Phase fucks up motor CAN.
Conclusions:
Mostly reuse @Oscar Portillo 's FSM and add regen. Have a meeting to review that.
@Adiv Padgilwar will be working on new FSM. FSM to be done in 2-3 weeks (initial review on Sept 11th, finalized by Sept 18th)