| ROS Resources: ROS Homepage | Media and Trademarks | Documentation | ROS Index | How to Get Help | Q&A Help Site | Discussion Forum | Service Status |
We actually made a choice for gazebo for one of our projects because
(If we made a wrong assumption here I’m happy to learn!).
Thank you the feedback. That’s very helpful.
Hi @robusto,
It is unfortunate that you are having problems. I think we’ve all been there the difficult and specific thing we want do doesn’t work the first time we try. As a developer it is extremely frustrating when we receive negative feedback, in the wrong channel, with insufficient information to rectify the situation. There are –multiple – places – where – we ask developers – to submit their questions so we can help. Moreover, we frequently release new versions of the software to address issues as they come up and as libraries evolve. When you use a software version that is no longer supported (like Gazebo 7) you don’t take advantage off all the changes that we’ve made to address usability and performance issues. I would also add that judging software by what was released over five years ago is a bit disingenuous.
While you think this project may be simple, the reality is that what we’re doing complex work with multiple software teams spread across the globe who do this work on a voluntary basis. The only way these remote teams can help is if you provide them with timely and very detailed reports on what you did and what went wrong. Often it is the case that what is wrong is that people are trying to shim together versions of software that weren’t meant to work together (e.g. A five year old version of Gazebo with a brand new version of OpenCV and Python). That’s why we need detailed information about your system and setup. To minimize the potential permutations of system configurations, and help standardize the platform, we also make recommendations about what versions of each library to use.
If you want the best experience I would suggest you start with the combination of software that is recommended and is currently under long term support (roughly Ubuntu 20.04, Gazebo 11, ROS Noetic, OpenCV 4.2).
This topic is really interesting to me in the context of someone who’s been a casual ROS tool-user until recently.
I’ve always felt a strong pull and have encountered quite a bit of explicit community advice to install the oldest supported release of ROS, maybe even an older, unsupported release. Porting several packages like someones_PhD_map_algorithm was not something I could understand enough to consider.
Drivers and robot description assets for very popular robots are still listed as only officially supported on Kinetic (I know that is not at all the full story there, because I spend a lot of time browsing the universal_robots GitHub issues, but at first glance at various docs it feels like Noetic isn’t even on the roadmap).
I finally have the time and mandate to learn ROS properly. Browsing ROS source trees in lieu of documentation is becoming more productive now that I’m a full-time C++ dev. And now that I’m feeling more sure-footed in the internal structure of the ROS project I’m building, the idea of starting on the newest supported distro and fixing incompatibilities if they exist doesn’t feel nearly as heavy as it used to.
But I wonder if the community here has some suggestions for resources to help newer and less-knowledgeable users feel confident that the latest release really is best for a limited-scope project? Is there a nice high-level “Only Kinetic? Don’t Panic!” tutorial out there about how to grok early on if it’s really just going to be a few XML and YAML edits to get a critical package up to speed with the latest release?
I would like to echo that concern. We’ve also been trying to update to something newer than kinetic, but the fact that many very popular packages are still unsupported makes it really difficult.
If that were the case, I would assume the maintainers would have done it already, so I tend to assume that’s not the case (unless the package is not maintained).
Not my experience. They don’t do it until they migrate themselves or when people ask them to. Where I notice that latter has less priority but usually they do it.
And of course there is:
rosrun roscompile noetic_migration 
That actually brings back (not only) my rouge idea of guerilla releasing 
Once I met a package that worked in Melodic without a single change, but the maintainers were totally unresponsive. So I thought about doing the Melodic release from an alternative release repo - I haven’t come up with any technical problem on the way (except ROS maintainers noticing that a non-maintainer of the package is doing the release)… But there were ethical concers which won in this case and stopped me from doing that However, there is now a process for taking over abandoned packages - if you’re willing to maintain them in the future: Releasing repositories form "other" people - #11 by k-okada .
I can confirm that upgrading to the latest version can work miracles.
Simulations are worth it’s weight in gold, especially now when me and my students have to work from home. However, we faced quite a few common issues:
I spent the last week with a weird issue that the robot assembly would move when starting the simulation after attaching a Lidar to the first link in the URDF. Moreover the endeffector flipped even though the joint was supposed to be fixed. I could solve it by using ODE instead of Bullet or Bullet + a seemingly random combination of preserve fixed joint tags in the URDF. However our use-case grasps seem less stable when using ODE so this is no satisfying solution either. I might open an issue if I ever find the cause or a minimal setup to reproduce the glitching.
Today I tried one more thing: using noetic & Gazebo 11.3 instead of melodic & Gazebo 9 and my issues magically disappeared. Now the troublesome part: it is an ongoing project and all of our partners agreed on using ROS melodic (and I am really grateful that all of them agreed). And of course the compatibility of our hardware is another headache.
My current solution is using devcontainers (vscode + Docker) to build a melodic + Gazebo 11.3 container and I am quite pleased with the result. I can use the hardware drivers which have melodic support and run the latest less buggy simulation software.
I don’t know if it’s because it’s been a long time, but Gazebo has a lot of bugs now!
quote
One of the great things about ROS is that there are many great simulators. Have you tried the Unity open source LGSVL Simulator? It works with ROS, ROS 2 and Autoware.Auto autonomous driving. It also great for autonomous racing, F1TENTH, evGrandPrix Autonomous, SAE Formula Student Driverless, et al.
fyi Robotec.AI created a high performance ROS2-Unity3D CycloneDDS plugin that can be used with Unity or LGSVL Sim. Volvo Trucks already uses it.
https://robotec.ai/case/simulation-module-ros2-unity3d/
Can you give some more info perhaps a link on the last paragraph, mainly how did you setup the launch files to allow resetting the simulations without restarting Gazebo. Right now if something goes wrong and the robot starts flying or something in the environment is messed up I have to kill all the processes and start over which wastes a lot of time but I don’t really know any other way to do it.
Ctrl+Shift+R in the GUI, or gazebo_ros also exposes a reset service. What I don’t understand is why Ignition Gazebo doesn’t have support for resets from the very beginning… But Gazebo Classic does.
Also, make sure you actually installed gazebo from the packages.osrfoundation.org repository and not from packages.ros.org (or even worse from Ubuntu repos). This duality (or “triality”) of the sources where you can get Gazebo is something really confusing in my view. On Ubuntu, call apt-cache policy gazebo9 to find out where is your Gazebo installed from.
Hi @Ammaar_Solkar. I have posted my model training python file as a Github Gist. This python will run your launch file using Ros Launch API. It will use the entity spawn/delete service to reset sim for each episode.
I am also successfully using the Gazebo reset-sim service call (same as Ctrl-R in gazebo IIRC) which is the quickest way to restart but in order to do this I had to track down a lot of issues in other nodes that didn’t like time jumping back to 0. Gazebo elects to be become “father time” and the reset does go to t=0…so prepare to put your gdb hat on. 
Maybe you can go half-way with a reset of robot pose and your own node’s state but not a system-wide reset.
Thanks a lot for sharing. I too tried the gazebo reset service which peci1 suggested and it works well. Doesn’t hurt to know different ways to do something your and file contains loads of things which are new for me so more things to the list of things to learn.