Repository navigation
Drive the performers in CI, not by watching Gazebo - #1
Merged
Merged
Conversation
Every claim the mission makes is a claim about rmf_action_node, which CI does not build: it links plansys2_executor, and the image carries no planner. So they were checked by launching Gazebo and reading the console, which is a human observation dressed as a test. Neither end of the bridge has to be real for the claims to be testable. The executor is a handshake on actions_hub; a fleet adapter is a subscriber to task_api_requests and a websocket client. drive_mission.py is both, and asserts the five things the README promises: a movement action goes to the robot its agent is bound to, at the waypoint the zones table names; a sensing action carries what the fleet reported; with the fleet silent it carries the reading taken at its own site and not another site's; a private speech act reaches its listener's channel alone, carrying what the speaker sensed; and an agent bound to no robot fails the action instead of letting RMF pick. The new job builds eplansys at v0.2.0 to get the performers, pinned for the same reason eplansys pins Aletheia: a red tick should say which repository broke. What is left to the demo is what needs a floor --- robots crossing it, traffic management routing them, and a policy from the planner choosing these actions in this order.
The mission job builds cascade_lifecycle from source, and with it its tests, which construct an rclcpp::experimental::executors::EventsExecutor that Humble's rclcpp does not carry. The build failed there, before anything of this repository was reached. This job runs a mission rather than a test suite, so it has no use for any of the tests it was building. Taking the dependency's branch to the one named after the distribution would have been the other way, and it is the wrong one: plansys2_executor links a target that branch predates.
HanielUlises
force-pushed
the
ci/mission-end-to-end
branch
from
September 22, 2026 18:28
e1dd799 to
cfa2f80
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Every claim the mission makes is a claim about
rmf_action_node, which CI does not build — it linksplansys2_executor, and the image carries no planner. So they were checked by launching Gazebo and reading the console.Neither end of the bridge has to be real for the claims to be testable. The executor is a handshake on
actions_hub; a fleet adapter is a subscriber totask_api_requestsand a websocket client.drive_mission.pyis both, and asserts:The new
mission end to endjob builds eplansys atv0.2.0to get the performers, pinned for the same reason eplansys pins Aletheia: a red tick should say which repository broke.Left to the demo: robots crossing a floor, RMF's traffic management routing them, and a policy from the planner choosing these actions in this order.