Integration and design questions around new CF2 defconfigs (cf2p, cf2t)

[gemenerik]

#1465 added two new defconfigs: cf2p_defconfig (for upgraded propellers) and cf2t_defconfig (for the thrust upgrade kit).

At the moment, they don’t seem to be fully integrated - they aren’t documented, included in build_targets.json, or part of CI or automated testing.

Beyond that, a few broader questions came up while looking at how these are being used:

• Both defconfigs still set CONFIG_PLATFORM_CF2=y and only differ from the base CF2 by the battery compensation setting.
  That raises the question: is this kind of variation best handled through separate defconfigs, or should it be exposed via Kconfig?
• There’s also some blurring between platform identity and configuration. Even though these are clearly still CF2 in software, treating them as separate defconfigs invites interpretation that they represent distinct platforms.
• More generally, it’s not always clear where a particular setting is configured between Kconfig, defconfigs, and platform defaults, it can take effort to track down what’s actually in effect.

Opening this up for discussion: what’s the intended role of these defconfigs, and how should we approach this kind of variation going forward?

[ataffanel]

Result of triage discussion, we should:

• Delete the defconfig
• Document how to compile the firmware using KConfig to enable the right battery compensation
• Open a new Client/Firmware issue about allowing to configure the hardware setup of a Crazyflie.

[matejkarasek]

Hi, we will soon face a similar situation with the Flappers, as we will have multiple configurations (Nimble+, Triple). These are different platforms, but in the end there are only minor differences (power distribution, control gains, ...).

We do like the fact that with a platform the firmware is precompiled and can be easily updated via cfclient. But seeing this issue, I suppose you would like to limit the number of platforms.

Did you discuss how the hardware setup configuration would work?
Would this "just" be via Kconfig (requiring to compile the firmware) or maybe with something like a persistent parameter, where the configuration could be chosen within a precompiled firmware?

[gemenerik]

I propose two core principles for defconfigs:

1. Every defconfig must represent a distinct platform - not just a configuration variant or use case
2. Every defconfig must correspond to a precompiled binary that users can flash via cfclient

These principles create clear accountability and prevent architectural confusion. If we're not willing to maintain and release a platform binary, or if it's not actually a separate platform, it shouldn't be a defconfig.

The recently added cf2p_defconfig and cf2t_defconfig violate both principles. They exist in the configs directory but aren't built in CI or released as binaries, creating a disconnect between what defconfigs imply and what they deliver. More fundamentally, they're not separate platforms - we've never considered the CF2 with thrust upgrade kit or upgraded propellers as distinct platforms (not internally, not in documentation, and not in store listings). Even their defconfig files acknowledge this with CONFIG_PLATFORM_CF2=y.

Crucially, users should not need to compile firmware for hardware modifications like propeller upgrades. This should be as simple as changing a setting in cfclient imo. We need to design a runtime hardware configuration system that makes this intuitive and accessible. Let's keep @matejkarasek involved in the design of whatever this will be.

Similarly, configurations like sysid_defconfig and wearable_defconfig represent use cases rather than platforms. The system identification setup is a research/dev configuration that could work on any platform with the right deck attached. The wearable configuration is (currently) just an estimator choice that's platform-agnostic. These are better served as feature overlays (.conf files) that can be merged with any platform defconfig during development and testing.

Beyond this architectural cleanup, we need to document how users can currently configure their CF2 for thrust upgrade kits and 2.1+ propellers (through kconfig).

The proposed cleanup maintains clear architectural boundaries: platforms get defconfigs and binaries, hardware variants get runtime configuration, and use cases get feature overlays. This prevents an explosion of barely-different binaries.

Implemented necessary firmware changes in #1527