-
Notifications
You must be signed in to change notification settings - Fork 196
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 First-Time Robot Setup Guide for Modern Gazebo #618
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: Aarav Gupta <[email protected]>
There was a problem hiding this 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 :-)
I'm wondering if we should possibly create new pages for the odometry, sensors (in addition to the SDF we've already discussed) and leave the current pages alone. That would let you start fresh (which would probably make this easier honestly than trying to shoe horn the changes in) and also let us on the Index page https://docs.nav2.org/setup_guides/index.html allow people to choose their adventure for GZ Classic or Modern GZ if they're still on Humble. Unfortunately Humble is supported until mid-2025, so there will still be alot of GZ Classic users around for awhile.
Basically what I'm thinking is to have 2 parallel table contents, one for GZ and another for GZ Classic. They'd both share the Transformations and URDF tutorials, but the Odometry, Sensors, and SDF would change by simulator -- and then the Footprint / Plugins would again be the same. That would also give us a recipe to work with for adding support for new simulators in the future
Then once that passes, we can just delete those changes to complete the migration. What do you think? I think that would make your life easier by being able to have more control on the flow of the guide page and code blocks instead of trying to make a 1:1 analog.
You are welcome! Thanks a lot for appreciating the effort.
Those ideas do sound good to me. I'm not sure what you mean by "2 parallel table contents." Could you go into a bit more detail about that/how to implement it? |
In the index page, we have a section called "Table of Contents" where we list those guide pages. Instead, we could have 2 separate sections, one for GZ Modern and another for GZ Classic where we link the appropriate versions of the pages. For some, they'll be the same page (URDF, Footprint), but for others they'll change (the ones you're working on). that would give us the tutorials for both up simultaneously and give you more free reign on the Modern GZ pages to break from the existing where things change more easily |
@SteveMacenski, I'm sorry for the delay on this! I will try my best to get this completed in a couple of days. |
Hey no worries at all - the holidays are for relaxing afterall :-) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice thinking in breaking out the robot localization page for both to share :-)
Largely speaking, this looks great! More or less small tweaks and a few things to shuffle around
About the SDF and URDF things: |
Ah I see, I think we should have the instructions be best practices: URDF for robot description, SDF for simulation, and we help them setup both. I don't think its wise to give folks too many options in first time setup (since they're new to all this and can't make a knowledgeable trade off yet), so I think its best to go with the best practices only. |
Co-authored-by: Steve Macenski <[email protected]> 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]>
Signed-off-by: Aarav Gupta <[email protected]>
Signed-off-by: Aarav Gupta <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks again! I did another run through and it looks like the only remaining thing is getting on the same page about URDF and SDF. Let me explain what I'm thinking
- URDF is the file used by the robot state publisher to setup the static frames and visualize the robot in rviz. This is used regardless of simulator, if we're using a simulator, or a physical robot. This must always be present.
- SDF is a specific file for Gazebo / GZ for describing the simulator environment or model - and wouldn't be used if using something like Isaac Sim or Open3D Engine
- We can setup URDFs that are SDF and Gazebo-free (see Update First-Time Robot Setup Guide for Modern Gazebo #618 (comment)), so we should as best practices from the GZ maintainers. We should also be recommending that to users. If they happen to do something else, that's on them, but this is the habit we should be steering people down -- both so that they can swap simulators later easily and so that if Gazebo stops supporting implicit URDF to SDF conversions, we don't need to update everything
- So with that in mind, the tutorial has a URDF section that sets up the basic static frames. We should build on that in the SDF tutorial, not replace it. We should have the SDF setup for what the SDF needs as the base-file going into the Odom/Sensor/other tutorials (installing SDF, if needed; creating the file next to the URDF; copying over whatever from the URDF is minimally required; adding in physics tags; etc)
- In the later tutorial steps, we should have the frames added to the URDF and the simulator items added into the SDF. But we should be having both, not expressing things as optional or having an option to do it one of two ways
bridge_config_path = os.path.join(pkg_share, 'config', 'bridge_config.yaml') | ||
Making a Gazebo world |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might recommend clipping this section and just putting in a setnence in the Build, Run, and Verification section that there's an empty world file in the navigation2_tutorials package that we'll be using (with a link) and copy it over. I don't think we need to put it inline since its a supporting piece
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to guide the reader a bit better as we also make a small change in the CMakeLists.txt.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK - I think this could be a dropdown then so that it can be opened if someone wants to look at it (otherwise point to a link to it). The CMake changes I 100% agree with!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to do this but it didn't work and gave the below error.
ERROR: Unknown directive type "dropdown".
.. dropdown:: Making a Gazebo world
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Amronos I think it has to be
.. dropdown::
Making a Gazebo world
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If that doesn't work, see: https://github.com/ros-navigation/docs.nav2.org/blob/master/development_guides/build_docs/index.rst
It uses .. rst-class:: content-collapse
and sections to create collapsing sections in https://docs.nav2.org/development_guides/build_docs/index.html#install
This is overall really good! Thanks so much for your efforts here so far 😄 |
@SteveMacenski thanks a lot for the reviews and sorry for being a bit difficult with the URDF and SDF things. I get your point now. I think this reasoning should also be available to the readers so is it ok if I add the following note in the URDF tutorial? "Note that you will also be setting up a SDF for simulation in Gazebo in the next tutorials, you don't need to and shouldn't make it if you are not going to use Gazebo. Also, I think the SDF tutorial should remain as it is (if you agree with the above note) with a message that some parts of it will seem redundant if the URDF tutorial has been followed. P.S. I would like if you had a look at this. |
Co-authored-by: Steve Macenski <[email protected]> Signed-off-by: Aarav Gupta <[email protected]>
Co-authored-by: Steve Macenski <[email protected]> Signed-off-by: Aarav Gupta <[email protected]>
Co-authored-by: Steve Macenski <[email protected]> Signed-off-by: Aarav Gupta <[email protected]>
I'd rewrite a little to: "Note that you will also be setting up a SDF for simulation in Gazebo in the next tutorials. URDF is used to set up the robot frames and describe the robot's structure for run-time use on hardware and possibly in simulation. SDF is a specific file for simulators, like Gazebo, that describes the simulator environment, model (including its frames and Gazebo-specific information), and appropriate plugins. The SDF that we will make is for Gazebo, but could be replaced with an appropriate SDF or other format file for Open3D Engine or Isaac Sim." Its a little more concise - and you actually can use SDF with other simulators, but most of the SDF we're setting up is with Gazebo sensor and odometry plugins, which are obviously going to be different from other simulators since they have their own plugins or capabilities. So I think this is important to reword for that distinction.
Isn't this still saying do 'this' or 'that' for SDF vs URDF? I think we want to steer down a single direction still
I get their point from the GZ project's perspective. Just use SDF, since you'll have the SDF for the simulator. But alot of people are now using other simulators as that technology has been massively improving over the years and there are new ones like MoJoCo, Isaac Sim, Open3D, Unity, etc. So, I think its more important than ever we still have URDF for the robot description that's not dependent on simulator (and used on actual hardware) and the SDF for simulation. |
Ok, thanks! Will make the necessary changes needed then in all the tutorials. |
Signed-off-by: Aarav Gupta <[email protected]>
Signed-off-by: Aarav Gupta <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very close to being done! Just a few small changes and I think this is good to go!
I think after you make these changes, its worth reading through it from start to end once more just to make sure there's no additional duplication or gap missing :-) Also make sure the files in ros-navigation/navigation2_tutorials#102 keep aligned with the tutorial's contents. I'm going to review that PR next
Co-authored-by: Steve Macenski <[email protected]> Signed-off-by: Aarav Gupta <[email protected]>
Co-authored-by: Steve Macenski <[email protected]> Signed-off-by: Aarav Gupta <[email protected]>
Signed-off-by: Aarav Gupta <[email protected]>
Signed-off-by: Aarav Gupta <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hopefully the last round!
|
||
To add a sensor input to the ``ekf_filter_node``, add the next number in the sequence to its base name (odom, imu, pose, twist). In our case, we have one ``nav_msgs/Odometry`` and one ``sensor_msgs/Imu`` as inputs to the filter, thus we use ``odom0`` and ``imu0``. We set the value of ``odom0`` to ``demo/odom``, which is the topic that publishes the ``nav_msgs/Odometry``. Similarly, we set the value of ``imu0`` to the topic that publishes ``sensor_msgs/Imu``, which is ``demo/imu``. | ||
|
||
To understand how ``robot_localization`` is configured and understand the reasoning behind the config have a look at `Configuring robot_localization <http://docs.ros.org/en/melodic/api/robot_localization/html/configuring_robot_localization.html>`_. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please readd the bit you deleted in a8c25ad, but I agree that we should point to those docs (and we do right below this in the seealso
). So I think this can/should be reverted
|
||
SDF is a file format for simulators, like Gazebo, that describes the simulator environment, models (including its links, connections, and physics simulator metadata), and appropriate plugins. The SDF that we will make is for modern Gazebo, but there are other simulator options such as Open3D Engine or Isaac Sim. | ||
|
||
We can also use our SDF with the robot_state_publisher using the following package: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can also use our SDF with the robot_state_publisher using the following package: | |
We can also use our SDF with the robot_state_publisher using the following package. You will see how to do this in the tutorial below. |
Writing the SDF | ||
================ | ||
|
||
For now the SDF will pretty much be a copy of the URDF code converted into SDFormat. Changes between the two descriptions will happen when we start adding various plugins and sensors in the next tutorials. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now the SDF will pretty much be a copy of the URDF code converted into SDFormat. Changes between the two descriptions will happen when we start adding various plugins and sensors in the next tutorials. | |
For now the SDF will pretty much be a copy of the URDF code converted into SDFormat. Changes between the two descriptions will happen when we start adding various plugins and sensors in the next tutorials. We also add in physical properties needed by the simulator such as the ineria, mass, and material. |
===================== | ||
|
||
Create a ``world`` directory in your package and add the following to a new file named ``my_world.sdf``: | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quick change to complete this page:
- Have the section as any other section
- Leave the "Create a world directory..." like any other
- The world file is shown below but can also be found on the tutorial at .
- Move the
.. rst-class:: content-collapse
to just surrent the code block (also that code block might technically need to be listed as a new section for the title of the collapsed block, but that's just a quirk of the RST and not how its read by users) - The stuff below the collapsed code block should not be in the collapsed block ("We also have to add the..." bit)
Fixes #608.