First project, fallen at first hurdle!

1

I am really keen to use FOC to give me good motor control and have a few projects lined up to use this.
Unfortunately I’ve had a couple of false starts with this sytem but have returned to my first project and I’m really hoping to make a go of it this time.

This first project was, I thought, relatively simple in that I simply want to spin the motor at an RPM, ideally between around 50-2000RPM and update periodically based on input from a speed sensor of some description - For now just a single hard-coded value.
I have been working with a friendly AI bot to help me along but it seems to be getting out of its depth and throwing anything at it without much rhyme or reason.

Ultimately the project will define the speed value via processing another input such as ADC, I2C, SPI or GPS but for now, to keep things simple, I’m using a hard-coded value.
Also for simplicity I want to drive the motor initially in open loop mode, hence not currently using an encoder although I have one available (tested and working).

I initially deployed a sketch and wired up the motor (IFlight IPower Motor GM3506 130T) and drive board (SimpleFOC Mini v1.0) as AI suggested, uploaded the program to the ESP and nothing happened!

It seems logical to me to take a step backwards, take the drive board and motor out of the equation and check if I’m even getting the derired output from the ESP, my take on this is that if I don’t get to that point anything downstream is irrelevant?
My expectation is that, if the program is doing its job, I should get a PWM output on each output?
The PWM will have var

I have done this today via 'scoping the output connections and I don’t see any activity on them.
I did also issue some code to place a simple PWM output on these pins and this did work indicating that the pins are PWM capable.

Indications on this page:

seem to indicate that my ESP32-S3 can use any pins for MCPWM (Motor Control PWM?) and that timer and pin association is performed automatically by SimpleFOC.

It seems that even simpler boards (S2, C3) can alternatively use LEDC for PWM but presumably it is not required for me to look further into this as my board should be good with MCPWM.
I have tried using pins 4, 5 & 6 and 35, 36 & 37 each time with no success.

I am programming via the Arduino IDE and have linked to the latest SimpleFOC library and ESP board manager so hopefully have the best available?

My take on this at the moment is:
My expectation of the ESP producing the PWM output is wrong.
There is a problem with the code.
There is a problem with my ESP (I do have an alternative available, ESP-WROOM-32)

I’ve reproduced the text of the sketch below. I’m new to this so may have missed some detail, please don’t hesitate to ask. As always thanks in advance for any help.

Screenshot 2026-07-27 185605
Screenshot 2026-07-27 185605484×658 41.3 KB

2

I think that the issue is the loopFOC.
Add motor.loopFOC(); to the loop in addition to the motor.move();.

This is needed from v2.4.0

3

Thanks for your very prompt reply @Antun_Skuric I’ll give that a go first thing and let you know how it goes.

4

I wonder, how many example files come with the 2.4 library, which aren’t working anymore because of this line missing…

5

Yeah, there aren’t that many actually. I’ve updated all the docs. The only ones that I forgot are the open loop examples in the library. But yeah, many people start with them and hit the wall right away… Sorry about that!

6

@Antun_Skuric I have added this command and the motor is now working, thanks for your help with this.

The motor runs quite smoothly at low RPM, better than expected, particularly considering this is currently open loop, presumably could be better once encoder is added.

I’ve added some code in the loop to increase the RPM but I’ve found that I hit a limit once I go from 150 to 300 RPM.
This does increase if I increase :
motor.voltage_limit = x.x;

This started at 1, now increased to 3 and I the RPM before stalling has also increased but only to about 600RPM.
I guess I could hike the “motor.voltage_limit” further but I’m a bit worried about any negative consequences, presumably there must be a limit anyhow.
Would this be likely to improve with a closed loop system?

7

Nice!
Ok I’d suggest you to use the estimated_current torque control mode where you can set the desired current limit (not the voltage limit).

You only really need the KV rating and the phase resistance of your motor for it. That should not be too difficult to find.

Using this control mode the library will automatically calculate the appropriate voltage to compensate for the Back-EMF voltage and you’ll not need to update the voltage limit by hand.

See more info here:

And with respect to the efficiency of different open-loop methods, see this:

8

Thanks @Antun_Skuric, I’ll look into that.

I did try a higher voltage but found that the motor started to get hot as the RPM went up. This is with no load on the motor which would indicate not very efficient working so something is not ideal. But it’s early days yet and I need to get into a bit more detail. I’m just happy at the moment to have the motor spinning.

9

Are you aware that the motorspeed is in rad/s not RPM? 300rad ~ 3000RPM which is not bad for a gimbal motor.
The openloop examples are there to test your wiring and pin-definitions, it doesn’t make much sense to waste time on tuning/maxing. The risk to burn up the driver isn’t worth it.

