We are using WaveSculptor22 for motor controller, see TritiumWaveSculptor22_Manual.pdf (tritiumcharging.com) for docs.
Motivation
The motor controllers (MC) are a third-party board with a custom CAN communication protocol. The MC must send and receive messages to the driver controls (DC), however because the MC protocol is strict and thorough it requires abstraction from the rest of the system. The motor controller interface (MCI) handles this abstraction.
Components
Moter Controller (MC)
MCI must transmit to MC every 250ms or else the MC will shut down. This will be a periodic (200ms) task.
...
(Try to see if it’s possible to use can.h to control two can controllers simultaneously, if not, use mcp2515 needs to be migrated to fwxv)
Driver Controls (DC)
MCI will receive can msgs from DC requesting to set the car’s drive state. MCI then sends the message to MC.
MCI will transmit voltage and current updates to the main CAN line.
Can
There are two can lines, one communicates only to MC referred to as MC-CAN, the other communicate to the rest of the car referred to as CAN.
Task
CAN rx, MC-CAN rx
process msgs sent by CAN rx, update any states
process msgs sent by MC-CAN, update any states
build messages for MC-CAN and CAN
CAN tx, MC-CAN tx
Can Messages
WaveSculptor’s broadcast messages can be found TritiumWaveSculptor22_Manual.pdf (tritiumcharging.com) section 18.4
...
| Code Block |
|---|
1: - velocity left: uint16 - velocity right: uint16 2: - voltage left: uint16 - current left: uint16 - voltage right: uint16 - current right: uint16 3: - limit_bitset left: uint8_t - error_bitset left: uint8_t - limit_bitset right: uint8_t - error_bitset right: uint8_t - board_fault bitset: uint8_t - overtemp bitset: uint8_t 4: - motor_temp left: uint16_t - heatsink_temp left: uint16_t - motor_temp right: uint16_t - heatsink_temp right: uint16_t 5: - dsp_temp left: uint32_t - dsp_temp right: uint32_t |
FSM
There will be fsm to make sure state transitions are valid, valid transitions are
...