Constant tension / Velocity issue

[towen]

@robinojones

Also regarding tension, would it be possible to keep constant torque with my setup? Right now if I put a larger roll, the torque reel (left hand side when playing back) is set to 0.12 and because the reel is heavier the tension is looser at beginning of the roll. If I increase to a higher number torque value, the tension is fine at beginning but it gets to tight mid roll until end as it unspools.

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.

@robinojones

Do you guys think the new odrive would work better for my machine? Easier to implement?

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.

[Wetmelon]

@towen

And the programming features haven’t changed a great deal.

It does, however, support dual encoder.

But I agree, 3.6 is sufficient.

[robinojones]

@towen

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.

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.

@towen

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.

@Wetmelon

But I agree, 3.6 is sufficient.

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.

[towen]

@robinojones

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.

Correct. But if you do a bit of geometry, I think you should be able to prove that the same correction factor that you need for the velocity also applies to the torque, just the inverse.

[robinojones]

@towen @Wetmelon Thanks for your help, I now have good speed regulation in my code

Trying to figure out how to trigger an index search when I press a hardware button on my machine but I can’t figure out what command to use.

This is the syntax I use in my Arduino code which works great:

examples:

_reel1.write(“controller.config.input_mode”, 1);
_reel0.write(“controller.config.pos_gain”, 20);

What should I put between the quotes to run an index search?

thanks!

[Wetmelon]

"axis.requested_state", 6

https://docs.odriverobotics.com/v/latest/fibre_types/com_odriverobotics_ODrive.html#ODrive.Axis.AxisState.ENCODER_INDEX_SEARCH

[robinojones]

@Wetmelon

“axis.requested_state”, 6

That did it thanks very much!

[robinojones]

I’m able to trigger an “Index Search” via a hardware button, but when the code switches to “Closed Loop” after completing the Index Search, it does another index search.

This is the code I’m using:

void ReelController::calibration() {
  
// Start Index Search for both reels

delay(100);
  _reel1.write("requested_state", 6);
  _reel0.write("requested_state", 6);

// Wait 7 seconds
delay(7000);

// Set both reels to Closed Loop
  _reel1.write("requested_state", 8);
 _reel0.write("requested_state", 8);
}

Any recommendations?

[robinojones]

This was an issue with the button library I was using. it was running the loop twice.

Fixed now.

[robinojones]

Is it possible to run in sensorless mode / without encoders if I only use Torque Control?

I’ve since changed to a Capstan drive (using a stepper motor) and the odrive is now used to keep tension only.

Would love to be able to skip the index search. Is this possible? @Wetmelon @towen

[towen]

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.

[robinojones]

@towen

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.

I ordered 2 kits thanks for the link!

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.

@towen

Edit: Just read the bit about the stepper motor. That’s sad that you are no longer using ODrive for the precision part.

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.

[towen]

@robinojones

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.

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.

[robinojones]

@towen

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.

[robinojones]

If anyone needs a mount for the 5047P encoder and 5065 motors here’s the link to download the Fusion 360 Design.

Fusion

Self tapped with m2.5 screws.

I included a magnet orienter tool, you can add a mini drop of superglue on your magnet so it doesn’t move and then remove the tool.

[towen]

1. 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.
2. 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.
3. If you don’t want to change the firmware, you can add 50 Ohm resistors instead into the MISO, MOSI and SCK wires.

[robinojones]

@towen

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.

Currently the motors phase cables are breaded with 12 AWG wires. I will get big rings and add them.

@towen

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.

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.

@towen

If you don’t want to change the firmware, you can add 50 Ohm resistors instead into the MISO, MOSI and SCK wires.

I’m totally down to upgrade firmware and do the calibration again - I prefer knowing that the issue is repeatable or fixed.

Again thanks for your help @towen!

[towen]

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.

[robinojones]

@towen

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)

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] 

@towen

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.

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 ?

[towen]

@robinojones

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?

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.

@robinojones

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 ?

Yep that should be fine
Although I use 12AWG and even 10AWG with the stock one