I’m planning to make a 100% open hardware ‘toy’ robot. Similar to the ~$200 M5mouse but cheaper.
Based on the ESP32devC board as I want to run uROS on it. I’m looking to do a ‘open core’ for the M5stack daughterboards (particularly LoRa & Canbus). looking at Deng controller and wondering if it can be shrunk to 5cm x 5cm, to fit the M5 profile?
I like LifePO4, so looking at either 3x or 4x 14650 (AA) batteries ~9.6v or ~13.2v.
So to motors:
Are the $42 2205 the smallest/cheapest option for Simple FOC?
For small motors, also consider the STSPIN233… it will allow tiny solutions!
And AS5600 is not the greatest sensor, you’ll also have to consider I2C addressing if using many of them.
As you might expect the construction on the $3 motors won’t be so nice, you’ll get significantly less smooth rotation, but so far all the cheap motors I’ve ordered from AliExpress have worked ok. So I definitely recommend trying them, given the price.
I can also say from experience that you can get the price of self-made sensor boards down quite low… since they are very small you get many in a panel, and they have hardly any components on them. So ordering them assembled in the shape you need in quantities of 10-20 works out at more or less the same price as the cheaper offerings on AliExpress. So in this way with the cheaper motors and a self-made board you can also reach prices of <$20 per motor+sensor.
If you’re interested I’m happy to share my designs.
I’ve never seen a 4 channel board… would be cool though. I guess the DJI RoboMaster must have one, but I haven’t looked at the chips on it, so don’t know if they do it from a single MCU.
The main problems will be the following:
Running 4x FOC loop will be really a heavy load for a MCU, only the fastest MCUs will have acceptable FOC performance when running 4 motors. The ESP32, with 2 cores, could probably do it. One of the high-end STM32s probably could too.
Having enough timer peripherals. Most MCUs only have one or two timer peripherals capable of running 3 PWM channels (let alone 6) for motor control. And often the peripheral assignment to the pins causes conflicts (i.e. even if you could use 4 timers, you then can’t use SPI or an ADC channel you need, something like that).
Having enough pins. Even the simplest possible configuration with only 3xPWM and no current sensing would require 4 pins per motor + the sensors pins + comms - it will be very tight! And doing 4 motors with full features (current sense, 6 PWM, etc) would really need lots of pins.
Reading sensors quickly enough. Probably can’t use cheap I2C sensors if you want read 4 of them quickly enough (or maybe - but you’d need 4 I2C buses, which is lots of pins). But even SPI might be slow for 4 sensors…
But if you can overcome these problems it should be doable. it would certainly be exciting to give it a shot!
Note there are several choices for 3x motor drivers - thanks to the 3-axis gimbal use-case. Something like the STEVAL-GMBL02V1 or the cheaper Storm32 boards. The ST board is more expensive, but much easier to hook up SPI. The Storm32 boards are cheaper but you have to hack them with a soldering iron to connect an SPI bus.
That would let you build a 3-wheel omni-drive robot
I say no way, it has far too few pins, and it only has 2 MCPWM units… but just maybe it could work in a very minimal configuration.
Yeah, I just checked, and I don’t think anything I have designed can be made right now based on chip availability… on the other hand it can be worth asking, as PCBWay (for example) has been able to source chips I haven’t found available anywhere here.
I’ll try to post some pics and links today. I am focusing on “small robots” - so unlike many people in this forum my power requirements are modest, which makes things much simpler.
I started out trying to find ready solutions, but they were too expensive, didn’t do FOC, and most of them far too big for my purposes. Next I looked into doing it by making a motor driver “shield” for an existing MCU - but my conclusion is more than 1 motor is unrealistic, due to the number of pins needed. Only the large MCU boards like the big Nucleos or a Metro M4 would even have enough pins for 2 motors, and those boards are too big for me. So now I’m designing small drivers with the MCU integrated, but I’m stalled for the last 6 months due to the chip situation…
I’ve done some designs, but not produced anything yet… its a choice that’s hard to make:
do you put the motor driver and the sensor on the same PCB which means one driver per motor, but no sensor cables. motors drivers could be connected via CAN, or on small systems via I2C. MCU choice is flexible since not so many pins are needed. Making small PCBs with MCU and motor driver on them is not easy to do though.
or do you make a central board with multiple motor drivers, which will necessarily be a bit bigger, and require sensor cables and separate sensors on each motor? Might be easier from other standpoints, e.g. having one MCU to handle all the motors is much easier to update firmware than if it is 4 separate driver boards with their own MCUs.
It seems like a reasonable suggestion to me. Make sure you have enough pins for everything, the ESP32 has less pins than it seems because a bunch of them are always connected to flash and can’t really be used.
UART I would avoid (just a gut feeling), although in theory of course you could use the SimpleFOC Commander as the basis for a Serial-based protocol, or design your own.
I2C could work, I think, especially if the master can control the slave without needing too much feedback. (stay tuned for my I2CCommander class which I am just in the process of testing, and will publish to GitHub soon )
SPI could be a good option if you need lots of communication back from the slave, as it is fast, fully synchronous and generally quite easy to design protocols around.
CAN-bus would be a professional style choice, though maybe more appropriate when the devices are further apart from each other than in your case. There is some CAN-bus code available for SimpleFOC in the forum somewhere.
Whatever your choice, you will have to make sure that the comms layer does not interfere with the FOC algorithms execution (by taking too much time). On Dual-Core ESP32s you could separate motor driving and comms between the two cores, that might be a good solution. Or use the RTOS support on the ESP32. Or just make sure you send and receive in a non-blocking way.