Getting Started - Software🔗

This guide should get you from 0 to 1 for getting a motor to spin assuming all of the hardware is setup per Getting Started - Hardware.

In addition to setting up the hardware, before proceeding through this guide, it is recommended to understand the fundamentals of how the software works. Consider skimming through these chapters to get a high-level understanding of the system.

Validate Interfaces🔗

First, apply LV power to the motor controller through the LV Connector Pinout. After a short (<=5 second) delay, the unit will start emitting telemetry packets over the CAN bus. Before attempting to spin under HV power, it is prudent to ensure that all sensors are operational

Validate Internal Sensors🔗

Read the data from the 0x016 (State ID). Both cangaroo and wireshark are excellent tools to use for this purpose on Linux. When the motor controller first turns on, it will be in the Init state (learn more here: State Machine). It should then quickly and automatically progress to the ReadyToSwitch state if the temperature, current, and resolver sensors are healthy. Additionally, none of the fault bits should be active.

If one or more fault bits are set, it could indicate that the resolver’s external signals are not properly connected, or that there is an issue internal to the unit.

Write Initial EEPROM values🔗

For proper commutation, there are a few EEPROM values for which the default value is unlikely to be appropriate for your usecase. You will almost certainly need to update these values from the default See EEPROM Configuration for details on how to set configuration values.

EEPROM Fields🔗

Field Name

Default

Description

What will happen if it is incorrect?

ResolverOffsetDegrees

\(0.0\)

This value should be the electrical angle read by the resolver when the rotor is aligned to phase A of the motor.

Motor may not spin, or if it does, commutation efficiency may be severely degraded

LoopIqPGain

\(0.0\)

See below

Improper commutation, or poor performance under high speeds/torques

LoopIqIGain

\(0.005\)

See below

Improper commutation, or poor performance under high speeds/torques

LoopIdPGain

\(0.0\)

See below

Improper commutation, or poor performance under high speeds/torques

LoopIdIGain

\(0.005\)

See below

Improper commutation, or poor performance under high speeds/torques

ResolverPolesPerMotorPole

\(1.0\)

This value should be the motor pole count / resolver pole count. For example, with a 10 pole motor and a 5 pole resolver, this value should be 2.0. The sign of this value indicates whether the resolver is expected to read forwards or backwards relative to the motor.

Motor will not spin, reported \(i_d\)/\(i_q\)/torque values will be incorrect

TorqueConstant

\(1.0 \, \frac{\text{Nm}}{\text{A}_\text{peak}}\)

This value should be the torque constant from the motor’s datasheet (rescaled to \( \frac{\text{Nm}}{\text{A}_\text{peak}}\))

Torque values to/from the motor will be incorrect

MaxTorqueSlewRate

\(65.0 \, \frac{\text{Nm}}{\text{sec}}\)

Maximum allowable change in torque per second

Aggressive motoring/regen action may sag/boost HV DC bus beyond system limits.

Calculating initial PI gains🔗

We have found these to be a good initial guess for PI gains when manually tuning:

\[ K_p = 0.8 \cdot \frac{L_{ph}}{0.0002} \qquad K_i = 0.8 \cdot \frac{R_{ph}}{0.0002} \]

where \(L_{ph}\) is the motor’s phase-to-neutral inductance (in Henries) and \(R_{ph}\) is the motor’s phase-to-neutral resistance (in Ohms).

The quality of your chosen gains can be evaluated by using the Torque Control mode in the 0x019 (Command Packet).

Note

Autotuning, plug and play operation of the motor controller units is coming via a firmware update in 2026.

Validate Position Sensing🔗

Read back the data from 0x012 (Resolver) and 0x025 (Electrical Angle). Validate that in 0x012 (Resolver) there are no fault bits (FAULT should equal 0x00).

Manually spin the motor by hand to complete 1 mechanical rotation. The position reported in 0x025 (Electrical Angle) should increment or decrement depending on the direction of rotation. Ensure that the angle returns to it’s initial angle N times, where N is the number of poles in your motor.

Tune Resolver Offset🔗

There are a few ways to tune the resolver offset. In the future there will be more robust control algorithms to automatically determine the optimal resolver offset.

For now, it’s possible to guess and check it. Set ResolverOffsetDegrees in the EEPROM Configuration and apply torque using the 0x019 (Command Packet). If you see rotation begin to occur, you are close. You should be able to tell it’s roughly tuned when applying a torque causes desired rotation and the DQ currents are reasonably stable.

Complete!

Once you’re spinning with reasonable PI gains and a working resolver offset, you’re off to the races!