The best way to skip the index search is to use magnetic absolute encoders e.g. AS5047p connected over SPI.
The dev-kit I linked is well-supported by ODrive (I use them for everything) and it also includes the special magnet (diametrically-polarised disc magnet) that you need.
Sensorless is not really sensorless - it uses the motor itself as a sensor, but a motor is a “rate of change of magnetic flux” sensor i.e. it can only work when it is moving, ideally moving very fast. There’s no such thing as a free lunch, and there’s a reason that sensorless is only really used for propellers.
So the first problem with sensorless is that it cannot work at low speeds (anything below 1000 rpm) because the voltage signal is too low to be measured by the controller. If you used a KV 200 motor, then at 1000 RPM, the back-EMF voltage is 5 volts, which is just about significant enough to measure.
The other problem with sensorless is that the commutation estimator is not perfect, so it will frequently go out of position, (i.e. if you spin it 1000 turns one way and 1000 turns back, don’t expect the position counter to be zero).
It cannot hold position at zero speeed (because it only works above 1000 rpm) and as such, position control mode (which I think you ate using) is not supported at all in sensorless mode. It is basically completely useless for any application where precision is required.
You could use it for a fast re-spool machine, but that’s about it.
Edit: Just read the bit about the stepper motor. That’s sad that you are no longer using ODrive for the precision part.
If all you need is a torque, and not an especially precise torque, then maaybe sensorless could work in theory, but everything I said still applies - it doesn’t work at low speeds, and it would have to drop back to lockin mode if the signal is too low from the motor. That means that it would drop out and stop providing torque. Normally the ODrive would try to spin the motor open-loop until it gets a good enough signal, but you don’t want that, its worse than doing the index search, and it would occur any time that you drop to a speed too low for sensorless.
So I’d recommend to either stick with your current set-up and run the index search, or get some absolute encoders.
Will making a 3D Printed bracket for mounting work? Or maybe there’s a mounting bracket that can be bought?
I assume once these are installed, I just run a full calibration sequence and save the results to odrive and that’s it? no more index search will be really cool for my application.
I really tried - I was trying to avoid adding more hardware to my machine maybe in the future I could try again but everything we tried had an oscillation and it wasn’t perfectly smooth, it would get progressively worst as the roll unspooled - it was not a smooth ride unfortunately.
By introducing the capstan, the velocity curve is now completely flat without any oscillation, I could probably capture sound in real time when using the correct frequency.
Now all we need to control with Odrive is torque value. Since this value is based on the circumference of a roll, we are now entering the roll size manually in the MCU when initializing a new roll of film. I have proximity sensors coming that I might point at the roll and auto-detect the size - will try this week.
The odrive is still doing a great job and it saves me a lot of headache!
Thanks for all the in-depth explanation, you helped me a lot making this project.
Yes and yes. A simple 3D printed bracket works well. The height and alignment to the magnet are important but not super tight tolerance.
With these encoders you can save everything to the ODrive and there is no need for index search, you can even set startup_closed_loop_control=True. You need to wire up the SPI signals, not the A/B/Z though obviously, and you need to change your encoder config to use them. But it should all be covered by the SPI encoder guide.
Got the kits and it works but I had a major issue and I’m not sure why.
I followed the guide you linked, swapped the resistor on the board to enable 3.3v (that’s a damn small resistor) and powered the machine.
Did a initial / testing calibration without issues and played with the machine a bit. It’s so great to be able to turn on the machine and not having to index search - game changer here.
Then I had to remove the reels (the platters that are hooked up to each motor shafts, so I decided to do a proper calibration and I was getting errors all over the place, random stuff, I didn’t even change or move any cable.
I was getting ENCODER_ERROR_ABS_SPI_COM_FAIL and Encoder not found errors randomly. I would save configuration, reboot, sometimes the ENCODER_ERROR_ABS_SPI_COM_FAIL error was there right after boot.
Tried everything and gave up at 2am.
So this am I wake up and try again, same calibration sequence… everything works flawless, so I calibrated, anti-cogging etc saved and now my machine is back up no index search needed.
I have no idea why this happened but it’s a little scary, any idea why this happened? I was tired, maybe i was doing dumb dumb things after a long day but as far as I’m concern nothing changed from last night to this am.
Are you using the ferrite rings? These SPI encoders are a bit more sensitive to noise than incremental ones, and the motors can act as big antennas if you don’t use the ferrites.
Make sure you have the latest firmware, there was an improvement recently that enabled some filtering on the chip to make it less susceptible to noise.
If you don’t want to change the firmware, you can add 50 Ohm resistors instead into the MISO, MOSI and SCK wires.
Currently the motors phase cables are breaded with 12 AWG wires. I will get big rings and add them.
I’m on 5.0.4 - Unfortunately I don’t know how to compile the firmware, I tried on Mac and failed miserably If there’s a compiled version somewhere would love to have a download link.
I’m totally down to upgrade firmware and do the calibration again - I prefer knowing that the issue is repeatable or fixed.
Have you tried odrivetool dfu with no parameters? That should autonatically fetch the latest compiled version for your board and flash it.
(be sure to back up your config first)
Also for the ferrites I would highly recommend using the ones from the shop - not all ferrite chokes are created equal, and these ones are particularly good at absorbing common-mode noise in the MHz-GHz range from inverter switching edges.
When running odrivetool dfu I get the message below, are you saying that it will install an incremental version of 5.0.4 with the fix in?
ODrive control utility v0.5.4
Waiting for ODrive...
Found ODrive 2061358B5748 (v3.6-56V) with firmware v0.5.4
Checking online for newest firmware... found v0.5.4
You are about to flash firmware v0.5.4 which is the same version as the firmware on the device (v0.5.4).
Do you want to flash this firmware anyway? [y/N]
Actually I found this one from the same company you guys use with same range (≤ 300 MHz
FM band range), just bigger ID to fit my 12AWG wires, that should be good right @towen ?
No, it will only install the latest… The fix I am talking about was only a couple of months ago.
I suppose it would be a fairly major change, but It is worth a try though, we have compiled binaries for a lot of old versions if you need to revert.
Otherwise, you’d have to apply it as a patch and compile it… I might be able to do that for you if I get time, or Paul might do it.
Yep that should be fine
Although I use 12AWG and even 10AWG with the stock one
Do you mean because of major changes the calibration sequence I use might be different and Arduino uart communications might not work without modifying code?
not sure I understand, would using “odrive tool dfu” revert to the 5.0.4 I’m currently using?
ah that’s good to know, I should be able to do 3 turns!
Would love some guidance on an issue I’m trying to resolve.
When a film roll completely unspools onto another, both reels start spinning fast because torque mode is still turned on for 1 second until the “no film detection” triggers and set odrive motors torque and vel to 0.
The odrive reel motors continue to spin because of inertia.
What I would like to know is how could I “brake” the reels to a stop? Right now I just use my hands and pinch the reels to a stop. If I let it spin it will stop spinning after a minute or so.
It does stop but it’s an abrupt stop because the reels are spinning freely due to inertia and it has no idea of what velocity it is at , so when velocity is set to zero, it cannot ramp down, it just stops on a dime.
Try lowering the gains for the velocity controller. set vel_integrator_gain to 0, and lower the proportional gain by quite a lot. (you aren’t using the position or velocity modes for anything else so doing this won’t affect your torque control)
When I rewind or forward at high velocity, with both motors in torque mode, sometimes the odrive stop working and I get this error:
In [19]: dump_errors(odrv0)
system: no error
axis0
axis: no error
motor: Error(s):
MOTOR_ERROR_UNKNOWN_TORQUE
MOTOR_ERROR_UNKNOWN_VOLTAGE_COMMAND
sensorless_estimator: no error
encoder: Error(s):
ENCODER_ERROR_ABS_SPI_COM_FAIL
controller: Error(s):
CONTROLLER_ERROR_INVALID_ESTIMATE
axis1
axis: no error
motor: no error
sensorless_estimator: no error
encoder: no error
controller: no error
This started to happen today, was fine before - what could this be?
so weird, it started happening more and more yesterday was able to run the machine all week without issues -
Thinking about it… I added two loadcells (on each reel) for measuring tension 2 days ago, which are close to the motors. Could this be interference? I think they are also SPI devices. I use the loadcells data to adjust torque values in realtime. Here are the load cell amps I use: https://www.sparkfun.com/products/13879
Would having shielded cables for both the SPI encoders and the LoadCells help me? Right now the SPI encoder cables are breaded and the loadcells cables are in a non isolate but thick sleeved 5 wire cable.
If I can’t make this work with the SPI encoders, would going back to index search encoders solve this issue? Would really love to keep SPI encoders because I’m spoiled being able to start the machine without index search and going back would be a real depressing situation.
Ok will try to move the cables a bit. I added the ferrite rings on the motor cables and did 3 turns. Should I add ferrite rings to encoder cables as well?
When I run odrivetool dfu it says I’m about to upgrade to 5.04 same version I already have so I didn’t do it - would you be able to send me a compiled firmware?
You had mentioned something about that in a post above and was not sure I understood what to do - if there’s a new 5.0.4(with the fix in) I’ll do that - Please let me know, otherwise I’m really stuck and would need help getting a compiled version.
That’s sad that you are no longer using ODrive for the precision part.
