Practical SimpleFOC Limitations?

Is there a practical limit on the number of pole pairs that SimpleFOC can work with?

I am interested in building a BLDC which is to be both driven as an outrunner and in runner at the same time. The motor radius will be ~4 ft., with a large number of poles pointing inwards towards the rotor around the outer edge and the same number of poles, but smaller in size, on the inside pointing outwards towards the rotor. My objective is to create a motor with very high torque, smooth and precise control, vibration and noise free. This will be used in a scale model aircraft. Will it handle 50 or more pole pairs?

Thanks very much,
Andre

A scale model aircraft with a 4ft motor! 2:1 scale methinks! :wink:

You might have to draw a picture of this for me. I don’t quite get it! Both inrunners and outrunners typically have magnets on rotor with coils on stator but it sounds as if you are placing magnets (poles?) on outside and inside ‘stators’ so presumably you are energising the rotor?? Or are your inner and outer elements traditional stators with windings and the rotor has magnets. You’d be wanting to synchronize inner and outer stator fields.

@schoch has made a home made motor. It was an inrunner with 3 slots and 22 poles and used a home made encoder.

In terms of practicalities of high pole count motors - the higher the pole count the higher the precision required out of the sensor. If you had a 50pp motor (100 magnets) then you have 50 electrical revolutions per shaft revolution and the FOC algorithm is only interested in electrical position! That said 50pp has already been shown to work with SimpleFOC as it has been used with Nema17 stepper motors. When @Antun_Skuric played with a 100pp stepper - I think he found 100pp worked ‘less well’ than 50pp. Perhaps he was starting to hit the resolution limit of his sensor??

Hi Owen, thanks for the reply;

Yes, the project will be approx. quarter scale. The motor is essentially going to be a giant fan with blades like a turbofan engine that can have their pitch adjusted much like a helicopter rotor swash plate system. The magnets will be on the rotor outer circumference (facing outwards) and the inner magnets will face inwards as you suggested - stators around the rotor circumference and a set of stators inside the rotor with a much smaller radius. I am thinking one stator per pole pair at this point but wondering what is the optimal stator-pole pair combination. Synchronization between inner and outer stator-pole pairs will be critical.

I will post a rough diagram in the near future but I think you already have a good idea of what it looks like. Cheers.

I am considering using the STM32 or would you recommend another board.

Are you planning on having the same number of pole pairs on both sides of rotor and same slots on inner and outer stator?
If so then perhaps you could send same PWM signal to both stator windings?? What is the distance between inner and outer magnets? I can imagine that they could interfere in some weird ways if you don’t have the same number of PPs. Could you not use one magnet that serves inner and outer?

I take it you have seen Cristoph Laimer’s halbach array motor (youtube/instructables). It is a single stator outrunner but the halbach magnet arrangement means that the magnetic field is concentrated inwards.

stm32 seems a reasonable choice. esp32 another option. What RPM are you hoping for?

this makes me think of getting a brushless washing machine motor going with simple FOC but that isn’t even close to 4 ft! I can’t imagine the power that could draw. A brushless washing machine motor can do 28NM for $50 bucks on ebay!

Hey guys,

Just few things to add.
The number of pole pairs is not really a limitation for the simple foc. The high number of pole pars influences two things:

  1. The sensing. If you have a huge number of pole pairs you will need a sensor to be able to sense it. Basically you will need to have a sensor with as large resolution per pole pair as possible at least the resolution of 6 (for bldc motors).
  2. The processing. Now this one is a bit more complicated and depends a lot on the type of algorithm you will need and the type of application.
    • For smooth operation you will need as large reoslution of pwm for each pole pair (electrical rotation). The more you have the smoother the rotaiton.
    • Furthermore the smoothness will depend on the processing time for each loop. The faster you can do it the smoother it is.
    • The smoothness will depend on the velocity as well. Since you are passing each pole pair faster you even with lower resolution of pwm and sensing you will have good results.

In your case since you will mostly be running your motor in velocity regulation mode (I think so :D)
you can I think get away with hall sensors (or similar low resolution sensors).
And in terms of processing, I would certainly recommend the stm32 boards. The stronger the better. :smiley:

On the other hand, this library at the moment does not support current sensing and true torque control, so with your huge motor that might be a problem. :slight_smile:

