Skip to content

fix(pixi): source dds_env.sh from activation, not only the launch wrappers - #71

Merged
Arcod7 merged 1 commit into
devfrom
aes/fix-pixi-dds
Sep 8, 2026
Merged

fix(pixi): source dds_env.sh from activation, not only the launch wrappers#71
Arcod7 merged 1 commit into
devfrom
aes/fix-pixi-dds

Conversation

@Arcod7

@Arcod7 Arcod7 commented Sep 8, 2026

Copy link
Copy Markdown
Contributor

OP#227
Pixi activation didn't source scripts/dds_env.sh like the launch wrappers do, so ros2 CLI commands from a dev shell used subnet discovery and couldn't see a stack running with localhost-only discovery.

…ppers

scripts/pixi_lucy_launch.sh sources scripts/dds_env.sh before launching, so
the stack runs with ROS_AUTOMATIC_DISCOVERY_RANGE=LOCALHOST and a CycloneDDS
config pinned to 127.0.0.1 with multicast off. Pixi activation did not, so a
`pixi shell` or `pixi run` got Jazzy's default subnet discovery instead.

Two consequences:

- ros2 CLI commands from a dev shell could not discover a running stack. Same
  RMW on both sides, but incompatible discovery config, so the participants
  never found each other: `ros2 control list_controllers` hangs on "waiting
  for service /controller_manager/list_controllers" against a healthy stack.
- Subnet discovery merges anyone else's Lucy on the network into the graph --
  two robot_state_publishers and two controller_managers driving the same
  joints, which is precisely what dds_env.sh exists to prevent.

Added to both activation blocks: target.linux overrides target.unix rather
than merging with it.

Sourcing the script twice is a no-op: _lucy_cyclone_uri returns early when
CYCLONEDDS_URI is already set, and _lucy_dds_range re-exports the same values.
@Arcod7 Arcod7 self-assigned this Sep 8, 2026
@Arcod7
Arcod7 merged commit bbf914e into dev Sep 8, 2026
4 checks passed
@Arcod7
Arcod7 deleted the aes/fix-pixi-dds branch September 8, 2026 17:49
Arcod7 added a commit that referenced this pull request Sep 9, 2026
* hotfix(config): change branch from 'dev' to 'master' for repos

Signed-off-by: Charles Madjeri <80175305+charlesmadjeri@users.noreply.github.com>

* fix(install): verbose install, quit keys on menu (#69)

* fix(install): verbose install, quit keys on menu

* fix: remove quit test

* fix(pixi): source dds_env.sh from activation, not only the launch wrappers (#71)

scripts/pixi_lucy_launch.sh sources scripts/dds_env.sh before launching, so
the stack runs with ROS_AUTOMATIC_DISCOVERY_RANGE=LOCALHOST and a CycloneDDS
config pinned to 127.0.0.1 with multicast off. Pixi activation did not, so a
`pixi shell` or `pixi run` got Jazzy's default subnet discovery instead.

Two consequences:

- ros2 CLI commands from a dev shell could not discover a running stack. Same
  RMW on both sides, but incompatible discovery config, so the participants
  never found each other: `ros2 control list_controllers` hangs on "waiting
  for service /controller_manager/list_controllers" against a healthy stack.
- Subnet discovery merges anyone else's Lucy on the network into the graph --
  two robot_state_publishers and two controller_managers driving the same
  joints, which is precisely what dds_env.sh exists to prevent.

Added to both activation blocks: target.linux overrides target.unix rather
than merging with it.

Sourcing the script twice is a no-op: _lucy_cyclone_uri returns early when
CYCLONEDDS_URI is already set, and _lucy_dds_range re-exports the same values.

* Migrating to v0.2.1

---------

Signed-off-by: Charles Madjeri <80175305+charlesmadjeri@users.noreply.github.com>
Co-authored-by: Maël RABOT <mael.rabot@epitech.eu>
Co-authored-by: Charles Madjeri <80175305+charlesmadjeri@users.noreply.github.com>
Co-authored-by: Antoine ESMAN <antoine.esman@epitech.eu>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
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.

3 participants