Been away from SimpleFOC for a while (so a bit rusty). I’m doing a bit of research for a new board
for a single gimbal (r > 5ohms)
all components available on lcsc.
probably going to try stm32g431cbt6
driver to have integrated FETs and current sensing
magnetic spi sensor
So looking for advice on integrated fet bldc driver. What I’ve considered:
l6234 is unavailable
drv8313 is available (and we know quite a bit about it)
drv8311 is available but only in drv8311p variant
The p variant is unusual and quite interesting. The a/b/c duty is set over tSPI and it cleverly allows 4 drv8311p to be controlled from a single microcontroller. It also has a decent 100ma LDO. However it would be a fair bit of dev to get it supported and seems to be focused on sensorless/velocity controlled applications (e.g. drones see vid).
drv8316 and drv8317 are interesting but not available
Of the above the drv8313 seems the obvious choice
Any other integrated FET drivers (available) that I should consider?
Part of the reason for picking stm32g431 is that I’d like to see if I can get USB PD working + I understand that it has good ADCs on it that might help me get results with current sensing (an area that I’ve avoided). Eventually (in a year or 2!) I might string 4 or 6 of these together over canbus to create something of the style of Ascento two wheeled robot.
Thanks Valentine. Your mosquito will be great for cross checking! Nice board.
Why does low current mean I won’t get much benefit from current sensing, too noisy? Or do you mean the low currents mean that I’ll not have much bemf i.e. Vin ~= I *R works well at these slower speeds?
I’ve never been happy with the cogging I tend to see with smaller gimbals at low speed/low load (closed loop) and thought perhaps current sensing was the answer.
I snagged some very low cogging motors, they are very hard to find. You want what’s called a ring magnet. It’s the SM type motor, most are the IP type. The IP type use flat plate magnets, the SM use curved magnets. However I think it’s because the ring magnets have no gaps in between the magnets.
However they are quite hard to find and yes expensive, so I think it would be a really good idea to figure out some anti cogging stuff. Once the software is written then anyone in the world can use a cheaper easier to get motor and get the same results as an expensive hard to find motor. Progress.
Owen, why do you need integrated FETs? It shaves some $ off but is the per unit cost the main thing?
I also would like to use one of the G431 chips as the higher clock speed and M4 core with floating point has floated to the surface as important features, and I know someone else that I think would like to go that route, and the current is also in the same region as what you need. I think maybe we should collaborate.
The lepton runs the motor.move(target) command at 5 khz in open loop, while it runs at 37.5 khz on the b-g431B-ESC1 board, so it is way faster. Also less glitching and noise, although these may be soluble through other means, that floating point hardware and faster clock rate is clearly useful in this context for sure.
SimpleFOC has a Step/Dir interface. If you connect that interface to the output of a microcontroller running something like GBRL, couldn’t you make SimpleFOC work with GCODE?
Interpreting GCODE in my opinion is completely outside of the scope of engine drivers. There are countless variants of GCODE that you have to specify when using a CAM tool.
That is the whole point. If using Klipper w. SimpleFOC, we don’t need the usual step-generating MCU.
Each node will then work like sub-drivers in OPnP
@JorgeMaker maybe you should reed up on Klipper. Klipper interpret Gcode and sends the move commands to each node. Or turn on LEDs, heat-bed, etc.
But of course, diving into actual USB implementation, like Klipper does. Will either make your Studio useless or you will have to upgrade that with a real USB option (64-bit)
Maybe Klipper will be the place to monitor data while in use?
Valentine, that’s awesome, I know another guy that is also going down this road, I think we should totally collaborate, I’m waiting to hear back more of his thoughts by email. Releasing a proposed draft could be a good way to do that for sure. I think the guy I know may be willing to pay for getting boards made, and I can help with testing. I think this is going to be a really good thing for the community
Yo can develop an interpreter of Klipper commands making possible to run Klipper on the same microcontroller that you are using for your SimpleFOC instance, effectively creating a “Klipper Node.”
However, in my opinion, this is not in line with the purpose of SimpleFOC, as it operates at a higher layer. If you look at examples such as oDrive, VESC, or Moteus, none of them go beyond basic motion planning for a single axis.
I’m still getting back into simplefoc, so klipper/gcode isn’t on my mind at the moment. There are quite a few great boards in development, but like most people I want to make my own!
I’m likely to go the drv8316 route, my pcb design skills and rusty electronics knowledge makes the onboard 200ma buck, integrated fets and current sensing appealing.
Once I’m comfortable with my board/motor setup. I’ll work on a combined power/brain board controlling multiple motor boards perhaps with a bit of ML/vision recognition.
