Release V1.0.0 - #88
Draft
Mael-RABOT wants to merge 38 commits into
Draft
Conversation
Hotfix: Demo updates
…on-link Mra/hotfix documentation link
Signed-off-by: Charles Madjeri <80175305+charlesmadjeri@users.noreply.github.com>
…scroll Signed-off-by: Charles Madjeri <80175305+charlesmadjeri@users.noreply.github.com>
Signed-off-by: Charles Madjeri <80175305+charlesmadjeri@users.noreply.github.com>
Signed-off-by: Charles Madjeri <80175305+charlesmadjeri@users.noreply.github.com>
Signed-off-by: Charles Madjeri <80175305+charlesmadjeri@users.noreply.github.com>
feat(lcp): live sensor graphs, robot configuration route, and shell UI fixes
Signed-off-by: Charles Madjeri <80175305+charlesmadjeri@users.noreply.github.com>
…r-distro-change evol(readme): update ubuntu version refs for Jazzy match
…fault-port changing default lcp port to uncommon 4004
Signed-off-by: Charles Madjeri <80175305+charlesmadjeri@users.noreply.github.com>
feat: adding button for resetting every actuator to its rest stage
fix(ci): commit yarn.lock for immutable installs on PRs
* fix(ci): commit yarn.lock for immutable installs on PRs
Signed-off-by: Charles Madjeri <80175305+charlesmadjeri@users.noreply.github.com>
* Surface rosbridge service errors instead of hanging until timeout
roslib's Service.callService drops the failure message when no failedCallback
is passed:
if (message.result !== undefined && message.result === false) {
if (typeof failedCallback === 'function') { failedCallback(message.values); }
} // else: nothing. The promise never settles.
So when rosbridge answered "Service /config/get does not exist" in milliseconds
— because config_pipeline_node had died at startup — the config request hung
for the full 45s SERVICE_TIMEOUT_MS and then surfaced as
Error Loading Robot Configuration
Service /config/get timed out after 45000ms
blaming a timeout that never happened and hiding the actual cause. The same
omission left the client count silently stuck whenever the registry node was
not advertising.
Pass a failedCallback in both, so the real message arrives immediately and the
45s bound goes back to meaning what it says: no answer at all.
Mesh.handler, ControlMode.handler and ros.service already pass one.
---------
Signed-off-by: Charles Madjeri <80175305+charlesmadjeri@users.noreply.github.com>
Co-authored-by: Charles Madjeri <80175305+charlesmadjeri@users.noreply.github.com>
Four lines to say one thing.
…ndpoint and can't have it back
…idge-endpoint feat: explaining rosbridge purpose and fixing case where we deleted e…
The 3D viewer reported "No URDF received on /robot_description" against a healthy robot_state_publisher, and neither waiting nor Retry recovered it. rosbridge fixes a subscription's durability when the subscription is created, from the publishers present at that instant, and its subscribe op accepts no QoS field -- only type, throttle_rate, fragment_size, queue_length and compression. A client that subscribes before robot_state_publisher exists therefore gets a VOLATILE subscription and can never receive the single latched message published later, however long it waits. That window is real on the non-simulated path. rosbridge accepts clients about 0.2s into the bringup; robot_state_publisher is started by lucy_control_supervisor at about 4.7s, after it has waited for the generated ros2_control xacro, checked for a foreign controller_manager and expanded the URDF. In Gazebo the node is launch-managed and up at 0.7s, so the window barely exists there. Read the URDF from robot_state_publisher's `robot_description` parameter instead. A parameter read has no durability to get wrong: once the node is up the call returns the URDF, and until then it fails visibly and is retried with backoff rather than leaving a subscription that is silently dead for the life of the page. The topic stays subscribed so a republished URDF still reaches the viewer without another call. Verified against a real bringup: the call through rosbridge returns the full URDF as a PARAMETER_STRING value once robot_state_publisher has propagated into rosbridge's graph, which takes a few seconds and is what the retry covers.
fix: adding a text explaining purpose of blue and green tooltips
…n-activation fix: activate reset all button only when control is on
…table-sticky fix: made configuration table header visible when scrolling
…take-control evol: adding a modal to confirm we want to take the control from anot…
…-header fix: made the control page header sticky while scrolling down
Mael-RABOT
marked this pull request as draft
September 4, 2026 10:31
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
4 participants
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.
OP#215