Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update sam_bot_description for the new Gazebo #102

Open
wants to merge 9 commits into
base: rolling
Choose a base branch
from

Conversation

Amronos
Copy link

@Amronos Amronos commented Dec 10, 2024

Fixes ros-navigation/docs.nav2.org#608.

  • Update DiffDrive plugin for the new Gazebo.
  • Update IMU for the new Gazebo.
  • Update to use stamped twist messages for /demo/cmd_vel
  • Make SDF description
  • Finish and test sensor description and bridges
  • Make necessary changes to navigation and test it.

Copy link
Member

@SteveMacenski SteveMacenski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First of all, a huge, huge thank you for taking this on, it really helps alot to get some support in updating documentation :-)

sam_bot_description/config/bridge_config.yaml Show resolved Hide resolved
ros_type_name: "rosgraph_msgs/msg/Clock"
gz_type_name: "gz.msgs.Clock"
direction: GZ_TO_ROS

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need TF as well?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the ekf node should publish the transforms instead of Gazebo. I have documented this here.

Copy link
Member

@SteveMacenski SteveMacenski Dec 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess i haven't typically used EKF when using gazebo, I just let the diff drive plugin provide TF as pretty close to ground truth. I'm open to both ways, but just what I've usually done and makes it a little easier for folks to understand on a tutorial level

Also, it might help in the issues you've mentioned by just removing EKF from the situation 😉

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess having EKF would be a good idea for a real robot, but not really for Gazebo. I can add the bridge and then maybe make launching EKF an argument of the launch file. Then I can edit the tutorials accordingly.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess having EKF would be a good idea for a real robot, but not really for Gazebo. I can add the bridge and then maybe make launching EKF an argument of the launch file. Then I can edit the tutorials accordingly.

Done in 7c1ddc8.

@SteveMacenski
Copy link
Member

SteveMacenski commented Dec 17, 2024

Let me know when you want me to take a look again! I don't want to nitpick mid-update unless you want me to :-)

@Amronos
Copy link
Author

Amronos commented Dec 18, 2024

Let me know when you want me to take a look again! I don't want to nitpick mid-update unless you want me to :-)

Go ahead with it, everything should be good to go.

There is just one problem I have been trying to solve for a while now though:
On running:

ros2 run teleop_twist_keyboard teleop_twist_keyboard --ros-args -p stamped:=true --remap cmd_vel:=/demo/cmd_vel

It does not seem like the robot moves with every command (happens more on publishing a value on angular z) even though on running gz topic -et /demo/cmd_vel I can see the messages are getting received by Gazebo. Also, the odom->base_link transform doesn't appear to be changing in the same way in ROS & Gazebo. This occurs with and without the ekf_node (when not using it I bridge the transforms from Gazebo to ROS).

Update nav2_params.yaml

Update to use stamped twist messages

Add SDF description

Signed-off-by: Aarav Gupta <[email protected]>
Signed-off-by: Aarav Gupta <[email protected]>
Signed-off-by: Aarav Gupta <[email protected]>
Signed-off-by: Aarav Gupta <[email protected]>
@Amronos
Copy link
Author

Amronos commented Dec 20, 2024

There is just one problem I have been trying to solve for a while now though: On running:

ros2 run teleop_twist_keyboard teleop_twist_keyboard --ros-args -p stamped:=true --remap cmd_vel:=/demo/cmd_vel

It does not seem like the robot moves with every command (happens more on publishing a value on angular z) even though on running gz topic -et /demo/cmd_vel I can see the messages are getting received by Gazebo. Also, the odom->base_link transform doesn't appear to be changing in the same way in ROS & Gazebo. This occurs with and without the ekf_node (when not using it I bridge the transforms from Gazebo to ROS).

@SteveMacenski this should be fixed with the latest commit. The only problem is that when the imu topic is included for the ekf_node, the robot rotates more on the z-axis than it should. I am not sure if this is a problem of Gazebo or robot_localization.

@Amronos Amronos marked this pull request as ready for review December 20, 2024 17:08
sam_bot_description/config/bridge_config.yaml Outdated Show resolved Hide resolved
ros_type_name: "rosgraph_msgs/msg/Clock"
gz_type_name: "gz.msgs.Clock"
direction: GZ_TO_ROS

Copy link
Member

@SteveMacenski SteveMacenski Dec 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess i haven't typically used EKF when using gazebo, I just let the diff drive plugin provide TF as pretty close to ground truth. I'm open to both ways, but just what I've usually done and makes it a little easier for folks to understand on a tutorial level

