motor does not reach max speed like old Gen2.x binary about split_hoverboard_simplefoc HOT 84 OPEN

That is really good news @RoboDurden. We can confirm it's a IRQ overhead issue. I will send you a couple of file to try before my end of day (overwriting the existing one for now). Thanks for doing this, and clever use of the audio, well done!

Just FYI: the GD32 Arduino core has some weird behavior with the interrupts, I opened an issue in their repository to be sure CommunityGD32Cores/ArduinoCore-GD32#105.

TLDR:
The GD32 interrupt handler (at a hardware level) groups GPIO 0-1, GPIO 2-3 and GPIO4-15 as separate interrupt source. So the EXTI01 handler must check if GPIO0 or 1 fired. Same for EXTI23. The problem is that any interrupt for pins 4 to 15 fires only one interrupt, and the handler must scan all 12 possible sources to see which one fired. So the HALL sensor on PB11 takes a long time, and the one on PC14 even more. The easy hack is to only check for pin=11 or pin=14 in the EXTI4-15 handler (which makes the code much, much faster), but I wanted to fully understand the GD32 logic for multiple ports and pins before messing with it.

Also opened CommunityGD32Cores/ArduinoCore-GD32#106 to see if we can speed up the IRQ handler without having to change the GD32 Arduino files

Bottom line: as long as we know what interrupts we need for GPIO pins change, we can easily speed things up, and I have working code. Just want to finish testing it

from split_hoverboard_simplefoc.

Ok, here are 3 files to replace whenever you have time @RoboDurden

C:\Users[yourname].platformio\packages\framework-arduinogd32\cores\arduino\gd32\gpio_interrupt.c
[project_dir].pio\libdeps\GD32F130C8\Simple FOC\src\sensors\HallSensor.h
[project_dir]..pio\libdeps\GD32F130C8\Simple FOC\src\sensors\HallSensor.cpp

Please note that one is in the platformio GD32 platform directory, the other 2 in the project directory. And please check that the changes are compiled. Incidentally, the VS Code UI sometimes gets confused by all the nested defines, so in the gpio_interrupt.c file, the portion following `#elif defined(GD32F3x0) || defined(GD32F1x0)" is shown as disabled (greyed out), but it's active and gets compiled (GD32F1x0 is defined). It's a VS code UI bug. That one is the file I hope not to have to change thanks to this

Please also keep the -Ofast optimization enabled for now. It will make debugging harder, but a 4% gain is non-trivial. There are further optimizations possible in the Hall sensor code (updateState()), but those require more thinking. The ones I did for now are pretty safe.

If anything is unclear, just ask. I tested everything and it seems to work as expected, but it would not be the first time I screw up 😊

hall_IRQ.zip

from split_hoverboard_simplefoc.

I am wondering if at high duty cycle the values are clamped, so the sinusoidal is flat.

The best way to verify that would be to use a logic analyzer connected to the processor PWM pins (it's enough to only use 3 pins, like the 3 high phase pins), and once the motor is spinning at constant speed, capture enough pulses to see the PWM signal. It's easy that way to see a clipped signal, as a long sequence of 1s

from split_hoverboard_simplefoc.

I am still not sure if the sensor alignment is good.

One way to check this is described here

Do you see/hear differences in how the motor spins in each direction with both binaries?
A wrong offset could lead to phase advance in one direction, and phase delay in the other direction.

from split_hoverboard_simplefoc.

you can hear in the video for yourself but no the sound is the same.
The current however is about 540 mA spinning "left" and about 580mA spinning "right".
So there indeed is some asymmetry

Good night ! i am tired now and i still want to finish the rewatch of https://en.wikipedia.org/wiki/The_Hunt_(2012_film)
Good dvd...

from split_hoverboard_simplefoc.

@RoboDurden can you please do a quick test

Add the following to the plaformio.ini file

build_unflags = -Os
build_flags = -Ofast

It compiles the binary with the highest level of optimizations possible, and if my theory is correct (slow interrupt), it should speed up the motor by a small but measurable amount.

Meanwhile I'm looking at the interrupt code

from split_hoverboard_simplefoc.

@robcazzaro , I would rather do that tomorrow when I have arrived at my solar warehouse. I have already packed the test setup in a box. And my notebook is occupied with 3d printing..

from split_hoverboard_simplefoc.

If the effect is small i will need UART rpm logging and I have yet to setup that again.

from split_hoverboard_simplefoc.

@robcazzaro , I would rather do that tomorrow when I have arrived at my solar warehouse. I have already packed the test setup in a box. And my notebook is occupied with 3d printing..

Of course, I didn't mean "right now" 😉 whenever you have time, no hurry

I saw a few Android apps that can measure RPMs if you stick a white tape to the wheel, maybe that is easier than enabling UART. I mean, UART is good to have, but an RPM meter app might be a quick way to see if there are differences

from split_hoverboard_simplefoc.

@RoboDurden I understand the interrupt handling code pretty well now, and there are a few hacks that would speed things up. But it requires a few changes to a few files and possibly breaking compatibility with the official GD32 core.

If, whenever you have time, you can confirm that compiling with -Ofast (the platformio.ini changes above) makes a difference, I will send you the modified files. Otherwise there's no point in having you waste time with the changes.

from split_hoverboard_simplefoc.

Okay that were my changes:

;build_flags = -D __PIO_DONT_SET_CLOCK_SOURCE__
;	-D __SYSTEM_CLOCK_48M_PLL_IRC8M_DIV2=48000000
build_unflags = -Os
build_flags = -Ofast	

I did not hear a higher speed and android apps do not use camera but inernal IMU and you have to put your phone on the turntable..

But current was sligtly less. before 590mA and 550mA (left/right) and with your requested changes: 550mA and 500mA

So i recorded the audio: www.robosoft.de/forums/rpmsound.mp3
first you hear simpleFOC-old left/right, than your new ini file left/right, and last the gen2.x left/right
And i made a fft analysis from the constant part of all three left(?) sounds:

So yes, your requested ini changes result in a 476 Hz / 456 Hz = 4.3% speed increase,
but the gen2.x still has another 547 / 476 = 15% rpm increase on top of your changes.

This was a long sunday for me. Got 3.5 kW old solar panles for free:

Good night and good luck :-)

from split_hoverboard_simplefoc.

BTW: I have been looking at other ways to potentially speed things up, but would require changes here and there. If the interrupt enhancements are not enough, I have a few more things to try. But the GD32 at 48MHz is slower than most other processors recommended for SimpleFOC, so we might have to hand-optimize more. To be fair, the FOC algorithms are more compute-heavy than the type of control implemented by most hoverboards

from split_hoverboard_simplefoc.

Don't be pessimistic, I am sure we will get there.
We are not doing foc yet, but I assume that the boards with current sensing had foc implemented.

We for sure will have to optimize because of the arduino-gd32 and simplefoc overhead.

from split_hoverboard_simplefoc.

no, the new three file do not make a difference:

The gen2.x also has a speed difference with left/right, but only 0.7%.
the simpleFOC has 1.5%.

I think the gen2.x has no interrupts for the three hall sensors at all but simply reads the state in the bldc.c 16 kHz CalculateBLDC():

	// Read hall sensors
	hall_a = gpio_input_bit_get(HALL_A_PORT, HALL_A_PIN);
	hall_b = gpio_input_bit_get(HALL_B_PORT, HALL_B_PIN);
	hall_c = gpio_input_bit_get(HALL_C_PORT, HALL_C_PIN);

So i do not really think that the three hardware interrupts from HallSensor class take longer or are less accurate ?

The EFeru FOC is faster than the Gen2.x anyway and with field weakening it can get even faster (20%). So maybe we should procceed with current sensing to get simpleFOC foc working and then have new options to tune speed and power consumption.

from split_hoverboard_simplefoc.

Foc is actually slower than trapezoidal or sinepwm, even with EFeru's firmware.

from split_hoverboard_simplefoc.

Bummer. And thanks @RoboDurden for your additional tests.

Clearly, even if the interrupt code was inefficient, it did not consume enough cycles to be a meaningful difference. Was a low hanging fruit, but not the right one.

There might be other opportunities (for example the sensor.updateState() function is over complex and calls bloated functions (like micros() that is needlessly complex, would be easier to re-implement using DWT_CYCCNT and knowing that the core clock is 48MHz). @RoboDurden if you try following the hall sensor code, you will see that a simple 3-line GPIO read in the gen2.x software is more than 50 lines, called each hall interrupt (open and close). SimpleFOC abstraction makes things more complicated (SimpleFOC can for example use SPI encoders for angle control, and the same code works with hall sensors)

As for the speed difference between boards, that is 0.7%. We are running the GD32 using the internal oscillator, which has a 1% accuracy, so that could explain the small difference you are seeing.

The next step unfortunately it's profiling the code. The best way is to use SWD/SWO, but if you have a cheap STLink Chinese clone, the SWO pin is not enabled. It can be enabled with https://lujji.github.io/blog/stlink-clone-trace/ and it's well worth it, but time consuming and you need to be good at soldering on the small STM32 pins. With that enabled, you can ten use the STM32CubeIDE from ST to run the SWV Statistical Profiling (it's under Window, Show View, Other

That would get you a complete profiling profile, but might be too slow over SWO and pretty hard to get running.

Otherwise use macros and DWT_CYCCNT to measure execution cycles by function, which is probably the best way to go for us here. There are even available implementations like https://github.com/Serj-Bashlayev/STM32_Profiler. DWT_CYCCNT is a standard M3 core register, so available on the GD32. That library prints using SWO (once again), but it could also print to a debug output after a fixed time profiling.

Or it would be easy to enable DWT_CYCCNT once at the beginning, create a structure for the various functions we use, store the DWT value upon entering the function, subtract the value at the end from the start, and add the instruction count to the right element of the structure for that function

//the following code needs to run only once when enabling the profiling

// enable DWT
CoreDebug->DEMCR |= 0x01000000;
// Reset cycle counter
DWT->CYCCNT = 0;
// enable cycle counter
DWT->CTRL |= 0x1;

// for each function
uint32_t start = DWT->CYCCNT;

// code to be measured here

structure.this_element += DWT->CYCCNT-start;

Then stop the code after, say, 1000 loops and print the values in the structure. the DWT counter can go up to 4294967295, so at 48MHx, as long as the profiling session ends within 89 seconds of the DWT->CTRL |= 0x1 instruction, we won't have to worry about handling the counter overflow

Alas, I can't profile on the Bluepill dev board. Without a motor and hall sensors, the code won't work as expected. If you think you can run the profiler, I'd be happy to then analyze the code and see where we can gain. If you can't, I'll have to set up my only board and hope for the best

from split_hoverboard_simplefoc.

Well all the many lines you wrote here about such a profiler does not make me wanting to do it at all :-/
My dso single channel did show that the simpleFOC and gen2.x waveforms are quite alike.
So.why not find a clever way to see what is different...
I think candas mentioned a different alignment.
I think I have a cheap multi channel logic analyser in my train station but I forgot to take it with me to my solar warehouse.
Logging the three hall inputs and some gate outputs might shed some light in what simpleFOC is doing differently or badly.

If there are some delay parameters we could program an Auto-Tuning that optimizes rpm with a steepest descent over all parameters..

I would prefer some direct approach instead of blindly increase analyzing..

Good night for today's

from split_hoverboard_simplefoc.

Profiling is not blindly increasing analyzing 😉. It's looking for inefficient areas of the code that are holding back performance. If we are performance limited now, it's only going to get worse once we add the more complex elements of the SimpleFOC code. Insufficient processor performance is one of the most common causes of problems reported in the SimpleFOC forums.

You can't examine external signals to see where the problem is. Let's assume we find that the PWM waveform is 3% delayed compared to other code. How would we go about changing that, if we don't know what's causing it?

The main take away from my previous comment is that measuring performance is as easy as adding 2 instructions, one at the beginning, one before the exit of each function, plus half a dozen at the end of setup(). If we use macros for the beginning/end of each function, we can enable/disable perf measurement during development. And that will benefit everything we do and help optimize in the future.

That is the clever way to see what's happening, IMHO. But I'd be happy to be proven wrong, if you can find something else that works. And, yes, it might be just a hall sensor alignment, that would be great. I'll hold on doing anything wrt profiling until you fully evaluate that option.

from split_hoverboard_simplefoc.

Just a reminder.
Gen 2.x is running at 72Mhz, the simpleFOC one at 48Mhz.

from split_hoverboard_simplefoc.

I simply am the totally wrong guy to analyze bad code instead of writing good code right from the beginning :-/
?? The GD32 runs at 72 MHz, Gen2.x and simpleFOC both run on the same hardware ??

Speaking of bad code, putting a time critical function in to loop() should be an absolute no-go. It only needs a delay(1); to crush the motor output:

void loop()
{
  // main FOC algorithm function
  // the faster you run this function the better
  // Arduino UNO loop  ~1kHz
  // Bluepill loop ~10kHz 
  motor.loopFOC();
  delay(1);

I do not really understand The Gen2.x code comments. bldc.c:

// Calculation-Routine for BLDC => calculates with 16kHz
void CalculateBLDC(void)

Which is called by an interrupt handler in it.c:

// This function handles DMA_Channel0_IRQHandler interrupt
// Is called, when the ADC scan sequence is finished
// -> ADC is triggered from timer0-update-interrupt -> every 31,25us
//----------------------------------------------------------------------------
void DMA_Channel0_IRQHandler(void)
{
	// Calculate motor PWMs
	CalculateBLDC();

1s / 31,25us = 32 kHz, not 16 kHz. But nice idea to trigger the CalculateBLDC() when all adc input are ready to be read.
I guess that handler is initialized in setup.c::ADC_Init() :

	// Configure ADC clock (APB2 clock is DIV1 -> 72MHz, ADC clock is DIV6 -> 12MHz)
	rcu_adc_clock_config(RCU_ADCCK_APB2_DIV6);
	// Interrupt channel 0 enable
	nvic_irq_enable(DMA_Channel0_IRQn, 1, 0);

But i do not understand how RCU_ADCCK_APB2_DIV6 -> 12 Mhz translates to 32 kHz.

As all three phase channels should be absolute in sync, i also do not understand why three different timers are needed. But maybe all 4 (or 5 for the C8 variant) 16-bit timers are in sync as they are based on one internal counter..

What i like about the Gen2.x code is that it is plain simple. One CalculateBLDC() that runs at whatever kHz and everything is in sync.

I guess we are free to overwrite some simpleFOC classes and replace code the object oriented way.
Instead of modififying simpleFOC or GD32-Core files.
I am the wrong guy for analyzing code without first having understood what it is intended to do.

from split_hoverboard_simplefoc.

okay, max speed is even higher (545 Hz left and 555 Hz right) then Gen2.x when setting these two init values to 20 instead of 26 (Volt):

  driver.voltage_power_supply = 20;
  driver.voltage_limit = 20;

But the current high rises to 850-900 mA instead of the Gen2.x with less than 500 mA :-/
I have the feeling that the problem is not code optimization but wrong pwm alignment and therfore inefficient motor control.
But with my 1 channel dso i fear i can not dig deeper.

Update:
22 Volt lead to 537 Hz and 544 Hz at about 700 mA.
24 volt give 502 Hz and 502 Hz (left/right) at about 600 mA.

It think these two parameters get used here:

// Set voltage to the pwm pin
void BLDCDriver6PWM::setPwm(float Ua, float Ub, float Uc) {
  // limit the voltage in driver
  Ua = _constrain(Ua, 0, voltage_limit);
  Ub = _constrain(Ub, 0, voltage_limit);
  Uc = _constrain(Uc, 0, voltage_limit);
  // calculate duty cycle
  // limited in [0,1]
  dc_a = _constrain(Ua / voltage_power_supply, 0.0f , 1.0f );
  dc_b = _constrain(Ub / voltage_power_supply, 0.0f , 1.0f );
  dc_c = _constrain(Uc / voltage_power_supply, 0.0f , 1.0f );
  // hardware specific writing
  // hardware specific function - depending on driver and mcu
  _writeDutyCycle6PWM(dc_a, dc_b, dc_c, phase_state, params);
}

from split_hoverboard_simplefoc.

short note to @Candas1 , that add_RTT_task.py needs
"\"$PROJECT_PACKAGES_DIR/tool-openocd/bin/openocd\"" +
to handle path names with " " spaces.

Nice to have log output without another cable. But the sensor.getVelocity() output is not smooth at all:

GD32: 26500     0: 0    1: 1    2: 1    angle: 103.81   speed: 41.65
GD32: 26600     0: 1    1: 0    2: 0    angle: 107.79   speed: 38.98
GD32: 26700     0: 0    1: 1    2: 0    angle: 111.70   speed: 41.68
GD32: 26800     0: 0    1: 0    2: 1    angle: 115.61   speed: 35.01
GD32: 26900     0: 1    1: 1    2: 0    angle: 119.59   speed: 40.85
GD32: 27000     0: 0    1: 1    2: 0    angle: 123.43   speed: 41.02
GD32: 27100     0: 1    1: 0    2: 1    angle: 127.41   speed: 36.84
GD32: 27200     0: 0    1: 1    2: 0    angle: 131.39   speed: 41.31
GD32: 27300     0: 0    1: 1    2: 1    angle: 135.23   speed: 41.83```

