Page Comparison

...

Notes Cont'd: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 Image Added

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

...