Skip to content

Ci core bringup test - #56

Merged
Arcod7 merged 1 commit into
feat-pixifrom
aes/ci-core-bringup-test
Sep 3, 2026
Merged

Ci core bringup test#56
Arcod7 merged 1 commit into
feat-pixifrom
aes/ci-core-bringup-test

Conversation

@Arcod7

@Arcod7 Arcod7 commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

OP#207

@Arcod7 Arcod7 self-assigned this Sep 2, 2026
@Arcod7 Arcod7 changed the title Aes/ci core bringup test Ci core bringup test Sep 2, 2026
@Arcod7
Arcod7 force-pushed the aes/ci-core-bringup-test branch 2 times, most recently from 7265c83 to b5b7734 Compare September 3, 2026 08:19
ci_tmux_launcher_smoke.sh answers "did the processes start", and both of the
bugs behind the blank 3D viewer passed it cleanly. A stack can have every
process alive and still be useless to the control panel:

  * Another machine on the network running Lucy puts a second
    robot_state_publisher on the graph. Both latch /robot_description, viewers
    take whichever they discover, and meshes then resolve against the other
    host -- file://C:\Users\...\stand.dae reaching a Linux RViz. The same
    collision puts a second controller_manager on the joints.
  * rosbridge fixes a subscription's durability when the subscription is made,
    from the publishers present at that instant. Subscribe before
    robot_state_publisher exists and it is VOLATILE, so the latched URDF is
    never delivered and the viewer waits on a topic already published.

So assert on the graph rather than the process table: exactly one publisher of
/robot_description, that it is transient_local, that its meshes resolve to
files inside this workspace, that every loaded controller reaches active, and
that the URDF reaches a websocket client through rosbridge the way the panel
fetches it.

Core is launched through _tmux_new_pixi_window rather than ros2 directly, so
the test covers the path production uses. The Pixi task sources dds_env.sh for
the same reason the launcher's prelude does: a probe on a wider graph than the
stack itself can see reports publishers no node in the stack could reach.

Controller activation is polled rather than sampled. The spawners are staggered
behind the entity reaching Gazebo, so a single sample after a fixed wait
returns a different controller set run to run -- 4 active, 3 active and 0
loaded across three runs of the same command while this was being written.

Teardown runs in a finally and dumps the core pane when a check fails, since
the session is about to go away.
@Arcod7
Arcod7 force-pushed the aes/ci-core-bringup-test branch from b5b7734 to 47d7125 Compare September 3, 2026 08:34
@Arcod7
Arcod7 merged commit c487672 into feat-pixi Sep 3, 2026
@Arcod7
Arcod7 deleted the aes/ci-core-bringup-test branch September 3, 2026 09:41
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