Add a Gazebo plugin to better match driver interfaces#51
Draft
nickswalker wants to merge 5 commits intohello-robot:dev/noeticfrom
Draft
Add a Gazebo plugin to better match driver interfaces#51nickswalker wants to merge 5 commits intohello-robot:dev/noeticfrom
nickswalker wants to merge 5 commits intohello-robot:dev/noeticfrom
Conversation
Add gazebo_ros_control PID gains Tuned manually to make movement via the teleop interface behave well Wheels still unspecified because they cause the robot to collapse Use effort joint interface for the gripper so that gripper contacts are well simulated
Removes most of the instability in simulation behavior when lifting objects
Makes tipping behavior in simulation more plausible I assume that the mass of an assembled base is at least this heavy, given that the robot is around 50lbs total
This better matches the physical robot, though this interface doesn't handle the virtual joints that the robot uses
This plug in is a modified version of the original ros_control plugin and that plugin's "default hardware plugin" (confusing, I know) The modified model plugin provides a /runstop service to match the real robot's driver, and hooks this up to ros_controls existing estop implementation The modified hardware plugin provides the mode switching services that the real robot has (mocked for now) and publishes joint states that include the virtual joints used by the real platform. The wrist extension joint behaves the same as the driver implementation. The rotation and translation joints aren't hooked up yet, and it may be difficult to provide their functionality without forking the actual "follow_joint_trajectory" implementation, which expects only joints that are present in the URDF Mirror the real platform setup and use a joint state publisher node to republish the subset of joints that match the URDF
Contributor
|
Thank you for opening this PR @nickswalker. I'm just starting to read through it, but it sounds like these custom plugins drastically reduce the sim/real difference between Stretch and its gazebo simulation. This is a great win! As I continue to understand your changes here, I'll take a look at what it would take to get trajectory interface support for the mobile base joints into simulation. Overall, this is fantastic work and I'm excited to get this merged in. @vatanaksoytezer and I will begin testing out these two PRs. Thanks again! |
nickswalker
added a commit
to hcrlab/hcrl_gazebo
that referenced
this pull request
Nov 17, 2021
Add Gazebo plugin This plug in is a modified version of the original ros_control plugin and that plugin's "default hardware plugin" (confusing, I know) The modified model plugin provides a /runstop service to match the real robot's driver, and hooks this up to ros_controls existing estop implementation The modified hardware plugin provides the mode switching services that the real robot has (mocked for now) and publishes joint states that include the virtual joints used by the real platform. The wrist extension joint behaves the same as the driver implementation. The rotation and translation joints aren't hooked up yet, and it may be difficult to provide their functionality without forking the actual "follow_joint_trajectory" implementation, which expects only joints that are present in the URDF Mirror the real platform setup and use a joint state publisher node to republish the subset of joints that match the URDF Add controller shim that mimics the fake joints used by the real robot Use effort control for all arm joints Increase mass of base Makes tipping behavior in simulation more plausible I assume that the mass of an assembled base is at least this heavy, given that the robot is around 50lbs total Use single controller for the simulation This better matches the physical robot, though this interface doesn't handle the virtual joints that the robot uses This commit tracks the changes proposed in hello-robot/stretch_ros#51
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
2 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.
This PR assumes the changes of #40.
This plug in is a modified version of the original ros_control plugin and that plugin's "default hardware plugin" (confusing, I know)
/runstopservice to match the real robot's driver, and hooks this up to ros_control's existing estop implementationstretch_controller_rawto indicate that it behaves differently than the real robot's.I have been using this plugin, along with a shim on top of the
stretch_controller_rawinterface to run code that expects the physical robot API in the simulator. There's likely a better implementation strategy, but I think a lot of the alternatives would require custom controller implementations which would only be used in simulation. I'm opening this PR because the changes improve the sim/real correspondence considerably for basic uses, but there are still some subtleties around the modes to fill in.