Skip to content

Add bitbots cargo#944

Draft
Flova wants to merge 10 commits into
mainfrom
feature/bitbots_cargo
Draft

Add bitbots cargo#944
Flova wants to merge 10 commits into
mainfrom
feature/bitbots_cargo

Conversation

@Flova

@Flova Flova commented Jun 30, 2026

Copy link
Copy Markdown
Member

Summary

Add a way of integrating cargo with colcon.

Proposed changes

As a demonstration the extrinsic calibration node and the global planning library are build using this way. This should also fix the issue @ayin21 had on her laptop.

Related issues

Checklist

  • Run pixi run build
  • Write documentation
  • Test on your machine
  • Test on the robot
  • Create issues for future work
  • Triage this PR and label it

Flova added 2 commits June 30, 2026 02:53
… rename, Rust migration

- Add bitbots_cargo cmake package with r2r_cargo(), cargo_pyo3_extension(), cargo_binary() helpers
- Set up root Cargo workspace covering bitbots_extrinsic_calibration and bitbots_global_planner
- Rename bitbots_rust_nav → bitbots_global_planner; remove stale pixi-build files
- Bring PolygonObstacle/AnyObstacle and goal obstacle support into bitbots_global_planner
- Migrate bitbots_extrinsic_calibration from C++ to Rust using bitbots_cargo
- Add rust and clang to pixi deps; route cargo target into build/ via CARGO_TARGET_DIR activation env
- Add cargo fmt pre-commit hook and rust-analyzer vscode settings
- Update bitbots_path_planning import to use new bitbots_global_planner module name
Comment thread src/bitbots_misc/bitbots_cargo/cmake/bitbots_cargo.cmake.in Outdated

@MegaIng MegaIng left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't build for me; It appears that a global llvm and/or clang version is being found instead which is missing some symbols.

@github-project-automation github-project-automation Bot moved this from 🆕 New to 🏗 In progress in Software Jun 30, 2026
@jaagut

jaagut commented Jul 3, 2026

Copy link
Copy Markdown
Member

Apparently:
r2r generates Rust bindings from the ROS C headers on the target machine. On the robot, bindgen is producing rosidl_message_type_support_t as opaque (_address) instead of exposing .data.
I fixed it by vendoring a tiny patched r2r_msg_gen 0.9.5 and overriding it in Cargo.toml. The patch reads the ROS type-support data pointer via the stable C struct prefix instead of relying on bindgen exposing that field. Cargo.lock now resolves r2r_msg_gen to the local patch under patches/r2r_msg_gen-0.9.5.

@jaagut

jaagut commented Jul 3, 2026

Copy link
Copy Markdown
Member

I don't like the vendoring solution in the latest commit. Feel free to revert this.

@jaagut jaagut marked this pull request as draft July 3, 2026 23:05
@Flova

Flova commented Jul 3, 2026

Copy link
Copy Markdown
Member Author

Do we know why the robot is different in this regard?

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

Labels

None yet

Projects

Status: 🏗 In progress

Development

Successfully merging this pull request may close these issues.

3 participants