Also, it might help in the issues you've mentioned by just removing EKF from the situation 😉

Copy link
Member

@SteveMacenski SteveMacenski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little unclear as to why there are <gazebo> tags and sensor plugin definitions in the URDF. I think the URDF is just the non-GZ things and the SDF contains the gazebo and sensor plugins that attach to frames defined in the URDF. I think things like the IMU gazebo stuff should be removed to the SDF and only the IMU frame is created / linked in the URDF (and similarly for other sensors, diff drive plugin, joint state publisher, etc).

I don't think there needs to be / should be duplication. I'm not familiar with that much duplication in SDF and URDF

sam_bot_description/launch/display.launch.py Outdated Show resolved Hide resolved
sam_bot_description/launch/display.launch.py Outdated Show resolved Hide resolved
DeclareLaunchArgument(name='model', default_value=default_model_path, description='Absolute path to robot urdf file'),
DeclareLaunchArgument(name='rvizconfig', default_value=default_rviz_config_path, description='Absolute path to rviz config file'),
DeclareLaunchArgument(name='use_sim_time', default_value='True', description='Flag to enable use_sim_time'),
ExecuteProcess(cmd=['gz', 'sim', '-g'], output='screen'),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a ros_gz launch file for this which includes some other useful things we should use instead

Edit: how does this play with the GZServer() you already created?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have a look at this: https://gazebosim.org/docs/harmonic/ros2_overview/#composition
Also, I think the launch file you are mentioning is this. This launch file doesn't let you use composition and that's why I implemented what's done in this launch file.
The ExecuteProcess(cmd=['gz', 'sim', '-g'], output='screen'), simply lets you start a Gazebo GUI, without the server which we are already launching before.

@mikeferguson
Copy link

I'm a little unclear as to why there are <gazebo> tags and sensor plugin definitions in the URDF

I haven't looked at this PR at all - but I will note that for a long time there have been gazebo tags in many URDFs - the URDF parser silently ignores them. The SDF has usually been more the description of the scene, not the robot. I'm not sure what the "best" practices are for new gazebo.

@SteveMacenski
Copy link
Member

SteveMacenski commented Dec 21, 2024

For example, in nav2_minimal_turtlebot_simulation contributors at OSRF put together a URDF that has no gazebo / sim things in it and a separate SDF that contains the Gazebo bits to decouple them

I think this model can/should be followed. I think this was always the 'best practice' even in ROS 1, but confusion / convenience / hacking led to them kind of bleeding together since the gazebo tags don't hurt anything for non-gazebo use as you mention

If we're going to bleed them together, then I think its probably better to just use a singular file then and save the duplication maintenance work. You can actually see that we did that for the TB4 portions of that repository that were modified and pared down from the iRobot / Clearpath stacks. But I think its possible / reasonably easy, especially using those TB3 files as a baseline :-)

@mikeferguson
Copy link

In the turtlebot example, isn't the SRDF got a lot of duplicated things from the URDF (for instance, just the base_link definition is basically fully duplicated - if one gets updated but not the other, things get out of date)? The workflow I've seen in the past (again, ROS 1) was to create your base URDF, with no gazebo tags and then use xacro to include that and add the gazebo stuff in a more gazebo-specific urdf.

I guess I'm assuming here that ROS 2 / new gazebo still has the tools to load a URDF/xacro directly (basically, it creates the SDF under the hood) - if that's gone, it's a moot point and users have to maintain separate SDF & URDF files.

@SteveMacenski
Copy link
Member

SteveMacenski commented Dec 21, 2024

I think the intention is to long-term stop allowing or promoting users to use URDFs in this way due to the limiting nature of the URDF format w.r.t. SDF. With this said, I forget entirely where I heard that so I could just be making that up 😆

@mikeferguson
Copy link

I think the intention is to long-term stop allowing or promoting users to use URDFs in this way due to the limiting nature of the URDF format w.r.t. SDF. With this said, I forget entirely where I heard that so I could just be making that up 😆

I mean, this is the team that built their own ROS-alternative for Gazebo internal comms, so... I feel like Gazebo keeps getting harder and harder to use, at the same time so many alternatives keep coming on the market. /rant

Signed-off-by: Aarav Gupta <[email protected]>
Signed-off-by: Aarav Gupta <[email protected]>
Signed-off-by: Aarav Gupta <[email protected]>
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.

Update sam_bot + first time setup guide for Modern Gazebo
3 participants