Same as what the title says. But if that’s too much work, then uploading the features file from the custom firmware into the custom firmware builder website would select all the features in the file so you don;t have to manually check/uncheck everything again.
Thanks
3 Likes
That’s a very useful features We would start using it in our workflow as soon as it is implemented 
I think this PR is similar: Add custom defines support by rob-clarke · Pull Request #218 · ArduPilot/CustomBuild · GitHub.
That’s exactly my idea for the custom build website … i mean it’s working very good but if i spent 30 minutes to check all the components and i click wrong the refresh button , all is lost…
Also i really would like it for having a import componenets feature to pass to other people…
I share this discuss on the group of the custom build on discord
2 Likes
https://custom-beta.ardupilot.org is running a new UI. Please try and feel free to give feedback. It is in final stages of polishing and it would take some time before we roll it out on the main server.
4 Likes
What is the config.yml file that can be uploaded?
My opinion about the UI is that there is some value in seeing everything at once like currently possible.
After each build, you would see a button to “Save config”, that gives you a file which you can use to rebuild again.
I totally agree. But we have to make trade-offs to give more features vs the simplicity.
The existing UI was flawed in many senses, on each dropdown selection, it would select the defaults for next dropdowns automatically which is essentially wasted work.
Also, I have tried to keep in mind to show most information to users on each step, for example you can always see which vehicle, version, board you have selected in previous steps.
The features, I mean they were all visible at once I agree, but human eyes can focus only at one thing, to find a feature there, someone would most likely have to do a ctrl+f rather than trying to find it by going through all of them, so I have put a search bar on the top. The category list is still there on the left. But I will surely see, if we could do a bigger feature selection modal somehow.
Saw now. I think it’s better to upload the extra_hwdef.dat though, right? That way, you can select another board/version and get to use the same features as you used before. If the new board/firmware doesn’t support one of the features, then that can be disregarded, or better warn the user about that particular feature.
Also, you may have this in mind already. But Light mode UI is appreciated. Thanks
Extra hwdef is too limiting in many ways. We need a file which contains feature ids as per custom build server api.
Btw, you can upload any config on the feature selection step and it will try loading those features on your selected vehicle-version-board combination. But there are no guarantees there, features might differ based on that cobination. We do a best-effort to select them.
Sure.
2 Likes
Can’t build.log be used instead? Maybe add a few more lines for missing info. That way, an additional optionally downloadable file is not necessary.
IMO using anything other than a properly structured config file will be a hack and become a maintenance burden in future.
I have noted your point about it being “optionally” downloadable, I will try to bundle it with the build artifacts so that it is always included.
2 Likes