AS5047P encoder on the reducer

[alireza_abdolkarimi]

Hi. my project is using motor with 100:1 reducer and AS5047P as an encoder which connected to the reducer not the motor.
My motor has 14 magnets and in my case i set the pole pairs to 700 to create a virtual motor (100 times bigger than the real motor).
I use TobinHall’s branch and set the encoder cpr on 16384. But when it goes to encoder offset calibration it throws the ERROR_CONTROL_DEADLINE_MISSED and ERROR_MOTOR_DISARMED errors without turning the motor.
when i reduce pole pair to 70 and send encoder offset calibration request, it turns the motor and throws ERROR_CPR_OUT_OF_RANGE error which is correct. But i don’t know why when i set the pole pair more than 200~300 , it throws ERROR_CONTROL_DEADLINE_MISSED error!
In addition i have tested the 100:1 reducer with incremental encoder and it was ok. i put the cpr on 1000000 and the pole pair on 700 and it was ok and had no problem.

[towen]

Alireza,

The AS5047P has 4096 counts/rev. If you divide this by 100 then you have only 41 counts per motor revolution. In terms of pole count, only 5-6 counts per pole. No wonder your motor is not controllable!

With your 1 million CPR encoder you would have 1428 counts per pole, which is plenty enough resolution, but your performance will still be bad with no encoder on the motor.

Moreover, I suggest that you calculate how much backlash you have in your gearbox, compare it to the motor’s movement around one pole, and consider the effect this alone is having on the controllability of your motor in this system.

I would suggest that you put an encoder on the motor. You can keep your AS5047P on the load/gearbox, as some of the development branches of ODrive allow you to use two encoders, including the SPI interface of the AS5047P.

[alireza_abdolkarimi]

Hi Towen . Thanks for your solution.
based on your solution i think it’s good to put an incremental encoder on motor and put absolute encoder on the gearbox. then i use another processor to read the absolute encoder’s value on startup and set the value on Odrive by set_linear_count function. then Odrive work with incremental encoder after startup.
So if i want to not use other processor to set the position on startup, do you know any branch which can handle both encoders?

cheers

[towen]

Hi Alireza,

It seems I was mistaken when I said there was a branch that did this already
TobinHall’s branch which you are already using can read the absolute encoder over SPI, but unfortunately it replaces the incremental encoder rather than augmenting it.

What you want is the feature described here:

2 encoders per Motor - before & after gearbox - for backlash/stiffness compensation

Hi, I’ll be using Odrive motors with 1:80 reduction. Precision after the reduction is key to me and i know that the reduction has some backlash and isn’t perfectly stiff. I wanted to use 2 encoders per motor (4 per Odrive): first - directly on the motor - for commutation, speed and acceleration control; second after the reduction for position control What is the best way to solve this, Is it possible to ad it all on the Odrive, or will I be forced to use an arduino for the encoders after red…

This was 6 months ago, however it doesn’t seem to be implemented yet as far as I can tell.
It should be fairly simple to implement a secondary encoder class, based on TobinHall’s code for the AS5047P, which feeds the position controller without touching the velocity or current controllers.
If you are comfortable hacking the firmware, you could try it yourself…

Cheers,
Tom

[towen]

I wasn’t mistaken, there is support for this, but it is still very much in-development.
Dual-encoders was added to the RazorsFrozen branch of the mainline repo as of this commit

So, try switching to RazorsEdge and see what performance you can get. Good luck
note that as of now you will probably have to sacrifice one axis i.e. it hasn’t been integrated with the SPI encoder stuff yet, so you would need to use the incremental interface from the other axis.

[alireza_abdolkarimi]

Thank you Towen. i will check them. but what is clear, is that they use two incremental encoder instead of absolute one.
In addition i was reading the configuration of hoverboard motor in this page and i figured out that there is only 90 cpr for 15 pole pair on hoverboard motors which is only 6 state for each pole pair. so why isn’t there any error in encoder offset calibration for hoverboard motor? but there is error for me with 700 pole pairs?

[towen]

The 90 cpr encoder you mentioned is a hall sensor. This is the absolute bare minimum resolution that you need to drive a motor, but hall sensors only work because they are precisely aligned with the motor coils. A normal encoder at the same resolution will not work. Also, hall sensors or low resolution encoders are not very useful to the control algorithms of the ODrive. It is designed to work with a high resolution encoder on the motor.
When you put an encoder on your motor, you will be able to configure the correct number of pole pairs.