Torque mode, FOC?

[robcazzaro]

Just wondering if you are planning to add FOC and torque mode like the Eferu project, or if you know of any FOC algorithm implemented for the GD32F130C8T6.

If not, I might want to try "merging" your base GD32 code with the FOC algorithm from Eferu

[Candas1]

Hi,

Your nickname rings a bell. Are you in the simpleFOC community?

If you want to port FOC, check this, someone had started to port it, I did small adjustments but couldn't finish as I was busy with something else.

Another idea I had is This
It could potentially lead to use simplefoc but a lot has to happen before (testing/arduino core for gd32, sensor smoothing in simplefoc), so it's more long term

[RoboDurden]

Oh yes, https://simplefoc.com/ looks very promising.
And fully object orientend as far as i can see: https://docs.simplefoc.com/source_code

Not only the stm32f1 family but also the stm32f4 family is said to be supported: https://docs.simplefoc.com/stm32_mcu
If the code runs on a bluepill (stm32f103), then it should directly run on an old gen1 board (stm32f103 and gd32f103).
But the doc says that only 1 motor low-side current sensing is possible.

But to my understanding, phase current sensing is only needed without hall sensors. But Candas said the EFeru FOC code needs two phase currents (the third can be derived from the first two).
I think, FOC basically is only the closed loop to control the six mosfet in a rotating coordinate system which makes the closed loop simpler. The rotation should also be able to be found from the hall sensors. But the current sensing is analog whereas the hall sensors are digital...

The docs of SimpleFOC in https://docs.simplefoc.com/code says:

proceed to initializing and configuring the current sense, if available of course. If current sense is not available you can skip this step. The library supports two types of current sense architecture:

    in-line current sensing InlineCurrentSense.
    low-side current sensing LowsideCurrentSense.

That example code looks really nice and it should be straight forward to get two motors (without phase current sensing) running on the old stm32f103 and the new stm32f403 boards !?

There is https://github.com/keyboardio/ArduinoCore-GD32-Keyboardio but maybe only the GD32F303 is supported and not the GD32F130 that is found on these Gen2 boards.

Adding FOC to my Gen2.x repo is not really on my todo list.
At the moment i am merging the two serial communications (Esp32-Hover_master + Hover_master-Hover_slave) into one universal uart communication that can chain several baords. For example a robot arm on a moving platform:

typedef struct __attribute__((packed, aligned(1))) {
   uint16_t cStart = START_FRAME;   // new version
   uint8_t iSize;
   Server2HoverSpeedSteer oMover; // digger moving wheels
   Server2HoverPos oPos1;   // robot arm servo 1
   Server2HoverPos oPos2;   // robot arm servo 2
   uint16_t checksum;
} Server2Hover;

So additional structs Server2HoverTorque or Server2HoverRpm might be in reach.
But these structs should of course be c++ classes derived from an abstarct class Server2HoverControl with an element function (method) Control() that hosts the closed loop needed to control a position or torque or rpm in these classes.

So yes when i have finished a closed loop for positioning a rotation angle, it would be easy to add a torque mode.

@Candas1 i have probed the DIO2032 dual opamp outputs of the gen2.2 board with my dso and they do not seem to be current and voltage:

Do you recognize these outputs (motor was spinning) as tow low-side phase currents ?
Then at least the 2.2 layout might support the EFeru FOC code ?

Greetings from sunny Germany :-)

[Candas1]

No simplefoc cannot handle 2 motors yet.
Phase current is needed for FOC.
Hall sensors are needed for motor angle but as simplefoc was mainly used with encoders, it has not extrapolation of the angle between hall changes yet as Eferu's firmware uses it for SIN and FOC. It's work in progress.

[RoboDurden]

Thanks Candas1 for your feedback!
If simpleFOC is truely object oriented then of course it should support as many motors as there are IO pins availble. And all motors should share the same 16 kHz interrupt to handle the foc control loop.
Our hoverbord motors have 90 hall steps per revolution and with 14 rpm/V we have 5-8 revs/s yielding 450-630 Hz.
Should be no problem to make a quadratic extrapolation somehow like s(t) = v*t + 1/2 a * t² to boost that to 16 kHz

We have to find such a solution anyway for the modern stm32f403 boards anyway ?

[robcazzaro]

Also: the "split boards style" hoverboards all have a processor and drive only one motor, communicating with each other over serial. So, all those are great candidates for Simplefoc. It's the first generation boards that used a single processor driving both motors (and using side boards for the IMUs).

