Better cloud build options

[MrD-RC]

Is your feature request related to a problem? Please describe

Sorry, I don't like the cloud build at all. It will be especially confusing to new users. I also don't like that you will need to flash new firmware if you change some little hardware thing, like a receiver for example. I under stand it's there for F411 and F722 MCUs. But surely compiling some areas of the code for efficiency would have solved that problem, and not needed cloud build at all.

Anyway. I have a couple of suggestions which may make the process better.

Describe the solution you'd like

1. Have an Install All option next to the Core Only option. This will just install the full firmware in the old way. Much simpler if space is not an issue.
2. Allow selection of multiple radio protocols. For example if I want to install CRSF and FPORT, this is not possible now
3. Have separate telemetry options (again, multi-selectable) for all systems. CRSF and GHST not being in the list adds confusion. Also, I can't then install CRSF and SmartPort.

Describe alternatives you've considered

Pretty self explanatory in the last section

Other information

No response

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.

[MrD-RC]

No one else thinks that this can be improved?

[haslinghuis]

You can add whatever you like, but radio, telemetry and motor protocol should be a single option.

And yes we can improve here and there.
For one we can preset these options in settings (my idea was to lock it)

However for your use case you can add to custom defines from this list:

SERIALRX_CRSF
SERIALRX_IBUS
SERIALRX_JETIEXBUS
SERIALRX_SBUS
SERIALRX_SPEKTRUM
SERIALRX_JETIEXBUS
SERIALRX_SUMD
SERIALRX_SUMH
SERIALRX_XBUS
SERIALRX_FPORT


TELEMETRY_CRSF
TELEMETRY_GHST
TELEMETRY_FRSKY_HUB
TELEMETRY_HOTT
TELEMETRY_IBUS
TELEMETRY_IBUS_EXTENDED
TELEMETRY_JETIEXBUS
TELEMETRY_LTM
TELEMETRY_MAVLINK
TELEMETRY_SMARTPORT
TELEMETRY_SRXL

[MrD-RC]

Thanks for the info @haslinghuis But, I think it should be easier to use than having to edit custom defines. One note though. You said that "telemetry and motor protocol should be a single option.". But, the default telemetry is not a single option. It installs CRSF and GHST telemetry with the default settings. I don't really see why it needs to be singular either. Otherwise, if you change receiver, you could end up having to re-flash again, where as in 4.3 it would have just been changing an option.

I also think the Install all option would be useful. If I don't use an F411 or F722, I really can't be bothered with all this just to flash firmware.

[haslinghuis]

Do you have more then once receiver installed on the flight controller and why? This is really an edge case. You still need to change settings etc.

Yes the CRSF, GHST, SBUS option should already have been removed.

[aQuaplug]

I do need option 'Install all'.
I have several radios and plenty of receivers. I like play and test with them. That's my hobby.
I don't want flash everytime when I swap some littlething.

