Anyone interested in collaborating on anti-cogging (lowest hanging fruit for smoother motion)

Based on the experimentation I have undertaken, I think I will need anti-cogging functionality. I am trying to make a quiet fan, but the number two source of noise is the cogging of the motor. I have been able to determine this reliably by noting the noise level while the motor is coasting (thus, no noise caused by chopping of the electronics, which is the primary noise source, actual air turbulence/noise is number three).

I ordered a simplefoc board and angle sensor but it hasn’t arrived yet. I’m anticipating that using an angle sensor will naturally provide some anti-cogging tendency, as the system tries to produce smooth motion. However the PID control loop that is meant to provide the smooth motion will likely not be able to dampen the effects of cogging very well, due to response time limitations. It needs more predictive ability than a pid control loop can provide.

There are many papers on e.g. google scholar, which discuss algorithms and approaches for motor drivers to implement anti-cogging, and I think it fits in well with the high level goals of the simpleFOC project. I don’t have much money to spend on this as my project is supposed to be a side hustle and is proving to have doubtful return on investment promise as it is, however I think I can muster the $ to pay for prototype boards, do the work of testing on a common gimbal motor and do research on the algorithms, I know a little C and may be able to do the work myself, but my coding skills are limited so I could definitely use any help I can get.

Is anyone interested in collaborating? BTW my project is

I have investigated other drivers, but simplefoc appears to be my only hope for anti-cogging. Also it’s conceivable that the current control strategy, which is noise source number 2, could be a problem with other drivers, and with SimpleFOC there is at least hope that if it’s an issue, I can change it by increasing the frequency above the audible frequency range or whatever.

The commercially available driver ICs don’t seem to have any provisions for cogging, and although they are supposed to be made for producing quiet fans, I’m not convinced they did a decent job of it, because I have noticed that a lot of quiet fans on the market actually make a lot of motor noise due to the drive electronics. People generally don’t understand the value or point of making things quiet, so it is really an uphill battle, you can’t get suitable components at many levels. Also I would like to use general purpose widely available components and open source whenever possible.

I think there is definitely interest in this topic, others have been asking about it.

Our most recent release of the drivers library also includes some code for motor calibration. This code is trying to solve alignment problems of the magnet when using magnetic sensors, but could be a starting point for anti-cogging also…

Note that it will need a decently fast MCU with lots of RAM for building calibration tables…

I’m also kind of wondering how quiet you need it to be… if I run a gimbal motor, like an emax GB4008 at low speed, I have to put my head within about 50cm of it to hear it at all… and even then it’s super quiet. And that’s with no special calibration code, just standard SimpleFOC…

Is there an example for calibration? And how can I use the data obtained to work with the motor?

1 Like

Hey, the calibration code is in the drivers library, and there is also an example. It’s not tested much, so YMMV…


I would be happy to collaborate on the cogging compensation, though I’m very limited in time at the moment.

Are you on discord, perhaps I can help you out to start up?

I wrote the eccentricity calibration (for SimpleFoc) and I think cogging calibration could be done in a very similar way.

1 Like

Hey guys, sorry I haven’t answered, I’m still here and have been recieving email updates of messages, but I can’t reply easily with my phone.

Yes, from what little I know of the situation it seems like the approach Runger suggests sounds sensible.

It seems to me that some kind of calibration proceedure to produce a new table for pwm duty cycles, which used angle information from the angle sensor would be a good idea, I don’t know if that’s what the calibration subsystem is doing.

As you say Runger, simplefoc might work as is, I have ordered a board and it was supposed to arrive 2 days ago. I should have ordered from the official store, lesson learned. I will test things out and try to ascertain a promising way forward. I have the motor and fan assembly built already, and it is amenable to the attachment of the angle sensor without further changes. So I should be able to rig up the board and test things as soon as I can.

If things can be worked out, with or without code base modification/improvement, then I can proceed to get an angle sensor integrated into a fork of the Lepton and use that as my go to driver board.

I envision several good applications for this board, mostly quiet fans, however a fully contained open source servo motor would also fill a gap in the ecosystem that we see in the open source environment. In my short career I have seen several times already people needing this type of thing. These little gimbal motors are common, widely available and inexpensive. A companion board that is similarly low cost and of good performance would be significant progress.

And yes it is only a drop in the bucket, any system contains many such subsystems, however there is no other way to get a full bucket than many drops ;-). I am stoked that we can do this with open source tech.

