New method for battery compensation

[Rather1337]

Changed the battery compensation to go from V_bat to thrust with a third order polynomial. Adjusted the system id scripts accordingly.

Added functionality to change the battery compensation at compile time (type is set in defconfigs).

Open questions:

• Sysid readme mentions some emergency stop branch in cflib. Seems to not exist anymore
• In motors.c: motorsCompensateBatteryVoltage(), it might make sense to either make batCompEnable as a parameters s.t. it can be changed on the fly. In that case, remove the battery compensation setting in the defconfig.
• In motors.c: motorsCompensateBatteryVoltage(), removing the batVoltage < 2 check might make sense. Other code should catch a case like that and the battery low indication is also in place.

[Rather1337]

Hi @ToveRumar,
I've just seen that in the powerDistributionForceTorque in power_distribution_quadrotor.c, the quadratic fit is still used. With the new setup, that should also be changed to:
motorThrustUncapped = motor_force / thrust_max * UINT16_MAX;
In that case, it would also make sense to move the constants out of motors.c into some config file, like platform_defaults_cf2.h, s.t. there is a proper global definition.
Should I add those changes to the PR?

[tobbeanton]

Should I add those changes to the PR?

Yes, they all sounds like good changes

[spencerfolk]

Hey @Rather1337 thanks for contributing. In a separate discussion post I was asking about ways to get an accurate measurement of thrust from the motors for state estimation purposes. It seems the best I can do right now is to infer the thrust from the 16-bit commanded pwm signal to each motor as well as the supply voltage.

@tobbeanton pointed me to this PR. It looks like you might have these mappings here. Although I looked at the files and it looks like you only have data for the brushed CF. Do you happen to have data for the brushless Crazyflie? I previously conducted thrust stand tests for the isolated brushless CF motor/prop, but I wasn't using the same ESC and I'm concerned that it won't be an accurate fit since each ESC is different.

[Rather1337]

Hey @spencerfolk,
unfortunately, we currently don't have access to the brushless version, but we would be happy to take the measurements with our setup. @tobbeanton does the sysid deck also work with the brushless cf?

[tobbeanton]

@Rather1337 The system-id deck works with the brushless as well. If you can not get hold of a brushless let us arrange one for you!

[Rather1337]

@tobbeanton that would be great! Good to hear that the deck works too.

[Rather1337]

I've now also updated the power distributionForceTorque. If you are happy with the way I've structured the constants, the PR is almost ready from my side. All the tests are passing now. One thing that is still a to do is the "Emergency Stop branch" mentioned in the old readme. This would be nice, since right now pressing CTRL-C makes the drone getting stuck in the current state. Also, as soon as we get hands on a brushless drone and our 6 axis load cell arrives, we can identify the missing parameters (mostly thrust->torque).

To make sure I understand this correctly: Since for brushless motors, the speed does not depent on the battery voltage, but only the commanded PWM, we only need to identify the PWM-> Thrust curve instead of the v_motor->thrust. So I assume that will be a different PR then?

[ToveRumar]

Hi @Rather1337 !

Apologies for the long delay in answering! We have been a bit low on man power since many has been gone for fairs etc.

I glanced it through and it looks good to me. However we did not get the time to test it yet.
We will try and get that done soon.

In the mean time you should also have received a Brushless to do sys id on.
To answer your question about voltage->thrust:
As I understand it, the ESC protocol we use (Dshot) will give a throttle command in percent. This means that the output thrust will be influenced by the supplied voltage. So there should be no difference in how to create the sys id for the Brushless platform.

When we are at fuller capacity at the office we will have some time to test it. Thanks again for the help!

[ArisMorgens]

Hello @Rather1337!

We finally managed to test your PR with our Crazyflies and the results seem pretty good. Here is what we did:

Test 1: Hover with the Lighthouse deck

We used 4 Crazyflies:

• 1 with old propellers (2.1) and the PR
• 1 with new propellers (2.1+) and the PR
• 1 with the thrust upgrade kit and the PR
• 1 with the thrust upgrade kit without the PR (2025.02 release fw)
  All of them behaved normally and started drifting only when their battery was low.

Test 2: Hover with the Flow deck v2

With the same setup, their behavior was pretty normal.

Test 3: Lifting weights

We used 2 Crazyflies:

• 1 with the thrust upgrade kit and the PR
• 1 with the thrust upgrade kit without the PR (2025.02 release fw)
  The Crazyflie with the PR managed to carry a weight that the Crazyflie with the release fw couldn't. The difference was not that big but still noticeable.

To sum up, the PR seems good in action. In the following days, we will take a look at the structure and might propose some necessary changes.