Do not think that the rpm at max speed changes by 40.85/35.01 = 17% within 100ms

Maybe we should indeed implement/derive our own HallSensor class :-/

from split_hoverboard_simplefoc.

@RoboDurden the sensor is not filtered in SimpleFOC and very "spiky". There is a new smoothedsensor class being developed for that reason.

The folks running the forum recommend using motor.shaftVelocity() instead of sensor.getVelocity(). That is filtered and smoothed

As for your question on the clocks, the GD32 (like STM32) have multiple buses and clocks, each with PLLs and dividers, and it's a puzzle trying to understand how fast each bus runs. for STM32, there is a function in the STM32CubeIDE that helps calculate each and every PLL and divisor and gives you an idea in MHz or kHz. I haven't checked, but if Gen2.x is running at 72MHz, all bets are off with clocks and timing accuracy and I doubt it's. But if you want to truly understand the actual values, you need to look at the clock initialization and note each and every value being configured, then you can know the actual speed of a specific bus or component (in some cases, the speed can be half of the clock, depending on the edge polarity). Just to give you a sense, here's the clock tree for the GD32F130 (page 79, User manual)

from split_hoverboard_simplefoc.

@RoboDurden one more comment re:

void loop()
{
  // main FOC algorithm function
  // the faster you run this function the better
  // Arduino UNO loop  ~1kHz
  // Bluepill loop ~10kHz 
  motor.loopFOC();
  delay(1);

Adding a delay(1) is really a lot in what should be a tight loop. A loop() with only a single instruction of delay(1) runs at less than 1kHz, which is way too low for SimpleFOC. So adding a huge delay of 1msec in that loop will never work. For a more relevant test you might want to use delayMicroseconds(1); If that causes problems, that means that the processor is not fast enough with the current code. If even something like delayMicroseconds(10) causes no problems, that means that the code is fast enough and the problem is not code efficiency (but settings and hall alignment)

The goal is to run the loop at at least 10kHz to have a smooth performance. Alas, SimpleFOC is not timer-driven, but runs in a tight loop which is a bad way to write time-critical code.

From the Gen2.x code I can't understand how the GD32 clock is initialized. Usually there is a call to SystemClock_Config() to initialize the GD32 clock, but the Gen2.x code uses a non standard way.

	//SystemClock_Config();
  SystemCoreClockUpdate();

I don't have Keil, so can't quickly test. I could port the code to VSCode, but it will take some time.

@RoboDurden If you have spare time, could you print the value of SystemCoreClock ? That variable is the GD32 clock (48000000 or 72000000). Knowing it will help making comparisons to the gen2.x code

from split_hoverboard_simplefoc.

We are free to move loopfoc and move functions to interrupts if we want to

https://community.simplefoc.com/t/simplefoc-theory-timing/2310/2?u=candas1

from split_hoverboard_simplefoc.

Good point @Candas1. Just a note that if we do that, we need to change how the hall sensor code works and disable those interrupts. Basically read the hall sensor upon receiving the timer interrupt like Gen2.x does (which would also make the velocity calculation much simpler and faster compared to the current one using the time between changes to calculate velocity, which as Robodurden noticed is very spiky). And make sure that the ADC code doesn't rely on interrupts either (Gen2.x uses ADC interrupts, but there are ways to start the ADC without interrupts). And look at how USART uses the interrupts in the Arduino code

Otherwise we have to deal with re-entrant interrupts and that causes all sorts of problems.

from split_hoverboard_simplefoc.

Yes we will trigger inserted adc at timer update event.

from split_hoverboard_simplefoc.

Some good advices were shared just now
https://community.simplefoc.com/t/hall-sensor-bldc-motor-does-not-turn/3046/10?u=candas1

from split_hoverboard_simplefoc.

In honor of @flo199213 who ported the good old Niklas Fauth hoverboard firmware to the split boards, we should refer to "Gen2" as my "Gen2.x" only added odometer, better serial and different board layouts.

Our main loop of the simpleFOC fimrware normaly takes about 110 us but max 1122 micro seconds, i guess when debug output gets sent:

  long long iMicrosNow = _micros();
  long iMicros = iMicrosNow - iMicrosLast;
  if (iMicrosMax < iMicros) iMicrosMax = iMicros;
  iMicrosLast = iMicrosNow;
  motor.loopFOC();
...
  if (iTimeSend > iNow) return;
  iTimeSend = iNow + TIME_SEND;
  DEBUG( 
    OUT2T("SystemCoreClock",SystemCoreClock ) 
    //for (int i=0; i<HALL_Count; i++)  OUT2T(i,aoHall[i].Get())
    OUT2T("angle",sensor.getAngle()) 
    OUT2T("speed",sensor.getVelocity())
    OUT2T( iMicros , iMicrosMax )
    OUT2T( 1000.0f/iMicros , 1000.0f/(float)iMicrosMax )
    OUTLN()
  )
  iMicrosMax = 0;

SystemCoreClock: 72000000       angle: 284.77   speed: 0.00     116: 307        8.62: 3.26
SystemCoreClock: 72000000       angle: 269.76   speed: -36.21   118: 294        8.47: 3.40
SystemCoreClock: 72000000       angle: 250.98   speed: -40.05   115: 1116       8.70: 0.90
SystemCoreClock: 72000000       angle: 230.66   speed: -44.78   114: 1114       8.77: 0.90
SystemCoreClock: 72000000       angle: 210.49   speed: -40.10   114: 301        8.77: 3.32
SystemCoreClock: 72000000       angle: 190.38   speed: -38.98   113: 1115       8.85: 0.90
SystemCoreClock: 72000000       angle: 170.27   speed: -42.86   113: 1115       8.85: 0.90
SystemCoreClock: 72000000       angle: 150.17   speed: 0.00     113: 301        8.85: 3.32
SystemCoreClock: 72000000       angle: 129.92   speed: -44.98   116: 1114       8.62: 0.90
SystemCoreClock: 72000000       angle: 109.75   speed: -40.80   125: 1122       8.00: 0.89
SystemCoreClock: 72000000       angle: 89.71    speed: -37.17   125: 308        8.00: 3.25
SystemCoreClock: 72000000       angle: 69.60    speed: -37.45   127: 312        7.87: 3.21
SystemCoreClock: 72000000       angle: 49.50    speed: -41.19   126: 313        7.94: 3.19
SystemCoreClock: 72000000       angle: 30.23    speed: -35.66   126: 311        7.94: 3.22
SystemCoreClock: 72000000       angle: 14.59    speed: -27.01   125: 316        8.00: 3.16
SystemCoreClock: 72000000       angle: 3.21     speed: -17.61   123: 308        8.13: 3.25
SystemCoreClock: 72000000       angle: -3.63    speed: -8.89    125: 313        8.00: 3.19
SystemCoreClock: 72000000       angle: -5.59    speed: -0.79    123: 310        8.13: 3.23
SystemCoreClock: 72000000       angle: -4.19    speed: 6.77     126: 1114       7.94: 0.90
SystemCoreClock: 72000000       angle: 1.75     speed: 16.40    117: 302        8.55: 3.31
SystemCoreClock: 72000000       angle: 12.36    speed: 23.44    116: 303        8.62: 3.30
SystemCoreClock: 72000000       angle: 27.09    speed: 33.13    114: 302        8.77: 3.31
SystemCoreClock: 72000000       angle: 45.52    speed: 37.23    113: 302        8.85: 3.31
SystemCoreClock: 72000000       angle: 65.35    speed: 40.35    115: 301        8.70: 3.32
SystemCoreClock: 72000000       angle: 85.24    speed: 41.09    112: 302        8.93: 3.31
SystemCoreClock: 72000000       angle: 105.07   speed: 36.76    113: 300        8.85: 3.33
SystemCoreClock: 72000000       angle: 124.97   speed: 39.38    115: 302        8.70: 3.31
SystemCoreClock: 72000000       angle: 144.65   speed: 39.49    114: 296        8.77: 3.38
SystemCoreClock: 72000000       angle: 164.41   speed: 36.42    113: 302        8.85: 3.31
SystemCoreClock: 72000000       angle: 184.17   speed: 38.72    112: 301        8.93: 3.32
SystemCoreClock: 72000000       angle: 203.99   speed: 41.02    115: 301        8.70: 3.32
SystemCoreClock: 72000000       angle: 223.82   speed: 40.83    114: 1113       8.77: 0.90
SystemCoreClock: 72000000       angle: 243.72   speed: 37.37    115: 304        8.70: 3.29
SystemCoreClock: 72000000       angle: 262.57   speed: 32.56    125: 312        8.00: 3.21
SystemCoreClock: 72000000       angle: 277.93   speed: 26.89    124: 310        8.06: 3.23
SystemCoreClock: 72000000       angle: 289.17   speed: 18.26    125: 311        8.00: 3.22
SystemCoreClock: 72000000       angle: 295.94   speed: 8.62     123: 308        8.13: 3.25
SystemCoreClock: 72000000       angle: 297.89   speed: 0.00     116: 313        8.62: 3.19

So 0.9 kHz some times is not acceptable and normal Arduino users will load the loop() with lots of i2c modules and even wlan or bluetooth anyway.

I think we should move on with low-sde current sensing because that will come with better timing than the hall sensors anyway ?
When porting that low-side current sensor to GD32 we might want to introduce a new timer interrrupt for adc sampling anyway.
Like letting it "called, when the ADC scan sequence is finished" = https://github.com/RoboDurden/Hoverboard-Firmware-Hack-Gen2.x/blob/main/HoverBoardGigaDevice/Src/it.c#L137
When we have such a 16kHz (or 32 kHz) interrupt we can overwrite the HallSensor class and call motor.loopFOC(); from there.
That might simplify the alignment and we better understand what the difference to the good old Gen2 code is.

from split_hoverboard_simplefoc.

Yes we can use the adc interrupt, but we don't need the dma.

Let's implement, we will see what needs to be optimized.

I think segger rtt shouldn't introduce any delay, it's just reading from memory.

from split_hoverboard_simplefoc.

Sounds like a good plan. Please assign to me any low level issue and I'll take care of it.

@RoboDurden thanks for verifying that Gen2 actually runs at 72MHz, which is a very high overclocking (50% above rated). While that might be ok for basic core math and some GPIO, more complex functions like PWM and especially ADC will be impacted. We should keep running at the rated 48MHz, even if that has a performance impact

@Candas1 RTT does have a small performance impact when sending data, but much less than any other channel (like UART), since it uses the existing SWD protocol. Having no debug is the best option for speed, but if any output is needed, RTT is by far the best option

from split_hoverboard_simplefoc.

According to the manual the GD32F13x is a 72 Mhz chip:

from split_hoverboard_simplefoc.

@RoboDurden not sure where you found that, but the datasheet has only 48MHz for the GD32F130xx https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20230314/GD32F130xxDatasheetRev3.7.pdf and in this one https://www.gigadevice.com.cn/Public/Uploads/uploadfile/files/20230209/GD32F1x0_User_Manual_EN_Rev3.6.pdf it says Note:(1) The maximum operating frequency of GD32F150xx is 72 MHz, and the maximum operating frequency of GD32F130xx is 48 MHz.

It looks like 72MHz was corrected in a revision 3.2 1. Modify 72MHz system frequency to 42MHz. Jul.25, 2019. The GD32F150 runs at 72MHz, so maybe that's where the confusion comes from. It's entirely possible that most of the times it will work at 72MHz, but given how critical the correct working of the firmware is, I would not like to take that risk

from split_hoverboard_simplefoc.

GD32F130K6U6_C81552.pdf
I found this datasheet after the others did not have the K6 package pinout..

from split_hoverboard_simplefoc.

Well, as you can see, that is an old revision from 2018. After 2019 all versions have the 48MHz clock

from split_hoverboard_simplefoc.

@Candas1 i will delete my original Split_Hoverboard_SimpleFOC repo so i can fork your repo, add the LowsideCurrentSense code and make a pull request. Then @robcazzaro if he wish can start with a SimpleFOC/src/current_sense/hardware_specific/gd32/gd32_mcu.cpp. If not, i would try to port the Gen2 analog read of

typedef struct
{
  uint16_t v_batt;  
  uint16_t current_dc;
} adc_buf_t;

by adding the two low-side currents like

typedef struct
{
  uint16_t v_batt;  
  uint16_t current_dc;
  uint16_t current_B;  
  uint16_t current_C;  
} adc_buf_t;

As the Gen2 code does read v_batt and current_dc at 16 kHz (or 32 kHz?), i think that should also be good for the LowsideCurrentSense class.

from split_hoverboard_simplefoc.

I think we need to do something different.
We would sample currents with inserted adc, and read anything else separately. We don't need battery voltage 16000 times a second, it will only delay the current sampling and foc calculation.

from split_hoverboard_simplefoc.

google gives me no hits for "inserted adc" or "inserted adc stm32" or "inserted adc gd32" :-/
That Gen2-FOC-port you host also adds the low-side currents to the one adc_buffer:

typedef struct
{
  uint16_t v_batt;  
  uint16_t current_dc;
  uint16_t phase_a;  
  uint16_t phase_b;
  uint16_t mcu_temp;
} adc_buf_t;

https://github.com/Candas1/Hoverboard-Firmware-Hack-Gen2/blob/master/HoverBoardGigaDevice/Inc/defines.h#L49C1-L57C1

Here the GD32 init code: https://github.com/Candas1/Hoverboard-Firmware-Hack-Gen2/blob/master/HoverBoardGigaDevice/Src/setup.c#L368

With simpleFOC i think, the current_sense is synced to the motor which is simply triggered in the loop() :-(
What might work is to not motor.linkCurrentSense(&current_sense); at all and instead do the motor.loopFOC(); from our LowsideCurrentSense implementation when the ADC scan sequence is finished and DMA_Channel0_IRQHandler(void) gets called :-)

That would be my approach without knowing what "inserted adc" is.

from split_hoverboard_simplefoc.

@RoboDurden Gigadevice calls it inserted ADC, STM calls it injected ADC. It's a way to have multiple channels start ADC when an event (e.g. a timer) triggers it, without software assistance. SImpleFOC uses it to ensure that the current sensing is always time-aligned with the PWM. Adding interrupt servicing to the code will make it non deterministic (compared to a purely HW-based solution like injected ADC).

Here's a relevant snippet from the SimpleFOC forum

So at the moment, to avoid potential problematic situations due to the ADC conversion lasting to long and entering the high-side activation of certain mosfets we suggest using the PWM frequencies that do not exceed 20kHz. This in most cases results in behavior.

I'll leave it to you two to decide the best way to structure the high level code, you both have a lot more experience with motor control. I'll be ready to help on anything once the main structure is in place.

from split_hoverboard_simplefoc.

Injected adc is also what the simpleFOC current sense driver is using.
I have experience with injected adc and know what to do, so please leave it to me, I will check when I am back.
I think there is a lot more in the to-do list.

And let's discuss adc in a new thread.

Are we done with this thread?
Now we are able to go as fast as gen2.X, but not at maximum target value?

from split_hoverboard_simplefoc.

max speed like Gen2 is reached but at the cost of 850-900 mA instead of the Gen2.x with less than 500 mA :-/
If the Gen2 code has a motor efficiency of 80%, then with simpleFOC we have 42% :-(
I wonder how max speed (with no load) can be reached with such a low motor efficiency.
But when moving from the NiklasFauth (that Gen2 is based on) to EFeruFOC it was like having new motors in my solar vehicle: less sound, more torque, less current (indeed i never tested for max speed).
So maybe Gen2 is below 80% efficieny.

So no, we are not really able to go as fast as gen2.

P.S. i deleted my original Split_Hoverboard_SimpleFOC, did fork your version here, cloned my fork to Github-Desktop, made some code improvements and added current_sensor code and now Github-Desktop hangs and i can not push my changes to my fork (in order to make a pull request).

I guess deleting my original repo to replace it with your fork of my original now causes an infinite loop :-(
Ideas welcome :-)

from split_hoverboard_simplefoc.

I am still betting on sensor alignment.
Current sensing/foc won't solve this issue.
Current sensing/foc won't be beneficial without the precise angle the next release will bring with sensor smoothing.

from split_hoverboard_simplefoc.

I wrongly thought that current sensing somehow replaces the hall sensor angle and gives more precise angle ?
But the lowside current sensing will be worth nothing without a precise angle derived from a hall sensor smoothing ?

With the current HallSensor and it's three channel callbacks, the hall position is immediately updated i guess - but the pwm calculating motor.loopFOC(); is not called peridically but from every 112 ms up to 1122 ms :-(
I fear that sensor alignment can not really work that way and we better sync Hall + Current + Pwm to one 16 kHz timer.

But you say that with hall sensor smoothing, the motor.loopFOC(); will get more precise angle and it only matters that the loopFOC is called often enough.

Then hall sensor alignment (to phase pwm) is not a problem because only one precise angle is important ?
Good to hear that the simpleFOC community is already working on such a hall sensor smoothing.

But current-sensor to phase pwm alignment will be very important, so we could continue with issue #6

from split_hoverboard_simplefoc.

Without smoothing, simplefoc only has one angle per hall position.
With smoothing, the angle will be extrapolated between 2 hall positions.
FOC needs that angle, and phase currents.

Smoothing wasn't available before because simplefoc was mainly used with encoders, they are much more precise than hall sensors already.
I think the hall sensor support in simplefoc is not very old, so there is for sure room for improvement and contributions.

Sensor alignment initialization doesn't seem very accurate so we need some manual finetuning. This is not happening in the loop, and just gives you a zero electrical angle offset.

from split_hoverboard_simplefoc.

I still do not know what you mean with "sensor alignment" :-/
You mean "hall sensor alignment" ?
But alignment to what ? As the motor.loopFOC() is not aligned to anything, we can not align the hall sensor changes to motor.loopFOC() -> setPhaseVoltage() -> driver->setPwm(Ua, Ub, Uc)
And the offset of the three pwm do only need to be aligned to each others, not to the hall sensor changes.
And the three phase pwm are outputs not sensors.

So what do you mean with "(hall) sensor alignment" ?

from split_hoverboard_simplefoc.

A motor is an electric magnet, using the 3 phases, you generate a 360 degrees magnetic angle. This angle doesn't match with the angle you get from hall sensors.

from split_hoverboard_simplefoc.

So you say that the angle doesn't match (you call it "not aligned") because the hall sensor is discrete and we need a smoothed hall sensor output. Then such a precise angle will really describe the current motor position and the motor.loopFOC will work better.
So you do not mean an alignment of digital rising/falling edges but simply a more precise motor position.
That has nothing to do with timers or interrupts :-)

But then still i wonder why Gen2.x is doing it so much better ???
Gen2 is not even updating the hall inputs with rising edge interrupts but simply samples them and does not smooth them either.

from split_hoverboard_simplefoc.

Your question was about the alignment, the precise angle is another topic.
Forget it, there is a lot of litterature about that, I can't summarize it all here.

The gen2.x firmware is only for hoverboards so it's already tuned.

from split_hoverboard_simplefoc.

The gen2.x firmware is only for hoverboards so it's already tuned.

Sorry Candas, i don't want to spoil your holidays but that sounds nonsense to me.
There is no tuning at all in the Gen2 firmware.

// Calculation-Routine for BLDC => calculates with 16kHz
void CalculateBLDC(void)
{
...
  // Read hall sensors  
  hall_a = gpio_input_bit_get(HALL_A_PORT, HALL_A_PIN);	
  hall_b = gpio_input_bit_get(HALL_B_PORT, HALL_B_PIN);
  hall_c = gpio_input_bit_get(HALL_C_PORT, HALL_C_PIN);

  // Determine current position based on hall sensors
  hall = hall_a * 1 + hall_b * 2 + hall_c * 4;
  pos = hall_to_pos[hall];
...
 // Update PWM channels based on position y(ellow), b(lue), g(reen)
  blockPWM(bldc_outputFilterPwm, pos, &y, &b, &g);

The only paramater (that could be fine tuned) i find is in config.h:
#define DEAD_TIME 60
and is used to setup TIMER_BLDC, just like you did with the same 60 in drivers/.../gd32_mcu.h

Maybe it would be nice to have a FOCModulationType::BlockCommutation in BLDCMotor::setPhaseVoltage(float Uq, float Ud, float angle_el) that is a stupid simple as the blockPWM(int pwm, int pwmPos, int *y, int *b, int *g) of Gen2
Because for that the inacurate motor angle from the 3 hall sensors would matter just as less as it does for Gen2

I guess your
motor.foc_modulation = FOCModulationType::SinePWM; // choose FOC modulation (optional) is very sensitive to the

float HallSensor::getMechanicalAngle() {
return ((float)((electric_rotations * 6 + electric_sector) % cpr) / (float)cpr) * _2PI ;
}

and we need some smoothing there before SinePWM makes any sense.
As i said a long time ago, i could quickly add a quadruatic interpolation one liner to that function.

from split_hoverboard_simplefoc.

btw, i introduced the BLDC_POLE_PAIRS 15 only after a short google search: "Standard 6.5 inch hoverboard hub motors have 30 permanent magnet poles, and thus 15 pole pairs.". Hope that is correct.

from split_hoverboard_simplefoc.

Okay i quickly added a linear interpolation which should also have an effect (on max speed) if sensor smooth would be the problem - yes i see a higher max speed

4° coarse angle: 459 Hz / 471 Hz
with linear interpolation 477 Hz / 486 Hz

That is a 3.5% increase in max speed. Current consumption is also about 50m less and quite like the Gen2.
But Gen2 reaches 547 Hz at the same current consumption.

199: 538        angle: -16.48   speed: 0.00     51325: -0.07
215: 501        angle: -15.50   speed: 5.36     13013: 0.07
200: 1215       angle: -10.40   speed: 0.00     4477: 0.07
216: 497        angle: -1.12    speed: 23.55    2965: 0.07
215: 1215       angle: 12.01    speed: 31.04    2249: 0.07
213: 543        angle: 28.00    speed: 30.01    2326: 0.07
227: 526        angle: 44.12    speed: 33.99    2054: 0.07
227: 547        angle: 60.18    speed: 31.40    2223: 0.07
228: 545        angle: 76.24    speed: 32.53    2146: 0.07
228: 1228       angle: 92.29    speed: 34.16    2044: 0.07
227: 549        angle: 108.49   speed: 35.21    1983: 0.07
229: 1226       angle: 124.41   speed: 30.82    2265: 0.07
228: 562        angle: 140.60   speed: 35.05    1992: 0.07
227: 544        angle: 156.66   speed: 32.44    2152: 0.07
228: 1228       angle: 172.86   speed: 31.25    2234: 0.07
226: 550        angle: 188.91   speed: 33.06    2112: 0.07
216: 540        angle: 204.90   speed: 29.80    2343: 0.07
215: 532        angle: 218.59   speed: 0.00     2732: 0.07
201: 1217       angle: 228.57   speed: 15.07    4634: 0.07
216: 532        angle: 234.36   speed: 7.86     8882: 0.07
201: 538        angle: 235.83   speed: 0.00     41090: 0.07
215: 486        angle: 234.92   speed: -6.10    11438: -0.07
217: 538        angle: 229.76   speed: -15.66   4459: -0.07
213: 1228       angle: 220.40   speed: -21.47   3252: -0.07
217: 1228       angle: 207.21   speed: -28.45   2454: -0.07

The first numbers of the last colum are the micro seconds between each change of the hall sensors. Even at max speed, there is a 2 ms gap that gets filled with my linear interpolation. And as the motor speed changes slowly, the linear inerpolation should already give a far more precise angle then the coarse 0.07 deg steps.

The 0.07 degree is 2 * pi / (4°/360°). and as our hoverboard motors generate 90 ticks per revolution, that is 4° per hallsensor callback :-)

Here my simple linear interpolation:

float HallSensor::getMechanicalAngle() 
{
  long iTimeSinceLastUpdate = _micros() - aiTimeLastUpdate[0];
  float fGradient1 = (float)(aiAngleLastUpdate[0]-aiAngleLastUpdate[1]) / (aiTimeLastUpdate[0]-aiTimeLastUpdate[1]);
  long fAngleSteps = aiAngleLastUpdate[0] + (long)(fGradient1 * iTimeSinceLastUpdate);
  return ((float)(fAngleSteps % cpr) / (float)cpr) * _2PI ;

  return ((float)((electric_rotations * 6 + electric_sector) % cpr) / (float)cpr) * _2PI ;
}

Maybe i could now "fine tune" by adding a 0.00x angle offset so the motor.loopFOC() -> setPhaseVoltage() -> driver->setPwm(Ua, Ub, Uc) sees a slightly advanced motor angle.. But i think their FOC algorithms should be exact and not need such a tweaking

I am not that eager to advance from my linear interpolation to a more general https://de.wikipedia.org/wiki/Spline-Interpolation

from split_hoverboard_simplefoc.

Ah, chatGpt should write a polynomial evaluation algorithm in ten seconds. Does anyone of you have experience with chatGpt and coding ?

from split_hoverboard_simplefoc.

Yes, asking Bing.chatGPT "Schreibe mir in der Programmiersprache C den vollständigen Code für eine Polynominterpolation nach dem Horner-Schema welches auch die zugehörigen Koeffizienten berechnet." gives a complete code example that might work:

// Dies ist ein Programm, das eine Polynominterpolation nach dem Horner-Schema durchführt und die zugehörigen Koeffizienten berechnet.
// Es verwendet die Funktion horner, die ein Polynom vom Grad n, einen Vektor von n+1 Koeffizienten und einen Wert x annimmt und den Wert des Polynoms an der Stelle x zurückgibt.
// Es verwendet auch die Funktion coeff, die eine Matrix von n+1 Punkten (x,y) annimmt und einen Vektor von n+1 Koeffizienten zurückgibt, die das interpolierende Polynom bestimmen.

#include <stdio.h>
#include <stdlib.h>

// Die Funktion horner berechnet den Wert eines Polynoms an einer Stelle x nach dem Horner-Schema
double horner(int n, double *a, double x) {
  double p = a[n]; // Initialisiere p mit dem höchsten Koeffizienten
  for (int i = n-1; i >= 0; i--) { // Iteriere von n-1 bis 0
    p = p * x + a[i]; // Multipliziere p mit x und addiere den nächsten Koeffizienten
  }
  return p; // Gib den Wert von p zurück
}

// Die Funktion coeff berechnet die Koeffizienten eines interpolierenden Polynoms für eine gegebene Matrix von Punkten
double *coeff(int n, double **points) {
  double *a = malloc((n+1) * sizeof(double)); // Alloziere Speicher für den Vektor a
  for (int i = 0; i <= n; i++) { // Iteriere von 0 bis n
    a[i] = points[i][1]; // Setze a[i] gleich dem y-Wert des i-ten Punktes
    for (int j = i-1; j >= 0; j--) { // Iteriere von i-1 bis 0
      a[j] = (a[j+1] - a[j]) / (points[i][0] - points[j][0]); // Berechne den Dividierten Differenzenquotienten für a[j]
    }
  }
  return a; // Gib den Vektor a zurück
}

// Die Hauptfunktion liest die Anzahl der Punkte, die Punkte selbst und den Wert x ein und gibt den Wert des interpolierenden Polynoms an der Stelle x aus
int main() {
  int n; // Die Anzahl der Punkte
  double **points; // Die Matrix der Punkte
  double x; // Der Wert x
  double y; // Der Wert y

  printf("Geben Sie die Anzahl der Punkte ein: ");
  scanf("%d", &n); // Lese n ein

  points = malloc((n+1) * sizeof(double *)); // Alloziere Speicher für die Matrix points
  for (int i = 0; i <= n; i++) {
    points[i] = malloc(2 * sizeof(double)); // Alloziere Speicher für jede Zeile von points
    printf("Geben Sie den %d. Punkt ein (x y): ", i+1);
    scanf("%lf %lf", &points[i][0], &points[i][1]); // Lese die x- und y-Werte des i-ten Punktes ein
  }

  printf("Geben Sie den Wert von x ein: ");
  scanf("%lf", &x); // Lese x ein

  double *a = coeff(n, points); // Berechne die Koeffizienten des interpolierenden Polynoms

  y = horner(n, a, x); // Berechne den Wert des interpolierenden Polynoms an der Stelle x

  printf("Der Wert des interpolierenden Polynoms an der Stelle %lf ist %lf\n", x, y); // Gib das Ergebnis aus

  free(a); // Gebe den Speicher für a frei
  for (int i = 0; i <= n; i++) {
    free(points[i]); // Gebe den Speicher für jede Zeile von points frei
  }
  free(points); // Gebe den Speicher für points frei

  return 0;
}

Here an english prompt that also seems to do the job: "Write complete code for a polynomial evaluation according to the Horner's method in the C programming language, which also calculates the associated coefficients based on an array of x,y pairs."

#include <stdio.h>
#include <stdlib.h>

// A function to evaluate a polynomial using Horner's method
// Input: an array of coefficients, the degree of the polynomial, and the value of x
// Output: the value of the polynomial at x
double horner(double *coeff, int degree, double x) {
  // Initialize the result as the highest degree coefficient
  double result = coeff[0];
  // Loop from the second highest degree coefficient to the constant term
  for (int i = 1; i <= degree; i++) {
    // Multiply the result by x and add the next coefficient
    result = result * x + coeff[i];
  }
  // Return the final result
  return result;
}

// A function to calculate the coefficients of a polynomial that passes through a given set of points
// Input: an array of x values, an array of y values, and the number of points
// Output: an array of coefficients, or NULL if there is no unique polynomial
double *coefficients(double *x, double *y, int n) {
  // Allocate memory for the coefficient array
  double *coeff = (double *)malloc(n * sizeof(double));
  if (coeff == NULL) {
    // Memory allocation failed
    return NULL;
  }
  // Copy the y values to the coefficient array
  for (int i = 0; i < n; i++) {
    coeff[i] = y[i];
  }
  // Loop from the first point to the last point
  for (int i = 0; i < n; i++) {
    // Loop from the last point to the current point
    for (int j = n - 1; j > i; j--) {
      // Apply the divided difference formula to update the coefficients
      coeff[j] = (coeff[j] - coeff[j - 1]) / (x[j] - x[j - i - 1]);
    }
  }
  // Return the coefficient array
  return coeff;
}

// A function to print a polynomial in a readable format
// Input: an array of coefficients and the degree of the polynomial
// Output: none
void print_poly(double *coeff, int degree) {
  // Print the highest degree term
  printf("%.2lf x^%d", coeff[0], degree);
  // Loop from the second highest degree term to the constant term
  for (int i = 1; i <= degree; i++) {
    // Print a plus or minus sign depending on the sign of the coefficient
    if (coeff[i] >= 0) {
      printf(" + ");
    } else {
      printf(" - ");
    }
    // Print the absolute value of the coefficient and the power of x
    printf("%.2lf x^%d", fabs(coeff[i]), degree - i);
  }
  // Print a newline character
  printf("\n");
}

// A main function to test the above functions
int main() {
  // Define an array of x values and an array of y values
  double x[] = {1, 2, 3, 4};
  double y[] = {3, -2, -15, -24};
  
  // Define the number of points and the degree of the polynomial
  int n = sizeof(x) / sizeof(x[0]);
  int degree = n - 1;
  
  // Calculate and print the coefficients of the polynomial
  double *coeff = coefficients(x, y, n);
  
   if (coeff == NULL) {
     // Coefficient calculation failed
     printf("Error: could not allocate memory for coefficients.\n");
     return -1;
   }
   
   printf("The coefficients of the polynomial are:\n");
   for (int i = 0; i < n; i++) {
     printf("%.2lf ", coeff[i]);
   }
   printf("\n");
   
   // Print the polynomial in a readable format
   printf("The polynomial is:\n");
   print_poly(coeff, degree);
   
   // Evaluate and print the value of the polynomial at some x value
   double x_value = -2;
   double y_value = horner(coeff, degree, x_value);
   printf("The value of the polynomial at x = %.2lf is %.2lf\n", x_value, y_value);
   
   // Free the memory allocated for the coefficient array
   free(coeff);
   
   return 0;
}

from split_hoverboard_simplefoc.

@RoboDurden please also keep in mind that SimpleFOC has already implemented a smoothed hall sensor class, discussion here https://community.simplefoc.com/t/smoothingsensor-experimental-sensor-angle-extrapoltion/3105/4 (I think @Candas1 also mentioned it before)

The code is in their tree, in the dev branch, this is the relevant check-in simplefoc/Arduino-FOC@510527a. It's not been released yet, but we could start using it and give feedback

from split_hoverboard_simplefoc.

!! Eureka !! - i have found it - after replacing the integer mod % with fmod, my simple linear interpolation works - exceptionaly good:

old HallSensor.cpp		460 Hz / 454 Hz at 650 mA
with 30% linear interplation:  	525 Hz / 529 Hz at only 380 mA
with 50% linear interplation:  	565 Hz / 561 Hz at only 400 mA :-)
with 60% linear interplation:  	579 Hz / 491 Hz at 480 mA :-(
Gen2				543 Hz / 544 Hz at 460 mA

Yes, the motor sometimes got stuck when changing rotation direction and makes an aweful sound :-(
But at low speed it is okay to simply disable the linear interpolation, and then that bad behavior disappeared :-)

I fear that the simpleFOC community only went for smoothing with a low pass filter. That is no prediction ..
My linear prediction might be to bold and only adding 0.5 of the linear gradient seems to be best.
Applying it at 100% will not make the motor spin correctly :-/

I still get some "ticks" at full speed that also happen on rotation changes. I guess when my prediction was to advanced and the next hall sensor event corrects this.

So a quadratic interpolation might be even better. Or indeed adding some simple 0.6 * fOld + 0.4 * fNew low pass..

The chatGPT code seems to get stuck in an infinite loop.. will still be fun to analyze that.

float HallSensor::getMechanicalAngle() 
{
...
  int iAngleChange = aiAngleLastUpdate[0]-aiAngleLastUpdate[1];   // is either +1 or -1 (hall step)
  if ( iAngleChange * (aiAngleLastUpdate[1]-aiAngleLastUpdate[2]) == 1) // no direction change
  {
    iTimeSinceLastUpdate = _micros() - aiTimeLastUpdate[0];
    fGradient1 = (float)iAngleChange / (float)(aiTimeLastUpdate[0]-aiTimeLastUpdate[1]);
    float fAngleSteps = aiAngleLastUpdate[0] + (fGradient1 * iTimeSinceLastUpdate * 0.5);
    fAngleLin = (fmod(fAngleSteps,cpr) / (float)cpr) * _2PI ;
    return fAngleLin;
  }
  fAngleOrg = ((float)((electric_rotations * 6 + electric_sector) % cpr) / (float)cpr) * _2PI ;
  return fAngleOrg;
}

It really looks as good interpolation was the problem,
and we now have a better motor then with Gen2, Alleluja :-)

