ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

Why are ROS and Ignition/Gazebo diverging (or not converging)?

I’m preparing a presentation for novel ROS programmers, and during preparation of the presentation, I just started asking myself why doesn’t ROS integrate with Ignition at all?

If I get it right, both ROS and Ignition are developed by Open Robotics (and community!), and Ignition is a set of tools for roboticists. So why is it completely omitted in ROS?

I can see a lot of parallel implementations of basically the same stuff (Transport, Math, CMake, Rendering, Plugin, Msgs, Gui). Because the developers of both are more or less “under one roof”, I just don’t get it…

It would be super-nice to have e.f. ign-math used by basic ROS tools and readily available for anyone working in ROS. I can’t count how many times I’ve seen people converting quaternions to RPY angles by snippets of math they don’t understand… With Ignition, it’d be so much simpler…

4 Likes

A related question on ROS Answers: Why do we use Rviz when we have Gazebo ? (specifically about Gazebo vs RViz, but fits the issue raised here).

There is quite a bit of support for lin alg and the kind of conversions you mention in TF2, so I’m not sure Ignition math would be needed here, but that doesn’t change the validity of your question.

Being in need of a math-and-only-math library that I can potentially certify, I’ve had my eye on ignition-math for a little while now. It would be great to see it become the standard math-and-only-math library for ROS as well as Gazebo, and then for tf to use it.

Off-topic, but: tf2 (and tf before it) does not mandate using any math library per se. AFAIU the idea is to provide packages that support to-from conversion for specific libraries (potentially using type masquerading).

Compare tf2_eigen, tf2_bullet, etc.

Perhaps a tf2_ignition_math could be created, if that would be desirable, but I don’t necessarily see a need to standardise on ignition.

Even more off-topic: ignition math appears to contain concepts and functionality that many other libraries already support (Eigen, Bullet, RBDL, DART, KDL, MRPT and others). I fully understand the convenience of using your own library (in terms of control and development), but ignition math seems like “just-another-math-library”.

That’s already been asked: Ignition Math to TF? .

I did not know that.

From the point of view of certification, such a thing can be beneficial if it has just the stuff you need. I haven’t looked at if IM is that, though, and libraries like Eigen have the benefit of being extremely well used to balance out having more than you might need.

And I even replied!

Alas my head is too full of now to hold memories of 2017. :wink: Thanks for the pointer!

@peci1: apologies for side-tracking this thread.

I’d also be interested in knowing why there is this divide while there appear to be some opportunities for re-use and sharing.

There are a few reasons to the perception that ROS is not converging with Ignition. The reasons on the top of my head are:

  1. ROS and Ignition have different needs. For example, most of the time simulation is run self-contained on a single PC, and the features contained in DDS are not needed in this type of setup. Instead, we opted for the performance and open-source nature of ZeroMQ and Protobuf. This particular example may not be the best because Ignition Transport was need back in 2014, before ROS2 & DDS was a viable option.

  2. Many ROS packages are not available in the official distribution of an OS, which prevents Ignition from making use of these packages. This is not always the case, for example URDF is in Ubuntu.

  3. Diversity can be a good thing. As an example, we have made use of both ROS and Ignition transport in the same application in order to control/limit communication capabilities. This comes up in simulation competitions. For better or worse, there are also people and organizations who do not want to use specific features of ROS or Ignition.

  4. It’s hard to overcome history. ROS has a way to doing things, and Gazebo has a way of doing things. Gaining the momentum to overcome the past is non-trivial. There is probably some term from economics that succinctly captures this. The sunk cost fallacy is close, but not quite right.

That being said, there have been discussions about using some Ignition software within ROS. Rendering could be used by rviz, which would allow us to maintain one code base that supplies 3D rendering capabilities to Gazebo, Rviz, and others. So far, progress has mostly petered out due to lack of resources (time and people) and urgency.

1 Like

Perhaps a mild form of NIH?

Happens everywhere.

I’d maybe just call it “momentum” - there’s a lot of code towards each of their more specific goals, and wrangling that into a common use case is a lot of work without immediate reward so there’s not investment in that direction.

Thanks for your insights, Nate.

I’m not going to claim this is even close to the majority use case for simulators overall, but in autonomous driving, running distributed simulations in the cloud is significantly more important than running on a single PC. Of course, this probably isn’t a common use of Gazebo, but I imagine that the growing fleets of mobile warehouse robots, autonomous forklifts, etc. are going to want something similar.

This isn’t a reason to use ROS or even DDS, because in this use case determinism is more important than real-time simulation. In fact I’d go as far as to say that real-time simulation is completely unnecessary and a hindrance. That means that using ZeroMQ or any other protocol is perfectly valid.

Personally I think distributed simulation is quite common for learning applications, and will become even more common. Better to have it on the radar.