[ToveRumar]

This looks good!
@arnaud and I had a look at the overall structure and agree its ready to be merged.

Thank you so much for your contribution @Rather1337! We are looking forward to the Brushless system id PR.

[jglane]

Hi,

I just noticed that in #3893c67, src/platform/interface/platform_defaults_cf2.h, CF_MASS was increased from 0.027f to 0.03454f. This seems like quite a big increase, especially because the stock Crazyflie 2.1+ does not weigh that much. Was this intended?

[ArisMorgens]

That's a nice catch @jglane! 0.027f is not correct either since Crazyflie 2.1 and 2.1+ weight 29g.
CF_MASS is currently used only by these three controllers: Mellinger, Brescianini and Lee. This means that we couldn't notice the difference using the default PID controller. However, it would be helpful to have a precise mass parameter for the different stock Crazyflies (29g for 2.1 and 2.1+, and 32.5g for the thrust upgrade kit).

@Rather1337 Could you explain how you measured the CF_MASS? I assume that 0.03454f results from a Crazyflie with the thrust upgrade kit and maybe a lighthouse deck?
This value is set in the default parameters and is now used by every Crazyflie 2.x drone. I think we should change that since it's not true. A possible solution would be to have the CF_MASS equal to 0.029f as the default value and define it equal to 0.0325f (or add the difference) when setting the THRUST_BAT_COMPENSATION_TYPE to 2 (meaning that thrust upgrade kit is used). What are your thoughts on that?

[Rather1337]

Thanks for bringing that up @jglane! I've double checked and the stock Crazyflie with battery weighs indeed only 30g (on our imprecise scale). So 29g sounds good. The 34.54g is some number that has been floating around in the lab for a stock cf2 with marker deck and markers. I've never checked the value exactly, since we currently don't have a high precision scale, but our scale displays a value around 34g. I thought the 27g was the weight of the drone without the battery - which is roughly true if you have the marker deck on, see here - and didn't think the marker deck would make such a large difference, but it does apparently. Sorry for letting that slip!

@ArisMorgens I agree that we should change the CF_MASS in accordance to the battery compensation type and change it to 29g for the stock cf2. Maybe some more precise measurement is possible there?

I'm wondering how one is intended to change the weight of the drone depending on the used decks? It would be nice if the mass was a parameter you can change online. I guess the alternative would be to change the mass parameter in the platform_defaults before flashing or somehow in the config file (maybe setting the additional mass, i.e. payload, added to the drone).

[jglane]

Glad I could help! What you said makes sense. In my humble opinion I don't think it's necessary to change the mass parameter online because all the controllers should have some sort of disturbance rejection like an integral term implemented. So the mass value just needs to be close to what it actually is and the controller will compensate for the rest.

If it helps, my lab has a precise scale and I measured the stock Crazyflie 2.1+ at 28.3g and with a passive marker deck with 4 markers at 31.1g.

[ArisMorgens]

Hello everyone! Depending on the components used (e.g. batteries 1, 2, or deck connectors 1, 2) the weight of the Crazyflie changes significantly. Our measurements for the stock Crazyflie 2.x were between 28.1g and 29.9g, so I think a mean value of 29g is good for now. Do you agree with that @jglane?

@Rather1337 Changing the weight depending on the used decks is a great idea that we've discussed in the company. Our long distance goal is to automatically modify the mass value depending on the detected decks and that's why we prefer the CF_MASS to refer to the stock Crazyflie. I think a way forward is to set CF_MASS to 0.029f and increase it to 0.0325f when using the thrust upgrade kit. Do you agree with the idea and would you like to do that?

[jglane]

Hi @ArisMorgens, yes that sounds good to me.

[Rather1337]

@ArisMorgens that works for active decks only, so not for the passive marker deck. Do you have a suggestion on how to include that? To be frank, it doesn't really affect us that much, since we are only using attitude controllers for high performance tasks. However, it would be a nice improvement for the onboard position controllers, which we use for swarm applications. I think having a payload parameter or making the mass a parameter would be easiest.

I can create a new PR with the fix for the mass!

[ArisMorgens]

@Rather1337 All the decks (including the passive marker deck) have a 1-wire memory in order to be recognized by the Crazyflie. The battery holder and the breakout deck are the only exceptions. The prototyping deck has also a 1-wire memory that the user can write. Making the mass a parameter sounds like a good idea to me. Since this is an important change, we will discuss it internally next week and we will get back to you as soon as possible.

[ArisMorgens]

Hello @Rather1337!
I opened this issue regarding the CF_MASS parameter. Let us know if you would like to change something on the proposed solution and if you're interested in working at it.