from split_hoverboard_simplefoc.

Feel free to contribute to simplefoc if you think your interpolation is better. That still doesn't clarify why gen2.x was more efficient without interpolation.

from split_hoverboard_simplefoc.

Well this FOC code is still a black box to me:

void BLDCMotor::setPhaseVoltage(float Uq, float Ud, float angle_el) 
{
...
    case FOCModulationType::SinePWM :
      // Sinusoidal PWM modulation
      // Inverse Park + Clarke transformation

      // angle normalization in between 0 and 2pi
      // only necessary if using _sin and _cos - approximation functions
      angle_el = _normalizeAngle(angle_el);
      _ca = _cos(angle_el);
      _sa = _sin(angle_el);
      // Inverse park transform
      Ualpha =  _ca * Ud - _sa * Uq;  // -sin(angle) * Uq;
      Ubeta =  _sa * Ud + _ca * Uq;    //  cos(angle) * Uq;

      // center = modulation_centered ? (driver->voltage_limit)/2 : Uq;
      center = driver->voltage_limit/2;
      // Clarke transform
      Ua = Ualpha + center;
      Ub = -0.5f * Ualpha  + _SQRT3_2 * Ubeta + center;
      Uc = -0.5f * Ualpha - _SQRT3_2 * Ubeta + center;

      if (!modulation_centered) {
        float Umin = min(Ua, min(Ub, Uc));
        Ua -= Umin;
        Ub -= Umin;
        Uc -= Umin;
      }
      break;
...
  // set the voltages in driver
  driver->setPwm(Ua, Ub, Uc);
}

