RDL API Documentation

Code Coverage

Disclaimer

RDL is a dynamics library that is a derivative of Rigid Body Dynamics Library(RBDL) written, owned, and copyrighted by Martin Felis. I, Jordan Lack, do not wish to misrepresent any of the works contained within this project that were not originally created by me as my own in any way.

The original work from which RDL is based upon can be found here.

RDL - Robot Dynamics Library

RDL is a c++ library derived from Rigid Body Dynamics Library(RBDL) for computing dynamics and kinematics of rigid body systems, however, kinematics in RDL are handled differently than in the original work of RBDL. In RDL, a number of spatial objects(SpatialForce, SpatialMotion, SpatialInertia, FramePoint, FrameVector, etc) are provided that, when used, provide runtime checks that ensure rules on the frames these objects are expressed in are obeyed.

Licensing

The library is published under the very permissive zlib free software license which should allow you to use the software wherever you need. See the LICENSE file for the detailed language and permissions of the zlib license. The License file for the original work from which RDL is a derivative can be found in the file RBDL_LICENSE.

Credits

First and foremost I would like to give due credit to Martin Felis, the creator of RBDL of which this work is a derivative. Additionally, RBDL is a fantastic library, and should you find that RDL doesn’t meet your needs you may consider giving RBDL a try. It may better fit your needs/application.

I would also like to acknowledge the folks at the IHMC Robotics Lab. Their dynamics libary(which is written in Java) provides runtime frame checks, and after working with them and seeing first hand how it enables very quick development of control algorithms and helps prevent a lot of bugs I knew the world of c++ needed something similar. If you are interested in writing code for robots and Java is your thing then definitely check out IHMC’s open source stuff here.

How to contribute

If you are interested in contributing, please give this guide a quick read to make sure the code you write is formatted correctly.

Formatting and style

The formatting is done with clang-format. Running tests will check the formatting, and if reformatting is needed you can do so by running `ament_clang_format –config --reformat.

Error handling

• Code must compile with all warnings turned on
• Exceptions are ok. Use the RdlException though and provide a useful message

Documentation

Any methods, public or private, must be commented with doxygen style comments as well as any member variables created. There are lots of comments in the code, it should be pretty easy to just pattern match something that’s already there.

Bug fixes

If you believe you have found a bug and would like to provide a fix(thanks!), you are required to also submit in your pull request a unit test that exposes the bug you are fixing. If you aren’t interested in fixing it yourself, create an issue giving as much information as possible as well as a failure case so the developer(s) can reproduce the bug. Also make sure that your pull request is back onto the develop branch.

New features

If you are interested in adding a completely new feature, please follow these steps

1. Create an issue so folks know you’re interested in the feature and so others can weigh in. This is important because some features the developer(s) may not want in RDL, so it’s encouraged that you get the thumbs up to keep you from wasting time. Also others might be able to help or have good implementation ideas.
2. Fork RDL. I think you’ll have to put your fork on GitLab for the PR back to upstream to work properly.
3. Create your branch off the develop branch. If the issue created for this feature is #123, then please make your feature branch named feature/RDL-123.
4. Implement the feature in your fork, unit testing as rigorously as possible all added functionality
5. Once your feature is implemented, tested, and documented and it’s ready for prime time, create a merge request to the develop branch and the developer(s) can start reviewing it.
6. Once it has gotten the thumbs up from reviewers and the build has passed in the CI pipeline, it’ll get merged in!