# Constraints in RigidBodyDynamics

Is there a way of adding kinematic constraints using RBD? For instance, I have a double-prismatic joint, i.e a telescopic joint, where the inner always moves at twice the speed of the outer. (The two components are huge and have very different inertias.)

Is there a way I can enforce a constraint that models the telescopic joint properly? Also, I still haven’t got my head around adding angle constraints on revolute joints.

The short answer is no. The only kinematic constraints currently ‘natively’ supported are in the form of joints, with types listed in http://www.juliarobotics.org/RigidBodyDynamics.jl/latest/joints.html#JointTypes-1.

But RigidBodyDynamics.jl does implement a lot of the functionality needed to implement more generic constraints involving multiple joints as a result of its support for closed-loop mechanisms. The constraint you describe should only require adding one more row to the constraint Jacobian and one more element to the constraint ‘bias term’ vector, after which the low-level `dynamics_solve!` function applies unmodified. So it wouldn’t be hard; the main question is what the right API is for these generic constraints. I think I have a basic idea, but if you have any thoughts about this, please let me know.

Do note that currently, the position/velocity/effort bounds in each joint are just there for storage; none of the algorithms in RigidBodyDynamics.jl use these bounds. This is mainly because there isn’t one ‘right’ way to implement these bounds. They are currently used by some dependent packages, such as MeshCatMechanisms (to determine the ranges for the sliders in `@manipulate`), and in LCPSim (researchy code), where they are enforced as hard constraints. If you’re using RigidBodySim, for now you’ll need to code up your own `control!` function that computes penalty joint torques (e.g. using a linear or stiffening spring-damper).

Many thanks for your very clear reply and for the link to Robin Deits’ work. I’ll have to work with barrier functions at some point in the future anyway.