Stepped torque curve with BlueJay at low to moderate RPM

[ChrisRosser]

Describe the issue

Testing BlueJay using an intertial dynomometer I notice quite a stepped/quantised torque curve compared to BLHeli_S.

BlueJay does deliver more torque across a wider range of RPMs but it would interesting to know if there might be an improvement to smooth out the torque delivery particularly above 10000RPM. Similar to BLHeli_S or, ideally, AM32.

More info here: https://youtu.be/OT_dxmIrooE

Bluejay version

0.16

ESC variant

C-H-25

PWM frequency

24

DShot bitrate

300

Bidirectional DShot

Off

FC firmware

Betaflight 4.3.0

Motor size

2207

Configurator debug log

No response

[stylesuxx]

Very interesting - thanks for taking the time to do all the measurements. This is definitely something worth looking into and also a "problem" I ran into with a different application than mutlirotors.

I will see if @AlkaMotors is going to help us out here and teach us how they do it and see if we could maybe borrow some code and get some improvements on our end.

@saidinesh5 is building a test stand for automated testing of our future firmware releases, maybe the test setup that @ChrisRosser is using here could also be valuable for us, sounds like a nice thing, to additionally have a torque curve - the "external" measurement of RPM could also help with sanity checking our erpm values - what do you think?

CC: @damosvil @Burdalfis

[ChrisRosser]

Following in the footsteps of AM32 seems to be a very good call here. The AM32 ESCs I've tested consistently perform the best in terms of torque production and smoothness of torque delivery.

If you're building a test stand already with high speed logging then adding an inertial Dyno test is easy. You just need some flywheels of known inertia which I can send you my designs for 20,50,100,200,kgmm2

[stylesuxx]

Oh yeah, if you would share your designs, we would very much appreciate that.

[AlkaMotors]

I guess it all depends what is causing the issue. It may be low rpm throttle restrictions. I am not sure how its done with the other firmware but with AM32 the maximum throttle allowed is raised proportionally as the rpm is increased at a fairly high update rate. In the config tool there is a motor KV and motor poles value. The rpm range of the throttle restrictions is based off this KV/poles value.

[damosvil]

At this time Bluejay allows to send debug values back to the fc. I think a good starting point would be to prepare a release that sends pwm output value, and commutation timing to guess what code path Bluejay is taking depending on rc pulse, and rpm.

Bluejay has several code paths to control pwm, and commutation timing depending on erpm values, in order to optimize calculations and allow higher rpm values (we have checked a max rpm of 80.000), but I think it may be more than possible to sacrifice some of those max rpm in order to get a better motor response.

It could be interesting to find somebody to implement a simulation in Simulink to know how to calculate the best switching timings depending on current rpm value and rc pulse. Then we could port the resulting c code to into assembly.
I say this because in the case of Bluejay there are many code paths depending on several factors in Bluejay, but every 'if' in the code paths take CPU cycles like any other instruction, so my guess is that it would be even more optimal to make a unique 32bit formula calculation in the venerable 8051 for all cases based in a well known formula designed in Simulink.

Simulink has a BLDC module that would help to create a formula for commutation timing. We could even compile the function in C code into assembly with Silabs tools and then copying the resulting assembly code to Bluejay.

[pitts-mo]

I have been very interested in motor torque since @ChrisRosser 's first video. Specifically, I have speculated this inconsistency of torque may be related to my startup behavior observations between blheli-s and bluejay firmware on micro quads... Now I have loaned out my micro quads and none of them have black box anyway. But, If OSD clips of debug data would help I will get one of my TinyHawk's back from my friend.
-p

My observation detail:
Immediately on switching micro quads from blheli-s firmware to bi-directional D-Shot firmwares I have long known motor startup on small quads to be much more sensitive to resistance. Most of my observations listed were regarding motor startup on EMax TinyHawk series quads.

Running stock blheli-s I pretty much needed to block the motor with battery lead or other notable object to prevent startup.

Running blujay I found these items notably influenced motor startup toward more reliable.
-higher minimum startup values
-higher maximum startup values
-higher RPM power protection values
-lower PWM builds

Note that 48khz firmware can provide a reasonably reliable startup on the EMax TinyHawk providing quad motor resistance is perfect in all respects. Eg: no hair or other material in motor, stock motor connectors are perfect or just removed, and perfect battery connection

[Camo55]

I would like to add that in the Battlebots Scene, particularily in the smaller weight classes (150g, 1 lb, 3lb) This startup torque issue has plagued all speed controllers that aren't Simonk, which to this day has the best low rpm-high torque scheme at the 0-500 rpm range, which is the most critical for this application, notably because either people want to direct-drive a 30mm wheel with a 2205 1500kv motor on 3s, or for a majority of cases, spinning an 1806 or 1000kv 3035 or similar propdrive with a 3-10 oz 'flywheel' (Weapon) with 1000+ kg*mm^2 Inertia (My 1lb bot uses an emax rsII 2207 1600kv to drive a shell with 1400kgmm2 of inertia)

The problem being these are all sensorless motors and VESC is just too big to be viable, so we are forced to use what the quadrotor scene uses.

To some extent, setting startup torque to 150% and turning off stall protection helps, but it's still a big issue and most of the solutions seem to still be very inefficient, not to mention most of the smallest speed controllers are still BL-Heli_S

I myself would love to see an example of this code running on an emax bullet 30A.

and @ChrisRosser It would be awesome to see your dyno graph expand to include the 0-5000 rpm band, I believe it would be useful for the boat crowd as well as the battlebots crowd.

[stylesuxx]

@Camo55 Bluejay does not aim to be an allround firmware, it is intended for quadcopters and very specialized in those needs - see for example bi-directinoal DSHOT with eRPM telemetry. Such low RPM are not really interesting for us. I would suggest you look into AM32 - they also cater to the "crawler" crowd, and it might be more what you are looking for.

That being said, we would not object against submissions that go into this direction just that the dev team is very small and all of us are into quads and not into battlebots - so, yeah I am really surprised that the battlebot community does not have their own thing going...

[stylesuxx]

Summoning @ChrisRosser - just wanted to ask if your offer still stands with sharing the designs, if so we would very much appreciate it.