rdl repository

Repository Summary

Checkout URI https://gitlab.com/jlack/rdl.git
VCS Type git
VCS Version master
Last Updated 2019-05-12
Dev Status DEVELOPED
CI status No Continuous Integration
Released RELEASED
Package Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Packages

Name Version
rdl 3.2.0
rdl_benchmark 3.2.0
rdl_cmake 3.2.0
rdl_dynamics 3.2.0
rdl_msgs 3.2.0
rdl_ros_tools 3.2.0
rdl_urdfreader 3.2.0

README

Master: build status coverage report

Develop: build status coverage report

RDL API Documentation

rdl_dynamics Code Coverage

rdl_urdfreader Code Coverage

rdl_ros_tools 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.

CONTRIBUTING

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, and all you have to do is run the format code target and commit the newly formatted code before you make a merge request. To do so, if for example you make a change to rdl_dynamics, just run catkin_make --make-args format_code_rdl_dynamics. If you make a change to rdl_urdfreader, you should run, catkin_make --make-args format_code_rdl_urdfreader. This will result in all of the c++ files in the rdl_dynamics package to be nicely formatted. Make sure to do that to all packages you modify. There are a few things uncrustify won't catch, so i'll list those here, please abide by them, - Classes and structs are camel case with the first letter capitalized, e.g. MyStruct. No underscores - Functions and class method names are camel cased with the first letter lower cased, e.g. myClassesMethod(). No underscores - variable names are camel case the same as functions and methods. Lowercase first letter and no underscores - Make your variable names and function names as clear as possible, even if it means they are 50 characters long. An exception to this rule would be variables from Featherstone's book. It is ok, and even encouraged, that you use the variable name from the book - Const correctness is required as well

Additionally, if you have trouble getting your branch to pass the GitLab pipeline, it is likely due to style errors which are checked every build using cppcheck. When you run catkin_make run_tests, the style of your code will be checked and a results folder will be generated in <path_to_catkin_ws>/build/static_analysis. That file should tell you if it found any style problems, so if the pipeline is failing and you're not sure why you should check there.

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!

Repository Summary

Checkout URI https://gitlab.com/jlack/rdl.git
VCS Type git
VCS Version master
Last Updated 2019-05-12
Dev Status DEVELOPED
CI status No Continuous Integration
Released RELEASED
Package Tags No category tags.
Contributing Help Wanted (0)
Good First Issues (0)
Pull Requests to Review (0)

Packages

Name Version
rdl 3.2.0
rdl_benchmark 3.2.0
rdl_cmake 3.2.0
rdl_dynamics 3.2.0
rdl_msgs 3.2.0
rdl_ros_tools 3.2.0
rdl_urdfreader 3.2.0

README

Master: build status coverage report

Develop: build status coverage report

RDL API Documentation

rdl_dynamics Code Coverage

rdl_urdfreader Code Coverage

rdl_ros_tools 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.

CONTRIBUTING

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, and all you have to do is run the format code target and commit the newly formatted code before you make a merge request. To do so, if for example you make a change to rdl_dynamics, just run catkin_make --make-args format_code_rdl_dynamics. If you make a change to rdl_urdfreader, you should run, catkin_make --make-args format_code_rdl_urdfreader. This will result in all of the c++ files in the rdl_dynamics package to be nicely formatted. Make sure to do that to all packages you modify. There are a few things uncrustify won't catch, so i'll list those here, please abide by them, - Classes and structs are camel case with the first letter capitalized, e.g. MyStruct. No underscores - Functions and class method names are camel cased with the first letter lower cased, e.g. myClassesMethod(). No underscores - variable names are camel case the same as functions and methods. Lowercase first letter and no underscores - Make your variable names and function names as clear as possible, even if it means they are 50 characters long. An exception to this rule would be variables from Featherstone's book. It is ok, and even encouraged, that you use the variable name from the book - Const correctness is required as well

Additionally, if you have trouble getting your branch to pass the GitLab pipeline, it is likely due to style errors which are checked every build using cppcheck. When you run catkin_make run_tests, the style of your code will be checked and a results folder will be generated in <path_to_catkin_ws>/build/static_analysis. That file should tell you if it found any style problems, so if the pipeline is failing and you're not sure why you should check there.

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!