Skip to content

Mavros in its own build stage#241

Open
amarburg wants to merge 6 commits intoRobotic-Decision-Making-Lab:mainfrom
apl-ocean-engineering:dev/mavros_in_build_stage
Open

Mavros in its own build stage#241
amarburg wants to merge 6 commits intoRobotic-Decision-Making-Lab:mainfrom
apl-ocean-engineering:dev/mavros_in_build_stage

Conversation

@amarburg
Copy link
Copy Markdown
Collaborator

@amarburg amarburg commented Aug 14, 2024

Changes Made

This is an experimental PR which isolates the Mavros/Mavlink build in its own (cacheable) build stage. It builds on #220.

Mavros is built in a standalone workspace (~/ws_mavros) in a build stage. This workspace is then copied into the ci stage. Subsequent builds in ws_blue then extend this mavros workspace rather than the base ROS environment.

Besides increasing complexity of the build process, the major negative is that more functionality is pulled into the ci stage, specifically:

  1. The non-root "ubuntu" user is created earlier than before so ws_mavros can be built and owned by the non-root user.
  2. The built ws_mavros workspace is copied into the "ci" stage as a dependency of blue (given mavros would normally would be installed by rosdep anyway if a binary was available)
  3. The rosdep dependencies of mavros are installed.

(on further reflection, these aren't strictly required, depending on how pedantic we want to be about what's in/out of the ci stage:

  1. Since more noble-based images include the ubuntu user anyway, this isn't a big deal.
  2. The workspace could be copied in the robot stage. Appropriate --ignore-keys would need to be added to the call to rosdep in ci
  3. This would then need to happen in robot.
    )

I've also committed my docker-bake.hcl to simplify repeatability. I have not updated the Github action to use buildx bake. This conflicts with #266, and if/when that's merged it will require some manual rebasing in this branch.

Cross-compile performance

All builds on an i7-11800H, running docker buildx bake mavros --no-cache with appropriate platform -- only one platform at a time. Package time are reported by colcon, "total" is the value reported by docker buildx for the colcon build step.

"amd64 bare metal" is a with rolling installed directly onto the same laptop

Raspberry Pis are on a clean distribution of Bookworm 64bit "Lite" (no GUI), with no active or passive cooling on the board (so thermal throttling may be a factor)

Package amd64 bare metal amd64 arm64 (qemu) arm64 on Pi 5 arm64 on Pi4 4GB (-j2)
mavlink 1.95s 2.14s 3min 46s 7.44s 31.1s
libmavconn 8.73s 9.00s 2min 14s 34.6s 3min 20s
mavros_msgs 1min 25s 1min 27s 2h 56min 31s 5min 21s 26min 28s
mavros 1min 15s 1min 17s 16min 59s 7min 45s 35min 55s
mavros_extras 1min 1s 1min 2s 13min 46s 6min 27s 25min 25s
Total 3min 42s 3min 46s 3h 27min 25s 19min 33s 1h 27min 49s

Yikes.

n.b. The Pi4 would OOM (even with 8GB of swap), so the job was run with -j2

Testing

Please provide a clear and concise description of the testing performed.

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants