2024 - 2026 Electrical SRR Presentations

Date

03 Feb 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