But i guess it is very sensitive to the motor angle, whereas Gen2 directly and non-tunable "block commutates" the three phases according to the hall sensors - not much to be done wrong.

I still have not undestood why setting driver.voltage_power_supply lower as the true battery voltage makes the motor even spin faster. And now with true voltage already exceeding Gen2, setting

driver.voltage_power_supply = 2.6 * BAT_CELLS; // power supply voltage [V]
will boost the max speed from 42.49 to 55.28 and the current still is only 550 mA.
That is a 30% speed boost !!!
The Audacity fft frequency analisys no longer works because the sound spectrum has changed.
But as i store the angle/time tuples for my linear interpolation, i also smoothed the

float HallSensor::getVelocity()
{
  long last_pulse_diff = pulse_diff;
  if (last_pulse_diff == 0 || ((long)(_micros() - pulse_timestamp) > 2*last_pulse_diff) ) // last velocity isn't accurate if too old
    return 0;

  float vel = direction * (_2PI / (float)cpr) / (last_pulse_diff / 1000000.0f);

  bNoUpdate = true;   // thread safety
  float fPulseDiff = last_pulse_diff;
  int iSum = 1;
  for(int i=1; i<PolynomialInterpolationCount-1; i++)
  {
    int iDiff = aiTimeLastUpdate[i] - aiTimeLastUpdate[i+1];
    if (  (fPulseDiff + iDiff) > 50000) // do not average over more than 50 ms
      break;
    fPulseDiff += iDiff; 
    iSum++;
  }
  if (bNoUpdate)
  {
    fPulseDiff /= iSum;
    vel = direction * (_2PI / (float)cpr) / (last_pulse_diff / 1000000.0f);
  }
    
  // quick fix https://github.com/simplefoc/Arduino-FOC/issues/192
  if(vel < -velocity_max || vel > velocity_max)  //if velocity is out of range then make it zero
    return 0;
  return vel;
}