And newbies in community of South Korea(my country :)) sometimes asks 'how to change receivers of second hand drone.'
, 'flashed for receiver, and motor spins but acts like crazy, what should I do T.T' (he don't knows about backup)
In BF 4.4. Newbies should know about their protocols(Yes, many newbies don't think about it), configuration backup and restore for just switch little thing. In many case, reply is 'Just using 4.3 or do not flash 4.4 if yours flying well'
Just put every options in firmware, if it could, is easier way especially for newbies.

I think classic way full build is still good and straight way, even cloud build is necessary for future.

[sugaarK]

Point it with some chipsets you can’t build all because stuff already doesn’t fit. The bf system has on average 6000 builds a day going through the system so it seems people are adapting and using the system just fine

[MrD-RC]

Point it with some chipsets you can’t build all because stuff already doesn’t fit. The bf system has on average 6000 builds a day going through the system so it seems people are adapting and using the system just fine

It doesn’t fit because everything is just optimised for speed. There is loads of code that could be optimised for efficiency. That would have not needed any of the cloud stuff. INAV is no doubt a bigger firmware. But that can still fit on F411 due to how it’s compiled.

[haslinghuis]

It doesn’t fit because everything is just optimised for speed. There is loads of code that could be optimised for efficiency. That would have not needed any of the cloud stuff. INAV is no doubt a bigger firmware. But that can still fit on F411 due to how it’s compiled.

Guess it's a trade off. Betaflight's main goal is flight performance.

Having categories (race, freestyle, cinematic, long range) we could choose the optimization level for specific needs.

The cloud API already allows addition of multiple radio and telemetry protocols using custom defines as I think this is still an edge case.

[aQuaplug]

my case, adding multiple protocols with custom defines not working.
FC is MATEK F405CTR
I added like this : SERIALRX_FPORT SERIALRX_IBUS SERIALRX_SPEKTRUM.
none of them working. only radio protocol works that selected in drop down menu.
And even if custom defines works, I'm still think this is not familiar to newbies.
It's common, newbies learning FPV drone with second hand drone and replace receiver and fly.
And, how about BNF drones? Will manufacturer add all protocols on their BNF drones? I think no.
In BF 4.4, newbies should know about protocols and define protocol names with using specific sentence.
4.4 firmware update UI is really not considered about newbies.

[haslinghuis]

@blckmn After all the hard work to downsize the firmware should we consider a full build option for firmware size > 512KB ?

[blckmn]

@blckmn After all the hard work to downsize the firmware should we consider a full build option for firmware size > 512KB ?

This is available already for download from the releases itself. Anything with >512kb of flash space has everything compiled in. You will need a complete dump to make the target operational. You don't need cloud build. It is merely a convenience.

Also, the original author has missed one of the big features of cloud building, which is the defaults for a target without reserving flash space for and needing to "download and set" defaults.

This becomes apparent in 4.5.0.

NOTE: Some targets with external flash for booting can only be provisioned by cloud build or local build.

I think a better solution to the authors dislike of cloud build is to perhaps add in the ability to build locally within the configurator itself.

[Prajwal-Koirala]

This is an issue about improving the Betaflight cloud build options. The author dislikes the current cloud build system because it requires flashing new firmware if a user changes some hardware, like a receiver. They also find it confusing for new users. The author suggests several improvements, including an “Install All” option that would install the full firmware without needing the cloud. They also suggest allowing users to select multiple radio and telemetry protocols. Other users chime in with their own suggestions and experiences. The discussion is ongoing.

I hope this is helpful!

[hydra]

1. Have an Install All option next to the Core Only option. This will just install the full firmware in the old way. Much simpler if space is not an issue.

As a manufacturer of flight controllers, I fully agree with this, as I mentioned today in the discord #development channel.

Currently there are five ways to build the firmware:

1. Normal/Baseline build - includes majority of features, currently only available when building locally, at the time of writing I couldn't find a way to install a baseline build from the configurator. (make <target>)
2. Default cloud build from UI - removes many features, UI adds some default features.
3. Cloud build with user selections from UI - removes many features too.
4. Core build - minimal, but with all drivers. ('make CONFIG=${target} EXTRA_FLAGS="-DCORE_BUILD"`)
5. Cloud build from command line - removes many features, no additional features selected by default. ('make CONFIG=${target} EXTRA_FLAGS="-DCLOUD_BUILD"`).

(Some information above gleaned from this comment: https://github.com/betaflight/betaflight/blob/master/src/main/target/common_pre.h#L28-L36)

So given the above, it would be nice
a) for users to be able to install the 'baseline' build from the UI.
b) for manufacturers to be given clear guidance on what firmware to install the factory (i.e. add "install the baseline firmware, built with make <target>" to the documentation here: https://betaflight.com/docs/development/manufacturer/creating-an-unified-target or here: https://betaflight.com/docs/development/manufacturer/manufacturer-design-guidelines

As a manufacturer of non-budget hardware, I want the user's experience to be as simple as possible, without them getting confused when they see and select an option in the UI which isn't compiled into the firmware. Seeing an option in the UI, e.g. a radio or motor protocol, creates the expectation that it will work when the user selects it. If the firmware flashed in the factory is a cloud-build, with no options selected, or not the ones the user needs, then the user will be confused an this generates support overhead and dis-satisfaction with the product, sometimes even leading to unwanted chargebacks or refund requests.

As a user and manufacturer it would be nice if the UI showed the user exactly what features are going to be enabled, and what can be enabled, so the user knows what their build contains, secondly, and I know this is more difficult given the current code-base, it would be ideal if the UI could show the same information after the firmware has been created, installed and the user has connected to the FC, but likely that is out-of-scope of this issue, but very related.

[nerdCopter]

+1 for full-feature option (by any name -- full, baseline, ...). i mentioned in the past as well, specifically with vendors in mind. but have now become accustomed to cloud-building.
make all currently has no errors, so no reason not to.

[hydra]

+1 for full-feature option (by any name -- full, baseline, ...).

naming wise, as a name, 'factory', 'default' or 'baseline' works for me, 'full' does not as it implies everything is included when some code is not included unless specific defines are used. I'm also not 100% convinced by the 'core' name, as it doesn't convey it's meaning or intent well since it's not really meant for end-users to use, same goes for 'cloud', perhaps 'custom' would have been better there IMHO, but that's a different story.

[hydra]

Going back to the issue of users being confused by cloud builds, one major issue is that if they have a 'baseline'/'factory' firmware installed and try and add some 'non-baseline' feature, what happens is that they don't actually /add/ something, instead what happens is that they /remove/ loads of features and only add the additional feature they chose, so then all their other stuff that was working stops working until they figure out the exact features to add to the cloud build extra args input, which most users, in my experience, are not capable of doing, which leads to frustration and support requests.