I've been working on an open-source C++ library for articulated rigid body simulation, and I would appreciate some feedback on the codebase, and on a couple of key architectural decisions.
First off, ARB is MIT-licensed with header-only dependencies GLM and autodiff, and non-header dependencies TinyXML2, libccd, and openGJK.
The repo can be found here: https://github.com/wbyates777/Articulated-Rigid-Body
ARB (Articulated-Rigid-Body) is a rigid body simulation library for graphics and robotics written in C++23.
It consists of a compact implementation of a differentiable spatial algebra which is used
to implement three important dynamics algorithms: the Articulated Body Algorithm (ABA), the Composite Rigid Body Algorithm (CRBA), and the Recursive Newton-Euler Algorithm (RNEA),
and an impulse-based, Projected Gauss-Seidel (PGS) contact solver. See Featherstone 2008 and the GitHub project README.md for more details.
The project has two notable design features:
i) it uses GLM over Eigen3 for linear algebra operations, and
ii) it is entirely differentiable.
Eigen3 and GLM
Many industrial physics and robotics engines (such as Pinocchio or RBDL) rely on Eigen3.
In contrast ARB is built on GLM (OpenGL Mathematics). This ensures a lightweight footprint and native graphics interoperability.
Although the current ARB implementation performs within 1–6% of RBDL's execution speeds,
after conducting some profiling, I am confident that rewriting some heavily used GLM formulas can close this gap.
The main issue is that after translating between Eigen3 and GLM syntax, many block matrix formulas do not map to GLM exactly as they appear in textbooks (even though they are numerically correct). This gives rise to lots of frustrating false-positive "bugs".
End-to-End Automatic Differentiation
The GLM library is templated and when parameterised with autodiff types the spatial algebra and the entire simulation pipeline, including contacts, becomes differentiable.
End-to-end differentiability facilitates advanced techniques such as analytical system identification (SI),
gradient-based trajectory optimisation, model predictive control (MPC), and the application of machine learning algorithms.
The issue here is that differentiating across impulse-based contact manifolds introduces non-smooth mathematical boundaries. For those working on differentiable simulation in robotics or machine learning, what strategies are you using to manage or smooth gradient discontinuities during contact transitions? Basically, is the openGJK implementation useful or are other approaches (i.e. signed depth functions) preferred?
wbyates777•1h ago
I've been working on an open-source C++ library for articulated rigid body simulation, and I would appreciate some feedback on the codebase, and on a couple of key architectural decisions.
First off, ARB is MIT-licensed with header-only dependencies GLM and autodiff, and non-header dependencies TinyXML2, libccd, and openGJK. The repo can be found here: https://github.com/wbyates777/Articulated-Rigid-Body
ARB (Articulated-Rigid-Body) is a rigid body simulation library for graphics and robotics written in C++23. It consists of a compact implementation of a differentiable spatial algebra which is used to implement three important dynamics algorithms: the Articulated Body Algorithm (ABA), the Composite Rigid Body Algorithm (CRBA), and the Recursive Newton-Euler Algorithm (RNEA), and an impulse-based, Projected Gauss-Seidel (PGS) contact solver. See Featherstone 2008 and the GitHub project README.md for more details.
The project has two notable design features: i) it uses GLM over Eigen3 for linear algebra operations, and ii) it is entirely differentiable.
Eigen3 and GLM
Many industrial physics and robotics engines (such as Pinocchio or RBDL) rely on Eigen3. In contrast ARB is built on GLM (OpenGL Mathematics). This ensures a lightweight footprint and native graphics interoperability. Although the current ARB implementation performs within 1–6% of RBDL's execution speeds, after conducting some profiling, I am confident that rewriting some heavily used GLM formulas can close this gap. The main issue is that after translating between Eigen3 and GLM syntax, many block matrix formulas do not map to GLM exactly as they appear in textbooks (even though they are numerically correct). This gives rise to lots of frustrating false-positive "bugs".
End-to-End Automatic Differentiation
The GLM library is templated and when parameterised with autodiff types the spatial algebra and the entire simulation pipeline, including contacts, becomes differentiable. End-to-end differentiability facilitates advanced techniques such as analytical system identification (SI), gradient-based trajectory optimisation, model predictive control (MPC), and the application of machine learning algorithms. The issue here is that differentiating across impulse-based contact manifolds introduces non-smooth mathematical boundaries. For those working on differentiable simulation in robotics or machine learning, what strategies are you using to manage or smooth gradient discontinuities during contact transitions? Basically, is the openGJK implementation useful or are other approaches (i.e. signed depth functions) preferred?
Many Thanks.