Generating a custom firmware with default features enabled

So i need to create a new firmware using the custom firmware builder here:

After selecting the firmware version and board, some features are already selected as “default” but that is not really the full list. Things such as crossfire, rpm and gps are included in the Mission Planner firmware, but are not selected as “default” in the builder.

I expected that the selected options would match what is offered in the default firmware, letting the user remove them, and add non default features, but that is not the case.

Also, i haven’t managed to find a list of features included in the Mission Planner firmware (matching the same list as the custom builder options).

So how do i create the exact same firmware as Mission Planner, using the custom builder?

EDIT: Solution bellow:

1 Like

You should only select the ones you need. The preselected ones are the minimal set.

This way you get to know what the minimal set is. If all the defaults would be selected, how would the users know what is the minimal set? Besides that, each board has a different set of default features. There are over 90 boards!

Users usually know what they use, and need. If you do not use a rangefinder, just do not select it.

Defaults can be easily polled from the same config files as Mission Planner. Yes there are over 90 boards, but Mission Planner has all those so it means nothing.

There can be 2 buttons, one to select the minimum flyable feature set, and another for the default feature set in Mission Planner.

Most users will probably want to add a feature or remove a feature, it is not very user friendly to just remove all features and show the minimum, with no way to know what the defaults are in the Mission Planner firmware…

Pull requests are welcome :slight_smile:

Off topic, still didn’t answer my question on how to get the same firmware as Mission Planner using the custom builder :wink:

You need to take a look at the options enabled in the source code itself. If it was easy, it would just be a button on the GUI.

You have a link to the source code build configs of mission planner? So i can enable those features?

You keep repeating “Mission Planner”. This has nothing to do with mission planner. This is the default build of arducopter. Mission planner simply allows you to download and flash the firmware.

The firmware can be build locally on your computer according to the build instructions on the wiki. If you do not change any parameters you will get the default features.

Yes, the source code is at GitHub - ArduPilot/ardupilot: ArduPlane, ArduCopter, ArduRover, ArduSub source It is just around 300000 lines of code.

I can find that myself. I need the part where it selects just the firmware features, not the rest.

You don’t seem to want to help, i can wait for someone else if you don’t mind.

The firmware selection features are spread in the source code. There is not a single file. I do not mean to be rude, those are just the facts. I want to help, you do not seam to want to learn.

I shouldn’t have to go through a bunch of hoops to get the same firmware file as is default don’t you think? It’s not about learning or not.

I don’t see the point of the custom builder if it can’t output the same default file as most people are using.

The only hoop you need to jump to get the default firmware features for a specific board is to compile it yourself locally.

The custom builder is for people that want custom FW features, hence non-default features and can not be bothered to install the required compiler toolchain locally.

Here is an example on how a feature gets configured in a file I wrote:

This design pattern is spread in the code.

This is not the simple answer you wanted, but it is the way it works now… pull requests are welcome.

I only need to use the custom builder because the Sport flight mode was removed. I wouldn’t touch the builder with a 10 foot pole if i didn’t need to.

That is why i want all the default features, just adding back Sport mode. But it seems like an impossible task. The custom builder is not at all user friendly.

So tested a couple of builds using the custom builder, and didn’t quite get the exact firmware size as my local build but close enough.

So to answer my own question, to get the equivalent features as the default builds you basically enable all features in the custom build, apart from the VTOL

For my local build i got this output:

Target          Text (B)  Data (B)  BSS (B)  Total Flash Used (B)  Free Flash (B)
---------------------------------------------------------------------------------
bin/arducopter   1791284      3188   259172               1794472          171592

All features using the custom builder without VTOL:

Target          Text (B)  Data (B)  BSS (B)  Total Flash Used (B)  Free Flash (B)
---------------------------------------------------------------------------------
bin/arducopter   1788288      3188   259168               1791476          174592

All features using the custom builder with VTOL:

Target          Text (B)  Data (B)  BSS (B)  Total Flash Used (B)  Free Flash (B)
---------------------------------------------------------------------------------
bin/arducopter   1792276      3188   259172               1795464          170600

Not exact but close enough, the local build might be using only some of the VTOL features but not all.

Anyway. It shouldn’t be this hard. There should be a warning at the top of the custom builder “to generate a default ardupilot firmware select ALL features”, in case someone else needs to just add 1 feature to defaults.

Honestly, that doesn’t seem very difficult at all. And you likely just enabled a whole bunch of features needlessly.

I have 2MB flash so it doesn’t really matter. I rather have the full feature set of stable copter, than remove some features and end up with issues.

WARNING to all other users: enabling all features will not get default features build for your board. Most 2M boards do not have solo gimbal enabled for example. None has VTOL features.
Smaller 1M boards have a different, reduced default feature set. And it depends on both memory and processor.

This is not as simple as @Johnex wants it to be.

The dev team goes to great lengths to test that a reduced feature set works as it should. For flight certification purposes no dead-code (non-reachable code) is allowed. So certified vehicles actually use a reduced feature set when they comply with the regulations.

2 Likes

First of all, a user that downloads the default firmware for their board will not have the reduced feature set, they will get almost all the features that fit for their board. So we aren’t talking about that. Notice that the topic is about default features.

If you also want to get into certification and other things it is not as simple as @amilcarlucas wants it to be. There are many levels of certification, and there are differences between dead code and deactivated code which is allowed depending on what certification you want. You can look at DO-178 for example.

Also, if you look at the code, you will find libraries use the HAL_MINIMIZE_FEATURES definition. This lets each board definition remove features that would not fit on 1M boards. You can see here:

Enabling all features should not override this. If it does then the custom builder is flawed. From the output i do get hints that this is the case.

You seam to advocate that dead code is OK. ArduPilot allows you to turn that dead code into deactivated code. That is a good thing, and in-line with DO-178. There is no level of certification that does not frown upon dead code. Or do you know one?

The custom build server currently allows users to get as little dead code as possible, by starting with as much deactivated code as possible.

The concept is not flawed, the user can override the defaults, the user is, after all king!
If we implemented it the other way around, users would start complaining why some features would get automatically disabled.

I do like to see that you are passionate about this and that you do partially understand the problem now.

Well since the custom builder has been encouraged to use all over the forum, i expected it to behave in the same way as building locally, so just an “easier” option for the end user. But the behavior is not the same, so i’m sure a lot of users will be confused by that. It’s not as easy as just going from using the default firmware to using the custom builder.

IMO the builder should start with all features enabled (as building locally does), and not force override the HAL_MINIMIZE_FEATURES. Each board and vehicle type can disable their defaults Then have a button “force features if disabled” or something like this, to let the user enable the features even though they are disabled by default, due to flash constraints or other. Then there could be a minimum flyable config for those that want that.

I will continue building locally, i didn’t see the point of the custom builder. Others that want to use it could do some pull requests to improve it, making it more user friendly :wink: