Skip to content
This repository has been archived by the owner on Nov 26, 2020. It is now read-only.

RaiSim for Gazebo #40

Open
kumpakri opened this issue Feb 3, 2020 · 12 comments
Open

RaiSim for Gazebo #40

kumpakri opened this issue Feb 3, 2020 · 12 comments
Labels
enhancement New feature or request

Comments

@kumpakri
Copy link

kumpakri commented Feb 3, 2020

Hello,

I am using Gazebo simulator for some robot software development and right now I'm stucked on a problem where ODE just seems to be too imprecise to even be used for my case. When I simulate a wheeled robot it slips on the ground no matter how I set the friction, I cannot get it to be realistic. I saw your comparison of common physics engines where the RaiSim rated quite high. I do have certain doubts about the setting of the other physics engines in the tests but knowing that the ODE really does not perform very well for my usecase, I'm wondering if maybe your engine would solve my problems.

I am only a user when it comes to simulation software so I do not understand how it works (and I do not understand the physics you describe in your paper). But say I want to plug the RaiSim physics into Gazebo instead of ODE. Can you describe how would I go about it or point me to any materials that do describe this? When I look into the repos I see no hint on how to do it.

@jhwangbo
Copy link
Contributor

jhwangbo commented Feb 3, 2020

Hi Kumpakri,

Unfortunately, this is not trivial. I also don't know how to because I am new to Gazebo.
It is on my TODO list but it is not urgent. I will work on it sometime this year.

@jhwangbo jhwangbo added the enhancement New feature or request label Feb 3, 2020
@jacknlliu
Copy link

@jhwangbo Please consider here Ignition Gazebo.

In Ignition Physics, physics engines are integrated as plugins, so any engine can be integrated without changing the core source code, as it was the case in Gazebo.

@jhwangbo
Copy link
Contributor

@jacknlliu I'll definitely check this out when I implement it! Thx

@diegoferigo
Copy link

diegoferigo commented Feb 23, 2020

Hi @jhwangbo, please keep also me in the loop / get in touch if you intend getting closer to Ignition Gazebo. I already have a code skeleton to wrap RaiSim as a Ignition Plugin and quite a lot of experience with the sw architecture of the new Gazebo simulator. If you recall, when some time ago I opened #24, I was in the middle of early experiments to use RaiSim inside the new Gazebo. Then, I had other priorities and I had to put that side project on pause.

@jhwangbo
Copy link
Contributor

Hi @diegoferigo, can you share the code?

@diegoferigo
Copy link

diegoferigo commented Feb 23, 2020

@jhwangbo I have a private repository with some code, I can provide you access to have a look if you're interested. Don't expect a working implementation, but it could be a great start :)

Note that at the moment, the upstream version of Ignition Gazebo only supports DART and the name of the shared library of the physics plugin is hardcoded in their Physics system (some fresh information here). People are currently working on a new bullet3 backend, but the PR is proceeding quite slowly.

In a project I'm developing, I keep a vendored version of the Physics system (the piece of code that hardcodes the plugin name) and in robotology/gym-ignition#83 you can see an initial implementation that prevents using hardcoded names. Though, it's few months old and that PR should be rebased.

I also suggest to have a look to ign-physics#119 that shows a very contained example.

@diegoferigo
Copy link

diegoferigo commented Feb 25, 2020

Related upstream PR ignitionrobotics/ign-gazebo#541.

@diegoferigo
Copy link

diegoferigo commented Mar 5, 2020

Another interesting PR ignitionrobotics/ign-physics#123.

@diegoferigo
Copy link

I'm not sure how much you are following upstream's Gazebo efforts, but there have been recently major steps forward towards a more generic and lighter physics plugins implementation:

Here's a minimal example with the (unmerged, yet) bullet implementation. In light of the benchmark recently done in costashatz/raisim_dart_benchmarks, I'm looking forward even more to a possible integration in Ignition Gazebo. cc @chapulina

@jhwangbo
Copy link
Contributor

Frankly, I haven't spent much time on it yet. My focus was on 1. Win/Mac support 2. More unit tests 3. Better unity visualizer 4. performance improvement (~10%) 5. More articulated system methods.

BTW, Dart and RaiSim use different articulation algorithms. It's not surprising to see such a gap in performance.

I will experiment with the ignition-gazebo next week.

Before I spend so much time, can you comment on the benefits of the ignition gazebo? why is it better than the original one? and it is popular? how many people use it?

@diegoferigo
Copy link

diegoferigo commented Jun 16, 2020

My focus was on 1. Win/Mac support 2. More unit tests 3. Better unity visualizer 4. performance improvement (~10%) 5. More articulated system methods.

Cool, good to know. 10% of boost is a great achievement considering the good current performance.

I will experiment with the ignition-gazebo next week.

My comment's purpose was providing a quick update to the status and link resources together :)

In my opinion creating a Ignition Physics plugin is not a task that could be done in one day. There's some documentation and much could be adapted from other existing backends, but the development requires some domain knowledge, in particular:

  • How the SDF are parsed and stored in memory as Entities and Components, done by SdfEntityCreator (URDFs are converted to SDF by gazebo)
  • How these Entities and Components are re-assembled as SDF and passed to the physics plugin by the Physics system
  • When the physics plugin will receive these chunks, raisim should create link-by-link and joint-by-joint the model (maybe possible after Add APIs to create sequentially an ArticulatedSystem #24)
  • Finally, the physics plugin should implement the Features as described in the documentation and return the right data type to Gazebo.

All the rest is handled by gazebo: GUI, rendering (with multiple backends, ogre ogre2 and partially optix), distributed simulations, and so on.

Before I spend so much time, can you comment on the benefits of the ignition gazebo? why is it better than the original one? and it is popular? how many people use it?

Probably the developers can explain it better than me, but the old Gazebo Classic will receive only bug fixing starting from the current v11. Ignition Gazebo is currently used for the new Darpa SubT challenge and as far as I understood most of the recent development effort went into this new version. The new simulator has been rewritten in favour of modularity and abstraction (physics and rendering engines are plugins that can be switched very easily).

Personal opinion: Gazebo Classic has a huge user base that will progressively migrate towards Ignition Gazebo. In my lab we embraced it since a while now, and I'm personally very happy about it. Especially for RL experiments, the new simulator-as-a-library feature (similar to raisim, btw) is great. Before, due to its previous architecture, it was impossible to integrate Gazebo Classic in such big and distributed experiments.

@chapulina
Copy link

creating a Ignition Physics plugin is not a task that could be done in one day.

I agree that there's a learning curve. I'd also mention that ideally someone integrating a new engine through ign-physics wouldn't need to know anything about ign-gazebo's internals. This tutorial has some helpful info.

the old Gazebo Classic will receive only bug fixing starting from the current v11

Correct

Gazebo Classic has a huge user base that will progressively migrate towards Ignition Gazebo.

That's the hope 🤞

can you comment on the benefits of the ignition gazebo?

I think @diegoferigo made a great case for it. For those interested in plugging in their own physics engine, it's by all means better than Gazebo-classic.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants