Motor Controller Interface: MS 12
- Titus Chow
- Arshan Khanifar
- Karl Ding
Goals
- Abstract motor controllers from the main system CAN bus
- Reduce unneccesary information on the system CAN bus
Background and strategic fit
On MSXI, the motor controllers were on the system CAN bus. Since they are a commercial product, they already had a defined communications protocol. This locked our boards into the motor controller's protocol and a majority of the messages on the network were related to the operation of the motor controllers. In addition, driver controls needed to know the exact format of the drive commands and do all of the unit translation.
By moving the motor controllers to their own CAN bus, we can define our own CAN protocol that better serves our needs. We also have the ability to offload command processing onto the motor controller interface. This could involve target interpolation, modified curves in response to torque requirements, etc.
Assumptions
- We have controller boards already complete
- The CAN driver does not support alternative sources (i.e. SPI)
- The motors generate more information than we want to broadcast in real-time
Requirements
| # | Title | User Story | Importance | Notes |
|---|---|---|---|---|
| 1 | Bidirectional CAN communication | We want to be able to both send command packets and read back motor information. | Must Have | |
| 2 | Simple implementation | We need to consider the amount of firmware and hardware required to support this. | Must Have | If this is too complex, we may look into dedicating a more powerful chip with 2 CAN controllers to this. |
| 3 | Support different network speeds | The motor CAN network may operate at greater speeds than the system CAN network. | Moderate | |
| 4 | Data logging | It would be nice if we stored all the messages we got from the motor CAN bus if we aren't broadcasting everything. | Low |
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|---|
| What packet format do we use to drive the motors? | The Driver Controls board will peridocally broadcast a message containing the directon selector (Forward/Reverse) and the amount of torque requested (as a raw value with a known maximum). The Motor Controller interface will take the torque requested and divide by a known denominator and set that as the current limit. The voltage limit will be set when cruise control is set. |
| How do we handle turning? (differential) | This will be handled by the Motor Controller's control loop (needs to be configured by the WaveSculptor configuration tool) |
| How fast should the motor CAN network run? | |
| How do we get two CAN controllers? | Two Controller boards with a UART bridge |
Not Doing
- Torque vectoring algorithm (improvement for WSC maybe?) This will be handled by disabling Cruise Control when steering angle exceeds a threshold