You should also reduce the torque as the spool gets smaller to keep a constant linear force. Torque is in newtons * metres. So you’d need to divide by the radius of the spool to get a linear force in Newtons. It’s exactly the inverse of what you have done for the velocity, so it should be pretty simple to adjust the input_torque of the other spool in the same way at the same time.
Not really, no.
You’d need two of them for a start since it’s single axis. And the programming features haven’t changed a great deal.
This would rely on having to input the roll size before running the machine correct? it would be impossible to sense the torque automatically. For the velocity, I use the pulses frequency from the laser sensor to regulate the velocity in real-time.
I think the new GUI would also help tune quicker, the old GUI is difficult to install - good to know I’m still good with 3.6 though.
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.
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