Open ctzsnooze opened 2 years ago
Hi there, thanks for the detailed info and plots!
There's some approximation happening when scaling from DShot throttle value to PWM duty cycle, as well as converting commutation period to e-period (to RPM). DShot throttle scaling has been improved compared to BLHeli_S, but I'm not sure if this is the problem. The ERPM-TEST release should make RPM telemetry as precise as possible for the protocol, but I haven't been able to see any significant improvement from this.
Was this test made at 24kHz PWM frequency? It would be interesting if you could compare it to 48kHz to see if this affects the output.
I also made these test files a while ago that uses the original BLHeli_S scaling, if you want to compare: v0.14_bls_throttle.zip
I can also try to compile a version that scales DShot throttle to PWM without approximation (at the cost of underestimating and not being able to reach 100% duty cycle) to see if this would remove the non-linearity of the RPM output.
Here is the version without approximate scaling, so a DShot throttle value of 0-2000 will correspond to around 0-97% PWM duty cycle:
It would be interesting to see if this affects the linearity of the RPM output.
Hi Mathias - thanks for getting back to me! Here is an image with Bluejay 0.14 in 48k mode. I hacked the log viewer so I can see the whole ramp:
In the same format, this is the previous 24k log:
We couldn't say that the linear PWM at 24khz is much of an improvement, but it perhaps suggests that the reason for the steps at the top come from something else in the code.
@mathiasvr Happy to test whatever you come up with.
@ctzsnooze Do you still have these logs by any chance? 😅
I repeated the tests with 0.16.
Same abrupt, non-linear steps in RPM at high throttle. Left is 24kHz, right 48kHz.
Easy to make the logs. Get 4.3 RC or nightly, latest blackbox logger.
Put a fake prop on the motor (I made some out of TPU, about 1"diameter, little flat blades), or no prop.
Set all PIDs off, antigravity off, DShot telemetry on, dynamic idle off, idle % 0.1, and in CLI set blackbox_mode = MOTOR_TEST, debug mode to RPM_TELEMETRY.
Then just go to motors tab, enable motors, hold the up arrow on one motor, and watch the values increase slowly. RPM will increase steadily and be logged. The graphs above are easily made. The latest log viewer shows RPM correctly and allows zoom of 4% to show the whole ramp up.
.
Hi, and thanks for working on improving BLHeli-S.
I'm sure you're aware of this, it's a 'feature' of BLHeli-S, but I was wondering if you can do anything to improve it a bit.
What I'm referring to is the way that at high DSHot signals - high throttle - the ESC doesn't respond smoothly, instead it generates a series of steps. At least that's what the RPM data shows.
Here I am steadily increasing the motor drive signal in Betaflight's motors tab, by holding my up arrow. The entire pass takes about 16 seconds.
This image shows the last 10 seconds. Motor drive signal from betaflight in the top panel, RPM as measured by DShot Telemetry and recorded in the DShot Telemetry debug, with the debug mode set to
motor_test
.Bluejay was set to defaults with dithering active.
Note how there are 5 large, flat steps above about 80% throttle. This is a significant non-linearity that would markedly reduce the PID loop's ability to control the quad whenever a motor is driven above 80%.
I'm fairly sure this has always been the case with BLHeli-S but have always wondered why, and if anything can be done to improve it.
There are other brief steps at about 35 and 66% throttle.