SimpleFOC Best Compatibility Controller for One Wheel Balancing Robot

hardware support
1

Hello Members,
I am new to this community and I’ve observed it’s a great platform. I am building my robot that is reaction wheel unicycle robot as the tremendous work done by REMRC. (Unicycle balancing robot with reaction wheel).

In this project Gimbal Controller BGC3.1 board has been used, 8 bit.
image
which is now not available in the market. even if it is, it’s clone versions which one can’t update to connect to Arduino IDE.

I searched alot, most the boards are clones and don’t how to connect them with arduino IDE to control the Brushless DC motors with Magnetic Encoder AS5600. The original boards from (www.basecamelectronics.com) are very expensive.

I would really appreciate if someone can help me get started. Or if someone has already tried one of these boards to connect to Arduino IDE.

Your time and help is highly appreciated. I am stucked at this stage from weeks.

2

Hi @Nabeel21 , welcome to SimpleFOC!

The BGC3.1 controller is quite old now. It’s possible to get it working, but I really would not recommend it, especially in combination with I2C sensors and 2 motors, the ATMega chip is really not powerful enough, nor does it have enough RAM.

Doing this project (cool project!) will require you to tune several PID controllers and run many trials. It will be much easier for you using a up-to-date 32bit MCU.

Regarding the hardware: I think you can consider 2 types of setup:

  1. like BGC3.1 and Remy’s project, try to run 2 motors, 2 sensors and the control code on one MCU. This will place high demands on the MCU and you will have to code the solution carefully to keep the loops running quickly while at the same time producing telemetry and accepting control inputs.

  2. Run each motor on a separate MCU board, where the MCU does only motor control, and coordinate both motors from a central MCU which runs the control and balancing loop.
    This will be simpler in terms of the hardware resources and the code, but might have higher latencies in the control loop due to the extra communication between the MCUs.

It’s hard to say for sure which architecture is the better one…

For 1) you should choose a very fast MCU, perhaps an ESP32-S3 with 2 cores or a fast STM32G4 like a Nucleo64-G474 board. ESP32 could be tricky because they don’t have so many pins to use.

For 2) you could use 3 smaller MCUs, for example a Nano33 Sense or IoT (with integrated IMU on the board) as the controller MCU and two cheaper SAMD21 (like a Feather M0, Seeed XIAO), Nucleo32 or RPi Pico as the motor MCUs.
If you can connect the MCUs via I2C we have a I2CCommander class you could use to easily control the motors from the main MCU.

In either setup I would strongly recommend using SPI type sensors (AS5048A, various others) or ABZ type encoders and not to use I2C, which is really too slow for the sensor connection.

For the driver, you could use 2x SimpleFOC Mini drivers. I think it will be simpler to find two separate drivers than one dual one, but it doesn’t really matter. Look for drivers that allow you to use 3-PWM control, as this will be simpler to interface (less pins needed).
As long as you use relatively high resistance, gimbal type motors, you don’t really need current sensing I don’t think.

Let us know how it goes! We would love to see some pictures of your project!

3

About the MCU with integrated IMU.
If it is internally connected via i2c, doesn’t it slow down the whole control loop, no matter how fast the motor loops are? They simply work with the same outdated angle-data 4-5x before they get fresh data.
IMHO that’s the bottleneck unless it’s a SPI bus IMU? Does simpleFOC support Rev.2 nRF52840?

4

In this setup, each motor has a sensor which is connected to the motor board with SPI or ABZ - so the FOC motor control loop can run very fast.

The central MCU has the IMU and does the balance control loop. I2C would limit this loop to around 1kHz or so, but this could be enough. Even on a one-MCU setup it is normal to down sample the motion loop compared to the FOC loop if the MCU is fast…

But I did mention this type of setup has higher latency. To lower it, you could use (for example) PWM control of the motors, let’s say at 20kHz carrier frequency. That would let you control (theoretically) at 20kHz. We have such an PWM input class for STM32 MCUs. Or you could try connecting the motor MCUs via SPI or CAN-FD…

And for the IMU there are SPI based ones, although that’s not what’s onboard the Nano33s

5

Thank you so much @runger for your detailed reply. Indeed, your recommendations ring the bell. I actually bought a BGC3.1 board and tried to bootload using Arduino as an ISP. However, after one upload (which was successful, by the way), the board is dead now.

I can’t make it work now. The best thing about using this board is I don’t have to use separate BLDC drivers (like simpleFOC shields) in conjunction with the overall setup.

I came across the Storm32 BGC Board. What would you recommend about these board configurations with Arduino IDE?

6

Hi,

The problem with the Storm32 boards is they don’t easily support SPI sensors. They’re designed for open loop control or I2C sensors, which will be too slow. I think mostly they’re used open loop for the motors, with a IMU for the balancing loop.

I think there is a thread on the forum here about hacking them to support SPI (solder a line to one of the LEDs) but that’s not exactly easy.

You may like the STEVAL-GMBL02V1 - it has a STM32F3 MCU and STSPIN233 drivers, and you can connect SPI or ABZ sensors without too many problems. Bit more expensive though.

7

Thank you for your prompt response. I will further look into this and will keep the community posted here about my project.

I have done the simulations and other work which I will make it open source soon. Thanks

2 Likes
8

not to derail, but this would be another good candidate for the QADVRANS or Lepton 3.0 type board I think, so confirmation that project makes sense. Got too much else on my plate for another month but maybe after that. I got another guy making a quiet fan that needs a driver and I recommended the mosquito…