I don’t think it is strange at all… it’s the kind of design I’m slowly working towards, although I don’t think I’m as far along as you in the journey yet
I agree completely with the need to separate the higher level control from the motor driving, I arrived at the same conclusion. I think there’s a lot you can do with ESP32 and presumably the new RP2040 - as they are dual core. And the more you can offload to dedicated peripherals and driver chips etc, the more headroom you have on the MCU, of course. But in the end you just don’t want any interference with the FOC driving, especially for higher speeds. So a 2-MCU design makes perfect sense to me.
Why not go directly to RaspiPi as the second “MCU”? I was thinking about that, but I come to the conclusion that:
- there is still quite a need for low level stuff (e.g. reading sensors, controlling LEDs, CAN-bus, etc…) beyond the motor driver. RaspiPi is very cool, but not really that low-level
- it uses waaay more power
- it would be hard to integrate on a motor driver PCB. and a “Hat” solution would be awkward (and big).
Have you taken a look at the Arduino Portenta H7? I know it’s expensive, but it has a powerful STM32H747 chip - which has a M7 and an M4 core on the same chip. There’s a breakout board for it now, which makes it actually useable for prototyping.
But may I ask why you would want a second MCU on each motor board? Almost all robots need more than one motor - would you have physics calculations to do on each motor seperately? Or do you plan for a main dual-mcu controller, and separate “satellite” controllers, perhaps with only one MCU, for the other motors?