I guess RigidBodySim is the closest alternative in the current julia ecosystem to the Bullet Physic SDK. How do they compare? Would you rather recommend to write an interface to the Bullet Physics SDK or extend the collection of examples for RigidBodySim? I am particularly interested in Reinforcement Learning applications, where Bullet Physics has already many examples.
RigidBodySim and RigidBodyDynamics (Iām the main author) currently have pretty limited support for contact: only point-to-halfspace contacts are supported, with a penalty-based contact model. I have plans for extending that to more contact primitives including general convex polytopes (using GitHub - JuliaRobotics/EnhancedGJK.jl: GJK signed distance algorithm for convex bodies in Julia), but itās currently just not a priority for me.
Iām not aware of the existence of any Julia Bullet bindings.
Edit: sorry, somehow I thought you were specifically asking about contact (I guess because thatās Bulletās forte). What kind of systems are you interested in?
I am interested in having a few control problems with continuous action spaces as benchmarks for reinforcement learning methods. Since problems based on MuJoCo are currently popular in RL I guess it would be nice to have support for contact, but it would be nice to have also other benchmark problems for RL.
OK. I see you have a pendulum and a cart-pole model as examples; something like that is very easy to set up. RigidBodyDynamics can load URDFs, so you could just take the cart-pole URDF from bullet and load it as follows:
urdf = download("https://raw.githubusercontent.com/bulletphysics/bullet3/0e1dce41eab75fd210ec73a52adbf249710c8edf/data/cartpole.urdf", "cartpole.urdf")
using RigidBodyDynamics
cartpole = parse_urdf(Float64, urdf)
which results in
Spanning tree:
Vertex: world (root)
Vertex: slideBar, Edge: slideBar_to_world
Vertex: cart, Edge: slider_to_cart
Vertex: pole, Edge: cart_to_pole
No non-tree joints.
Note that there are some visualization changes coming soon in RigidBodySim (https://github.com/JuliaRobotics/RigidBodySim.jl/pull/64): fully switching to MeshCat.jl for visualization, making RigidBodySim quicker to install and available on Windows, among other things. Reducing load time and dropping more dependencies is also on my list.
Iām planning on writing a Rigid Body Dynamics package in Julia focused on efficient contact mechanics. Mainly Iād like to explore some alternative ways of solving the LCP/QP problem that arises.
Iām happy to see the EnhancedGJK package. Good collision detection with penetration depth/direction is one of more time consuming parts of writing a robust RBD engine.
Cool! Iām glad that more people are starting to think about Julia for robotics/dynamics. Also check out @rdeitsā ConditionalJuMP, especially the Stewart & Trinkle example, as well as GitHub - rdeits/LCPSim.jl (more researchy code), built on top of ConditionalJuMP and RigidBodyDynamics.
Looks good. I see those LCP solvers are leveraging either Gurobi ( not free for commercial use ) or Cbc ( restricted to integers? ). Are there are any free for commercial use floating point LCP or Sequential Quadratic Programming solvers you know of? I think Iāve seen an example of SQP using JuMP and non-commercial solvers.
There is an iterative relaxation solver that is specifically used for real-time rigid body dynamics Iāll implement at some point. Itās a bit trickier to efficiently integrate with generalized coordinate solvers, but can be done. The idea there is to lazily update the state vector by starting at the leaves first. http://www.bulletphysics.com/ftp/pub/test/physics/papers/IterativeDynamics.pdf
Iām using Gurobi because I have access to it (via their academic program) and because Iām familiar with it, but there are other options. In fact, in LCPSim, Iām constructing a linear complementarity problem as a general mixed-integer linear program (for simulation) or mixed-integer quadratic program (for trajectory optimization). For the simulation case, thatās really kind of overkill: a basic LCP solver like PATH would probably be more appropriate. At the time, integrating with PATH required a lot of code changes that I wasnāt interested in doing, but it should be much easier with the upcoming versions of JuMP and MathOptInterface. Iām not sure what PATHās license model is, but it canāt possibly be as expensive as Gurobi
RigidBodyDynamics.jl could actually also be useful for the āmaximal coordinatesā type of approach used in the paper you referenced. Continuing the cart-pole example:
which results in a version of the cart-pole with a flat tree structure (each body has a quaternion-parameterized floating joint connecting it directly to the world) and a bunch of non-tree joints that restrict the motion between the bodies:
after which itās pretty easy to compute the constraint Jacobian needed in the approach from your paper:
state = MechanismState(cartpole_maxcoord)
rand!(state)
result = DynamicsResult(cartpole_maxcoord)
RigidBodyDynamics.constraint_jacobian!(result, state) # currently not exported, but could be
This updates the constraintjacobian field of DynamicsResult, which is (at least part of) the J you need. constraint_jacobian! is reasonably fast and it doesnāt allocate. Itās automatically used internally in the dynamics! function for Mechanisms with non-tree (loop) joints.
Just a suggestion of course, I understand if you want to write it yourself.
Thatās a convenient function. Thatās much less complicated than what I had in mind. Iāll have to study your code, I havenāt kept up to date with the RBD algorithms in robotics since the original book from Featherstone .
What Iāve done in the past is to provide a general interface to the LCP solver where you can query an object for itās āeffective massā given a position and a set of basis vectors ( just one needed if no friction ) and then another to apply an impulse along that direction at that point. Which I suppose is a simple model of a contact patch. This allows the LCP solver to work with any object implementing that interface.
Seriously though, are there ways to (semi-)automate that kind of task? I realize there is much more to it than parsing C header files, but I feel a big chunk of it could be automated, and maybe for several target languages in one go.
See Sundials.jl. It is wrapped via BinaryBuilder/BinaryProvider to get the binaries and uses Clang.jl to auto-generate a bunch of Julia functions wrapping the whole API.
Itās very much research code in that maybe not all features are supported or there are bugs, but Iāve tried to keep it very similar to the C-API interface specified by the mujoco header files, with some Julia specific conveniences. Again, very much research code (Iāve used it to publish some RL papers and played around with some trajectory optimization), so I have not widely announced it, but have wanted to share it with interested folks. Iāll probably include the visualizer when I get it fixed up for Julia-0.7.
Kudos to @tkoolen and @rdeits for turning me onto Julia in the first place!
The visualization changes have been merged (Pkg.checkout for now, no new release yet; still want to fix a couple more issues in the next few days). See the updated quick start guide. Please let us know if there are any issues on Arch and if you have any comments.
.