SPEED mode choppy + RATE/FILTER/SPEED/STEER explanation + connected rotors

[Chaos99]

Let me start with a big thank you for your work and keeping this in active development!

I've an use-case with a balancing single-wheel skateboard ("Onewheel") and I'm using a heavily modified version of your FOC firmware.

Reasons for the modifications:

• I have a different HW: STM32F103 on both main and sensor boards, but changed pinout on the main board
• I use only one sensor board (the 'right' one) and the other UART for a debugging serial connection
• I use the sensor board with its original firmware, not your modified one
• I had problems with IRQ+DMA modes for the serial communication (I had to settle for IRQ without DMA)
• I use 2 motors with mechanically linked rotors, so I only send the same data to both motor controllers

My fork is here, but I removed most of the code for the variants I didn't use to make debugging easier. So it's probably NOT easy comparing to your original.

But the motor control code is unchanged, so maybe you could still help me with 2 questions:

1. I started with Type:Sinusodial and Mode:Voltage and implemented a balancing PID in the main loop. The balancing worked and the torque was pretty smooth, but as soon as there was some additional load (rough ground, incline, ...), the motor(s) would 'whine' and then stop. I assume that the 'overload' protection in your controller kicked in faster then my main-loop PID could increase the target voltage. The main loop runs slower than your controller, right? Do you have another theory what could cause the motors to stop?

   So I switched to Type:FOC Mode:Speed, because I understand there is an internal regulation to increase the power in case of additional load. But now my PID values were all wrong (everything was much to fast and powerful leading to oscillation). When I scale down my values, the motors don't run smooth, but choppy and loud.

   I have two theories, maybe you can give me some advise:

   1. Due to the down-scaling (floating point math is used) and then rounding, I lose precision and this leads to the choppiness.
   2. My external PID is fighting you internal regulation.
      Can you explain your config.h values RATE, FILTER, SPEED/STEER COEFFICIENT a bit more? Could I also use them to downscale the response in speed-mode? Will the suffer from lost precision around small targets too?

(Btw: I made all the tests for the issue above with only one motor (2 connected, but pwmr = 0 ), to avoid any interference from the other problem below)

2. As mentioned, I use two motors with connected rotors. Practically, this works at least intially in any mode I've tried so far as long as I keep the target values the same (pwmr = pwml).
   But I don't have a way of measuring current consumption while testing with load at speed and indeed some modes are 'choppier' than others.
   At least theoretically, it's still possible that some internal regulation could lead both motors to 'fight' one another about reaching a target position, as the magnets in the rotors are not perfectly aligned.
   With your internal knowledge about the regulation: do you see some types/modes more fit to handle the situation than others? (Mostly concerning smoothness and power consumption.)

Thanks a lot for your time and hopefully your answers.

PS: I now have another HW set available (GD32F103 on both main and sensor boards). I will try your un-modified firmware on both main and sensorboard there too.

[Chaos99]

Now that I re-read my own issue, I might already spotted one of my mistakes.

In FOC/speed-mode, there is no free-wheeling. So keeping pwmr = 0 actually might add a breaking force that could lead to the choppiness.

But if that's right, then with both motors active, the increases power would even make the problem with the overly-powerful regulation even worse. I'm already scaling with 0.001.

[Chaos99]

So I removed the pwmr = pwml line and replaced it with the solution given in #7 . This solved the major choppiness issues.

I've also converted all intermediate values to float and pushed the round() conversion to int16_t as far back as possible to reduce rounding errors.

Still I wasn't able to tune my PID to smooth balancing. At least not as good as with voltage mode and far from the stock hoverboard implementation.

Maybe this is because of the issue described in #20 ?

You proposed to switch to voltage mode for slow speeds. But this is very tricky to do within the PID. I'll try my best...

[Chaos99]

Spent about 5h tying to fine-tune the PID in SPEED mode. Wasn't successful.

I've gone back to VOLTAGE mode, connected the second motor, increased the speed of the main loop and made the PID more aggressive. This now works well even on rough terrain without 'whining'. I still have some issues with overshooting reactions on hard external inputs (curbs, stones), which I will try to tackle with not only regulating in board angle but also taking the speed gradient into account.

I'll try to rebase those changes back onto master to offer you a pull request for a new 'Onewheel' variant. I hope I can abstract my changed HW out of it.

I'd still be glad to receive some advice about the side-effects of mechanical connected rotors.

[EFeru]

Hi @Chaos99,

Sorry for my late reply.

• Regarding the SPEED mode, in my opinion is not recommended for balancing applications because of the internal loop which as you noticed it will fight with your controller. It is better to use VOLTAGE or TORQUE mode. I recommend to start with VOLTAGE mode because that should theoretically give the fastest response since there is no internal control loop (TORQUE mode has a current control internal loop).
• Regarding the choppiness, there is a possibility that the main loop code became too heavy for the STM32 MCU due to the balancing controller code, and it will not be executed correctly. What happens is that if the main loop code is computationally expensive, it will take a lot of time for the main loop to finish because the DMA interrupt has higher priority. That means the balancing controller will lag too much behind the motor.
• I would advise to check if you don't get the above behavior by toggling the onboard LED and checking with an oscilloscope connected to the LED's pin, what is the main loop duration. That will define how often the balancing controller will update and if it behaves as expected.

I am interested in your work because I would also like to implement a balancing controller in the FOC branch. You should join our Telegram group and share your work (people will like it): https://t.me/joinchat/BHWO_RKu2LT5ZxEkvUB8uw