I’m working on a robot that can’t have a calibration move and the motors I have don’t have index. I could add an index but I am trying to figure out if I can get around it.
I built the blind-openloop branch of the code, it wouldn’t connect, so I copied some of the code from the communication files in the newest branch, it built, flashed, and would run, but it was exactly like the normal firmware, if the index is off it can’t start up in closed-loop mode.
I have searched for existing answers, and I know people say you can’t run closed loop without an index or a calibration start, or it will run out of control. But this is a vehicle, not a CNC machine.
Would it make sense to try to make it start out in sensorless mode, and then fall into closed loop as soon as it can get the encoders?
Is it really not possible for it to just do speed control without an absolute index? My system already reads the initial position and accumulates the offset from there.
I did try just disabling the checks for an index in code, but it really did spin on startup, or lock in place. But I’m confused that this would be impossible to avoid without an index or starting with a calibration move, because many motor drivers can do that. For example, VESCs do it, I’ve used them for this many times, and they still run PID (although not as smooth as Odrive, which is why I’m trying to use this)
I’m not saying there isn’t a good reason, but if there is I’d like to know what it is in more detail. If there are any possible workarounds I might try to code I’d like to hear about them.
Hi,
You need some sort of reference to know the angle of the rotor so you can do accurate commutation. I.e. you need to know where the rotor magnets are.
This can be done either with a calibration, or with some sort of absolute reference such as an index or an absolute encoder (which include Hall sensors).
It is possible to bootstrap an incremental encoder without index using poor commutation initially followed by sensorless tracking once spinning fast, and then seed the encoder offset with that information. However that sequence is fairly complicated and we found that not many people are looking for something like that so it hasn’t been a priority.
fall into closed loop as soon as it can get the encoders?
What does “get the encoders” mean? What encoder do you have? Incremental without index or something else? What is the resolution? Do you have hall sensors?
The motor is a wheel hub motor, it has hall sensors and a 3200 ppr AB encoder. Are there settings (or firmware changes) where I can use halls and an encoder to power on and start without calibration or an index?
My immediate solution is to install a hall sensor, I tested it out on one of the motors and it works great. Smoother operation than I’ve gotten on these wheel motors with any other driver in fact.
If I can get around this in settings and firmware with a reliable start even if the torque is lower, it will save me a ton of time making and attaching hall sensor mounts. The robot will always start on a flat smooth floor so the lower torque would be ok.
For later revisions I can order motors with an index, but I was put on this project with robot bases already fabricated and motors already on hand, so a firmware/settings change to accommodate the ones I have without modification is worth the effort to me.
Motor details:
Approximate diameter of rolling surface: 170mm
27 poles and 1.7Ω winding resistance
Integrated 3200 PPR quadrature encoder
Operating voltage: 7-42V (takes 3-8 amps in my testing)