I am new to the forum, but experimented with SimpleFOC a few years back after getting a shield from the store: x.com
Background, feel free to skip over
For my day job I’m a product engineer at a company called Pimoroni, that among other things manufactures development boards powered by Raspberry Pi’s RP2040 microcontroller. My particular interest is robotics, where so far I have created boards for driving lots of servos, and DC motors with encoders.
One product I have been pushing is a board that rather than be for a single function, instead uses a modular approach to let it be adapted to different project’s needs. This came from my own personal experience of robot building, where I’d often need to drive a few motors, but then also need a few servos, speakers, lights etc. The board is called Yukon and was recently reported on by Tom’s Hardware after being teased at an event: https://www.tomshardware.com/news/pimoroni-stealthily-announce-rp2040-yukon-modular-robotics-platform
One of the things I would love to support with this platform is brushless motors, either by using our already designed motor modules in half-bridge mode, or making a dedicated BLDC module. My knowledge in this field is somewhat limited, both in terms of the hardware requirements to consider and what people would expect to be able to drive. For the software though my mind naturally turned to using SimpleFOC.
Am I right in understanding that the current Pi Pico support is based around Arduino, but still uses the Pico SDK under the hood? Assuming yes:
How much of a challenge would it be for me to make a Pico SDK native version of SimpleFOC (or a subset thereof)? I have yet to write our stepper motor support too.
Would the SimpleFOC team (and code license) be okay with me exploring this? I imagine it would have to be a standalone repo rather than a fork of the Arduino one, so I wouldn’t want to do this without approval. All our code is MIT licensed, which seems to match this project.
Also, we would be wanting to add support to Micropython as that’s the language the majority of our customers use with our Pico products. That’s not too difficult on our part though once the C++ side exists, as we would write a binding layer.
I very much welcome your input on this, as I would love Yukon to bring BLDC control to more people.
This project seems interesting. However, it seems this is a commercial effort and to put it bluntly you are asking for free help. I could be wrong, of course, so please feel free to ignore my input. I am probably misinterpreting your request. You may get some people giving you constructive input if you offer at least some king of reward or payment may be?
There are some people working with RP2040 motor control, so may be you will get lucky. Also, please search this forum for RP2040, there are both hardware and software posts that could be helpful.
I completely understand and respect your viewpoint. Adding BLDC support is something I am personally passionate about for this board rather than a business directive, so I automatically posted in the “excited about a maker project” style. I cannot deny though that in this context my asking for advice constitutes requesting “free help”, regardless of my intentions.
Perhaps there is an alternative communication channel I should reach out on? The MIT license of SimpleFOC does allow for commercial use and modification, which answers my second question in the original post, but I know that doesn’t necessary mean support will be provided.
From searching after your message it sounds like creating the port I need would be challenging but not impossible. If there are no objections from the SimpleFOC dev team I will make a start on what I need, then if something comes of it open-source the results.
It would probably take more thinking/work to put in safety features, it is very easy to fry your board with simplefoc it you don’t set appropriate limits for your setup.
Can you share schematics? You mentioned steppers, Does it have 4 half bridges? What drivers? It’s possible that you could use simplefoc for both bldc and steppers.
I’ve got good things to say about Pimoroni, they really helped out with 3d printing support for teams wanting to print stuff for NHS during Covid.
Doing some micropython wrapper around simplefoc would be super cool.
Getting simplefoc onto your board might really help us grow the community .
No problem, we are here to help, I was only making a comment if you want more serious help that could be commercialized you may want to add a carrot. Personally I have no experience with RP2040 so I’m just a cheering bystander.
AFAIK the whole point of MIT is to make it available and open. The more the better.
Of course I’m familiar with Pimoroni and have a bunch of your stuff here in my workshop So cool that you’re interested in SimpleFOC!
Firstly, to directly answer your questions:
We’re MIT licensed, so it’s not a problem. Of course we’d love a mention and link back to our site and docs, but its not required
it should be quite possible to port SimpleFOC to native PicoSDK. The core of the library is C++, and PWM and current sensing code is MCU-specific anyway. The parts most strongly using Arduino framework are the sensors, which use Arduino’s SPI and I2C functions. Other than this there will be a bunch of “general” functions and constants used which would have to be replaced.
But the question is, is that really necessary?
Let me comment on a few other points from your message:
That is awesome, and building small robots is also the reason I got involved with SimpleFOC… there are quite a few robot builders here
It’s definately a cool idea, and there are a few discussions in our forum on this, and even a couple of designs in that direction. But modular BLDC drivers are a challenge…
I (and I’m sure some others here too) would be very glad to help. We can check the specs of the drivers you have to assess whether it’s possible, and give advice on the question of making a dedicated module.
The question of what people want to drive is a very difficult one. We have users here driving tiny motors, or axial motors with only a few mA of current - and other users who are driving large motors in the kW range. I think targeting robots up to a certain weight/size makes it more possible to frame the problem. A key question to answer is whether you want to support low-ohm, high-KV motors (such as many quadcopter motors, RC car motors and similar) or only higher-ohm, low-KV motors (such as gimbal motors).
Lower ohm motors will probably need current sensing and current control to drive them well (and safely), which adds a lot of complexity to the problem. In fact ADC inputs aren’t RP2040s strong point and you’re quite limited there, so you may want to consider focusing on gimbal motors.
That would be awesome. Of course you can’t do the motor control from python, but providing an API to the C++ level would be great for the python users
Keep in mind that running the FOC loop and motion control will result in a loop frequency of about 6kHz or so when using 100% of one of the cores. There’s not much room for doing other stuff, but luckily the RP2040 has 2 cores!
Another question is how the sensor support will work. FOC control requires a sensor on the motor shaft to measure the angle - a device like an optical or magnetic encoder. There are many to choose from, and therefore many software options that can be configured. For your product, you may want to consider offering one or two specific sensor models to make the job of integration and support easier.
So there are many choices and configurations that the user has to decide on when setting up a new BLDC motor and its driver. From our point of view our library makes this easy without limiting the user’s options too much.
May I ask why you’d prefer a solution without Arduino framework? If it were possible to stick to the SimpleFOC library, you’d benefit from our regular updates and development, and the large ecosystem of code, documentation and community content that has developed around the core library…
Thanks for the replies! You’ve all certainly given me a lot to think about over the past week.
I’ve been a bit quiet on this due to a combination of getting ill, and just marching ahead with the porting effort.
It didn’t take all that many hours work, due to it all being C++ and the platform specific parts already using Pico SDK. I focused on getting the code paths needed for open-loop control working first as I am not in a position to test the other features of the library yet. I also spent some time changing the coding style to match the SDK, which although functionally unnecessary, was a useful way for me to gain some understanding of how everything fit together.
Too early for us to share the schematic, but I can tell you the drivers. We have two motor modules planned for Yukon:
“Dual Motor / Bipolar Step”, which uses a DRV8424P (datasheet is hard to find oddly)
“Big Motor” that uses a DRV8706H with external MOSFETs
I was able to test driving a stepper motor with the fork, using the “Dual Motor” module, and it worked! x.com
I quickly hit over temperature on my first run though, so I now understand your point about it being “very easy to fry your board”
Once I lowered the voltage level I was able to test properly, but this highlights my lack of understanding of how to drive stepper motors well. For example, to get high speed it seems I need to have a high voltage to push current into the coils fast, but then when at low speed I need to back off the voltage to maintain the same current. That caught me out, so would easily catch customers out. Maybe I would be better switching to a Trinamic driver instead . That would satisfy the people how just want to DIY a 3D printer or similar CNC setup.
As for brushless control, I checked the datasheet for the DRV8706H and it has both a H-Bridge mode and dual Half-Bridge mode … which we neglected to wire up the mode select for. In theory we could fix this on the next revision, but that only offers two half-bridges per module, meaning a customer would need two modules installed to drive a single motor. At that point it would be better for us to do a dedicated brushless driver module. A candidate that uses SPI is the DRV8311P. I don’t see support in SimpleFOC for that, which doesn’t give me confidence.
We have not looked at equivalent PWM versions yet. I assume PWM would be the better choice? Also, is there a benefit to 6 PWM over 3 PWM? Each Yukon module only has 4 PWM’s, so a 3 PWM driver would be preferable if there is minimal downsides to that operating mode?
I suspected there would be a broad range of users, which is both great, and difficult to offer solutions for. Gimbal motors would certainly be the easy option for us to support, but it would be nice to be able to support more than that. Each Yukon module is rated for 17V, 5A max, so that is the upper limit of what we would be able to drive. From memory, I was driving a 560kV motor with the FOC shield, but had to run it at a low voltage in software to keep the current manageable.
Ah yes, I knew they were bad from my own experience, but reading your code comment highlighted the real issues!
That’s an excellent point! My personal experience has been with I2C and SPI magnetic absolute encoders, so they would be my first choice. I know that high CPR optical encoders are popular too though.
Ultimately this comes down to the need for the library to be usable with our existing build processes. We follow Raspberry Pi’s setup and use CMake for building the C++ drivers and examples for our products, as well as our “Pirate Brand” Micropython. Switching the product to use the Arduino Framework would mean we would loose access to that codebase, and be unable to attempt the Micropython port. A relevant highlight being our PIO-based PWM driver, letting us use all 30 RP2040 pins as PWM outputs. Pulling the Arduino Framework into the CMake world may be possible, but as there is little that is actually used the overhead seems unnecessary.
Your points about regulars updates, documentation etc are very valid. I am not wishing for this fork to march off in its own direction (like Circuitpython did from Micropython), so I hope documentation would remain applicable. Code updates would be a manual process on my part though, which I may not have the long-term bandwidth to maintain.
With this in mind I’m thinking about deleting the repo and recreating it as an actual fork of Arduino FOC. That way there will be a history of the changes between the two, and it would in theory be easier to pull down updates from the original repo. I don’t know how that would affect things if it ever took off and you wished to bring it under the SimpleFOC umbrella like simplefoc-webcontroller though.
.
. That would satisfy the people how just want to DIY a 3D printer or similar CNC setup.