SimpleFOC started as a simple Arduino-based FOC implementation 6 years ago, and thanks to this community it has grown into a tool used by thousands of makers and engineers.
The ecosystem around us has also evolved: PCB manufacturing is easier, new MCUs and open-source motor-control projects exist, and software development is more accessible than ever. This gives us a great opportunity to focus SimpleFOC on the features and improvements that bring the most value to you.
Where we’d like your help
We’d love to hear:
What features or tools would make your projects easier?
Where do you struggle when using SimpleFOC today?
What documentation, examples, or hardware would you find most useful?
Are there specific applications you wish we supported better?
Feel free to propose ideas in the replies so others can vote on them. The more concrete, the better!
Polls
Below are some proposed directions. You can vote for the options you find most valuable, and we’ll also add your suggestions if they fit.
Usability Improvements
Make it easier to start with (ex. better guide the inital setup)
More application examples (ex. some robotics projects, …)
FAQ page
YouTube video guides
Improve the SimpleFOCStudio
Improve the SimpleFOCWebcontroller
0voters
New software features
Implement Back EMF control
Implement Anticogging
Implement HFI
Implement some new MCU families
A more capable Python framework (already well started by @runger with pysimplefoc)
0voters
Hardware development and availability
Make microspora like all-in-one boards available to buy - EasyEDA
A new more capable shield (ex. make DriveShield more available) - EasyEDA
Make SimpleFOCShield and SimpleFOCMini available in the shop again
A new all-in-one board for mid-range currents (<15Amps) - Similar to Dagor by @David_Gonzalez
SimpleFOC is fantastic. The only painful thing for me has been the unreliability of `SimpleFOCStudio` and `SimpleFOC WebUI`. A PID tuning tool is critical.
Completely agree on the PID tuning tool. I found control to be the aspect with the most improvement potential in my project. A frequency response measurement function would also be phenomenal. I think something like Frequency Response Measurement using Broadband Noise Excitation or measuring the Frequency Response Function using a swept sine could be possible, although I haven’t tried it yet. Maybe next year I will find time to implement a test. This would allow PID tuning based on an actual model.
I think the website could do with an overhaul. There are at least two paths to follow on the website if bringing up a motor/rotation sensor and it would be good if there was just one clear route.
What I mean is, there is duplication of getting started examples except the duplicates aren’t exactly the same.
We have:
SimpleFOCShield → Writing the code
Arduino SimpleFOC library → Writing the code
Arduino SimpleFOC library → Example projects
which all overlap to some extent and makes getting started a little confusing. Thanks.
Make SimpleFOCStudio a standalone program you can download and run without having to install Python and do all that command line stuff.
Better ADC code for STM32. Oversampling for inline current sensors, and fast reading (ideally also with oversampling) for LinearHall. I think @Candas1 was working on something, but I don’t know what the overall architecture was going to be like, and haven’t heard any updates in a long time.
This one is entirely on me: finish the final refinements on Gooser
IMHO the “startup” can be integrated into a relatively simple program.
it should simply prompt the user: pick your sensor from the list.
Then it should initialize the sensor and prompt the user: “give it a twirl” and provide feedback on the sensor readings. Looks good? Continue.
etc.
If such a program were started by someone, the community can easily add on. “oh, I have an XXX sensor, it should be able to detect that” .
The end results should be a structure that you can pass to an “init everything” function that gets the sensor type from the structure and initializes that, then gets the PWM pins etc etc.
Again, someone should write the framework, and once it is there, adding more variables is easy and can be done by almost anyone.
The motion_downsample parameter presents significant usability challenges that limit the library’s effectiveness:
Frame-rate dependency creates brittleness. Since motion_downsample is tied to loop speed, any configuration change that affects timing invalidates previously tuned values. This makes the parameter difficult to configure reliably and forces users to re-tune settings whenever they modify unrelated parts of their code.
Documentation lacks technical clarity. In my experience, the current explanation—that downsampling provides “more time between move() calls to compute accurate velocity”—doesn’t hold up under scrutiny, either theoretically or in practice. A more rigorous explanation of the underlying signal processing trade-offs would help users understand when and why to adjust this parameter.
