2022- 2024 Controls Retrospective

• For questions specific to controls, please contact

  • General controls: Nathaniel, Ishan, Maddie, Diya.

  • Previous controls members and at this time, current BPS members who helped with the bug fixes: Tianda, Clark, Rishi, Sid.

  • Controls enclosure was created by Changxu.

  • Controls (and general) wires harnessed by Frank, Prat, Lakshay.

  • Lights mounted by Cesar and Advait

• 2024 Comp timeline (technical changes, bugs, and fixes timeline)

  • Added debugging info to the screen provided by BPS

    • Motor, current, pack voltage, temp. all this information was useful as it communicated if (A) Controls was reading stuff right and was not the default value, although not critical and (b) if everything was as expected and was following a certain pattern.

  • Heartbeat LED – physical and software LED (on display)

    • This was used a lot for debugging purposes, especially to know when display was freezing up or if controls code was crashed but display was still on

  • Reflected ignition switch pinouts

    • Should have tested out the new pinouts with jumpers to fully ensure that the production wires would work.

    • We did not test them out before because the simulation board had different pinouts.

    • Confluence had both the simboard and production harnesses on the same doc, so we got them mixed up.

    • During comp, when switch would be in OFF, it would actually turn on and go to MOTOR position.

  • Display stopped displaying

    • bug in can transmit. unsure how it was working throughout competition until that point.

  • JTAG was annoying to plug in, as suggested by Nathaniel

    • use this https://github.com/jeelabs/esp-link

    • a CAN bootloader or UART bootloader is also a good option. if implemented across all electrical systems it could also offer electromech more freedom in where boards are placed.

  • CANdapter was useful, however also annoying to plug in. also as suggested by Nathaniel

    • For future, have a harness for it or also use this https://github.com/jeelabs/esp-link

  • Motor (tritium) faults

    • Ignored because they were too frequent. Do not know if any were critical, however BPS would have hopefully handled that

  • Accelerating without pressing on pedal

    • We had taken out the deadband for accel pedal because we thought it was interfering with the brake and was letting the car brake itself. However, this was not the case and the deadband was needed because after removing from our code, it would start moving forward without any pressure by the driver.

  • Brake pedal button is a floating signal rather than a switch connected to ground

    • added a hardware and software pulldown resistor

  • Brake pedal button used for brake lights not sensitive

  • Brake pedal wire disconnecting

    • Added Saturation buffer, however this would not solve the problem because brake logic does not keep it in brake position after braking one time. For how the state machine works, brake state should immediately go to Forward, Reverse, or Neutral state.

  • Continuous braking/ Motor speed cannot surpass 25 amps/ 9 mph

    • Still unsure, most likely due to a combination of not knowing wavesculptor manual throughout and messing with the PID config for motor.

    • We did not question it not working because it was working on the motor mount. From now, we should assume worst case scenario as well as best case and create contingency plans.

  • Ground Loop Issue

    • There was a ground loop on the controls board (see this)

    • Pretty sure this was causing an issue where every time we ran the motor, the ground loop acted as an antenna and since it was connected to the reset switch, it was causing our reset to go high and resetting the MCU

General

• Have more GPIO pins incase we need to use them for something else

• Detect EVERYTHING. Requirements should have every possible thing that could go wrong listed out, and a fault handling procedure to handle it. This includes simple stuff like wires becoming unplugged, but also more stuff found in initial vehicle testing. We should also get notified if something goes wrong through some mechanism (display was a useful debug tool during comp)

  • Specifically, system should be RESET-PROOF. If a reset occurs on any board there needs to be a mechanism to retain state or quickly get back to the exact same state with little effect to the driver.

• Question every inconsistency- every bug and anomaly we see on a testbench will be an issue we need to troubleshoot later, except later, we’ll have much less time. Ex: We knew the motor stalled when held because we had seen it do so on the mount, but we didn’t figure out why until we stuck it on the car and it became a real problem because it didn’t roll.

• Test in an environment that is as realistic as possible. Using production wiring, boards, tools, etc., increases the opportunity to catch bugs.

• Add more stats to display. Tighter integration with data acq might allow this, perhaps they could build a version of their dashboard for our display for debug purposes.

• Know how the motor controller works. We should be able to explain each and every number on the MC configuration tool and why it matters. This was a hurdle for us at comp because we did not realize Motor Current != Bus Current, and would have not taken us long to learn if we had read the documentation more carefully or done prior research.

• Try to put boards as close to sensors as possible and transmit info via CAN (e.g. accelerator pedal and brake pedal)

  • In general, we should modularize the system a bit more than it currently is so that different boards are in charge of different things, and we don’t have seventy billion wires going to the one controls board.

  • This also feeds into having some sort of zonal architecture with boards spread across the car in order to make wire harnessing easier (direct light control should not have to go from back of car to front of car; rather, a smaller PSOM could be placed near the back and then CAN could be routed to it to control the lights)

• More hardware design. As embedded engineers EVERYONE needs to understand what the hardware is doing and why it works electrically. It is not acceptable to be unclear on the hardware and black box it to do software development, everyone should be able to open the KiCAD and explain every circuit on every board under the system.

• Have a couple versions of code. may be convoluted. However, at comp, everything feels convoluted so making things simple as possible by creating multiple venues for isolating the logic, in different ways.

  • Meets regs, bare minimum

  • Meets regs, with full functionality

  • Does not meet regs, with pieces of functions for debugging

  • This can be done with conditional compilation and #defines to save effort (think makefile flag for DEBUG and RELEASE variants)

• Have a button for reset to reset controls code (other teams had this too)

• STM is beefy, as suggested by Nathaniel

  • can be use esp instead https://github.com/jeelabs/esp-link

• From a board design standpoint, make the working LEDs green or blue intead of red which can convey error

  • Add heartbeat on every board (should be standard with SOMs)

• Also from a design standpoint, ports should be on one side of the board..communicate with emech/enclosures about this to see what is easiest for them

• Have a full block diagram of the Apps and Drivers on each board before executing on it

• Perhaps consider integrating more tightly with data acq; there’s no reason they couldn’t share a board with us.

One on one with Prat (7/24)

• Zonal architecture

• stuff we will talk about in electrical leads meeting

  • proposed system architecture

  • system requirements

Tips from other team’s driver

• Need wires to have a lot of slack because once the car is moving, things will come undone. need to know where the stress points are

• Camera and horn are very important

• Display needs to be way brighter or requires some sort of shade

  • do not make display green as it is unreadable for driver (mentioned by Parthiv)

• Make sure that the driver knows what the faults mean. this is important because a number might not mean much without context. also need to show faults even when it’s a recoverable fault

• mirror on the inside (although sunlight may be reflected which is not good)? maybe cameras because visibility is incredibly low inside car

• Perhaps sideview mirrors could be implemented as cameras (like the blindspot cameras we were planning). one “mirror” (display) on each side of the dashboard?