I think that lowering the driver.voltage_power_supply will still allow that FOC black box to generate max sine curves.
Which afterwards get clamped to square waves in

void BLDCDriver6PWM::setPwm(float Ua, float Ub, float Uc) {
  // limit the voltage in driver
  Ua = _constrain(Ua, 0, voltage_limit);
  Ub = _constrain(Ub, 0, voltage_limit);
  Uc = _constrain(Uc, 0, voltage_limit);
  // calculate duty cycle
  // limited in [0,1]
  dc_a = _constrain(Ua / voltage_power_supply, 0.0f , 1.0f );
  dc_b = _constrain(Ub / voltage_power_supply, 0.0f , 1.0f );
  dc_c = _constrain(Uc / voltage_power_supply, 0.0f , 1.0f );
  // hardware specific writing
  // hardware specific function - depending on driver and mcu
  _writeDutyCycle6PWM(dc_a, dc_b, dc_c, phase_state, params);
}

But that is just my guess.
That max speed now totally outperforms the Gen2 code.

from split_hoverboard_simplefoc.

The chatGPT code was a misfire. Did only produce overflow floats.
I found a nice Lagrange Interpolation the old google way.

  long iNow = _micros();
  float fAngleNow = 0;
  for(int i=0; i<PolynomialInterpolationCount; i++)
  {
    float fCoeff = 1;
    for(int j=0; j<PolynomialInterpolationCount; j++)
      if( i!=j )
        fCoeff *=  (float)(iNow - aiTimeLastUpdate[j]) / (float)(aiTimeLastUpdate[i] - aiTimeLastUpdate[j]);
    fAngleNow += fCoeff * aiAngleLastUpdate[i];
  }
  fAngleNow = 0.1 * fAngleNow + 0.9 * (float)(electric_rotations * 6 + electric_sector);    // only take 10% of the predictioin
  fAngleLagrange = (fmod(fAngleNow,cpr) / (float)cpr) * _2PI ;
  if (bNoUpdate)  
    return fAngleLagrange;

https://www.codesansar.com/numerical-methods/lagrange-interpolation-method-using-c-programming.htm

