2024 - 2026 Electrical SRR Presentations

Date

Feb 3, 2024

Attendees

• @Sidharth Babu

• lots of ppl 

Agenda 

Presentation Notes

Sidharth Babu:

Data Acquisition:

Purpose of the system:

• Primarily a telemetry/race strategy team

• Goal is to monitor and report on the mechanical and electrical systems

Sensors:

• We want to add an additional suite of sensors to get extra data

• Currently:

  • IMU

  • Airflow

  • Temperature

  • TPMS

• New sensors:

  • Brake Pedal potentiometer

  • Steering position sensor

  • Atmospheric pressure (barometer)

  • Humidity

• New sensors will help inform our new models and lead to more accurate race strategy simulation.

Telemetry:

• What do we want to solve:

  • Collect useful signals for race strategy

  • Monitor vehicle health in real time

• Why:

  • Sufficient information capture is necessary for ML model

  • ... Went a bit fast here

Dashboard:

• What:

  • We want to add additional features for visualizing fault data as well as better battery health monitoring

• Why:

  • missed this, bit fast

Race Strategy:

• Purpose:

  • Optimize performance using incoming vehicle and environmental data

  • 2 main goals:

    • Output optimal vehicle speeds ever ~3 seconds

    • ...

• What are we modeling:

  • Various energy metrics as well as mechanical characteristics

  • Road-Related and Weather-related environmental simulations

Q&A / Notes

• Why IMU sampled faster than steering?

  • Steering changes slower than IMU data

• How do we model the laps themselves?

  • Replacing random track generation with actual topological data pulled from race tracks

• Why is the brake pedal sensor under Data Acq and not controls? 

  • Depends on whether or not controls wants to use that data, we're just measuring brake for data points

    • Controls does need it, so maybe they take it and it can transmit it over CAN

• Are we storing CAN messages anywhere for post-processing?

  • We have an InfluxDB that has the ability to store them, so we can make this available for other teams as needed

• Pressure sensor for downforce where are we mounting this:

  • Maybe rear of the car? 

  • Jacob: Get at least two, you need that for pressure differential 

• Are you pulling data from array?

  • Yes

• Is adding this many sensors a bandwidth strain on the CAN network?

  • We have a separate CAN network planned just for our sensors (TelemetryCAN)

• Are we sure that there is a link between humidity and electrical performance?

  • Initial research suggests that it does

• For the vehicle simulation itself have you looked at different solvers?

  • Not really

  • Jacob: Look into RK4 as an equation solver for the vehicle

• Have you thought about using dashboard for Real-time debugging for other systems?

  • We could add this, doesn't seem like it would be too difficult

• Look into RTK Station for highly accurate position monitoring

Controls:

• This presentation showcases what our planned new features and the relevant regulations are

• Main focuses: efficiency, safety, ease of use

New controls features:

• Currently: Regen braking, gears (direction), 1wd, cruise control (v1), 1-pedal drive (v1)

• Want to move towards: 2wd, software differential

Cruise control:

• Currently not ergonomic to use

• Want to improve the control flow

One Pedal Mode:

• Currently three discrete zones (regen brake, dead zone, accel)

• We want to move to a hybrid range where regen and accel are mixed throughout the pedal ROM

Display modifications

• Current features: single static page, no control / navigation

