[TASK] Thruster MCU

[forrisdahl]

Description

Develop firmware for the Thruster Control MCU responsible for receiving control commands, generating PWM outputs to drive thrusters, and monitoring system health. The MCU shall interface with the main control system over CAN and respond in real time to command messages.

---

Requirements

• CAN communication

  • Receive control commands over CAN (e.g., target thrust or PWM duty cycle).
  • Parse frames per the thruster CAN message specification.
  • Optionally transmit status frames (current draw, temperature, fault status).
  • Support configurable message IDs and update rates.

• PWM control

  • Generate PWM signals for one or more thruster channels based on received commands.
  • Ensure safe start-up/shutdown (no spurious pulses, defined idle state).
  • Support configurable PWM frequency and duty-cycle limits (min/max clamping, slew limits).

• Safety & fault handling

  • Implement command timeout/watchdog—stop thrusters if no valid CAN command within the configured window.
  • Detect and report faults (overcurrent, undervoltage, overtemperature, comms loss).
  • Provide an emergency-stop path and fault-latching/clear mechanisms.

• Modular code structure

  • Separate CAN, PWM/timers, and control logic into dedicated .c/.h modules.
  • Define clear, reusable interfaces for portability to other actuator MCUs.
  • Configuration via compile-time constants and/or non-volatile parameters.

---

Acceptance Criteria

• Valid CAN command frames are parsed and applied; out-of-range inputs are safely clamped.
• PWM outputs track commanded values within specified timing/jitter limits and respect frequency/duty constraints.
• On missing/invalid commands for longer than the timeout, thrusters cease output and a fault is flagged.
• Detected faults (overcurrent, undervoltage, overtemp, comms loss) are reported over CAN and reflected in status.
• Optional status frames are emitted at the configured interval with correct IDs and data formatting.
• Module boundaries are respected; unit tests or bench tests verify each module independently.

---

To-Do Checklist

• Research necessary peripherals (timers/PWM, ADCs or current sensors, temperature sensors, CAN transceiver, gate/ESC interface).
• Select components and confirm availability for PCB integration (MCU pins, timer channels, CAN, sensing).
• Implement drivers: CAN, PWM/timers, ADC/sensors, watchdog.
• Implement command parser, control loop, and safety/fault manager.
• Integrate modules into MCU firmware with configurable parameters (IDs, timeouts, PWM limits).
• Verify functionality on a development board (HIL/bench testing with simulated CAN traffic).
• Validate on final PCB hardware with real thrusters or load emulators.
• Document configuration (message specs, IDs, thresholds, scaling, PWM settings) and provide README.

---

Contacts

• @forrisdahl
• @IbixD97

---

[forrisdahl]

On Orca, the current Thruster MCU is a Raspberry Pi Pico. At the beginning of this year, we observed significant delays between sending PWM values over I²C and the thrusters actually responding. This issue was greatly improved by rewriting the Pico firmware from Arduino to bare-metal C, which reduced the delay by an estimated 0.5 seconds — a major improvement.

In parallel, development began on a dedicated PWM generator PCB based on the SAMC21. A prototype PCB was designed and produced, but late in the process we discovered that two of the PWM outputs were not distinct. Further details are documented in the PWM_generator.X README. As a result, the design did not provide enough PWM outputs to drive all 8 thrusters. This limitation means the current design must be scrapped, and we will instead move forward with a SAME5x MCU, which offers the necessary number of PWM channels.

For the concept review, I recommend focusing on why a SAM-series MCU is a better choice than the Raspberry Pi Pico. It will also be important to highlight the issues encountered last year and explain how we plan to address them in the new design.