Hello. Today I calibrated using an example from the library. But I don’t quite understand what to do next? Can I apply the received data?

Unfortunately, the example does not compile.

Have you included the most recent version of the SimpleFOC Drivers library in your project?

Yes. I have updated the library to version 2.2.3

And which version of the Drivers Library?

the library to version 1.0.2

I apologize for taking so long to answer. Was not at home))

Hello. I actually installed an encoder on my stepper motor. But the installation occurred with an offset. But I tried to do it exactly)))). Everything works in an open loop. But unfortunately not in the closed one. I thought it was possible to do calibration programmatically

replaced the computer. Now such a mistake. Ha-ha :smiley:

I found it)))). It is necessary in the calibratedsensor.h and cpp replace the bldsmotor with a steppermotor. Thanks

1 Like

Hello. I tried an example of a calibration for an engine from a hoverboard with an abz encoder. Encoder works with the esp32.encoder library. During calibration, it is noticeable that the engine has stops, perhaps between the magnetic poles? Is that how it should be? After calibration, the rotor rotates evenly, but has shocks, vibration. But if you apply a little force against rotation, the vibration disappears. How does the controller perceive these rotor stops during calibration?

It changes fast when you go to higher rpms, I find. I need max 3000 rpm.

I am encountering quite a few people that need anti cogging, and certainly noise is a form of pollution, so it is wise to undertake measures that reduce it, in whatever motor is being used. Thus, I think anti cogging in SimplFOC is a wise undertaking. It will get us closer to a good situation in a wide range of contexts.

Even in helicopters I see people trying to make their motors quieter, for example Blheli is an ESC software that people have been trying to implement noise reducing measures, in. Not usually anti cogging specifically, but probably because they think of it has hopeless.

There are others who are trying to make smark knobs, some on this forum, and this guy, scott bez, Motor Status - scottbez1/smartknob GitHub Wiki

Clearly he has huffed and puffed quiet a bit, much like myself, to overcome this issue to some degree. It sucks that motor manufacturer’s don’t make good stuff, it’s clear it’s not expensive and not that hard. There are a huge number of different motors, too, and they all suck, and they can’t just pick a standard.

In order to be able to reliably get good quality motion, we need SimpleFOC to save the day. The motors will be all over the map, only with software that can adapt and employ them are we going to have nice things…

I am one of the guys fighting with cogging on steppers. i have adapted the new calibration routines to my stepper on a STM32L432KC (64KB RAM, dynamic heap allocation, changed code to have only 2 arrays in parallel) and get a quite reasonable calibration LUT out of the noisy signal from the AS5147 encoder:

The AS5147 readings compared to my industrial 13bit optical encoder look like this:

. y-axis shows delta of the raw encoder outputs.
Using the calibrated sensor now in closed loop gives me a stepper not moving correctly - pulling max current and humming around at the same position. During calibration movements are ok, in openloop angle or velocity also. Maybe different PID parameters could ease the problem, not sure about it.
I have for velocity P=0.2, I=20.0, D=0, low pass=0.01. For angle P=20;
I assume that the sensor output is so noisy that the FOCloop calculates nonsense. That might work on BLDCs, but seems to be too much for steppers with 50 polepairs.
So without realtime anti-cogging I can’t proceed.
I could assist for getting a solution, at least for STM32 stuff.


Husky, as much as I want to promote simpleFOC, you may prefer a so called silent stepper driver such as the tmc2209. With tuning it may solve your problem. It depends primarily on RPM. I was able to get about 300 rpm with very smooth, very quiet motion. Cogging seems to be much less of a problem with stepper motors as the ferromagnetic attraction is not a thing. There are no permanent magnets in a stepper. In a BLDC, the cogging comes from the attracton of the ferromagnetic core to the permanent magnets. Steppers don’t do that.

Anthony, I did not mention what I want to do with the stepper - it is for a CNC mill. So I am heading for ultimate position accuracy, not so much high RPM and low noise. Closed loop is mandatory. I had checked the whole Trinamic stuff, unfortunatedly the entry costs for a proof of concept with their BOBs are too high.
But your statement about cogging and steppers is quite remarkable. It means that my diagram above shows more encoder noise than stepper cogging. Would be interesting if someone could share such a diagram for a BLDC motor - it should show the sum of encoder noise and BLDC cogging and help in realtime cogging filter design.