We are working on it at the moment and we are hoping to be able to release it soon!

Are you planning on having the same number of pole pairs on both sides of rotor and same slots on inner and outer stator?

Yes that is what I have in mind at this point. It is important that the torque generated on the outrunner and inrunner is balanced. If the SimpleFOC can achieve that in future that would be awesome, but for now it won`t matter that much.

What is the distance between inner and outer magnets? I`m sure they will be far enough apart - I will try to provide some more detail and a diagram soon, then everything should become clear.

I take it you have seen Cristoph Laimer’s halbach array motor. It is a single stator outrunner but the halbach magnet arrangement means that the magnetic field is concentrated inwards.

I have seen it - are you recommending that I use a similar magnet configuration?
Which esp32 board would you recommend?

I hope I can get a simple diagram uploaded this weekend, but I cant say for certain due to the Holiday season, well what happens.

Thanks very much for you input on this, it is really appreciated.

Hi Antun - thanks for your input;

I think the torque feature will be a huge plus for the application I have - I`m really looking forward to seeing how that will work.

I will definitely have a sensor which I think would be best placed near the inner radius (outrunner section) in order to keep the sensing accuracy higher. Perhaps a Hall sensor will be ok.

Sorry, I don`t know what you mean by: Basically you will need to have a sensor with as large resolution per pole pair as possible at least the resolution of 6 (for bldc motors). What is the resolution of 6 (Radians, degrees?)

Sorry for my ignorance, I am an absolute amatuer at this stuff.

thanks again for any help and advice and for the work you guys are doing.

Units of resolution are typically counts per revolution but are we talking about electrical resolution or shaft resolution!? Antun was referring to electrical resolution when he said it needs to be at least 6.
Using a couple of examples.

  1. A hall sensor arrangement is nearly always maid up of 3 halls that are 120degrees apart electrically. They transition when hall detects it is closer to N pole or S pole of the rotor magnets. There are therefore 3x2 = 6 transitions per electrical revolution. So 6 transitions for each pole pair therefore counts per shaft revolution is 6 x 50pp = 300 counts per revolution (cpr).
  2. Looking at a Magnetic sensors with a bit count of 2^14 (e.g. AS5147). They therefore have a shaft cpr of 16384. For a 50pp motor they have an electrical resolution of 327.7 which is significantly higher than 6!

In terms of esp32 (or stm32) boards - you may need to build your own! Because you have two stators in sync I think you may need a single mcu doing the maths for both (or at least that seems easiest to me). The gimbal controller boards clearly don’t have the power for your motor. ODrive might do it but nobody has tested SimpleFOC on that.
Where you planning to build your own board?

Thanks again for the good information:

I was not planning to build my own board because I am pretty new to all of this and hoping to be able to do this with off-the-shelf products. We’ll see about that.

I just discovered the teesny 4.1 with a 600 Mhz clock speed: https://www.pjrc.com/store/teensy41.html
maybe that would be a good choice along with the ODrive? This motor won’t use nearly as much power as one might think given its size.

I don’t think anyone has put simplefoc on the odrive so I’d be a bit worried about you spending money on it and hitting a blocker.

What do you plan to do on the teensy and do you need that power? Assuming you are using simplefoc, the odrive’s stm32f407 would have to do the FOC maths. I guess the teensy would be doing flight control e.g. talking to mpu9x50 and some 2.4Ghz tranceiver.

I made the following sheet to think about the limitations of FOC driving, and help size various components…

Perhaps it is helpful?

https://docs.google.com/spreadsheets/d/e/2PACX-1vR-RlC_ZLvMeFBCay4z9raOFO1Q5JecNpMdqjubMqwLvY8mX6RN1RXDybi3_PDfN7tMrCrPpAMmcCIw/pub?output=xlsx

Basically, I would say the limitations are not so much the sensing, as a 14 bit sensor like the AS5048 will still have >10 distinct positions on a (theoretical) 200 pole-pair motor…
I think the limitations are around the FOC algorithm iteration rate, compared with how smoothly / quickly you want to drive the motor…

The sheet makes this obvious, unless I have made some mistake in my thinking or calculations. If you do take a look, and spot an error or have any feedback do let me know.

I still plan to add current sensing and FET timings to it when I have time…

1 Like