But adding mor then 10% of that 4th polynomial interpolation did block the motor :-(
(i logged the fAngleLagrange and fAngleOrg and could verify that the predicted fAngleLagrange was reasonable)

I also noticed that the execution time of that code affected the motor behavior (additional 30 mA) even without using fAngleLagrange at all. So the getMechanicalAngle() call from BLDCMotor::loopFOC() is very time critical.
And my simple linear interpolation might already be the optimum :-)

from split_hoverboard_simplefoc.

I still have not undestood why setting driver.voltage_power_supply lower as the true battery voltage makes the motor even spin faster. And now with true voltage already exceeding Gen2, setting

The way I understand it, SimpleFOC needs to know the power supply voltage value when calculating currents (you can set the motor impedance) and to optimize voltage and current in each phase.

Then you use motor.voltage_limit and driver.voltage_limit to protect the motor especially when starting to protect the motor and board.

Let's say that you have a 10V power supply and set driver.voltage_power_supply to 10 and driver.voltage_limit to 5V. The PWM will never produce more than 50% voltage when the algorithm would output 100%. If you set driver.voltage_limit to 10, now at max phase voltage you will get 10V

It looks as if, by setting the power supply value lower than actual, you are driving the PWM more fully. Do you have motor.voltage_limit and driver.voltage_limit set, by chance? Try printing those values and see if they are the same or lower than the power supply value

Keep in mind that speed is only one aspect. For my uses, for example, I will need the motor to move very slowly (<10 RPM) with constant torque and be able to hold position with the same torque. The value of using SimpleFOC, for me, would be that once a board and motor parameters are optimized, it can be used in many different ways equally easy, without having to change the core code, just change settings in the setup()

from split_hoverboard_simplefoc.

I would check the 3 voltages with this, maybe we see what happens

from split_hoverboard_simplefoc.

I am wondering if at high duty cycle the values are clamped, so the sinusoidal is flat.

from split_hoverboard_simplefoc.

