Winter 23 Firmware Code Restructure

Open Questions

• What does the firmware system need to control?

  • What we know: Need to control motors all over the rover (drive train wheels, arm motors/servos, etc), LED matrix

  • Is there other stuff? Other hardware requirements? How about PDB, Gimbal, and science?

    • Custom PCBs and reading from sensors.

  • For the Jetson, will we just need CAN signals coming in and out to communicate with the rest of the firmware system?

    • Jetson → odrive with CAN. Maybe consider Jetson → nucleo → odrive if real time issues arise. Maybe the second option is overkill, odrive also has STM32 chip.

    • Jetson needs CAN driver; maybe a software team task.

• Should all motors and servos be controlled by odrives and handled via the same software interface?

  • We will probably have odrives connected to each of the major motors we need to control

  • Will we also need servos/motors connected straight to nucleos in other parts of the rover or does that make things too messy?

    • Direct comms between odrive and jetson (CAN bus). Get the network setup to get to all the subsystems

    • Try running odrives with CAN instead of odrive tool. Use nucleo or CANable? Make sure CAN connections work properly this way. Maybe Jetson?

• What we see firmware doing: 1. Creating a CAN network for the Jetson so that CAN signals can be transmitted (also received) to send control messages to other parts of the rover. 2. CAN transmission lines need to be setup to other major rover subsystems. 3. CAN messages must be received and extracted to get relevant data (likely by custom PCBs or odrives). 4. Custom PCBs or odrives will send commands to actuators to perform actions. 5. Actuators/odrives will give a response back, and data will get passed all the way back up the CAN line, probably making it back to the Jetson as responses to requested actions.

• Odrive → jetson connection. Wire CAN fw that is pretty much already on the jetson; package CAN message to send what odrive CAN protocol is expecting. Odrive CAN fw should work.

  • Ros python node wrapping odrive tool. Might have comms issues

  • CAN interfacing between jetson and odrive (probably the way to go).

  • First task: Send CAN messages on Jetson and get Odrives working using those CAN messages.

• Custom PCB → jetson. Separate app. CAN on jetson (same as above). On custom PCB side, write FW to read + send CAN messages. Task is to write CAN driver here using structures defined in HW bridge.

• Hw bridge is common message struct place.

  • If the above is somewhat right, how do we start making this happen? Planning on switching over to STM32 cube IDE

  • Should we start by making firmware apps for each of the subsystems we need to control? This implementation might be slightly easier but more overlapping code/overhead/boiler plate code - more code in general?

  • Or, do we just make a single firmware app and create multiple threads running the different subsystems (likely using an RTOS). Is using an RTOS going to be a headache and not worth it when dealing with race conditions in different threads?

  • Where do we start? What do we set up first? What subsystem should we work on first?

    • MBed OS: Look into prev fw repo and see if we can take stuff from this. Mbed OS should be very easy to use, and we have alot of stuff already here.

      • Write new app with existing drivers and mbed drivers. This should be pretty easy to generalize to new apps we need for the new rover. Look into the build system and building an app and flashing an STM32 MCU.

    • For “fun” fw, STM32 HAL might be good. This is going to take some time.

    • Both of the above are action items we should consider.

• Other than the above point, is there anything that firmware code must be able to do that we are not accounting for? Don’t think so .

Ideal meeting outcomes:

• Make sure we have a high level idea of what FW needs to do for the mars rover

• Make sure we know what we need to do to get CAN setup all over the rover (FW comms). CAN bus lines?

• Make sure we know what the first steps are to get started with creating a FW system from scratch using STM32 cube (FW functionality)

 Problem Statement

 Scope

 Timeline

 Milestones and deadlines

 Reference materials