I have the following set:
ODrive 56V v3.6
D6374 motor with 10cm lever attached to its shaft
AS5047p (AB mode; cpr=4000) encoder
20Amps power supply.
rc-v0.5.5
When I move the motor shaft out of the balanced position the motor counteracts
(trying to move its shaft back to the origin),
I can feel that torque produced by the motor is ⌠how to say⌠not smooth
Which parameters should I change to get the smoothest possible torque?
(to make my motor torque similar to a spring?)
Which parameters should I change to get:
odrv0.axis0.controller.start_anticogging_calibration()
working?
any examples? is there any parameter I should take into account (no. of pole pairs?)
I have to produce quite significant torque (35kgx10cm) most probably I will have to use a gearbox.
(the gearbox should be âŚreversible? - when I move the last gear I should be able to move the motor shaft. I think 10:1 chain drive will do).
Which parameters should be changed to play with spring parameters of the motor?
(pos_gain, vel_gain, vel_integrator_gain?)
no errors.
I tried different combinations of:
pos_gain(10/20/50/10/150/200)
vel_gain(1/5/7/10/50)
vel_integrator_gain(1/10/50/150)
the shaft is slowly moving back and forth (eventually doing a full revolution)
when I call odrv0.axis0.controller.start_anticogging_calibration() function, odrivetool goes to a new line immediately:
In [xx]:
when I check: odrv0.axis.controller.anticogging_valid after a while (even 12minutes) I always get False.
Ideally youâd use a motor that doesnât have iron in it, i.e. âslotlessâ âcorelessâ âironlessâ etc.
e.g. AFPM motors designed for wind turbines
No, this is probably the opposite of what you want. E-Bike motors (like mine) have quite a high cogging torque. Although the inertia is usually so high that you donât notice it. They also have a lot of magnetic hysteresis drag.
Unless it specifically says slotless/coreless/ironless, then itâs most likely a standard radial-flux motor with straight iron slots, because that produces the most power for a given volume. (volumetric power density)
Yes, same thing. They are current/torque transducers. Both are quantities that can be positive or negative
If you reverse the current, you reverse the torque, and so you reverse the flow of energy (if you donât also reverse the velocity)
If you pick the 48V motor, then you will get maximum efficiency (because resistive power loss goes with the square of current) but beware that you might not be able to reach the rated RPM with the ODrive (because the ODrive limits the applied voltage to 80% of the supply voltage) so you might want to pick a slightly higher rated RPM than you need, or use a lower voltage motor and drive it with a higher voltage - itâll be fine since the ODrive controls the current.
If you also pick the lowest RPM rating too, then you get the highest âtorque efficiencyâ i.e. it costs very little energy to hold a static load - i.e. closest to a real spring. But obviously it canât move very fast. If you are interested mainly in low speed / static conditions and high efficiency, then go with the 130RPM 48V motor (i.e. lowest âKvâ, highest âKtâ). This has both the highest torque AND lowest power demands, in theory.
That said, the ODrive is designed for higher currents closer to standard hobby motors. There are a couple other threads where people have needed to change the shunt resistors in order to get good control performance in the 10A range. So if you donât want to do that, go for a lower voltage motor and/or a higher speed motor. (increased âKvâ, decreased âKtâ. The velocity constant of a motor is actually the inverse of the torque constant if you use the right units
Itâs not so much how much power the motor will âdrawâ itâs more about how much power you can put into it before it overheats. The 100W figure is probably quoted as a generator (i.e. it can usefully provide 100W power output when backdriven). That means as a motor you can probably send more than that (but youâd get 100W of mechanical output) assuming the efficiency is the same.
Your calculations are roughly correct, but remember that you can always run the ODrive at a higher DC voltage than the motor needs. It will regulate the voltage & current by itself i.e. you can run a 12V motor from a 48V supply with the ODrive, and it would send 4A to the motor while drawing not much more than 1A from the supply.
The âspring parametersâ are force/displacement. But the controller is a nested velocity controller inside a position controller. If you set the velocity integrator to zero, then Iâd guess your spring constant should be proportional to the product of the position gain, the velocity gain and the motorâs torque constant Kt.
YES, anticogging would help on your current setup. Try that first
ok. First Iâm gonna try anticogging feature however It doesnt work in my setup
I dont get any dump_errors,
When I call anticogging function it seems to do nothing.
Any idea which parameters I should change to make it working?
Probably, you have too much noise on your encoder. You need to increase controller.anticogging.config.in_position_tolerance (or something like that)
Basically the velocity must be zero and the position be correct to a certain number of coutnts and counts/sec to move on to the next step of the calibration. If you have a high-res encoder with some noise on the lower bits, that will get stuck.
You can see controller.anticogging.calibration_step (or something like that) increasing as it moves around the rotation. Once it reaches the encoder resolution (ie one rotation) itâs done.
odrv0.axis0.controller.config.anticogging.calib_pos_treshold
?
default value is 1.0
what should be the behaviour of motor during anticogging calibration?
(one smooth revolution?)
with all ODrive parameters set to default (exept cpr), the motor goes nicely through FULL CALIB,
than in anticogging calib it slowly moves forward (with some back and forth movements), it takes a couple of minutes to do the full revolution.
Thatâs the one. Increase that to 2, 3, 4 or whatever until it starts to move. If itâs already moving at 1.0, leave it alone.
Is there also a vel_calib_threshold?
Yes it should go through one whole revolution, unless theyâve since improved it to do multiple revolutions forwards and back (as it really should)
When itâs finished and returned to normal operation, you can set anticogging_active to true, put it in current control mode at zero, and give it a turn by hand to see if you can feel any improvement.
in a closed_loop i start anticogging calib, and during this calib I can change all necessary parameters, right? or I have to stop, change parameters and start again?
You can change them during the process, but if you do, Iâd probably run it once more when it finishes so that the whole table is created with the same settings.
erase_config()
set cpr = 4000
full calib
closed loop
and
start_anticogging_calibration() - does nothing,
When I changed pos_gain from 20(default) to 200 the rotor started to move.
It takes a couple of minutes to finish the calibration (one revolution).
is that normal?
Are anticogging_calibration results always the same?
(or maybe they depend on my gain, vel etcâŚsettings?)
is it possible to make it sometimes better sometimes worse (depending on my odrive settings)?
after a couple of minutes:
odrv0.axis0.controller.anticogging_valid ======> TRUE
is it normal that when I rotate the motor (current_control mode = 0) to one direction (same direction as during anticogging calib) the force I feel on the shaft is different then when I rotate the shaft to the opposite direction?
(it is easier to rotate the shaft to the ârightâ than to the âleftâ)
is it possible to store anticogging_calibration?
(It looks like it is . after save_configuration() and reboot, I changed anticogging_valid = True (was false), and when I toggle between
anticogging_enabled = True/False I can feel a difference; or maybe It was a power of suggestion )
Read through this blog post, and pay special attention to the picture in chapter 5. To summarize, the larger the least-common-denominator of your magnetic + winding poles the less cogging torque you will have.
Also be careful with the anti-cogging function. Compensating for cogging torque requires additional control effort, which increases the likelyhood of overheating your board or motor.
Hmm, does it? Iâm not following you there.
Yes, cogging is a âtorque disturbanceâ as a function of position, and anticogging is a âcurrent disturbanceâ as a function of position. But it applies to the demand input of the current controller, not the actual output. Iâm not sure how it would affect its stability or envelope. The configured current limit should still be in force, for example.
The reason I mention it is primarily annecdotal. I burnt out one of my boards running the anti-cogging software. My motor had very high cogging torque, and maintaining position during the anti-cogging-calibration algorithm required relatively high continuous currents (and control effort). My normal use-case didnât require accuracy between âcogâsâ, so I wasnât familiar with the power required to hold these positions. In the end I moved to motors with less cogging torque, and I realised it was something I should have done earlier.
Guys, coming back to my question,
I would appreciate your further help:
Are anticogging_calibration results always the same?
(or maybe they depend on my gain, vel, otherâŚsettings?)
is it possible to make it sometimes better sometimes worse (depending on my odrive settings)?
What should I do to get the best anticogging calibration results?
Im gonna use anticogging feature in POSITION_CONTROL, are there any limitations?
(I think Ive read somewhere about current_control&anticogging limitations)
(I need to set a zero position, than rotate (by hand) the shaft by ~3 revolutions, and It should come back to the origin)
in the position_control mode:
pos_gain - âcoresponds to the accuracy of setting present positionâ
vel_gain - âproportional to the strength of the motor shaft - currentâ
vel_integrator_gain -âcorresponds to origin position overshootingâ
is that ~correct?
is there anything else I could tune to get the smoothest motor shaft behavior in the position_control mode (motor shaft rotated by hand from its zero position)
i think that when using anticogging feature, motor shaft respons to manual-hand disturbance is different in left vs right direction
)