Thanks for the additional links @Candas1 (and, yes, it's me on SimpleFOC forums :). I'll have a look at them, especially the Arduino port,

But the GD code (https://github.com/CommunityGD32Cores/ArduinoCore-GD32) is still pretty untested, so I will need to get a GD32F130 chip, replace it on a Bluepill, and verify that PWM, ADC and timers all work as expected before trying it on a board where the wrong signal can result in magic smoke release from the MOSFETs.

The split board hoverboards are a near perfect source of high power drivers: I just got a 25V/250W hoverboard with a dead battery for $10. Basically $2.5 each for drivers and motors :) Problem is, they all use different processors and it's a crapshoot to know what you will find when you open one, so a generic framework is the best option. And I'm ok using encoders instead of the Hall motors, if that makes SimpleFOC easier to run on them

[Candas1]

Also: the "split boards style" hoverboards all have a processor and drive only one motor, communicating with each other over serial. So, all those are great candidates for Simplefoc. It's the first generation boards that used a single processor driving both motors (and using side boards for the IMUs).

Thanks for the additional links @Candas1 (and, yes, it's me on SimpleFOC forums :). I'll have a look at them, especially the Arduino port,

But the GD code (https://github.com/CommunityGD32Cores/ArduinoCore-GD32) is still pretty untested, so I will need to get a GD32F130 chip, replace it on a Bluepill, and verify that PWM, ADC and timers all work as expected before trying it on a board where the wrong signal can result in magic smoke release from the MOSFETs.

The split board hoverboards are a near perfect source of high power drivers: I just got a 25V/250W hoverboard with a dead battery for $10. Basically $2.5 each for drivers and motors :) Problem is, they all use different processors and it's a crapshoot to know what you will find when you open one, so a generic framework is the best option. And I'm ok using encoders instead of the Hall motors, if that makes SimpleFOC easier to run on them

There is even a i2ccommander that could be used to control more than 2 boards.

Again I am not saying it's easy, this will take time. But if we get there we would have made gd32-arduino and simplefoc better, and we can go further than EFeru's FOC as simplefoc has also position control, it's more maintainable and has more support. Last few months I struggled improving EFeru's FOC because of the Matlab model.
I started this experiment with the sideboards as a proof of concept because those are mostly splitboards without motor control. I already found some issues with gd32-arduino that need to be fixed.

The quickest solution if you only care about FOC and torque would be the link I shared with EFeru's foc. But you need to find a board that has the current sensing.

If you want to go fast, go alone. If you want to go far, go together

[Candas1]

And the work recently done by @RoboDurden to document the different board layout is very useful, we could use those different define.h files

[Candas1]

Thanks Candas1 for your feedback! If simpleFOC is truely object oriented then of course it should support as many motors as there are IO pins availble. And all motors should share the same 16 kHz interrupt to handle the foc control loop. Our hoverbord motors have 90 hall steps per revolution and with 14 rpm/V we have 5-8 revs/s yielding 450-630 Hz. Should be no problem to make a quadratic extrapolation somehow like s(t) = v*t + 1/2 a * t² to boost that to 16 kHz

We have to find such a solution anyway for the modern stm32f403 boards anyway ?

Actually one of the improvements I did on mainboards that I didn't share yet is separating the current sensing and FOC for each motor.

But again mainboards would need even more work on the simpleFOC side, so I would focus on splitboards for now.

The extrapolation is not a problem in normal conditions, but you need to take care of transient cases like when direction changes, EFeru's does this well.

[RoboDurden]

Okay i better cancel my uart chain protocol and start with simpleFOC :-)
I was able to compile https://github.com/CommunityGD32Cores/gd32-pio-projects/tree/main/gd32-arduino-blinky
with PlatformIO in VisualCode with the readme.me of https://github.com/CommunityGD32Cores/gd32-pio-projects/

i switched to the available genericGD32F130R8 using the project environment switcher in the bottom taskbar. The R8 has the same hardware as the C8 but offers more io pins in the 64 pin package.

Choosing an led pin from one of my defines2-x
https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/tree/main/HoverBoardGigaDevice/Inc
should make the blinky code make a hoverboard led blink:

#include <Arduino.h>

#ifdef LED_BUILTIN
#define LED LED_BUILTIN
#else 
#define LED PC13
//#define LED PB13
#endif 

void setup(){
    pinMode(LED, OUTPUT);
}

void loop(){
    digitalWrite(LED, LOW);
    delay(500);
    digitalWrite(LED, HIGH);
    delay(500);
}

I will try to upload the bin file later the day. But i am totally new to PIO (platformIO).

[Candas1]

You can also check what I did here

[RoboDurden]

Oh yes thanks for the reminder. I was not aware that the sideboards of the gen1 hardware also have a gd32f130 on board.

Now seeing your serial code I am more confident to build a standalone replacement for gen2.x based on simpleFOC.
But the i2ccommander has more benefits.

[RoboDurden]

@robcazzaro if you want to join the gd32 coding and live inside Europe I would be happy to ship you two sideboards with a gd32f130c6 for free :-)
But you should be willing to spend some hours on the project!

[Candas1]

Oh yes thanks for the reminder. I was not aware that the sideboards of the gen1 hardware also have a gd32f130 on board.

Now seeing your serial code I am more confident to build a standalone replacement for gen2.x based on simpleFOC. But the i2ccommander has more benefits.

Step by step
I wanted to start with a proof of concept that is already useful

[RoboDurden]

Okay i am able to flash with PlatformIO. The flash header in the image of EFeru was wrong for me:
https://raw.githubusercontent.com/EFeru/hoverboard-sideboard-hack-GD/main/docs/pictures/sideboard_pinout.png

My header needed GND , DIO , CLK , 3.3V

I powered the board with 14V but no led blinking.
So i tried debug but the code seems to halt at startup

@Candas1 did you succeed with your https://github.com/Candas1/Sideboard-Arduino and the firmware is running and can be debugged ?

[RoboDurden]

YES, the Candas1 Sideboad code works. At least i can debug step by step :-)
Tomorrow i will test led output and pwm with his code.
Then i might already try to add the simpleFOC library.
Great work @Candas1 :-)