Hi, we are using 10pole motors with 8192 incremental encoders with index. I have noticed that there are times when I save the calibration, it does not work on restart. However, a new full cal always allows the motor to run properly. I can see the encoder parameters getting saved and recalled properly. I do notice the encoder offset changing. Is this a problem others experience?
Sometimes it works. It has worked for the motor / encoder combination, like this exact set. But now is broken.
You probably have some noise that is spuriously triggering the index signal. Try adding small valued capacitors (22nF) between each encoder signal and GND.
Also try using the ferrite rings from the shop.
Are you saying that the calibration is corrupt?
I guess what I am wondering, is why the motor can run for days on end just fine, until I reboot the odrive. Does the odrive only use the index signal once? Also, I have other motors that experience this. The behavior is tied to calibration cycles. It is not random.
The calibration is fine, but the index search has failed. The initialisation of the motor position using the index pulse gave an incorrect offset, because noise caused a signal to be seen in the index wire before the real index pulse (is my guess)
Yes, the ODrive only needs the index signal once.
The âFULL_CALIBRATION_SEQUENCEâ does two things:
Firstly, it runs MOTOR_CALIBRATION which measures the resistance and inductance of the motor.
Secondly, it runs ENCODER_OFFSET_CALIBRATION which micro-steps the motor in open loop, at the configured calibration_current, moving it by the configured âcalib_scan_distanceâ.
This checks that the encoder CPR is consistent with the pole_pairs and sets encoder.config.offset so that âzeroâ is aligned with the start of the electrical cycle.
If an index is configured, then it will also store the offset between the index pulse and this zero position, so that next time it boots up, you only need to run INDEX_SEARCH, not ENCODER_OFFSET_CALIBRATION. This is useful because ENCODER_OFFSET_CALIBRATION is open loop, and only works if there is no mechanical load on the motor.
So when you reset the ODrive, you would normally need to run INDEX_SEARCH. This still moves the motor in open loop, but it can tolerate a lot more mechanical load than ENCODER_OFFSET_CALIBRATION.
Or alternatively you can move the motor by hand until it sees an index pulse, which will initialise its zero position until you reboot again.
But if there is noise between rebooting and finding an index pulse, it may set the wrong offset.
Can you post your encoder.config ?
OK, I looked through the FW. I see this at the end of enc_index_cb:
GPIO_unsubscribe(hw_config_.index_port, hw_config_.index_pin);
Is it really true that the encoder index pulse is used only once? Or am I missing something here
Isnât this a huge weakness in a differential encoder system?
Itâs a weakness of incremental encoders, yes.
To get around it, use an absolute encoder. 
wow, I am kinda surprised the odrive would throw away valuable information about the state of the motor simply to avoid processing it
ok, that helps explain things a lot. Thanks
itâs not valuable information if the encoder is working properly.
If I see an index pulse on my 8192 pulse encoder, then I can guarantee to see another one in 8192 AB pulses time. If itâs working properly.
The best you could do with it is throw an error if it arrives out of place.
I was wondering about this myself. I agree with @Jason_Lewis.
In other motor controllers Iâm familiar with the index signal is used to monitor whether the encoder is slipping. Often times there is also a user setting to ignore this, throw an error and log the offset, or update/correct the offset.
It really helps people debug issues with encoder noise.
Yeah, this is something that we want to add but other things have taken priority. Pull requests are always welcome
OK, so I messed around with this thing some today after it failed again in the field.
The caps alone do not work - I am not a fan of this solution either as it increases strain on the emitter and noise from the emitter itself. Not much different noise signature. Performance is worse, motor is no longer able to calibrate.
I am using a shielded encoder cable already, so I decided to reduce the aggressor and braid and shield the motor wires. Maybe 6dB better noise signature. Motor is able to calibrate, but field performance is degraded. Needed to recal motor once in the field.
added RC filter network at the Odrive termination of the cable. I used 1nF, 672 ohms. Probably 10X improvement in observed noise, now motor calibrated reliably again. Please note that my noise is rining at about 40MHz. Also, strangely, the noise gets like 50% worse when the motor is stationary. Is this due to lossy switching, ringing or something?
HOWEVER, I SEE UNEXPLAINED BEHAVIOR NOW:
the calibration now oscillates between -5191 and -4372. I get the delta, it is 819 or one pole. The measurements are repetable 4X and split with a 50-50 chance. Kind of surprised by this, is the phase 0 not fixed to the stator?
All in all, I do not understand the strong push for absolute encoders while Odrive continues to sell boards and applications using differential encoders. Especially since very little effort has been given on the firmware or hardware to support the changes that would make differential encoders stable. The fact alone that the odrive ignores the index means the design cannot be used as is in production because it requires a perfect encoder channel with no noise which is pretty much guaranteed not to be feasible due to the 2 channel board requiring cabling. Please keep in mind that despite these weaknesses, I am a big fan of this card. It is a cost effective motor driver, and more importantly, the motor driver section works. You are not as far from a reliable system as you think.
I shouldnât say very little effort has been given to support differential encoders. What I am trying to say, is that with a minor board spin, or a daughter card that plugs into the odrive that lets you add filters easily and some FW work, it seems this card could be OK.
I would say probably most ODrive applications are not in CNC, theyâre in robots where calibration cannot happen easily. In these applications, users ask for zero-movement at start, which requires single-turn absolute encoders (or encoders with backup batteries but why bother).
ODrive does not sell or officially support differential encoders⌠Do you mean quadrature encoders? We do recommend adding a daughter board with an SN75 differential transceiver if you want to use a differential encoder - that has much better drive strength and wonât suffer from the noise issues. Use proper line termination etc. I have a prototype differential encoder board you can try if youâre interested?
When itâs oscillating around 0 itâs probably commanding + torque and then - torque. Not sure if that makes things worse but I could see it. Iâve seen very aggressive tuning cause problems here. You can try the gain scheduling parameters.
What encoders are you using? Weâve seen issues with certain weak NPN encoders struggling to pull down the line (pull-up resistors sized for 1mA pull up max). I canât remember if there are RC filters on the inputs or notâŚ
ODrive applies a constant current to align the motor to the nearest pole before it starts to move the calibration. But it tracks the encoder position from the time the board is turned on (or the index is found), not from the point of this âlock-inâ. So itâs possible that sometimes itâs locking to one pole or the other if itâs on the edge of stability right there. I think that answers your question?
Yeah, my terms are a bit confusing, by âdifferentialâ, what I mean is the quadrature incremental encoder that is commonly recommended for use with the board. Yes, we are interested in a differential daughter card. I assume you have one that mounts to the encoder as well? Can you send me links to the specs?
I was assuming the same thing about the motor calibration moving by one pole, but is the cal still guaranteed to work in the case where it goes to the other pole?
We are not a CNC application, but an autonomous robot. We are very sensitive to calibration and index searches. However, our robot is powered all the time. We are still early and piloting our system so we are heavily focused on mission, and getting the robot started is not our biggest problem, but is rapidly bubbling up. Instability in the odrive is one of our biggest issues, with the motors overheating due to lost cal being number one. It only happens on our drivetrain. We still see other bad issues such as locked up USB interfaces, lost flash, and devices that need reflashing as well. Our next build of the odrive FW will remove config flash altogether because in our experiece, the config flash is not reliable at all. We can share what we learn aobut the impact of this change.
by remove config flash, I mean remove the config flash erase and write logic
Oh, we are using CUI 103
I will share a point about this encoder, the latest shipment we got from Digikey has a fitment issue between the base and encoder. In short, it will not snap in properly.