Date

03 Feb 2024

Attendees

Sidharth Babu
lots of ppl

Agenda

Time	Item
10 AM - 10:10 AM	Data Acquisition SRR presentation
10:10 AM - 10:30 AM	Data Acq SRR Q&A
10:30 AM - 10:40 AM	Controls SRR
10:40 AM - 11:00 AM	Controls Q&A
11:00 AM - 11:10 AM	Power Gen SRR
11:10 AM - 11:30 AM	Power Gen Q&A
11:30 AM - 11:40	Power Sys SRR
11:40 AM - 12:00	Power Sys Q&A
12:00 AM - 12:10	BPS SRR
12:10 AM - 12:30	BPS Q&A

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

Browser not supported