Hi everybody!
There is a mistake at the suggested pinout for the Stm32 Nucleo at Soldering pads | Arduino-FOC.
For board #2 PWM C should be set to pin 11 not pin 13.
After using PIN 13 for my second little SimpleFOCShield on a NUCLEO-F446RE STM32 F4 board, the motor didn’t run smootly but shaked and jumbed.
First I thought that the SimpleFOCShield is damaged so I tried the pinout for board #1 and the motor run smooth again.
After that I tested again pinout for #2 with PWM C at pin 13 and checked all output pins with an oscilloscope.
Pin 3 and pin 5 had a usual square-wave signal (using FOCModulationType::SpaceVectorPWM).
But pin 13 had a changing analog like signal, maybe there is another pullup/pulldown resistor connected to pin 13.
Then I tried pin 11 instead of 13 and everything worked fine.
Cheers,
Juergen
Hey Jurgen,
I’m happy to hear that you already received your boards and that they work 
This is an interesting remark, because I have exactly opposite behavior with my stm32Nucleo F401RE and F411RE. And that is the only reason why I added the triple pad on the shields for that selector.
Basically I thought that stm32duino does not configure it right since the pin 11 belongs to the timer 1 and it is the complementary channel of the channel 1.
You can see the image:
Now this might vary in between boards so I suppose that is the reason for this.
Which version of the library are you using?
Are you using the newest version from the dev branch or the library v1.6.1 which comes with the Arduino Library Manager?
Cheers,
Antun
Hello Antun!
The library I am using is version 1.6.1 from the library manager.
Will there be a difference between version 1.6.1 and the newest branch for the NUCLEO-F446RE?
If the pin behaviour on your boards is different, it might be a good idea to mention the different board behaviours at at Soldering pads | Arduino-FOC , as I didn’t know it and I expected pin 13 to work, which gave me some worries first 
.
Cheers,
Juergen
Hey @Juergen_Abel
I just added the disclaimer to the getting started page. Thanks again.
It is hard to account for all the behaviors since the library has many different use-cases and is compatible with many different platforms, there is always stuff that I did not think of.
But I am always happy to add more info, thanks!
Version 2.0 will not change much in terms of execution but if you are interested in customizing the code it will be much easier to fig into!
Also the version 2.0 introduces the driver class so instead:
BLDCMotor motor = BLDCMotor(9,10,11,11,8);
You will have:
BLDCMotor motor = BLDCMotor(11); // just pole pairs
BLDCDriver3PWM driver = BLDCDriver3PWM(9,10,11,8); // all the hardware pins
void setup(){
...
driver.init();
motor.linkDriver(&driver);
...
}
It is in general more simple to use and should give better results.
It is a version preparing the turf for current sensing and torque control!!! 
Hello Antun!
Thanks for the remark on the pads_soldering page, maybe it helps others to run the F446RE successfully.
For so many platforms, motors and use cases, I am aware that it is difficult to be complete .
In any case, the current information, library and shield of your pages is allready very usefull, thanks for that.
Currently I am testing many different motor and controller types for my mobile robot, and I am not sure, if the bldc gimbal motors are the best choice for the propulsion of the robot.
My current bias is going towards dc controlled motors, as my gimbal motor, which I used in open loop mode, had extremely low torque and became very hot, even in no load conditions.
My dc geared motors, even little ones, have much higher torque (I would guess 10 to 100 times more torque using less current than the gimbal motor), and don’t run hot at no load conditions.
Do you know, if the torque is getting much higher for gimbal motors with the sinmpleFOCshield when using closed loop control, i.e. using an encoder for feedback?
On my STorM32 board is a IMU for feedback and the torque of the gimbal motors is a little bit higher than on my open loop gimbal motor with sinmpleFOCshield, but the torque is still much lower than my little dc geared motors.
Cheers,
Juergen
Hello Antun!
Just checked version 2.0, and the motor motion “feels better” than the old version .
Is it possible, that the movement in open loop control is more smooth than in version 1.6.1?
Cheers,
Juergen
Hey Jurgen,
It is possible, I am not sure what does it mean exactly feels better but there are quite a bit of changes that have been done.
For example the pwm setting has been completely refactored and the new code doesn’t use the analogWrite() function any more and the library configures the pwm modes itself. So it should be a bit faster.
Otherwise the pwm frequency and resolution stayed the same.
The sinusoidal modulation algorithm is doing essentially the same thing as in 1.6.1. sot that should not be the big difference.
Did you use in both codes the same modulation types?
I would suggest you to use sinusoidal pwm if you want smoothness.
motor.foc_modulation = FOCModulationType::SinePWM;
What is different though is the way we handle voltage limits. Before we centered the phase voltages around motor.voltage_power_supply/2 and in the new library we center it around driver.voltage_limit which can reduce the noise I imagine.
I am happy you like it more, but I am not 100% sure where the better performance comes from
Now this is a very complicated question. But in general dc motors without gearboxes are nowhere even close in terms of torque to bldc motors. At least for low velocities. If you are using a dc motor with gearbox then it will reduce the velocity and augment the torque for sure. And it is perfectly reasonable that you can find dc motors that have better performance for your specific task.
A small digression. Honestly I have a feeling that DC motors are unnecessarily ignored at this moment. If they would receive the same amount of care as BLDC motors do tehy could do the same things, but simpler.
So one of the problems of the DC motor is the gearbox, the backlash. I am not sure if that is a problem in you application. And also backdrivability, with a big gearbox you are unable to back drive the motor. You have a lot of torque though.
So it all boils down to the application you have a what are you actually searching.
Now BLDC without the position sensor is very very inefficient. That is the worst case performance of the BLDC I would say. If you want something comparable to the DC motor you need the position sensor.
It will augment the torque and reduce the current consumption.
Geared dc motors are intended for purposes to have a high torque, you could gear the bldc as well and then you would have much more torque. Gears are not just for dc motors.
DC motors usually spin on 10,000 rpm and are usually geared to 100rpm for example. That is a factor of 100.
If both gimbal motor and the dc motor use the same current and voltage they have the same power:
P = U*I
And if the gimbal motor has no gears the torque it will have will be:
T = K*I
And the DC motor will have exactly the same torque but multiplied by the gearbox value:
T = K*I*100
But it will have backlash and not be backdrivable.
Hello Antun!
The gimbal motor seems to run more evenly with less cogging using the new version, but the difference is very small.
When the gimbal motor runs slowly (velocity around 0.5 rad/s), you can still see some cogging.
Furthermore it seems that gimbal motor runs more more evenly using FOCModulationType::SpaceVectorPWM instead of FOCModulationType::SinePWM; but again, the difference is almost not noticable.
Concerning the geared dc motors, I am aware of the advantages and disadvantages, but a small geared dc motor can change direction (forward and backward) very quickly without problems.
Of course the gear has some backlash, but if you use an encoder, this is not a problem for mobile robot propulsion, as in more than 95% the mobile robot drives forward.
By the way, my gimbal motor is the T-Motor GB2208, and a typical dc geared motor would be a 12V, 10W, 25mm diameter dc motor with encoder and a 1:50 planetary gear, depending on your RPM or torque target.
Currently I make my gimbal motor tests with the F446RE board, using the ARDUINO IDE with the open_loop_velocity_example from the library examples.
Last but not least, there is one more observation I made with my gimbal motor with simpleFOCshield:
When the motor runs slowly with velocity 0.5 rad/s, it stops running after some minutes.
There is still power, as the motor keeps being hot and has cogging torque, but no more movement.
The L6234 is still cold on the simpleFOCshield.
When I adjust the speed higher to 20 rad/s, the motor moves again.
If I reduce the speed then to 0.5 rad/s, the motor stops again.
When I reload the program by the ARDUINO IDE, the motor runs again at 0.5 rad/s.
It seems, that the problem is not located at the motor or the F446RE board (as I can change the speed over the console), but inside the software.
Do you know, if the output voltage signal changes after some minutes?
I would say that for the mobile robot propulsion there is no real benefit of running it with the BLDC motor. Especially if you don’t care about the you dont change too much direciton and if you have the dc motor with good enough dynamics.
BLDC motors will just make everything more complicated.
Running the BLDC motor open loop is like running it in the stepper motor type of control. It is powerful only when it is still.
With the closed loop control you can control torque when the motor is moving. This is not possible with open loop (or steppers).
I would advice you to integrate a sensor.
I have no idea. I have not seen the same behavior. That is pretty odd I have to say. I’ll look into it and try to see if there is something similar for me.
What is your motor.voltage_limit you are setting?
Ps. With the higher motor.voltage_limit you should have less cogging but more current and everything hotter.
The motor.voltage_limit was the first thing I raised in order to get higher torques.
Unfortunately, the motor became even more and faster hot.
Therefore, I still use motor.voltage_limit = 3 and driver.voltage_power_supply = 12, using 12V dc for the motor.
Even with motor.voltage_limit = 3, the motor becomes very hot after a minute or so.
Maybe, there is a safety circuit, which shut’s down the motor, when current is to high after some minutes.
But strange is, that the motor starts running with 0.5 rad/s at once again, as soon as I download the program to the board, even when the motor is still hot.
Have you noticed this behavior in voltage mode too? if you haven’t tried, can you please try?
Dear David and Antun!
Since the problem with the stopping of the gimbal motor is going into detail, I suggest that I open a new topic at development, so that other users can find it more easily.
If the administrator disagrees, he can move the topic back here or to another category.
Thanks for the hint, I will try it and post my results at the new topic: “Gimbal motor stops after 14 minutes in velocity_openloop”.
Cheers,
Juergen