northeastern-electric-racing / embedded_code Goto Github PK

This is gonna involve taking the current drive state of the car and translating that to a set of IO behavior to increase the range of the car.

Things to do:

• Potentiometers on the wheel PCB should control the radiator and accumulator fan speeds
• Will need to broadcast a fan speed to shepherd that needs to be interpreted by shepherd
• Paddles change maximum torque (automatically derate the torque calculated based on the broadcasted current limit)
• Implement regen!

Right now, pedal hardware abstraction and torque calculations happen in one big class in two big functions. Goal of this issue is to create a class and functions solely for pedal hardware abstraction, and then a higher level class for torque calculations and logic handling

Idk why I made them capitalized originally, I think I figured that saying something like bigButton = BigButton() would be confusing but it is a bit stupid

The main MPU class is somewhat unnecessary and can be taken out to allow easier passing of data from CAN messages

Request by Matt for ease of tuning while testing. This change would probably entail putting important macros, such as maximum motor torque and debounce timers in a single file, possibly the platformio.ini file

We want to utilize the drive state of the MPU to control a set of IO behaviors to increase the performance of the car

Things to do:

• Traction control (if motor spins fast while we are giving constant torque, reduce torque, this will probably be PID loop style)
• "Maximum torque at all times," potentially optimizing the current limit to torque calcs to be more aggressive

The implementation of this will consist of:

1. Consolidating functionality of the board (currently Brakelight, Pump relay, and Radiator Fan PWM) into a single class
2. Implement a CAN message filling system similar to that of the motor controller's integration (bitfield union) to increase readability

This ticket is detailed in this confluence doc:
https://nerdocs.atlassian.net/wiki/spaces/NER/pages/16482305/Strain+Gauges+-+Suspension+17

For this ticket, we need to

1. Create a circuit to convert strain gauge output to a voltage readable to NERduino
2. Implement the ADC reading of the voltage
3. Log the data in a similar manner to logging accelerometer data

DO IT!

If we are supplying torque to the motor but the motor isn't spinning, this means that something has gone wrong and we might snap the diff or something. For this, we have to consider edge cases like going up a hill so that the car doesn't automatically shut off, so we might want to be gracious with any thresholding we do. I think that some calc was already done and is in the codebase, but the logic was just a bit fucked

This is probably contained within the TSMS class/in the cascadiaMC class, this logic is now handled entirely in hardware

In order to decrease the size of messages, we should send XBee data in a binary format. This can be done using bitfield structures and the Serial.write() function. An issue to solve will be how to reliably distinguish between messages using some sort of start/stop bit pattern that can't be seen throughout the rest of the message.

Add the ability to only log messages at certain time intervals, and not every time they are received. Would involve some sort of top level mapping of message ID to a timer, and only logging the message if the timer has expired.

Add EEPROM support for all TCU constants. This involves reading EEPROM values on startup and adding support for dynamically configuring them through a CAN or XBee message. Some parameters will most likely only be able to be changed on startup (baud rates), while others can be updated dynamically (loggable IDs).

This may be a useful feature across parts of the car, so designing it with this in mind is a plus.

@rydzynskip asked to get the NERduino library working with the TCU

These both are gonna be really similar, so I'm grouping them together

Things to do:

• Speed limiter and torque limiter (these are separate things, speed limiting will be motor feedback based)
• Maybe toggling IO to test components in pit lane mode?
• Speed and torque limiting is especially important in reverse

Now that we have confluence, we should move high-level documentation to confluence, and keep only what is needed for env setup/building/implementation in the README's

Switch UPPERCASE class names to CamelCase (Idk why I did uppercase to begin with)

Get rid of p_variable for function declaration (I originally thought of it as "passed variable" p, but it means pointer)

Kinda of a redundant ticket but still important
This ticket entails combing through all code in the MPU AND NERduino codebase to make sure that there is not blocking code

NERduino:

• Check sensor communication to ensure we never just wait forever/include a timeout

MPU:

• Make sure there are no blocking debounces
• Specifically, I think there is something in the motor controller logic that needs to be handled

Right now, DriverIO hardware abstraction and logic handling happens in the same class in some very large functions. Goal of this ticket is is to create a class and functions solely for hardware abstraction, then create a new class that utilizes that hardware abstraction to encapsulate logic and hardware.

Right now, GPIO hardware abstraction and logic handling happen in one big class. Goal of this ticket is to create functions solely for abstracting hardware, and then encapsulate any logic within a class.
Not sure if this is really needed, but we'll see

set up github action checks for formatting and linting