• New features: Multiple pages (have got be organized), Blind spot detection (we don't have side mirrors right now)

Interior Modifications

• We want to move buttons onto the steering wheel itself to make it a little easier to control.

New Controls hardware:

• Moving to a system on a module architecture where the shared core is common and quickly replaceable

• We are going to have a controls specific SOM just for our system along with the standardized leader SOM

Controls Q&A

• How complex is / what is a software differential?

• How do you propose to navigate the multiple pages easily? Touchscreen might be tough? 

  • Steering wheel buttons

• blind spot monitoring - how will this be monitored

  • distance sensor detects object within certain threshold and lights something up

  • idea for buzzer to indicate something is in the blindspot to reduce latency

• separate display board from Controls? via board that uses CAN instead of using UART

  • "not a terrible idea" - Ishan. would be faster

• who made the decision to switch to two-wheel drive/what is the justification

  • increases efficiency of motor performance

  • mechanical srr coming after current gen is finished

• where is dashboard/display located?

  • display is to the right of the driver

• will the display be directly on the Controls leaderboard? does it use USART?

  • top contender will use UART

• steering wheel inputs will use GPIO?

  • yes

• where will blind spot detection be?

  • ~back left of car

• pedal control

  • current pedal has thresholds for regen breaking, constant speed, and accel

  • new one pedal mode is more intuitive

• question about camera

  • backup camera will not be on display because driver needs to see it at all times

• how to coast

  • ideally use cruise control

  • one pedal mode should be separate mode, probably won't be used as much with two-wheel drive

  • enter normal mode to coast

• how to control motor

  • currently: mapped to current

  • next-gen mapped to voltage, provide current limit

• is there a difference between daughterboard and som?

  • daughterboard is for leader som

• do you have enough GPIO pins

  • need to check before PDR

  • can use GPIO extension

• still planning on implementing sim board?

  • sim board is only for testing purposes

  • could possibly add to display but no plans right now

  • might be hard to do with all buttons on steering wheel

• scroll wheel instead of potentiometer?

  • might slip too easily while driving

Power Generation:

Notes:

• Relevant regs

  • only Commercially available cells

  • 4m^2 total solar array

  • no more than 6 types or sizes of cells

• What are we solving

  • Our current cells are not the best

  • If we switch to better cells, we have to change the MPPTs

  • Blackbody A (telemetry) has design flaws and needs to be improved 

• The Array

  • We currently use Maxeon Gen 2/3 cells to Maxeon Gen 6/7 cells

  • Current cells are not being manufactured, which makes it more expensive than newer cells

  • Newer cells are larger single cells, and are more efficient at generating solar power

  • Form factor changes result in MPPT changes however

• Power Transfer

  • Maxeon Gen 6s and 5s are diff than 2/3, gen 7 are same size as 2/3

  • Larger sizes mean that the MPPTs need to be beefed up with bigger inductors and capacitors

  • The array current doubles, so we need to scale the existing design with improved hardware

• Telemetry

  • Blackbody A tracks the array's temperature and irradiance

  • SPI is just busted, we bit-bang an SPI protocol for this gen as a temporary fix

  • We need to actually fix the SPI

  • Instead of using multiple identical RTD chips, we're just going to use one with a decoder to profile the array, allowing for a cheaper and smaller board 

Q&A:

• Is profiling the RTDs serially (8 in a row using decoder) instead of 8 in parallel okay? Do we need real-time there?

  • We're sampling the serial stream fast enough to where it should not really matter.

• How much more current is expected to come out of the new array?

  • Nearly double the current coming out of the array

• Going to run sims to design the MPPTs, what sims?

  • We have the sims already written, they're effectively just sims to help determine Buck Converter topology specifications

• How many irradiance sensors are ideal?

  • 5 is roughly the ideal

  • Gut instinct, this is based on just shape of the aeroshell

• How do the irradiance sensors actually help you?

  • They are going to integrate into the MPPT algorithm to indicate when we need to do total rescans

• Do new cells affect lamination process?

  • Not significantly, just need to change SOPs

Power Systems:

• Goals:

  • Improve Pack safety & Reliability

  • Accelerate Battery mfg process

  • Optimize power usage and reduce waste

• Relevant Regulations:

  • Mainly define where we can send power from what source

• Power Distribution:

  • Current Design:

    • All LV system are always powered up using the same source

  • Concerns / Areas of improvement

    • Power board redesign to avoid logic operations at 12v

    • High current draw at 12v

• Battery Pack Design:

  • Current failures:

    • braided wires are too exposed and stiff

    • solder joints are unreliable and prone to failure

    • voltage taps and thermistor wires are extremely messy

    • emphasis was on modularity and cost efficiency over safety and reliability

• Batt manufacturing:

  • Current Failures:

    • Too many cells to charge and each cell takes too long to charge individually at. At current pace, it would take >1 year to characterize every cell

    • Unsafe charging setup, can lead to safety risk which slows down the problem

    • After characterizing the cells, we get cell curves. Matching these manually is not the optimal way to bin them

• Ignition Switch Redesign:

  • Signal path is long and goes through unnecessary middlemen. This adds unnecessary points of failure

• Questions

  • Benefits from sampling individually vs per box?

    • Batteries from similar boxes seem to perform similarly

    • Sample ~30 total to get an idea of variability

BPS:

• Current Gen:

  • Hardware: 

    • Central Leaderboard

    • Daisy-chained minion boards that talk through isoSPI (measures voltage and temperature)

    • Amperes board (measures current)

    • Problems:

      • Chip scarcity for critical chips

      • isoSPI has a long wakeup time, and is a major bottleneck for sampling

  • Software:

    • Micrium RTOS 

    • Periodically samples voltage, current, and temp

    • respond to unsafe condition by closing HV system and maxing fan speed

    • Send Telemetry over CAN

    • problems

      • FreeRTOS > Micrium for SP32

• Plans for Next Gen:

  • Goals:

    • Maintain all features

      • New hardware with more common protocols 

      • Standardize software stack with other systems

      • Transition to a SOM architecture for hardware

    • Planned New features

      • Monitor frame and HV isolation 

      • Contactor weld detection on array contactor

      • Switch to CAN from isoSPI

      • Tach feedback from fans

      • Bluetooth debug board - nice to have.

  • Hardware:

    • Bespoke SOM boards rather than complete leaderboard:

    • Leaderboard becomes a Leader SOM with a daughter

    • Amperes board becomes a Peripheral SOM with a specific daughter

    • Volt Temp board becomes a Peripheral SOM with a specific daughter

    • SOM architecture cuts down on hardware validation load

    • Isolate frame, HV

  • Software:

    • Standardize with rest of the team

    • Accurate state of charge

    • Fault recovery

    • USB / CAN Bootloader

    • Active battery balancing

    • USB, CAN bootloader - Debug/reliability

    • Contactor weld detection

    • CAN → isoSPI

    • Fan Tachometer feedback

Q&A

• How are we implementing active battery balancing?

  • Not active as in continual

  • Active as in we can turn it on and off

  • This is simpler than the commercial systems

• How are we implementing SOC monitoring?

  • Coulomb counting is a more standard method, but has some drawbacks 

  • Be careful on scope, might not be achievable

  • Based on a paper that claims to be cell-agnostic

• Can you define battery health?

  • Mainly affects discharge characterstics

• Fault recovery?

  • No fault recovery, reboot car for critical faults