Hi all! I’m just getting started with Julia. I’ll be working on motion planning algorithms and controls for rigid bodies. I’ve started to play around with various packages and had some general questions:
RigidBodyDynamics seems great so far! However, I’ve used Drake in the past and noticed it has Julia bindings. It looks like the author of the Julia package also tried the Julia bindings (and contributes to Drake?) but has contributed more actively to the Julia package. I’ll try out the Julia bindings soon but, in the meantime, can anyone share their experience with either of those options?
I’m not the author of RigidBodyDynamics.jl, but I do sit next to him in lab. I’m also one of the original developers of Drake and I’m currently using RigidBodyDynamics.jl in Julia for my research.
We briefly played around with Julia bindings to Drake as a proof-of-concept, but I’m pretty confident that they’ve never been used for any actual projects and I wouldn’t recommend that route. Drake is very heavily C++ and Python-focused and there’s no indication of that changing in the near future. For dynamics in Julia I’d definitely recommend RigidBodyDynamics.jl over trying to wrap Drake.
On the other hand, if you need access to a few Drake functions, it should be pretty easy to call them via the Python bindings with PyCall.jl. I’ve never actually needed to do that in my work, but it should be pretty functional.
I don’t use Quaternions.jl so I can’t comment on that, but you can see that Rotations.jl is indeed using the Hamilton convention for its quaternions:
This is the code that (lazily) computes each element of the rotation matrix corresponding to the quaternion. The i==2 element is at indices (2, 1) and has the sign we would expect from the Hamilton convention: Quaternion Conventions: Hamilton and JPL
Re: Julia bindings for Drake, those were just instructions for calling the C++ code using Cxx.jl. These aren’t really ‘bindings’ per se, Cxx.jl just makes it quite easy to call arbitrary C++ code. I’m not sure if those instructions still work; I haven’t used Drake in a while. I’m biased of course, but I think you’ll have a better time just using RigidBodyDynamics.jl than trying to call Drake using Cxx.jl.
I wouldn’t recommend building stuff on top of Quaternions.jl. I used to have it as a dependency of RigidBodyDynamics, but switched to Rotations.jl. Quaternions.jl has been pretty much unmaintained for quite a while now (often months go by before anybody responds to PRs/issues). Again, I’m biased, because I’ve contributed quite a bit to Rotations.jl, but Rotations has a lot of nice features, is fast, and already up to date with Julia 0.7. One difference is that Quaternions.jl allows non-normalized quaternions as well, while Rotations.jl doesn’t.
Hamilton convention
Wow, I’d honestly never heard of the other (JPL) convention before. Both Rotations and Quaternions use Hamilton convention, yeah:
Thanks for the quick reply! Well that’s 2/2, so I’ll stick to just Julia for the time being. Also, thanks for pointing out the differences in quaternion normalisation – another good reason to stick to Rotations.jl.
And I suppose here’s a general question to the both of you: it seems that we’re all in agreement that Rotations.jl uses the Hamilton convention based off the implementation details but would you happen to know off of which text the library is originally based?
I didn’t follow any particular text. In fact I inherited (ahem, stole) a lot of the code, especially the mathematical parts, from a co-worker and extensitively re-worked it so that it nicely fit into StaticArrays.jl and CoordinateTransformations.jl just the way I wanted it to
In turn, I believe my co-worker had been using Quaternions.jl as a basis for his quaternion rotation and added some of his own Eurler rotation types, derivatives, etc. I suspect that’s the only reason we use the Hamilton convention.
If you want a package with syntax similar to Octave/MATLAB, then you can try ReferenceFrameRotations.jl. It is being used on a daily basis at the National Institute for Space Research to simulate satellite attitude dynamics.