Thanks @robcazzaro , having two voltage_limit at the same time in different classes looks like very bad programming behavior to me.
FOCMotor::voltage_limit is never used in that base class FOCMotor class anyway and the dereived BLDCMotor can not work without a driver and also makes multiple uses of driver->voltage_limit.
So i guess it is a bug to use FOCMotor::voltage_limit in some other places of the same code file :-(
If indeed some other derived FOCMotor class would need its own voltage_limit without having a driver, then it should be defined in that other class and not in the base class.

OUT2T( motor.voltage_limit, driver.voltage_limit)
-> 12.00: 25.20

The 25.2 Volt is my 7s 3.6 * BAT_CELLS, the 12.0 is still the DEF_POWER_SUPPLY

Indeed, in BLDCMotor::move(float new_target), the motor::voltage_limit is used for clamping:

  switch (controller) {
    case MotionControlType::torque:
      if(torque_controller == TorqueControlType::voltage){ // if voltage torque control
        if(!_isset(phase_resistance))  voltage.q = target;
        else  voltage.q =  target*phase_resistance + voltage_bemf;
        voltage.q = _constrain(voltage.q, -voltage_limit, voltage_limit);

But BLDCMotor::setPhaseVoltage concludes with driver->setPwm(Ua, Ub, Uc); and there the
Ua = _constrain(Ua, 0, voltage_limit);
has no effect because driver::voltage_limit is way higher than the still default 12.0 used for clamping in BLDCMotor::move().
And the final clamp to [0.0..1.0] i guess will only allow the max of 1.0 if i also reduce the driver::voltage_power_supply to 12.0 V
dc_a = _constrain(Ua / voltage_power_supply, 0.0f , 1.0f );

I think there should not be a FOCMotor::voltage_limit at all :-(
It is never used in that base class FOCMotor, and in the derrived BLDCMotor class driver->setPwm(Ua, Ub, Uc); is hard coded in BLDCMotor::setPhaseVoltage(...). So it would be no problem at all to not use FOCMotor::voltage_limit in BLDCMotor::move() (and other places) but
voltage.q = _constrain(voltage.q, -driver->voltage_limit, driver->voltage_limit);
instead of what is now implemented:
voltage.q = _constrain(voltage.q, -voltage_limit, voltage_limit);

I also do not (want) to undestand why using voltages when in the end we factor and clamp it down to [0..1] anyway.
The voltage_power_supply is only used to scale the duty cacle down to 0..1. There is no analog read of the battery voltage to compare it against voltage_power_supply. in neither the base class BLDCDriver nor any of the derived BLDCDriver_x_PWM classes.
The [0.0..100.0] duty cycle is more intuitive.

But i think it is too late to change that now.
At least the FOCMotor:.voltage_limit should be removed i guess.

Do not really have the happiness to start arguing with the simpleFOC community..
@Candas1 , why don't you accept my pull request: #7 ?
Then @robcazzaro could already begin with adc low level stuff.
I do not really have a use scenario that needs currents sensing. I feel current sensing is NOT needed for FOC but only for torque control..

from split_hoverboard_simplefoc.

Because I don't aim to maintain my own branch of simplefoc except the GD32 drivers.
Anything else will also be beneficial to the simpleFOC community.
You are working on topics the simpleFOC team is already about to release, without even trying it.
This will even make it harder to merge anything new they are bringing.

from split_hoverboard_simplefoc.

I don't pose a problem if I can't offer any solutions

• i am totally undecided whether FOCMotor::voltage_limit or BLDCDriver_x_PWM::voltage_limit should be removed.
• I don't know if removing that unneccesary voltage stuff could be removed anyway
• I only have a stupid linear interpolation that boosts max speed by 33% but performs poorly at low speeds.

So no solutions to offer and therefore no happiness to pose questions to other people.

from split_hoverboard_simplefoc.

@robcazzaro i still do not really understand why you don't buy some used hoverboards locally. I do not know all the US websites to buy used items but already facebooks lists multiple items: https://www.facebook.com/marketplace/seattle/hoverboards?maxPrice=20&exact=false
And me (and i guess Candas too) would be happy to each $20 donate to you for getting some boards.
If your really plan to do multiple projects with hoverbaords you will need your own stock of used hoverboards anyway.

from split_hoverboard_simplefoc.

i am not really making progress with my linear interpolation. Has taken all day to verify that my angle prediction works quite good, but the motor does not like the "better" values.
I also notice that the motor is spinning more poorly left then right.
Sometimes it even gets "out of phase" and is rotating with a bad stutter. Then after a few seconds it kicks back "into the right phase" and rotates "nicely" again.
So the original HallSensor is also not perfect.

With Gen2 however, the phase pwm are simply directly calculated from the 6 (8?) possible hall combination.

  // Determine current position based on hall sensors
  hall = hall_a * 1 + hall_b * 2 + hall_c * 4;
  pos = hall_to_pos[hall];

So nothing can get "out of phase" over time.

With simpleFOC however, the angle increments with every hall step, is then mapped to 360° = [0.0 .. 2pi], some offset is added
sensor->getMechanicalAngle() - zero_electric_angle
but once that angle "gets out of phase", the three pwm phase voltages
get applied wrong "forever".

I think there should be an ongoing closed loop that corrects the zero_electric_angle.
to match the coarse hall_to_pos[hall];
And i guess there should be a zero_electric_angle_left and zero_electric_angle_right

@Candas1 , how did you obtain motor.initFOC(2.09,Direction::CCW); // Start FOC without alignment which skips the BLDCMotor::alignSensor()- which does not work at all for me. Only your 2.09 work
Was that simply try and error ? Then maybe with my "better" linear interpolation, i must find a new value.

from split_hoverboard_simplefoc.

Please check those comments:
#1 (comment)
#5 (comment)
#5 (comment)

from split_hoverboard_simplefoc.

@RoboDurden SimpleFOC is a bit hard to understand and has quite a few quirks. On the other hand, it's solid code that works for a variety of projects and hardware. Trying to hack around its inner workings without understanding why certain things were done a certain way it's a recipe for frustration. Many of the issues we are facing are known by the SimpleFOC team and work is happening to address them.

If we think something could be done better, the right approach is to engage with them and suggest changes. Most of the times, their answer will explain why their approach is better and the side effects of doing things differently. Every time I suggested changes, they were incredibly open and responsive.

You say I do not really have a use scenario that needs currents sensing. I feel current sensing is NOT needed for FOC but only for torque control.. Well, torque control at very low speeds is the only scenario that matters to me 😁, and the reason why we even started having these conversations. I'd like to have a solution for torque control using the hoverboard split boards. I already have other boards (like DRV8302 that works perfectly well with SimpleFOC, just wanted to see if it's possible to use a split hoverboard board

So, while I appreciate your desire to quickly get the code to a working state for higher speeds, that is not an approach I think will work long term. As I mentioned before, there is already a solution for a smoothed hall sensor that works at any speed. It might be suboptimal in certain cases compared to your approach, but works in general. IF you think your approach is better, I'm sure that the SimpleFOC people will be interested in hearing about it and discuss it with you.

from split_hoverboard_simplefoc.

Thanks @Candas1 for the links, i had searched for them but did not find them in our too long issues.
Tomorrow i will try adding the yet missing parameters to
BLDCMotor(int pp, float R = NOT_SET, float KV = NOT_SET, float L = NOT_SET);

That would give a "better" result in BLDCMotor:move()

        if(!_isset(phase_resistance))  voltage.q = target;
        else  voltage.q =  target*phase_resistance + voltage_bemf;

Then maybe the BLDCMotor::alignSensor() will result in a zero_electric_angle that at least will also work like your 2.09
I guess i can measure R with my multimeter, simple the resistance from blue phase to yellow.
KV should be 14, according to one of my first youtube videos: https://youtu.be/pbip8CVaAbc
How can i obtain L ? My cheap multimeters do not seem to measure inductivity.

according to https://forum.esk8.news/t/hoverboard-foc-motor-settings-vesc/25343/4 :
R = 0.1664 Ohm
L = 0.00036858 H
KV = 16

update2:
no, BLDCMotor motor = BLDCMotor(BLDC_POLE_PAIRS, 0.1664, 16.0, 0.00036858); did not help to produce BLDCMotor::alignCurrentSense() some usable value zero_electric_angle.
And motor behavor is badly. Motor quickly jumps to a high speed :-(

If these additional 4 parameters are the problem then i guess i will have to code my own optimizer :-/

from split_hoverboard_simplefoc.

"If the top speed is higher in one direction than the other, use sine modulation and adjust motor.zero_electric_angle until both directions are equal (it’s set automatically by calibration, but sometimes needs manual adjustment to correct for imperfect sensor placement)"

from split_hoverboard_simplefoc.

Spent nearly most of Sunday to find better motor settings but haven't found anything better then the 2.09 that Candas chose.
My linear predictions still gives a 30% speed boost but the motor gets very noisy. Do not understand this.

Speed_left/right  Average_r/l  AverageDelta_l/r   linerar [%]   loopFOC[ns]_loop[ms]   samples_LowPass
-14.51: 14.31   13.17: -13.13   0.19: 0.04      fLinAdd: 2.50   221: 1254       21605
-14.62: 14.48   13.18: -13.40   0.15: 0.23      fLinAdd: 7.50   237: 1224       21645
-14.72: 14.52   13.13: -13.34   0.20: 0.20      fLinAdd: 12.50  223: 1233       21057
-14.89: 14.61   13.21: -13.28   0.29: 0.07      fLinAdd: 17.50  223: 843        21871
-14.92: 14.70   13.36: -13.35   0.21: 0.01      fLinAdd: 22.50  236: 1240       20907
-15.08: 14.85   13.43: -13.43   0.23: 0.00      fLinAdd: 27.50  224: 1228       21659
-15.44: 15.09   13.40: -13.15   0.35: 0.26      fLinAdd: 32.50  239: 1226       21250
-15.79: 15.19   13.27: -12.94   0.60: 0.33      fLinAdd: 37.50  221: 1237       21107
-16.77: 15.87   13.59: -13.02   0.90: 0.57      fLinAdd: 42.50  234: 1266       21160
-17.23: 16.36   13.84: -13.17   0.87: 0.67      fLinAdd: 47.50  223: 1280       20119
-17.83: 17.13   15.12: -15.17   0.70: 0.05      fLinAdd: 52.50  224: 847        20163
-18.21: 17.65   15.86: -15.66   0.57: 0.20      fLinAdd: 57.50  238: 1276       19270
-18.48: 17.94   16.23: -16.22   0.54: 0.01      fLinAdd: 62.50  221: 1277       19498
-18.65: 18.37   16.48: -16.55   0.27: 0.06      fLinAdd: 67.50  237: 1267       19470
-19.06: 18.71   16.63: -16.86   0.35: 0.23      fLinAdd: 72.50  221: 1277       19011
-19.28: 19.02   16.85: -17.16   0.26: 0.32      fLinAdd: 77.50  223: 1263       19703
-19.65: 19.04   16.86: -17.19   0.61: 0.33      fLinAdd: 82.50  237: 1235       18921
-19.92: 19.38   16.92: -17.09   0.55: 0.17      fLinAdd: 87.50  214: 1268       19490
-19.98: 19.85   17.22: -17.11   0.12: 0.11      fLinAdd: 92.50  238: 1265       19200
-20.27: 20.19   17.07: -17.16   0.07: 0.08      fLinAdd: 97.50  222: 1279       19087
-20.23: 20.10   17.28: -17.12   0.13: 0.16      fLinAdd: 97.50  237: 1266       19515

The 20.10/14.31 for max_speed_r is a 40% boost, the 17.28/13.17 for average_speed_r is a 31% boost.
But even so the prediction should be accurate, the motor gets very noisy.
In these tests, i let the motor spin left for about 2 seconds, then right for another 2 seconds. Total time 5 seconds and samples_LowPass times LoopFOC was called.

  if (-fSpeed > driver.voltage_limit)  // will be clamped and therefore be constant
    fSpeedAvgMax = 0.99 * fSpeedAvgMax + 0.01 * fVelocity;

Today i have built myself a Gen1 test setup. Will try to flash our simpleFOC software to it. Then i can compare with the noise and max speed of the EFeru FOC.

Would be nice to have at least overall current adc. Then i could compare the power with speed to judge the efficiency of the different firmwares. If i remember correctly, the EFeru firmware outputs speed in rpm. SimpleFOC velocity seems to be angulare frequency ( 2 pu / f ).
First test run with EFeru FOC was so silent that my Audacity frequency analysis would give no results.

As Candas will not accept my pull request, @robcazzaro if you want to and know how to start a SimpleFOC/src/current_sense/hardware_specific/gd32/gd32_mcu.cpp , you could download my preperation from my fork: https://github.com/RoboDurden/Split_Hoverboard_SimpleFOC

But i guess, Candas will be back from holidays in about a week and if he wants to do it, we can happily wait :-)

from split_hoverboard_simplefoc.

had really bad sleep last night and am very tired today.
Have problems to match the EFeru rpm = rtY_Right.n_mot

rpm_l:-368 rpm_r:0 cmdL:1000 cmdR:1000 BatADC:1016 BatV:2695 TempADC:1722 Temp:227   
rpm_l:-368 rpm_r:0 cmdL:1000 cmdR:1000 BatADC:1006 BatV:2695 TempADC:1722 Temp:227   
rpm_l:-347 rpm_r:0 cmdL:1000 cmdR:1000 BatADC:1004 BatV:2695 TempADC:1722 Temp:227   
rpm_l:-353 rpm_r:0 cmdL:1000 cmdR:1000 BatADC:1030 BatV:2695 TempADC:1722 Temp:227   
rpm_l:-359 rpm_r:0 cmdL:1000 cmdR:1000 BatADC:1016 BatV:2695 TempADC:1722 Temp:227   
rpm_l:-365 rpm_r:0 cmdL:1000 cmdR:1000 BatADC:1008 BatV:2695 TempADC:1722 Temp:227   
rpm_l:-359 rpm_r:0 cmdL:978 cmdR:978 BatADC:1026 BatV:2695 TempADC:1722 Temp:227   
rpm_l:-326 rpm_r:0 cmdL:900 cmdR:900 BatADC:1006 BatV:2695 TempADC:1722 Temp:227   
rpm_l:-305 rpm_r:0 cmdL:828 cmdR:828 BatADC:1004 BatV:2695 TempADC:1722 Temp:227

with the simpleFOC angular speed.

float vel = direction * (_2PI / (float)cpr) / (last_pulse_diff / 1000000.0f); // cpr = 90 (hall ticks per revolution)

Speed_left/right  Average_r/l  AverageDelta_l/r   linerar [%]   loopFOC[ns]_loop[ms]   samples_LowPass
-20.40: 19.83   17.20: -17.13   0.57: 0.06      fLinAdd: 92.50  213: 846        18866

The EFeru max rpm was 368. Divided by my 26 Volt confirms the 14.15 KV of my old youtube video.
So 368 / 60 = 6.13 is the frequency f (revs). And therefore, the angular velocity w = 2 pi / T = 2 pi f should be 2 pi 6.13 = 38.5 which clearly is not close to 20.4 max_simpleFOC or 17.2 average_simpleFOC.

But maybe a factor 2 ?

But i do not find that in the simpleFOC code, unless we should use pole_pairs = 30 instead of 15:

//   - pp           - pole pairs
HallSensor::HallSensor(int _hallA, int _hallB, int _hallC, int _pp)
{
...
  // hall has 6 segments per electrical revolution
  cpr = _pp * 6;

But that should have the oppsite effect and half the 20.40 to 10.20 for the simpleFOC velocity :-/

from split_hoverboard_simplefoc.

Maybe there is an issue with time measurement.
I can measure the speed with a tachometer when I am back.

from split_hoverboard_simplefoc.

ah my fault. Now at the end of this day my mind gets a bit clearer.
I simply made the latest simpleFOC test with

driver.voltage_limit = 0.3 * driver.voltage_power_supply

Now with 1.0 i get a max speed of 44 and an average max speed of 38.0 at 1250mA/1200mA:

-44.27: 41.88   -36.69: 37.15   2.39: 0.46      0.00: 2090.00   205: 1279       38587
-43.72: 41.46   -38.66: 37.29   2.26: 1.37      0.00: 2090.00   223: 1279       38634
-44.05: 41.56   -36.61: 36.12   2.49: 0.48      0.00: 2090.00   218: 1277       38602

The EFeru_FOC gave an angular velocity of 38.5.

With 90% of my linear interpolation (prediction) i get a max average of 65 at 1000mA/1100 mA:

-74.91: 73.10   -65.86: 63.48   1.80: 2.38      0.00: 2090.00   193: 1277       38013
-73.49: 73.33   -65.36: 64.07   0.15: 1.29      0.00: 2090.00   222: 1271       38022
-74.11: 72.95   -63.44: 64.85   1.16: 1.41      0.00: 2090.00   237: 1280       38372

Now that is a 65/38 = 71 % speed boost with less current. Maybe my current limit was too low at the last tests.
Will have to make a youtube video so you can believe me.

P.s. i tried to white list my Arduino_FOC lib source and push it to my fork, so i can link to my code changes.
But this .gitignore does not work

.pio
.vscode/.browse.c_cpp.db*
.vscode/c_cpp_properties.json
.vscode/launch.json
.vscode/ipch
# Ignore everything
*
# But descend into directories
!*/
# Recursively allow files under subtree
!.pio/libdeps/GD32F130C8/Simple FOC/src/**

Github Desktop then already lists the folder as having changed, but they do not get pushed to github and no files are listed/found as having changed.
ideas welcome

from split_hoverboard_simplefoc.

If it's higher than rated KV you're probably doing field weakening.

from split_hoverboard_simplefoc.

This probably explains why the motor would slow down at higher target values.

from split_hoverboard_simplefoc.

Well this does not explain why my simple linear prediction makes a 37% speed boost. Here with only

    fSpeed = (0.5*driver.voltage_power_supply)  * (ABS(	(float)(((millis()-iLoopStart)/10 + 250) % 1000) - 500) - 250)/250;
    float fLinAdd = 0.9;

rpm/V loopFOC[ms]:HallStep[ms]  fAngle0:fAngle    predict[ms]:fAngleLin ...
KV: 17.29       273: 1460       3.28: 3.35      1307:3.33 1065:3.32   69:3.28
KV: 17.38       274: 1431       3.35: 3.42       hall_int  1176:3.40  933:3.39  121:3.36 
KV: 16.45       273: 1768       3.42: 3.49      1573:3.49 1331:3.48 1090:3.47  264:3.43
KV: 17.06       269: 1545       3.49: 3.56      1458:3.55 1220:3.54  980:3.53   79:3.49
KV: 17.08       270: 1452       3.56: 3.63      1322:3.61 1084:3.60  183:3.57

first column = KV [rpm/V]
second column = difference of last two loopFOC calls [ms] and milliseconds between the two last hall steps (the greater the slower the speed)
third column = the previous angle (hall pos) that the linear prediction based on: the true angle that followed after these ms between the two last hall steps (each increment is 4° = 0.07 rad)
fourth column = array of up to 8 paris predict time in ms: predicted angle.

Usually the predict times change by loopFOC[ms] but sometimes my loop() takes up to 1ms.

Here when the motor slowed down:

KV: 9.85        275: 2663       1.12: 1.19      2565:1.18 2323:1.17 2081:1.17 1839:1.16 1598:1.15 1356:1.15  197:1.12
KV: 9.77        276: 2733       1.19: 1.26      2563:1.25 2320:1.24 2077:1.24 1834:1.23 1590:1.22 1349:1.22  177:1.19 
KV: 9.84        275: 2708       1.26: 1.33      2497:1.31 2254:1.31 2011:1.30 1768:1.30 1525:1.29 1282:1.29  107:1.26
KV: 9.90        275: 2587       1.33: 1.40      2444:1.38 2202:1.38 1960:1.37 1719:1.37 1477:1.36 1235:1.36   65:1.33 
KV: 9.76        272: 2812       1.40: 1.47      2719:1.46 2480:1.45 2241:1.45 2003:1.44 1772:1.44 1534:1.43 1301:1.43 

My linear extraplation/prediction works nicely and i don't understand why that should have a field weakening effect.

BLDCMotor:move(target) does nothing but if(!_isset(phase_resistance)) voltage.q = target;
loopFOC() does nothing with our setting TorqueControlType::voltage and directly calls setPhaseVoltage(voltage.q, voltage.d, electrical_angle);
in which i do not see any parameter that might tune the pwm output in some bad way that my linear predicition resolves:

    case FOCModulationType::SinePWM :
      // Sinusoidal PWM modulation
      // Inverse Park + Clarke transformation

      // angle normalization in between 0 and 2pi
      // only necessary if using _sin and _cos - approximation functions
      angle_el = _normalizeAngle(angle_el);
      _ca = _cos(angle_el);
      _sa = _sin(angle_el);
      // Inverse park transform
      Ualpha =  _ca * Ud - _sa * Uq;  // -sin(angle) * Uq;
      Ubeta =  _sa * Ud + _ca * Uq;    //  cos(angle) * Uq;

      // center = modulation_centered ? (driver->voltage_limit)/2 : Uq;
      center = driver->voltage_limit/2;
      // Clarke transform
      Ua = Ualpha + center;
      Ub = -0.5f * Ualpha  + _SQRT3_2 * Ubeta + center;
      Uc = -0.5f * Ualpha - _SQRT3_2 * Ubeta + center;

      if (!modulation_centered) {
        float Umin = min(Ua, min(Ub, Uc));
        Ua -= Umin;
        Ub -= Umin;
        Uc -= Umin;
      }

The electrical_angle add your 2.09 to my mechanical_angle (prediction) but that only is the neccessaary calibration of the hall sensors position.

My linerar prediction works and i can not see how that should be bad.

Here max speed without my linerar prediction:

    fSpeed = (0.5*driver.voltage_power_supply)  * (ABS(	(float)(((millis()-iLoopStart)/10 + 250) % 1000) - 500) - 250)/250;
    float fLinAdd = 0.0;

KV: 12.54       263: 2122       1.61: 1.68      1957:1.61 1724:1.61 1482:1.61 1241:1.61  240:1.61
KV: 12.62       265: 2102       1.68: 1.75      2018:1.68 1784:1.68 1549:1.68 1315:1.68 1081:1.68   99:1.68 
KV: 12.71       264: 2022       1.75: 1.82      1955:1.75 1722:1.75 1488:1.75 1253:1.75  182:1.75

Of course the "predicted angle" stays at the old angle for all loopFOC calls until the next hall step occurs :-(

17.38 / 12.71 = 37% speed boost

Yes i know that we should not get a KV of more than 15 for our bldc motors.
And with full voltage_power_supply (1.5* gets clamped to 1.0) i even get a KV of 21.63 rpm/V

    fSpeed = (1.5*driver.voltage_power_supply)  * (ABS(	(float)(((millis()-iLoopStart)/10 + 250) % 1000) - 500) - 250)/250;
    float fLinAdd = 0.9;
KV: 21.49       263: 1151       1.88: 1.95       977:1.93  174:1.89
KV: 20.68       266: 1415       1.95: 2.02      1278:2.02 1042:2.01  807:2.00   90:1.96 
KV: 21.46       267: 1175       2.02: 2.09      1016:2.07  130:2.03
KV: 21.63       268: 1152       2.09: 2.16      1052:2.15  815:2.14  109:2.10
KV: 20.57       266: 1402       2.16: 2.23      1197:2.23  962:2.21  169:2.17 

Only by correctly predicting the current hall position :-/

I should test the motor under load.. Don't really know how to do this.
Ideas welcome.

P.S. i do not like voltage_power_supply nonsene. There isn't a single Driver class in simpleFOC that drives a motor with an analog voltage. It is always (of course) a pwm ration from 0.0 to 1.0.
So why the complexity of voltage_power_supply , voltage_limit and move(voltage) ??
Our 10s batteries can go from 42.0 Volt down to 25.0V ! But of course we always want the 0.5 for pure sine FOC.
Using absolute voltages does not make any sense to me.

from split_hoverboard_simplefoc.

So stm32 test setup is running and i can compare Gen1 vs Gen2 with the same simpleFOC software.
But i have a different motor in that setup :-/ It is not impossible that the Gen2 test setup has 20mm magnets and the Gen1 test setup has 25mm magnets inside. For difference see my old test: https://www.youtube.com/watch?v=cYIpnW6RCSE

And we really need a 16 kHz timer to move loopFOC() out of the main loop(). I can not log more output via UART on the Gen1 without the motor spinning poorly because loopFOC does no longer get called often enough.

Gen1 ----------------------

  driver.voltage_power_supply = 3.6 * BAT_CELLS; // power supply voltage [V]
  driver.voltage_limit = 1 * driver.voltage_power_supply;   // 0.3 = keep well below 1.0 for testing !
    fSpeed = (0.5*driver.voltage_power_supply)  * (ABS(	(float)(((millis()-iLoopStart)/10 + 250) % 1000) - 500) - 250)/250;
    float fLinAdd = 0.0;

KV: rpm/V   latest loopFOC[ms]: max loopFOC[ms]
KV: -9.58  186: 2615
KV: -9.53  183: 2835
KV: -10.34  187: 2531
KV: -11.10  183: 2264
KV: -11.26  187: 2200
KV: -12.00  188: 2040
KV: -11.84  210: 2227
KV: -12.11  176: 2205
KV: -11.38  173: 2260
KV: -11.26  173: 2333
KV: -10.23  204: 2565
KV: -10.16  177: 2574
KV: -9.54  173: 2708 

  driver.voltage_power_supply = 3.6 * BAT_CELLS; // power supply voltage [V]
  driver.voltage_limit = 1 * driver.voltage_power_supply;   // 0.3 = keep well below 1.0 for testing !
    fSpeed = (0.5*driver.voltage_power_supply)  * (ABS(	(float)(((millis()-iLoopStart)/10 + 250) % 1000) - 500) - 250)/250;
    float fLinAdd = 0.7;

KV: -8.48  187: 3060
KV: -8.78  188: 3014
KV: -9.47  182: 2793
KV: -10.09  188: 2435
KV: -10.19  187: 2505
KV: -11.08  183: 2329
KV: -10.96  183: 2347
KV: -11.76  188: 2289
KV: -11.59  178: 2283
KV: -11.95  188: 2258
KV: -11.23  173: 2286
...
KV: 8.23  207: 3047
KV: 8.66  205: 3058
KV: 9.94  233: 2647
KV: 10.33  200: 2583
KV: 11.26  207: 2323
KV: 12.09  235: 2305
KV: 12.51  206: 2237
KV: 13.36  207: 2057
KV: 14.25  207: 1875
KV: 14.71  207: 1871
KV: 15.00  205: 1921
KV: 16.38  206: 1526
KV: 16.37  226: 1610
KV: 16.84  207: 1592
KV: 16.83  206: 1555
KV: 15.65  205: 1673
KV: 15.24  207: 1601
KV: 13.90  207: 1989
KV: 13.48  208: 1817
KV: 12.63  207: 2149
KV: 11.54  206: 2356
KV: 11.20  208: 2264
KV: 10.09  207: 2597
KV: 9.30  207: 2818

Gen2.0 ----------------------

  driver.voltage_power_supply = 3.6 * BAT_CELLS; // power supply voltage [V]
  driver.voltage_limit = 1 * driver.voltage_power_supply;   // 0.3 = keep well below 1.0 for testing !
    fSpeed = (0.5*driver.voltage_power_supply)  * (ABS(	(float)(((millis()-iLoopStart)/10 + 250) % 1000) - 500) - 250)/250;
    float fLinAdd = 0.0;

KV: 11.73  255: 2278
KV: 12.01  258: 2408  
KV: 11.64  255: 2379  
KV: 11.53  290: 2472  
KV: 11.30  291: 2272  
KV: 10.93  258: 2584  
KV: 10.07  258: 2809  
KV: 10.11  257: 2604  
KV: 9.09  255: 3030  
KV: 9.22  257: 2886  
...
KV: -8.75  233: 3041  
KV: -9.21  234: 2940  
KV: -9.79  234: 2882  
KV: -10.59  230: 2337  
KV: -11.17  233: 2440  
KV: -11.24  233: 2331  
KV: -12.47  233: 1996  
KV: -11.92  234: 2166  
KV: -13.56  224: 1820  
KV: -12.09  234: 2169  
KV: -12.08  234: 2390  
KV: -11.34  265: 2343  
KV: -11.34  231: 2454  
KV: -10.39  230: 2593  
KV: -10.30  234: 2623  
KV: -9.51  234: 2801  
KV: -9.50  235: 2639  

  driver.voltage_power_supply = 3.6 * BAT_CELLS; // power supply voltage [V]
  driver.voltage_limit = 1 * driver.voltage_power_supply;   // 0.3 = keep well below 1.0 for testing !
    fSpeed = (0.5*driver.voltage_power_supply)  * (ABS(	(float)(((millis()-iLoopStart)/10 + 250) % 1000) - 500) - 250)/250;
    float fLinAdd = 0.9;

KV: 9.78  258: 2741  
KV: 10.16  258: 2603  
KV: 11.68  259: 2184  
KV: 11.87  290: 2290  
KV: 13.33  259: 2040  
KV: 13.13  255: 2096  
KV: 13.97  255: 1750  
KV: 15.03  256: 1726  
KV: 15.38  258: 1713  
KV: 15.83  258: 1726  
KV: 16.96  289: 1520  
KV: 16.27  247: 1542  
KV: 16.29  259: 1610  
KV: 16.76  287: 1531  
KV: 15.66  259: 1716  
KV: 15.62  260: 1569  
KV: 15.36  258: 1683  
KV: 14.38  258: 1822  
KV: 13.99  256: 1835  
KV: 12.71  258: 1913  
KV: 12.56  258: 2107  
KV: 10.58  241: 2650  
KV: 10.51  259: 2466  
KV: 9.20  292: 2751  
...
KV: -8.29  234: 3082  
KV: -9.04  230: 2744  
KV: -9.66  230: 2602  
KV: -9.68  230: 2771  
KV: -10.71  235: 2499  
KV: -10.63  231: 2471  
KV: -11.71  234: 2254  
KV: -11.65  235: 2201  
KV: -12.75  230: 2062  
KV: -12.40  222: 2115  
KV: -12.73  230: 2118  
KV: -11.68  234: 2283  
KV: -12.14  230: 2134  
KV: -10.83  233: 2460  
KV: -11.02  230: 2258  
KV: -10.08  233: 2620  

The Gen2 GD32 code is about as efficient as the STM32 code :-)
My linear prediction now only seems to work in one direction for both Gen1 and Gen2. Need to investigate why that changed for Gen2.
But i also see a 33% speed boost for the stm32 Gen1 code.
So that strange boost has nothing to do with the GD32_mcu.cpp implementation.

Will have to do more test.
My code is online here https://github.com/RoboDurden/Split_Hoverboard_SimpleFOC/blob/main/src/main.cpp
But the GD32/HallSensor and STM32/HallSensor changes needed are offline.
So the code currently is not ready for a pull request

from split_hoverboard_simplefoc.

I switched back to trapezoidal, sinePWM was a mistake without interpolation, I thought it would just perform like trapezoidal and it was less noisy.
In the next few days I will try the simpleFOC dev branch improvements (interpolation, better interrupt handling, faster sin/cos, new initFOC) together with the gd32 drivers and sinePWM.

from split_hoverboard_simplefoc.

Good to hear from you Candas :-)
When can i expect a 10-16 kHz Timer Interrupt to call loopFOC ?
If this will take you more then 2 weeks i might want to start with a dummy currentSensor the Gen2 style. Only to move the loopFOC out of the main loop. Then i may try to add adc sampling like done in the Gen2 code and we can later see what works better. your inserted adc or the gen2 style.

from split_hoverboard_simplefoc.

Feel free to experiment if you want to learn.

from split_hoverboard_simplefoc.

hm, no answer to my question.

from split_hoverboard_simplefoc.

I never said I was going to work on an interrupt, so feel free to experiment if you think what we need now is an interrupt.

from split_hoverboard_simplefoc.

Okay thank you for that answer :-) I thought it is obvious that we need an additional interrupt for loopFOC.
So i will begin to port the Gen2 adc the next days..

I am currently working on a vertical axis wind turbine with a 10" hoverboard motor:

The idea was to only use two blades as the hoverboard controller can start the turbine..
But now i guess i will add a little savonius wind turbine of 1/4 diameter. The tip-speed-ration is only about 1/4 of the darrieus..
Don't know if it is really worth adding a hoverboard controller with a kind of mppt that varies a target speed..

from split_hoverboard_simplefoc.