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 www.openerv.org.

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…

Hi,

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?
Thanks


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