No I agree completely actually but I see a two stage here like mentioned above. The simple one is the step dir approach and then one can proceed to the next step doing it right with a direct connection to the pi / klipper.
With the step dir approach I think it means one depends on klipper software to compute those profiles (it uses Scurve as far as I understood).
My guess is that as long as there are a lot of small steps sent to the Odrive (with a high frequency) the inertia of the system will allow the Odrive to generate a smooth movement. A bit like Robo mentions to solve his cogging issue.
To give an idea of what can more or less be achieved here since numbers from klipper:
It’s a test so no real case but the SKR I was referring to is the last one. So I think a multi / many kHz step signal is no issue and should give smooth running?
The Step/Dir interface is designed to directly mimic a standard stepper motor driver, so yes, the Klipper software will calculate the trajectories and such just as it would for stepper motors. There is no communication back to the Klipper software from the ODrive. This has no relation to the cogging torque issue, that has to do with the closed loop control that is happening within the ODrive.
That’s interesting when reading I think the Scurve from Kipper is a higher order filter actually. Could it perhaps interfere if the pulse train is high frequent enough with consequently small position steps? For sure it will help when the position steps increase, giving less “jerk” behavior!
Well guys: I’m all enthusiastic about using the Odrive! Gonna buy me one once I’m back from vacation!
I’m really interested to see where this project goes. I wanted to start something similar one year ago and started a discussion here:
In the end I went with Klipper and an SKR Pro Board with TMC5160 drivers running at 48V and Nema 24 steppers. This also gives an incredible performance at much less complexity. Of course, the energy consumption is much higher, but it works fine for me.
The reason I did not go along with odrive, was that Step/Dir was the only method to get the trajectory information out of a trajectory planner like Klipper or any other 3D-printer firmware.
My conclusion was that odrive is great for driving one or several individual axis in real time, but what I needed was a coordinated, pre-planned movement of several coupled axis at the same time which obeyed certain restrictions like speed- and acceleration-limits. 3D printer firmwares were the only things that could do that.
In theory, Klipper would be the perfect software to pre-calculate the trajectory and odrive would be the perfect solution, to drive servos. Both of them together would be able to make much more performance oriented and quieter 3D-printers, but currently there is no good way to transfer the pre-calculated trajectorys from Klipper to odrive, besides the “better than nothing” Step/Dir interface.
Thanks marine from space. I’m getting quite excited about trying. If all were to fail I can always replace with a stepper, so I see only positive things in trying the Odrive with a lot of potential improvement over those steppers
I can get a good deal on Tarot 6S 380KV 4008 4108 motors. They seem perfect for the job (?) and documented on Odrive. But I’m a clear novice and wonder how to:
connect the encoder in the back when it doesn’t have a second shaft sticking out? This is obviously very novice question, but I thought I’d ask anyways.
if it makes sense to mount the motor with a coupling as it doesn’t have a shaft coming out either and I fear misalignment with an adapter with shaft. Does anyone have an example setup perhaps on a Tarot?
I’ve also been thinking about the input filter for the step / dir. I found following on the step / dir interface.
There is also a config variable called <axis>.config.counts_per_step , which specifies how many encoder counts a “step” corresponds to. It can be any floating point value. The maximum step rate is pending tests, but it should handle at least 50kHz. If you want to test it, please be aware that the failure mode on too high step rates is expected to be that the motors shuts down and coasts.
So I wonder at what frequency the Odrive drives the Servos? Probably higher than that, so the input filter makes sense for sure.
So I didn’t give it too much thought at first, but what is really meant with a second order filter? Is the filter meant to upsample the signal to the Odrive control frequency?
I ask as I imagine stepper drivers do something similar with the incomming signal from the controller…
Most definitely, I am using ODrive at 12v for CNC and it doesn’t even remotely get warm. I’m using an Arduino Mega 2560 only and controlling the ODrive over serial, not step/dir.
I did exactly this, I have a bench power supply connected directly to a 12v lead acid battery (75Ah) and this connected to the ODrive (power in port) with its supplied resistor in the brake resistor port. I get around 65000 cps max velocity (with AMT-102, 8192cpr) without the battery and over 300,000 cps with the battery.
Also, without the battery I had a lot of current unstable messages due to low voltage dropout, something I never get on batteries.
Now I have my ODrive CNC machine running off 12v batteries and a 50W Solar Panel ;-D.
You wouldn’t connect it in place of the resistor, you’d connect it as you originally suggested, in parallel with the power supply. You can leave the brake resistor in place, and just set its resistance value to 0 in the config, which means it won’t use it, and will instead send regen energy to the battery.
Using a bench power supply you can adjust the voltage and current limit so that it doesn’t overcharge the battery, although a dedicated lead-acid trickle charger might be better (and cheaper). And a lead-acid battery won’t explode in flames when you overcharge it. (it does give off a bit of Hydrogen gas, though!)
The battery will also prevent the voltage rising too much on regen braking, which would otherwise bork your power supply. So I can see that it does make sense (although a large capacitor would also do fine). 75Ah seems a bit overkill though!
You are right - it can help precision in some cases. I just realised why on this thread:
If you are getting to the point where you need a higher current control bandwith than the controller can provide (i.e. >4kHz) then adding inertia can help, by essentially making the motor more sluggish to move so you don’t need such fast reactions from the controller. But it’s probably an unusual case for ODrive, which runs at low voltages where the inductance is probably the biggest limiting factor for current control bandwidth.
I’m checking your youtube movies Dev, thans for posting. Really interesting and helpful.
So cool to know that as Robo found, inertia can help to keep the motor from cogging and I imagine it can also help to improve the smoothness of operation when the Step / Dir is not really giving a high enough (frequent) pulse train. I’m now trying to find out how many steps I may expect when running an SKR with Klipper. But so easy to find the info though.
Also I’m still very interested in the filter function on the Odrive. Hope @Wetmelon can share more insight if it is indeed an upsampling of the pulse train or if the second order filter has another purpose.
And I hope I can fit an encoder on the Tarot motor?
Ok I did some more homework on my current Duet3 and I can expect to send up 120k pulses per second to the Odrive and even more if I could use the driver output wires (the A B etc) if I put in some kind of logic electronics in to get the step / dir back and eat the current?
But I would think 120k pulses per sec would be enough as it will give me a max speed of about 500mm/s print speed on a 8192 encoder sending a step for each countbwhich is more then enough right?
Ok I bought Tarot 4108 laat week and just now the Odrive. I’m still puzzling on the power supply a bit as there are so many options though. But at least now I understand what can be used in order not to blow up batteries and Odrives
Still figured what encoder to buy. To be honest I would like it best to place it on the pulley then on motor at some point as discussed elsewhere on the forum.
I recogn I’d have about 10 to 15 rotations a sec maximum. It is normal to zero 3D printers, so that would be fine for me.
Encoder on a pulley is a bad idea. If the belt slips over time your machine will go out of position, lose torque, and eventually the drive will fail to commutate the motor. You could also get into a really nasty dynamic oscillation if sudden acceleration of the motor causes the belt to stretch, even by a tiny bit.
Can’t you mount something like an AS5047p to the back of the motor?
I will start with encoder on the shaft die sure. Yet in the end I’d like to put it on the pulley. Gate belts don’t slip with they teeth and all and are (relatively) stiff. I computed first resonance frequency of the setup in the order of 120Hz. Should be possible to get a stable feedback on it would be my guess abs in the other thread I read the motor and pulley could get out of sync multiple degrees so feels like possible in principle? But you are right, I should start with the basics!
What is the best way to glue (?) a magnet on the rear end shaft of the motor? And how important is alignment of the magnet on the center of the shaft for encoder performance?
In my experience, the alignment of the magnet is not very important at all! The sensors are extremely tolerant of a magnet that has been superglued on the piss, or a sensor that is mounted slightly off axis.
Superglue tends to work well for me, because I can remove it if necessary. Maybe for speeds of 10krpm+ you might want to be more careful, but only to avoid the magnet pinging off.
.