Encoder calibration fails for T-Motor U10 Plus

I want to use the T-Motor U10 Plus (170KV, 36N40P) with ODrive. Unfortunately, encoder calibration consistently fails. I am currently using the new ODrive GUI and configure the motor to 170kv and 20 pole pairs. Calibration of the motor suceeds, but encoder calibration keeps failing (ATM102-V). The encoder is known to work properly, if I attach it to a D6374 everything works perfectly.

The U10 Plus is mounted to a harmonic drive, so it experiences some load, but that is barely noticeable. Even if I allow the housing of the motor to spin freely without any mechanical resistance, the calibration does not look as smooth as it does for many other motors, e.g. the D6374.

Any tips what to try?

Hi Adrian,

Since your motor has 20 pole pairs, can you set odrvX.axisN.encoder.config.calib_scan_distance to something like 42 * Pi and try to calibrate again? By default, it is 16 * Pi, which is enough for just over a full revolution of movement with a 7 pole pair motor like the D6374.

Hi Patrick,

thanks a million, that was the hint I was looking for!

I also had to increase calib_range for the calbration to succeed. To get started, I just set it to 5 times the default to make it work. I did not look into details yet, but probably there is some systematic functional dependency that would help to circumvent experimentation. That btw. makes me wonder why the firmware currently does not derive calib_scan_distance from the number of pole pairs on its own?

No problem! Glad to hear that it works!

We could do that, but in general the various firmware classes (like Motor, Encoder) are designed to not depend heavily on each other. This allows for more flexibility. It’s true that all of them are interrelated by virtue of controlling a motor, but conceptually they exist independently. However, changing parameters like calib_scan_distance based on motor parameters is a good idea, and is a feature that will show up in the GUI.

The development idea now is that the ODrive parameters are an API that the user need not interact with directly. Instead, pesky real-world details like calib_scan_range depending on pole pairs, etc, will be handled by higher level software like the GUI to be easier to use. There’s a lot of work to do on that front, but I figured this point warranted explanation.

1 Like