We have a custom build of Ardupilot / Ardusub created by using the following two commands:
./waf configure --board navigator
./waf sub
Out of the build process there is a file in the ardupilot/build/navigator/bin/ardusub folder.
How do I take that file (or what files do I need) and load the custom build into the Blue OS environment?
Hi @bfraz -
Welcome to the forums, and congrats on compiling your own ArduSub!
To program the system to use this with the Navigator, simply navigate to the Autopilot Firmware page in BlueOS, and chose “upload firmware file” and then install firmware. It should flash and run if everything is ok!
I tried this. On the BlueOS >> Autopilot Firmware page, it says “Successfully installed new firmware”, but it states on the same page that the Vehicle Type is unknown, and under Autopilot parameters, none of the Ardupilot parameters are shown. Also, under the notifications, the Autopilot Manager reports “AUTOPILOT_VEHICLE_TYPE_FETCH_FAIL”. So I am not sure how to proceed at this point.
Any help would be appreciated.
Another point of information. The Ardupilot modifications do build and run fine when running Ardupilot in SITL testing. And the only modifications to the baseline Ardusub configuration in Ardupilot that were made were to the manual mode behavior.
Hi @bfraz -
Sorry for the issue. To make sure it isn’t something about your build process or the custom code you added, please try compiling and flashing an unmodified version of ArduSub. If that works as expected, and parameters load after flashing, then the issue is somewhere in your custom code, and if it doesn’t work as expected, the build tool chain or the version you’re building based off of could be incorrect.
Can you share more detail about what types of modifications you made to manual mode behavior?
I actually had already started down the path of validating with a stable build. I figured a couple of things out. First off, I am used to standard software versioning control where most of the changes on a branch are brought / merged into the master. That apparently isn’t the case with Ardupilot / Ardusub.
My development computer is an ARM based computer and I was building in Ubuntu 24.04 (so already 1.5 year old version of Ubuntu). Well, Ubuntu 24.04 and later has Python 3.12 or later. This is where the problem comes in. The Ardupilot repo master branch builds fine with 3.12. And that is what I had built and tested with using SITL. However, it turns out that the WAF submodule in the latest ArduSub branches / versions is older than what is in the master branch. You must use a build environment currently that has Python 3.11 or earlier for the ArduSub releases to build. This is a head scratcher to me why nobody has pulled in the latest WAF submodule into the ArduSub branches in the last 6 months. My only solution was to go back to Ubuntu 22.04 (so an almost 3 year old operating system) so I could build the latest Ardusub stable release (4.5.3).
All my changes were innocuous, and it turns out that all my troubles were related to the branches not being maintained well to keep up with current operating system build environments.
Hi @bfraz, welcome to the Blue Robotics forums 
ArduPilot development (e.g. the introduction of new features) primarily occurs by contributors branching from master, making a change, then merging the change in to master via a pull request. The code contribution documentation goes into more details.
The official ArduPilot repository also includes several maintenance branches for tracking a specific release (e.g. Sub-4.5), which occasionally include back-ports of features and fixes from master, or version-specific fixes that aren’t relevant to master, which can then be turned into a patch release of that version (e.g. ArduSub-4.5.3 → ArduSub-4.5.4) after some degree of testing has occurred. It’s possible these branches are what you’re confused about.
If you find new features in a release branch that aren’t included in master then I’d recommend raising an Issue about it, because that’s not how features are intended to be developed.
A build system update is generally not suitable for patching into an existing release. The other firmware variants are currently up to 4.7, so the next minor (non-patch) update of ArduSub will involve creating a Sub-4.7 branch from master, which will include the new build system automatically.
Changing your operating system is definitely not required to be able to change Python version - there are many tools for managing installed Python versions, including pyenv and (the new kid on the block) uv.
Granted, ArduPilot’s default/recommended prerequisites management approach (using their install scripts) does assume the system Python version is used (rather than ensuring the correct version is installed), which is understandably problematic when that version doesn’t match the version ArduPilot expects for the branch/release being built (e.g. if you want to build off a stable version for some personal features).
If it’s relevant, @williangalvani has previously created some instructions for building ArduPilot for Navigator from inside BlueOS, which may simplify the setup process / reduce the prerequisite management requirements.
If what you said is true, then why didn’t my build off of master (with either the default build or the exact same changes I applied to 4.5.3) work on the Navigator? What you stated effectively says that the underlying Ardusub code on master should be up-to-date enough that if you do the default build on master of Ardusub, then it should work on BlueOS on the Navigator. I come to this conclusion because you affirmed through what you said that all significant changes on the different Ardusub branches are merged back to master.
What am I missing?
@bfraz Master should be fine, I’ve been working on it a lot lately.
An important thing to keep in mind is the compiler version. Versions of gcc higher than 10.2 will not work on our bullseye images (all prior to 1.4).
Also, on master can you do ./waf sub --upload-blueos http://192.168.2.2 so it uploads after building.
Which GCC compiler are you talking about? I assume iyou talking about the ARM version for the Pi / Raspbian Bullseye release (the gcc armhf compiler)?
The reason I ask is that the Ubuntu 24.04 ARM64 host environment has the aarch64 gcc version 14.0 but comes with the armhf gcc compiler version 12.
Ubuntu 22.04 ARM64 host environment also comes armhf gcc compiler version 12. The armhf compiler seems to cross compile the Ardupilot navigator configuration just fine on the 22.04 host environment based on the fact that the output executable ran just fine when transferred to the Navigator (in the Blue OS hosting environment).
Yes. The issue is that the binaries built with newer gcc try to use a newer glibc version that is not available on our older images, which causes ardusub to fail to start even though BlueOS thinks it started, which seemed to be the issue you had initially.
What is the current situation? Were you able to get a custom build to run?
Here is the mix of successes and failures tried so far: