Open-sourcing the MuJoCo physics simulator for robotics
deepmind.com
deepmind.com
When I was learning Deep RL, I edged on what could be done through OpenAI gym, or self-made environments, I decided to begin working with MuJoCo.
But for an undergrad student from a developing country, the fees were extremely high.
So, I just didn't go forward with Deep RL much. I dabbled for a while and tried using PyBullet. Did not go that well.
Also thought about creating custom environments in Unity and then apply Deep RL in there. But it took too much effort.
Creating a complex enough environment and getting used to it were, in themselves- full projects that took long term commitment.
As a result, I did not learn much Deep RL to be able to apply it to complex, real-world-like scenarios.
I think that it is going to change.
I am excited about books, blogs, and videos that are going to be created as MuJoCo is open-sourced and available for free.
I, personally, will get back into Deep RL the next opportunity I get.
So, I did not have a uni mail address.
That was required.
On the other hand, Brax is developed by Google and is written using Jax (which DeepMind loves and uses extensively).
Why would DeepMind have been concerned that people were switching to Brax?
Isn't that the whole idea behind college? Spend money to learn cool stuff?
Sure. But who argued for that? They merely pointed out that they considered this particular physics engine worth spending money on. The implication was that because money is typically limited for a college student, the software must really be worthwhile. The implication was not "LOL, you must be broke and can't afford good software."
TLDR: personal non commercial 500$/year for usage on up to 3 computers personal commercial 2000$/year
I used to use a rattleback as a test back when I was working on accurate but slow physics engines in the 1990s. That's an ellipsoid cut by a plane that isn't axis-aligned. You spin it, and it spins, stops, rocks, and spins a bit in the other direction. Very similar to what they're doing.
The key to this is a multi-point contact model. If your contacts are single points, the frictional effects are wrong. It's not that hard to do this. I held a patent on that (#6,067,096), and there was a product called Falling Bodies, the first ragdoll system that really worked.
It was just too early in the 1990s. 100 MIPS was not enough.
Each have their own strengths, there is no "definitive" physics engine. Bullet is probably the most generalist engine, but it suffers a bit because of this approach (it's split between the old 2.0 C++ API vs. the new PyBullet API with vastly different functionalities)
Super impressed with the data structures (and documentation) they've already released.
Are there any books describing how to implement this kind of physics engine?
But on the other hand, for many problems, the gain in training time using PhysX is just so massive (2 or 3 orders of magnitude), that you can then train with a much more aggressive sim2real policy to mitigate that to some extent, or even spend time debugging manually and still ending up more productive.
The docs are definitely a strong point, nicely written and presented.
1: https://mujoco.readthedocs.io/en/latest/computation.html# , about 1/4 of the way down the page