Button -> I click on the buttons -> Go to the callback function table (some sort of data structure) -> Go through them sequentially and call of those functions C CAR -> Button 1 -> Does something E CAR -> Button 1 -> Does something else ^ And frontend should be given the necessary functions that they can call to change the mapping ### Callback functions - When a dial is changed, a callback function would be called. You just have to provide a way to change this callback function ### Approach I guess, first, I should try and get a print statement to run as soon as a dial is changed or a button is pressed. And what prints should be different for each button/dial. I also need to setup the pipelines for CAN. Right now, there is absolutely nothing going on with the buttons. ## Understanding the CAN functionalities The `can` folder has a bunch of files dedicated for CAN functionality #### canRx.py - This is responsible for CAN functions that are being received from the car. This is essential data being piped to the backend. - It contains information for - SPDU faults - PCM hardware sensors (not sure what this is) - PCM stands for Powertrain Control Module - PCM virtual sensors (not sure what this is either) - PCM Engine Control - PCM Actuators - It defines rx for both the combustion car and the electric car. Based on the mode the steering wheel is in currently, the struct is chosen and the nature of the rx function changes #### canSM.py - It is not immediately clear with all of the stuff pertaining to the network configurations - It also appears to be sending using the tx function but I do not know why it is doing that #### canStruct.py - This just contains different struct for ev and combustion car mode #### canTx.py - Sparse file. Things need to be implemented #### mcpDriver - Special implementation for the mcpDriver - It has rxMessage and txMessage functions - Need to pay close attention to the constants being used. It appears that they are related to the MCP driver being used (whatever that is, need to look it up) **Note**: once I figure out how to easily send tx messages, the implementation becomes easy. ## Writing a CAN DBC - A DBC could very loosely be thought of as a struct specific to CAN ## Implementation I made an InputDevice class. GPIOs like buttons, dials, and joysticks, all conform to the InputDevice class. All this class lets you do is register a callback function and breaks out a run_callback() method that you can call to actually call the registered callback function. The idea is that there will be multiple configurable screens on the steering wheel's LCD display and so the functions that are mapped to a button will change according to the display. For example, in "race mode", a button could be used for torque vectoring and in "idle mode" the same mode could be used to change something on the screen ```python class InputDevice: def __init__(self): self.callback = None self.args = [] self.kwargs = {} def register_callback(self, callback, *args, **kwargs): self.callback = callback self.args = args self.kwargs = kwargs def run_callback(self): if self.callback: self.callback(*self.args, **self.kwargs) else: print("No callback function registered") ``` I made a lot of changes to each input device using this is as the base. This might not be the best way to do it but I think it works for now. Integration went quite smoothly and the steering wheel sends CAN messages with a ~3ms delay, which I think is pretty fast. ## Display abstraction - Currently, we do not have a way to track the current screen. We need that functionality in order to determine the button mappings. Each screen will have its own buttons mapped to different functions (the buttons bit is done and works as intended) - We need to track the current screen because the mappings change and GPIO State Machine needs to know those mappings. - We also need to figure out how to change screens. I am not sure if it is possible to interact with the screen. Maybe using the d-pad/joystick we can implement that. - How are we planning on changing Screens? Will there be a lot of screen changes happening? ## Steps to connect to internet https://inrg.engineering.ucsc.edu/howto-connect-raspberry-to-eduroam/ ## Implemented steering wheel callback function ## Steps to connect to internet https://inrg.engineering.ucsc.edu/howto-connect-raspberry-to-eduroam/ ## Issues with multi screen architecture - displaySM.canDataIn and displaySM.canDataOut do not update (fixed - had to update canSM) - Combustion screen is rendered incorrectly upon switching - Have to start using Screen superclass for new displays - Have to figure out id system for different screens - General code cleanup (getting rid of EV_MODE, buttons.py, ON_PI, making that stuff more streamlined)