After the June 2019 FSAE Lincoln competition, I assumed the role of Controls Lead on MIT Motorsports. The responisbilities of this role are to deliver the controls software on the vehicle control unit (VCU) that best satisfied the team’s goals and to help make high level decisions affecting the whole team as part of the exec team.

“Controls software” refers to any software that modifies the torque command sent from the VCU to the motor controller. Normally, this torque command is generated by converting the accel pedal sensor position (which the VCU gets over CAN from the a sensor node) into a torque command through a simple linear mapping. But controls software can modify this torque command to accomplish the team goals.

To decide what controls tasks the team would take on, I started with the team goals we had worked out with an exec team. Our first priority was to win competition, so I worked out points estimates and resource requirements (engineering and testing time) for each task. The projects I settled on for MY20 were as follows:

  • Launch control: Commands the optimal torque command for a fastest time during the Acceleration Event.
  • Power limiting: Prevent the power draw from the vehicle battery from exceeding the rules mandated 80 kW limit.
  • Battery temperature and voltage limiting: Limit torque to prevent battery cell voltage from falling below the undervoltage limit and to prevent battery cell temperature from exceeding the over temperature threshold.

I was responsible for the launch control project, and you can see my work in detail on this page. I assigned the other projects to members of the controls team that I managed. Specifically, I had weekly check-ins with them, gave feedback at their design reviews, and helped pick up any tasks they needed help with to hit deadlines.

As controls lead, I also ensured that we throroughly, efficiently, and safely tested our controls code. One of our sponsors, Palmer Motorsports Park, generously allows us to run our vehicle on their track when it’s not in use. (The picture above shows me taking our data logging SD card out of VCU on the track at Palmer.) However, driving there and running the car is time consuming and involves many man-hours, so minimizing errors on the track is crucial. And of course, ensuring the code has no mistakes that might lead to a dangerous situation for the driver or the vehicle is crucial. With the help of our Testing Lead, I implemented the following process to make ensure our testing went smoothly:

  1. Unit tests: Using the same testing framework as what’s used for the rest of the VCU code, check all basic logic, input and output reading, and math.
  2. Test plan review: Submit a detailed test plan
  3. Stands testing: On jackstands in our garage where we can run the car with the wheels off the ground, run the code to the fullest extent possible and document all test cases on Confluence, along with what git hash was used for the code.
  4. Code review: Using GitHub pull requests, have me (or if it’s my code, I would get another more experienced team member) read the code for good organization, correctness, and ease of use.
  5. Alley test: Run the vehicle at low power in the alley behind our shop.
  6. Palmer test: Execute the test plan.
  7. Documentation: Upload data to the team dropbox, summarize testing trip on Confluence, and link any analysis scripts on Confluence as well.