10

Hi @o_lampe , thanks for the input. I am up to speed on the units and I have put a calculation into the code so I can code in RPM while driving in Rad/Sec, I just kept that out of my code sample to save any confusion.

In terms of the advice against open loop, I absolutely agree with this, it was always the intention to use closed loop and the motor that I have has an encoder built onto it. However, working alongside this project is my learning process so I thought I’d push a bit further to see what is possible with open loop and what the downsides are. Working this way has also raised a few aspects for my brain to chew on so I’m glad I’ve spent some time with it. Today’s project though is to build it up into an open loop system.

11

Thanks for the help so far guys. I have made progress over the past few days, I’ve moved on to closed loop control and I can see differences both good and bad.

Not sure if I should start a new thread for this or continue here?

I’ve used the velocity_control sample as my starting point and modified to suit the encoder I’m using, AS5048, and pin numbers on the ESP32.
When the program runs, starting at zero RPM, the motor energised as it vibrates and moves slightly from side to side about 1mm or so at the periphery which I’d estimate at about 3° on a 40mm diameter.
When I enter a velocity value the motor spins but it not very smooth. At low RPM (20-40) the movement seems at though it moves slightly backwards every so often. Timing over 10 revolutions indicates it is about 15% slower than commanded which is consistent, this does seem to improve as the RPM increases but still about 10% slow.
I’m adding some code to capture the encoder values periodically to get a better picture of this particularly as RPM increases above what I can measure with a stopwatch.
What I an see is that the current draw is relatively low and only increases if I add some resistance to the motor showing closed loop doing it’s thing. Likewise and presumably due to this, the motor does not get hot even when running for a prolonged period. This is the “Good”

It’s worth mentioning that, in terms of motion behaviour, this is not as good as I was achieving in open loop control. Although the overheating issue in open loop would be harder to work with :-). The main reason I mention this is that it implies that the motor is physically capable of spinning smoothly at low speeds.

This is only a starting point and for this project I can more than likely work with what I’m getting however this is also a ‘finding out’ exercise for me so I’m hoping this behaviour can possibly can be improved (based on examples I’ve viewed on the Internet) which would help on other projects I have planned.

I guess what I’m looking for here is to have my expectations realistically set for what is achievable so I’d appreciate any feedback on the result I’m getting.

I have yet to work on the PID parameters, which are currently still at the defaults (0.2f, 20, 0) and there is also “motor.PID_velocity.output_ramp = 1000” & “motor.LPF_velocity.Tf = 0.01f” which I need to work out an understanding of so there is a way to go yet. I’ll be looking into these over the next few days and any pointers on where to look or which to look at first would be greatly appreciated.

12

I highly recommend adding the webcontroller to your setup, it takes away a huge load of guess work.

13

Thanks @o_lampe, I guess I need to also take a deeper dive into the PID (and other) controls to fully understand what effect each has otherwise I’ll just be throwing figures in haphazard and seeing what sticks.

14

Hi @0_lampe/@Antun_Skuric. I’ve had a look at the webcontroller utility, unfortunately I can’t work out how to get anything from this at the moment, it looks like something I need to investigate going forward but I don’t want to side-track this project just now and, although the motor may not be running at its best it is good enough for the current purpose.

Just to close the loop on this thread and put some context for anybody coming across this thread later on interested in a similar use case I’ll add a bit of detail.

I have an “old” car with mechanically driven speedometer which due to changes to rear axle and gearbox no longer reads the correct speed and so indicates a range of speeds around 10MPH, none or which is correct!

What I’m doing is adapting the motor to drive the eddy current spindle hence the requirement for both high and low speed values. I’ve got to the point now where I have the drive to the gauge and I’m able to show speeds down to around 4MPH and up to about 100MPH, that takes around 1200RPM and the setup is limited here, I’m assuming this is due to the KV of the motor and the voltage available (13V or thereabouts). This is not a problem as I’ve no intention of travelling at anything over that speed but my OCD makes my want to be able to run the gauge up to full scale (200MPH - Some hope!) so I’m going to leave it as this for now at least.

I need to work out exact motor speeds or indicated road speed, I know from previous tests that this is around 14RPM pre MPH so 140RPM will indicate 10MPH, 280=20 and so on and early indications are that this is working quite well. Obviously I can adjust this in program if I find there is any non-linear response in the system but I’m hoping the closed-loop nature will take care of this.

Next step is to get a speed reading to work with and do some testing. I have a few different possibilities for this, need to make a decision on which to use.