feat: top-handle collision model + recovery joint limits + publish_current - #11
Open
DanielyanNora wants to merge 2 commits into
Open
DanielyanNora wants to merge 2 commits into
DanielyanNora wants to merge 2 commits into
Conversation
…rrent For recovery deployment on the real robot (which has the top-mounted carry handles): - Top-handle collision (handle_F/handle_R, collision-only exact-CAD meshes on the Base link) so the model matches the handle-trained recovery policy. - Recovery joint limits: velocity_lim 10 -> 18.849 rad/s, effort_lim 50 -> 30 N*m. velocity_lim=10 is a placeholder the Gazebo/ros2_control stack OBEYS, clamping joints below the ~15.25 rad/s recovery needs. 18.849/30 match the trained model. - publish_current xacro arg -> robstride_ros2_control macro (default false). Cross-repo: publish_current pass-through needs the robstride_hardware macro param (Ayg branch hardware-deployment). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…or-curve params - mujoco/ayg.xml: joint armature 0.02 (the certified mujoco_val value; 0 was the documented snap/fail sim2sim gap) + handle_F/handle_R collision meshes, matching the cf_lab validation model (full-diff verified physically identical). - ayg.xacro + ayg_sim_ros2_control.xacro: motor_curve / motor_curve_tau / motor_curve_tau_knee args -> MujocoSystem hardware params (RS-03 four-quadrant torque-speed curve; tau follows the controller clamp: 20/16 cert, 30/30 HW plan).
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
1 participant
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.
What
For fall-recovery deployment on the real robot (which has the top-mounted carry handles):
handle_F/handle_Rcollision-only exact-CAD meshes on theBaselink (no visual/inertial; mass already in Base), so the model matches the handle-trained recovery
policy. The robot physically has these handles and they change belly-up recovery contact.
velocity_lim10 → 18.849 rad/s,effort_lim50 → 30 N·m,matching the trained model (AYG_CFG).
velocity_lim=10is a placeholder the Gazebo/ros2_controlstack obeys, clamping below the ~15 rad/s recovery needs.
publish_currentxacro arg →robstride_ros2_controlmacro (default false), for per-jointq-axis current logging on
/motor_states.Cross-repo dependency
The
publish_currentpass-through requires therobstride_hardwaremacro to accept apublish_currentparam — that lives in Ayg branchhardware-deploymentand should land beforethis is relied on at integration.
Validation
Sim-validated in the new
ros/layout: model builds,xacroexpands with the handle collisions,Gazebo Gate-3 recovery pipeline recovers belly-up→upright. Not yet hardware-validated (gate ladder
4→8 pending).
Test plan
xacro urdf/ayg.xacro sim:=false use_csp:=falseexpands (handle_F/R collisions present)publish_currentmacro param before integration