Agenda (+15min for pre-lunch presentations)
Time | Item |
|---|---|
10:00 - 11:00 | Controls PDR |
11:00 - 12:00 | Controls Q&A |
12:00 - 12:20 | 20-minute break |
12:20 - 1:00 | BPS PDR |
1:00 - 1:20 | BPS Q&A |
1:20 - 2:35 | Lunch Break |
2:35 - 3:35 | Power Systems PDR |
3:35 - 4:15 | Power Systems Q&A |
4:20 - 4:30 | 10-minute break |
4:30 - 5:30 | Data Acquisition PDR |
5:30 - 6:00 | Data Acquisition Q&A |
Presentation Materials
Presentation Recordings
Q&A
Notes from Matthew Mekha on LHRE:
Controls
Data Acquisition
Controls Q&A
Why different SOM versions?
Power consumption/microcontroller difference between leader and peripherals
Are the 2 SOM versions compatible?
no, but leader and peripheral SOMS are still compatible between systems
Any deadlines that you want to establish?
Motor Control timing at a certain frequency
Blindspot sensor polling
Event-driven Queue?
(I missed this part, blame Sid)
How bright is the display? bright enough for sunlight?
Have not looked into it but will make sure it works outside at multiple angles
Raspberry Pi for display? - how does that fit into SOM architecture?
The display is not linked up to CAN network, Pi talks to leader, serial directly to leaderboard, which should be ok since they are close together
Why not just use a peripheral SOM and an SPI display instead of a Pi?
PI has more functionality (Many libraries), but still low power consumption
Why 1 motor?
Jacob
Need to characterize to make sure we can still drive up hills
Reach out to other teams
Lots of buttons on the steering wheel → lots of wires to the steering wheel
Will possibly use a GPIO expander
Be careful of GPIO even with short wires
Add horn button
Add chase car communication radio button
Look through regs for additional buttons(All regs that could be relevant not just controls/electrical)
Implement another daughterboard on the steering wheel?
Boards physically small
Iron out button placement with Ergo soon for testing for useability/accidental activation/enough room(spacing)
Consider if having +/- CC velocity buttons worth space/complexity
ABS?
Potential for the future, but mechanical would need to implement electronic control of fluids
Replace blindspot TOF/ultrasonic with blindspot cameras?
Power draw is a lot higher
The driver still needs to look
How did you choose the blindspot sensors?
Most commercial use radio sensors - too expensive
Some use ultrasonic
A lot of these are too expensive
Ultrasonics are best used in low-speed applications when moving directly towards/away from objects, should test
Why 2?
It's worth it to buy better sensors
Also, be careful about infrared
May just want to use a camera - passes the driver more information
Maybe even just use a 360/ultrawide FOV camera to cover both blindspot and rear view
Change power distribution strategy to output 5V, pass 12V to MCU first, then to leader package
Consider the power draw of each peripheral, and wire losses to avoid undervolting the last package in the line
Make sure 5V is ok
Make sure your 12V-5V buck can handle the current draw from all the peripheral packages
also consider wire thickness and how easy they are to work with
The logic level is still at 3.3 so CAN bus compatible but powers at either 5 or 12 V
SPI/UART concerns
Keeping those connections short(On trace)
Display error code?
Error code for when the car pulls over/debug/post-race analysis
What causes the OS function errors, is there any differentiation in handling different errors?
Programmed in bugs - Likely to be persistent, will hit the limit quickly and shut down
bugs from RTOS - these are pretty niche, can reset, and not likely to fall back into the state
Error because of hardware errors/filled-up queues? - look into what errors functions return
When you reset while running, is that viable for the driver?
The motor will just coast
Display still gets 12V, can program to just freeze for a bit
Make sure on reset it is either stateless or you bypass ignition states
able to detect hardware issues on the pedal?
Should consider
Faulty ADC, pulled wires
ADC wiring on leader daughter, BPS minion board has wire detection integrated
Testing - Boot up in ReNode, fuzzing approach(random user inputs), check correct state transition
Unit testing is not the end all be all for state transition, test with ReNode in full system
Include side lighting
Backup MCU
Talk to Clark about testing
Can help set it up well
Look at regs to set each req
CAN - consider a ring topology to handle disconnects
BPS Q&A
How reliable will the system be? do we still need a commercial BMS?
Will keep compatibility
Form factor smaller than Orion for enclosure design
What if the I2C bus becomes disconnected from the fan?
Tachometer reads an invalid speed
Switching to 1 board creates a single point of failure
If any board fails to disable the car so in reality, less risk
Current leader SOM does not isolate 5V
Will fitting new hardware into the enclosure be an issue?
New hardware is smaller than old hardware, so it won't be a problem.
Sampling rate of thermistors?
Thermal mass of batteries makes higher frequencies not helpful
Ensure to tune LP filter for an appropriate TC for polling rate
Ensure power rating for contactors and fans on leaderboard
Everything is calculated to handle all possible draws at the same time
Is everything in stock
SOM all ordered
Making spares as well
Clearance to reach clip/attach connectors
Yes, the reason for diagonal connectors
Same system as controls? Still consider voltage drop along the CAN chain
still need to test with the hardware, expect 10s of mV
How easy is it to swap the peripheral boards
Looking at reducing size to make swaps easier inside the BB, hard to swap connectors
Start designing battery box sooner rather than later
Thought to cooling control loops for fans?
Technically have a PID though difficult to test without a battery pack
Potentialy Use a lab's facilities to help validate the systems
depending on sampling rates, keep network bandwidth in mind
Will have to look into data rates, potentially clock network faster
Previously IsoSPI allowed simultaneous communication which is now no longer possible on a shared bus
Yes, but all info sent globally on CarCAN; can also mitigate through packing or only sending some data
Non-noise-resistant protocols only used on board
Redundant boards
If want to should triple up on boards, may not be worth time
Testing strategy?
benchmark against current-gen hardware
Unit tests as necessary
most problems come from systems integration
System architecture handles unit testing very well but should create a testing plan
For non-differentiating BSP protocols(UART) needs to have an internal queue/handle queueing manually
Concerned about voltage taps/temp since they are long analog wires?
Hoping to mitigate with hardware filtering, software
Reference regs
Regs in appendix
Why I2C and SPI for temp
IC selection/compatibility
nice MUX chip allows it to easily switch for SPI
Power Systems Q&A
hV wiring diagram
Regs okay with using a diode for battery isolation?
Regs refers to complete disconnect, but diode is for the state of approaching (but not yet at) disconnect
Powergen prefers to drive directly to the battery to eliminate inconsistent current demand
Overvoltage and reverse current protection, PPT hardware?
Plan was to put it on MPPT boards but will look into this
No precharge on second hv diode line: if all contactors are opened but the battery is hot and you want to go into discharge only mode, you can't because there's no precharge resistor
Yes, but also in this case we are already at a fault state
Question about power gen & reverse protection
Where did the second precharge array circuit go?
Array tested and confirmed this isn't needed because the voltage is boosted to the level of the battery
What if the driver regen brakes after the contactors are disconnected?
Controls doesn't allow regen braking if the battery is hot, and the diode will protect against regen braking
Diode does not protect DCDC
Update diode - over spec battery nominal voltage
Manufacturing the long PCB may be difficult
Select bolts that can handle the vibrations
Found a specific drain cover bolt that would meet the specifications, also will work with enclosures to make sure there is contact between the whole module.
Options for improving the PCB (ex: different copper)
Yes but also adds to expense
Insulate sides
Justification for keeping same switch LV, HV positions- we may want to charge the vehicle without moving
Ignition: tricky part is switching from startup battery to DCDC converter. Previous design: after checks, switch to DCDC converter. Didn't see mention of it in presentation.
Handoff for LV is handled on power board. In this design it's not the ignition switch but where the dcdc reaches 11.5V threshold.
Still the same circuit from before?
Yes
Ignition switches just powered off 12V?
Done in software from BPS and Controls
Drawbacks of sampling only 15-20 cells?
Limited by one power supply but asked Sid to buy another.
Also conforms to what other teams do and cells tend to be similar
Concerns with battery box and horizontal size constraints?
a bit bigger, a little wider, half the height. Can put modules closer to each other now.
Cells tested so far are all from the same box
If cells are the same, may be worth it to just start assembling
How does new HV design isolate everything?
Pop all four contactors
Combine HV on switches
Check with Steve on the characterization plan
Check with other solar teams first(@Nathan Lee can ask MIT)
Characterizing cells allows you to put similar modules together
Planning to do it by box. Can still characterize each one if necessary
Internal resistance testing? Some was already done, check Sharepoint
What connectors between PCBs
Depends on what BPS wants
PCB and connector has stuff for the entire module
4x8 battery box was previously too large for frame
Orientation should make it okay but will talk to frame
Contact resistance between modules?
Should be less than current due to greater surface area but will also look into ways like using copper or sandwiching things with a conformable something
HV diagram for power systems has four contactors but BPS only has three
BPS can add a fourth one
Possibility of automating testing with a PCB to check assumption of cells from a box being similar
On volt and temp PCB, implementation and connectors between power systems and BPS should be the same so it's easy to connect/switch between the two
Will discuss with BPS on this
Plan for charging whole battery pack?
Use HV charger like electric does
Question about alternative possibilities of something... related to a battery pack
Didn't know about them but would love to hear them
O-Rings
Small PCBs that slide into each other instead of one long one? Less expensive and also cool
Using lead acid or nickel metal hydride?
Strongly recommended to switch out Tenergy supplemental battery because the voltage is too high, things could explode, and the nickel metal hydride doesn't help if it isn't charged to its full potential
Placement of ignition switch?
Issue is that current way still has power board to ignition switch wiring issue. Only way to do that is for Controls to communicate messages over CAN. Powerboard interfaces with igntion for LV, so must go through power board to turn on LV unless BPS sends message or something like that. So wire from ignition to car center to BPS for LV on. Array on goes to BPS, motor on goes to … still BPS. Controls doesn't need it
Controls looks for two confirmations. Will those come from BPS now?
BPS will just tell Controls if they can drive the motor
Considered cell upgrades?
Expensive and the current ones still work
Functionality desired in a supplemental monitoring board?
TBD
Data Acq Q&A
How long are your RL episodes? want to make sure the agent learns to control shorter episodes
Start with short episodes then increase episode time
Curriculum learning
Requires looking into classical race strategy
Can help models converge faster
Concerns for wire length/putting 3 sensors on a daughter board
May need to route CAN directly to sensors if non-noise-resistant WCP
Make sure the steering angle sensor does not affect control buttons
RL - Ishan knows people in texas robotics who may be able to give advice
New Telemetry daughterboard, will it have the same GPS connector?
xbee - UART
GPS - UART but new gps
Still using a realtime clock for the F4 chip?
Probably because logs need timestamps
Unless someone comes up with a better idea
noise to the xbee?
isolate xbee
Waterproof external sensors - airspeed
Characterize the steering angle after mounting to the metal frame
Metal hull will probably mess with magnetic field but lookup table will help with this
How accurate do you expect the simulator to be? and how accurate does it need to be to be useful?
Need to compare with other simluations and data over time
Can you build it so that its adaptable/tuneable
Can compare and update data, adjust manually
Make sure it can be updated after getting real data
Question related to linear regression and real data
Training on desktop or TACC
Currently on desktop but CPU limited so TACC would be ideal
Length to train?
Couple of months usually
TACC allocation has harsh policies so maybe look into LHR workstation
Radio, driver, data radio?
Two way radio with extendable push to talk button that will be attached by ergo
Antennas for solar car, chase car, pit? Heavy and easy to forget but important. May want to look into buing a new one
Need to look into
Genetic algorithm independent of RL?
Need to change speed array for different tracks?
Time to generate a new area?
Have you considered a model that takes an input based on the state of vehicle and track and then broke it up into segments and have weights to generate a speed?
Thinking of a different approach where which factor affects more in reinforcement learning but training weights is a bit different but could also be a different approach. Speed array is a more straightforward since they don't have a basis though
split race into condition/geography aware slices rather than just by distance/dynamic slice lengths
What if route changes last minute (not published until night before?)
Was able to generate a model in one night so should be okay
Why Cloud database
Web UI/API for interfacing with AWS?
Web interface may be hard but could do local
Putting additional sensors on the same peripheral board?
Yup, should have lots of space
XBEE receiver- will you be making your own board?
Making own should be similar
Could use another copy of SOM?
But don't see why the complexity is needed if a dev board would work
If already validating code for XBEE SOM stack why not also add receiving capability
Don't think there's really a need. Could also just use a pi
Why the 3D model?
Helps visualize. Not actually running druing race
Genetic algorithm- would it be better to calculate pit stops instead?
Optimal speed seems like the more important question to start with
Taking into account one pedal mode?
Is speed input for RL? Car isn't speed controlled
Have ways to choose and drive by speed though
Position of humidity sensor and accuracy?
Closer to the battery because humidity affects battery
Sunlight intensity?