Have spent a couple hours trying to get closed loop via spi magnet sensor smoother than open loop but no luck. I am using an ipower 5208 180t gimbal motor.
This is driving a belt driven turntable platter and while very stable, fair bit of cogging vibration is going into the turntable chassis.
Nothing would be smoother than open loop, it gets the speed straight from the MCU clock. Any closing of the loop will entail some oscillations, however minor, due to any noise or other issues.
Another way to think about it is that open loop is blindly throwing (wasting) energy into the coils, if you ask for an electrical position with loads of amps you are likely to get close to that position.
This seems to a be a huge problem for a lot of people. There are a few threads here looking into different ways of solving it. Right now the best way seems to be just to buy a less coggy motor, but this is not really a specification any motor vendor can really give you at this point. I would recommend just buying a handful of ones from different vendors and returning them if they don’t work for your case.
Cogging is not effected by open/closed loop so the control scheme would not help you here.
Yes there are, and they are specifically designed to operate with zero cogging but are really expensive. Use Google, search for “zero cogging motor”.
Cogging is a motor design flaw and has nothing to do with the simplefoc library.
Generally the more pole pairs the less the cogging.
There are actually methods that are described in the literature for more or less standard methods to measure cogging torque, it’s just not commonly done. You can just measure the peak to peak torque ripple, for instance.
I have posted on this forum a number of links to low cogging motors, some of which are only a few bucks on aliexpress. I use the JD-power 3505C motor, because I can’t use those cheap motors because the bearings are not replaceable but they should work for you.
A reasonably promising method to reduce cogging which is also reasonably simple is also to modify the waveform, possibly just by tampering with the sine wave lookup table. If you can ascertain what the torque ripple waveform looks like you could repeatedly just tweak the values in the sine lookup table by applying some kind of transform. There are some documents about doing this kind of thing, anti-cogging algorithms. There is a thread on the forum somewhere.
The easiest and cheapest is to get a motor that uses ceramic rings, a so called SM type motor, not the IP type. I don’t know why but they always seem to have a lot lower cogging torque.
edit: I can send you a bunch of the lowest-cogging motors, if you can’t find them on aliexpress any more, the stock changes all the time. I bought like 7 of them and was just earlier today trying to figure out how to not waste them.
That’s some great info! Will look into other motors as you mention. I am exquisitely useless at programming haha! So not sure if I could be effectual at modding the code but will have a peak. Thanks for helping out.
how do you know anything about the cogging torque? It says nothing.
edit: btw jd-power has a retail store, you don’t have to buy through alibaba, they will ship it by courier if you buy through alibaba which costs a lot.
I was just thinking that cogging as usually defined is due to the ferromagnetic attraction between the permanent magnets and the core material. However what we really want is a linear relationship between the angle of the 3 phase sine wave and the angular position of the motor, yes? Or between a value, X, which is the angle of a modified sine wave, and the rotor angle. I think there are probably several other probably more minor but also significant sources of deviation from the ideal that are not confined to ferromagnetic attraction between magnet and core material.
There is such a thing as a coreless motor, these are usually brushed motors but there is no good reason I know of you couldn’t make a coreless, brushless motor, and it wouldn’t be expensive. The copper coils are supposed to support themselves mechanically. This would theoretically eliminate that particular source of “cogging” by that definition. I have shopped for actual zero cogging motors and that does not appear to be how they do it, though. Probably because there are other sources of torque ripple that are not actually “cogging” by that definition. The anti-cogging methods I have seen described would also deal with these other sources of torque ripple, so that’s good.
These guys make coreless brushless motors, but I think their prices are in the “if you have to ask, you can’t afford it” range https://www.thingap.com/
Just to be clear, this won’t work: the sine wave LUT is just for computing sine/cosine values, in whatever context they are needed. It’s not suitable to use it for anti-cogging.
For computing and storing anti-cogging correction values, you would need a LUT indexed by (absolute) rotor position, typically with separate entries for forward and backwards direction.
Perhaps true if you assume the LUTs only purpose is the sin/cos calculation for the parke Clarke transforms. But that’s not the case. It’s a general sine function that is also usable in other contexts.
Also the torque ripple and cogging are generally functions of the rotors absolute position relative to the stator, while the parke Clarke transforms are used in the context of electrical revolutions, of which there are multiple per physical revolution.
I think it would be best to leave the sine LUT as it is, and create a separate LUT for compensation.
Yes, and there is no need modifying sine LUT values.
Subtracting certain harmonic (third in case of the stepper) can be calculated on the fly since formula is very simple:
a = 0…0.125 //so that there is no extra “troughs and valleys”
sin_comp = (1-a)sin(x) - a sin(3x)
cos_comp = (1-a)cos(x) + a cos(3x)
It would be interesting to determine how periodicity of the ripple in general depends on number of poles. For a stepper it can be expressed within electrical revolution, but maybe that’s special case.
Generally the correction schemes I’ve seen have different LUTs for forward and reverse directions.
The torque ripple depends partially on the physical construction of the motor…
But in the empirical tests I’ve done the ripple seems to correlate very strongly with the number of poles and has a large component that is regular and repeats per physical revolution.
So I actually like the idea of adding harmonics to the sine values (after the LUT). That makes sense to me, but I wonder how effective it winds up being?
I think a simple correction to the PWM out (very closely related to what we think of as the voltage waveform out) would only work well at one speed (well, a range, you know, an optimal point and then things returning to normal far from that point) and may mess things up even worse further from the optimal point (maybe not though(). However it would be a start. You could have many different LUTs for different speeds and stuff, I guess. Fundamentally I think making a crude mathematical model of all major sources of torque ripple is the best starting point. I don’t think what is technically called cogging by most authors I have read i.e. ferromagnetic attraction of the core to the magnets is the only major source.
One approach that could be a quick and dirty thing to do could be to just rig a motor to a disk with a modest known mass and an encoder and just plot the torque ripple and position vs electrical angle and see if a set of LUTs, each applying at certain speeds etc. could be useful. Maybe some means of smoothly transitioning between them. Could be written in micropython fairly easily, lots of data to handle. Some kind of algorithm that just adjusted the lut at each speed to minimize the de facto torque ripple. I was thinking of something like that for my fan. For a fan it could work as the load doesn’t change much but I could see it going south. I would definetely want to spend more time understanding salience and so forth first.