Agenda (+15min for pre-lunch presentations)

Presentation Materials

Presentation Recordings

Q&A

Notes from Matthew Mekha on LHRE:

Controls

• The common PCB design is clever, and I think STM32 is a good move
• "isospi proven to be unreliable" - explain 🤨
• To resolve the braking imbalance that calls for an electronic brake, couldn't you introduce a leftward brake bias on the rear axle and have the regen close the gap, keeping the two rear wheels' brake forces equal? If not, is the weight of an electronic brake worth it when you can just switch to two, smaller motors? then you can recover more energy through regen too.

Data Acquisition

• The architecture looks good, only question is why not bump up the CAN data frequencies? I may be missing details but 10 Hz seems kinda slow (especially for controls stuff) when you can probably do 100+ Hz no problem. You can also probably use just one CAN bus and be fine (that's what we're doing). Take a look at our CAN budget spreadsheet, and feel free to copy the formulas and stuff.
• I don't understand how the axial magnet will work for steering sensing, the radial magnet from the earlier slides makes more sense. Also, you may want to consider a component that you wouldn't have to mount in two different places. For example, this 2D hall effect IC I've used before has two axes already and it goes right under the magnet instead of beside it.
• The genetic algorithm stuff was interesting. If it turns out well, maybe you can extend it into deciding vehicle parameters as well as speed strategy 

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?