Dynamic Animation and Robotics Toolkit


DART: Dynamic Animation and Robotics Toolkit

Build Status

Item Status
Build Status CI Ubuntu CI macOS CI Windows
API Documentation API Documentation
Coverage codecov
Static Analysis Codacy Badge


Visit the DART website for more information

  • VisualNode & CollisionNode

    VisualNode & CollisionNode

    I think it would be appropriate to begin a conversation about the VisualNode/CollisionNode concept which is intended to replace the current method of using purely the Shape class to provide visualization and collision information. I don't anticipate this being finished any time before version 5.1, but I think it's worth opening the conversation now to give us some time to share ideas and flesh out a design.

    To review, the current way Shapes are used is: (i) The Entity class has a std::vector of std::shared_ptr<Shape> which it uses for visualization (ii) The BodyNode class has a std::vector of std::shared_ptr<Shape> which it uses to check collisions

    The nice thing about this scheme is that it allows us to share shape information between multiple Entities/BodyNodes which saves on memory. The downside is that Shape has several features, such as Shape::setLocalTransform and Shape::setColor, which could result in destructive interference if two Entities are sharing the Shape but want that shape to have a different local transform or a different color.

    Another issue with the current scheme is it does not allow a single BodyNode to have different parts with different physical properties, like coefficients of friction and restitution. A real physical body will have different friction properties on different parts, and different restitution properties on different parts, but DART cannot currently model that. Making friction and restitution properties part of a CollisionNode and allowing a BodyNode to have multiple CollisionNodes would address this issue.

    Design suggestions

    I think there is an interest in having the VisualNode and CollisionNode classes inherit the Frame class. This makes sense, because we want these Node classes to have a local transform property, and it would be convenient to have a reference frame tied to the Shapes. However, there is a bit of a conflict here: if we make a VisualNode responsible for visualization and we make VisualNode a Frame, then this means that we might need to remove visualization features from Entities, because classes that are derived directly from Entity (rather than from Frame) are expected to leaf nodes in the kinematic tree, so it would not make sense for a raw Entity to have child VisualNodes (since this would contradict the idea that the Entity is a leaf).

    So I have two suggestions to offer for how to resolve this:

    (1) We remove all visualization features from Entity. This would make the raw Entity class far less valuable, but maybe that's okay. Instead of creating an Entity to render an arbitrary (and non-physical) Shape in a scene, the user would have to create a SimpleFrame (which would inherit VisualNode) and fill it with some Shapes.

    (2) We put all the visualization API into Entity. We would also create a VisualNode class that inherits the Frame class, but its API for visualizing shapes will be entirely derived from Entity. This means that everything that inherits Entity will be able to contain its own Shapes, and the visualization of all those Shapes could be manipulated by the user. My main concern here is this could result in confusion: The BodyNode class would be able to contain visualization Shapes, but it would also have VisualNodes that can contain visualization Shapes, so the user might be confused about which to use when trying to manipulate visualizations.

    Of these two options, I think I would prefer (1).

    Visual vs. Collision Node

    The purposes of the VisualNode and the CollisionNode would be slightly different: VisualNode would be an interface for manipulating how things get rendered, while CollisionNode would contain some physical property data which describe how collisions should be handled.

    @psigen brought up how this type of separation between visualization and collision can be troublesome, and he requested that the concepts of the two classes be merged into a single ShapeNode class. Indeed, at the core of the two classes there is just a std::vector of std::shared_ptr<Shape> and a local transform, but the ShapeNodes being used for visualization would still need to be kept separate from the ShapeNodes being used for collision, because you do not always want to render everything that's used for collision checking, and you don't always want to collision check everything that's used for visualization. So rather than a ShapeNode class that has all the features of both, I would propose just having a way to implicitly convert a VisualNode into a CollisionNode and a CollisionNode into a VisualNode. An implicit conversion should address the main source of inconvenience that arises from keeping visualization and collision data separate.

    priority: medium type: feature request comp: gui comp: kinematics tag: collision 
    opened by mxgrey 88
  • SkelParser::readSkeleton assertion failure

    SkelParser::readSkeleton assertion failure

    At line 544 : it = joints.find(order.begin()->second);

    after the first joint is processed this line fails due to order being empty.

    The skeleton file i am using is based on (and nearly identical to, except for also having markers) fullbody1.skel, and the joint assigned to index just above is ("ground",0).

    Edit : note this skeleton file has multiple skeletons (ground and biped), and the first one only has 1 joint defined. the code in this section looks like it may be predicated on the assumption that more than 1 joint will always exist in any skeleton.

    opened by jturner65 37
  • Enabling proper URI resolution for World URDF parsing

    Enabling proper URI resolution for World URDF parsing

    The changes that were made to allow for correct URI resolution had an unintended side effect of breaking the relative path resolution for URDF files that represent an entire World (as opposed to the standard use of a URDF file, which is to represent an individual robot).

    This pull request fixes this issue and allows World URDF files to correctly resolve relative paths.

    opened by mxgrey 36
  • Aspects, States, and Properties

    Aspects, States, and Properties

    This pull request addresses #643, #627, and some conversations that were had offline. It's a doozy of a pull request, but I think it provides a lot of valuable improvements and features with minimal impact on the API (besides the renaming of Addon to Aspect).

    Due to the renaming, the diff that's available on Github is going to be virtually unusable. That being the case, I'm going to provide individual links that highlight important parts of this pull request.

    Air-tight (albeit complex) inheritance structures

    First I'd like to start with a simplified diff which illustrates the primary value of this pull request

    The key thing to note is that we eliminate a huge amount of code duplication between these two classes. EndEffector and ShapeNode no longer store their own relative transform property because now FixedFrame stores this information as part of its FixedFrame::Aspect. Moreover, EndEffector and ShapeNode don't need to define Node::State or Node::Properties for themselves, because all of their states and properties -- from the beginning to the end of their inheritance structure -- are stored within Aspects. This allows them to each inherit a class called CompositeNode which will wrap their Composite::State and Composite::Properties up into a Node::State and Node::Properties.

    Essentially, every class that has information which could be labeled as "State" or "Properties" will store that information with one or more Aspects. An Aspect can embed its information within the object that owns it (completely eliminating any overhead for the object to access it), or the Aspect instance may hold onto the information itself (allowing for more flexible memory usage). This decision is up to the developer/user to determine which approach is best suited for any given Aspect.

    The bulk of the implementation for these features can be found in dart/common/EmbeddedAspect.h and dart/common/detail/EmbeddedAspect.h.

    Direct access to members of Composite State/Properties

    Up until now, when you have a Composite::State (formerly known as AddonManager::State) it was completely opaque. You had no way of accessing or modifying its contents; you could only pull it out of one Composite and pass it to another Composite. Now, however, you can do the following:

    Composite::Properties properties;
    properties.getOrCreate<BodyNode>().mName = "Body";
    if(SoftBodyNode::AspectProperties* softProperties = properties.get<SoftBodyNode>())
      softProperties->mDampCoeff = 0.3;

    This allows you to dynamically construct and access individual Aspects of the Composite State. Identical features are available for Composite Properties. get<T>() will return a pointer which is nullptr if the Aspect didn't exist, whereas getOrCreate<T>() will return a reference, since the information will be created if it didn't exist already.

    The implementation for these features can be found in dart/common/detail/CompositeData.h.

    Seamless integration of both internal Aspects and user-added Aspects

    Because of the new system, any Aspects (formerly known as Addons) that user adds to a Skeleton, BodyNode, Joint, or Node will get sucked into the standard State and Properties of the BodyNode/Joint/Node that it's added to, as well as the Skeleton in which that object exists. This is in contrast to the prior approach where the was an ExtendedProperties class that mangled together the basic Properties and the Composite::Properties.

    The new system is completely unified---functionally, semantically, and mechanically---instead of having different information handled in different ways and then getting mangled together at the last second so that it can be delivered to the user as a single object.

    Template Madness

    I think the biggest catch to these changes is the ever growing usage of templates. As much as I may adore templates myself, I do recognize that not everyone is very comfortable with them, and they can result in very complex (read: confusing) inheritance structures when CRTP is involved. This template-based implementation is high performance and very flexible, but it will probably be confusing for reviewers and future developers. With that in mind, I encourage people to post any questions they run into while reviewing the implementation. Even if you can manager to answer the question yourself, it would still be good for me to know the question so that I can address it specifically when it comes time for me to get serious about documenting this implementation.

    API Changes

    I tried my hardest to keep the API changes minimal (with the exception of renaming Addon to Aspect and AddonManager to Composite). The biggest difference you'll see is in the SomeClass::Properties constructors. Only the constructors. The actual member variables of those classes should remain virtually unchanged, but their constructors won't quite work the way they used to, especially BodyNode::Properties. An easy fix for this is to allow it to perform a default construction and then fill in its member variables after construction.

    This change is Reviewable

    opened by mxgrey 25
  • End Effector, Inverse Kinematics, and OpenSceneGraph

    End Effector, Inverse Kinematics, and OpenSceneGraph

    This pull request introduces three new major features. While it's not preferable for me to dump out so many features simultaneously, this is happening because the features were all developed in parallel and tested by using each other.

    A very brief overview of the three new features is:

    1. End Effector

    We are extending the Jacobian features of the BodyNode class to an EndEffector class which is able to rigidly attach to BodyNodes with an arbitrary transform offset. The Jacobian API of the BodyNode has been moved into a new JacobianNode base class which is inherited by both BodyNode and EndEffector. The EndEffector also provides functionality for specifying support polygons, and in the future I intend to implement grasping context information into EndEffectors.

    2. Inverse Kinematics

    The new Inverse Kinematics module in DART is a force to be reckoned with. With the Inverse Kinematics module, you can customize the:

    • Error Method
    • Gradient Method
    • Objective
    • Null space objective
    • And everything else

    The way the IK module works is it sets up an optimizer::Problem with Objective and Constraint functions that it ties together. The Problem can be fully customized, but the IK module starts it out with a setup that is sufficient for most standard IK usage. The IK modules are clonable and can be cloned to operate on a new BodyNode/EndEffector.

    There is also a HierarchicalIK class that can tie together a hierarchy of individual InverseKinematics modules. Modules that have lower priority in the hierarchy will be projected through the null spaces of the modules with higher priority.

    3. OpenSceneGraph

    OSG is an open source C++ wrapper for OpenGL that has a very nice API and a boatload of features, like mouse picking. The new osgDart library provides an interface between DART and OSG, and offers drag-and-drop functionality for SimpleFrames and BodyNodes.

    Some of the nitty gritty details inside osgDart are not fully documented because much of it is liable to be replaced with the upcoming ShapeNode changes, so it would feel like a waste to spend time on that. Also, all of my changes to the Shape class will be migrated into the ShapeNode class once it's implemented, so if those changes look unappealing, don't worry; they won't last long.

    Other notes

    I've split out the nlopt, ipopt, and snopt portions of the optimizer namespace into their own libraries so that they're not hidden in the source code. I haven't updated the package management to support either of them yet, because I don't know yet how DART does package management, but I think it would be good if those could be packaged up and offered on the repos so they can be utilized without needing access to the source code.

    I wrote a simple GradientDescentSolver that optimizes using stochastic gradient descent. This way we have a solver native to DART instead of requiring a third party library. The GradientDescentSolver is what is used by default in the InverseKinematics modules.

    The SNOPT extension is definitely clobbered right now. Tomorrow I'll try to take a pass at it and attempt to make it functional, but since I don't have access to SNOPT it probably still won't work even after my fix attempts, so I'll need someone with SNOPT access to get it fully functional.

    Atlas Puppet

    A good summary of this pull request can be found in a single app: osgAtlasPuppet, which you can find in osgDart/examples/osgAtlasPuppet.cpp. The app lets you puppeteer an Atlas by clicking and dragging. You can see Atlas's support polygon and watch it try to solve its balance constraint.

    Here's a screenshot from the app: atlas puppet

    The green polygon is its support polygon, the blue sphere is its center of mass (projected onto the support polygon), and the green sphere is the centroid of the support polygon. You can also turn on interactive targets for more precise control over the end effectors: atlas leaning

    You can even toggle whether each foot can be used as a support polygon, and then have it balance on one leg: atlas one-leg

    opened by mxgrey 25
  • Eradicating memory leaks & making classes copy-safe and clonable

    Eradicating memory leaks & making classes copy-safe and clonable

    ~~This is a premature pull request for review and discussion purposes, not ready to be merged yet~~

    This pull request is ready for review

    This branch and pull request are dedicated to removing memory leaks from DART as well introducing the ability to copy properties and create clones of objects. Spawning clones will be useful for making efficient multithreaded applications.

    The changes being made here are pervasive, and some will require breaking the API, specifically the adoption of std::shared_ptr for the Shape and Skeleton classes.

    Here is a brief list of the conceptual changes:

    • BodyNode and Joint classes will all have a Properties struct that can be safely exchanged between different instances, and this struct will be used to standardize the constructors for the different types.
    • BodyNode and Joint instances will be fully managed by their Skeleton. BodyNode and Joint instances will only be creatable by the Skeleton class (the current procedure for assembling Skeletons will be deprecated) and they will be destroyed when the Skeleton class destructs
    • Shape instances and Skeleton instances will be treated as shared resources, and they will be managed by std::shared_ptr. BodyNodes and Joints are not shared resources because they are worthless/meaningless without being part of a single specific Skeleton.
    • It will be possible to clone Worlds and Skeletons.
    • Cloning a Skeleton entails creating a new Skeleton instance that is filled with new Joint instances and new BodyNodes instances which copy the properties of the original Skeleton's Joints and BodyNodes. Shape resources will be shared between Skeleton clones to minimize memory usage and copying overhead.
    • Cloning a World entails creating a new World instance that is filled with new Skeletons which are clones of the Skeletons of the original World.

    To be determined:

    It would also be good to have a concept of a "State" to complement the "Properties" concept. I am still hashing out the details for how a State class would work, so suggestions are welcome. At the moment, I think the State should belong to the Skeleton, but it's not clear to me exactly how much information it should contain. It could either be just Generalized Position, Velocity, Acceleration, and Force vectors, or it could also include information like external forces.

    opened by mxgrey 25
  • Frame class and auto-updating for forward kinematics

    Frame class and auto-updating for forward kinematics

    This pull request includes two significant new features: a Frame subclass (as well as an Entity subclass) and smart automatic updating for forward kinematics.


    The Frame class allows a greater amount of expression when defining and requesting data. For example, you can now request positions, velocities, and accelerations with request to an arbitrary reference frame by specifying a Frame class as an argument for various functions (as an example, see the getLinearVelocity() function).


    The Entity class is simply a base class for anything that exists within a Frame. At the moment, that only includes Frames (because Frames exist within Frames), but in the future it can include things like a Point class (useful for expressing center of mass or collision points), an Axis class, a Transform class, and perhaps many other things.


    The other -- and possibly more significant -- feature of this pull request is auto-updating for forward kinematics. From the user point of view, the impact of this feature is simply that there is no longer ever a need to call Skeleton::computeForwardKinematics(). More specifically, forward kinematics will always be computed when it's needed and will only perform the computations that are necessary for what the user requests. This works by performing some bookkeeping internally with dirty flags whenever a position, velocity, or acceleration gets set, either internally or by the user.

    On one hand, this results in some overhead due to the extra effort of bookkeeping, but on the other hand we have much greater code safety, and in some cases performance can be dramatically improved with the auto-updating (for example, the computeForwardKinematics() function was inefficient when only one portion of the BodyNodes needed to be updated rather than the entire Skeleton, which is common when performing inverse kinematics on a limb or on some subsection of a Skeleton).

    Speed Test

    To determine whether the bookkeeping overhead is worth the auto-updating, I wrote the speedTest app (note, this is not a unit test because it can take a while to run). When comparing this branch with the grey/speed_test branch (which is the same as the current master, but with the speed test added), the difference in performance between the two branches was not appreciable. I ran the speedTest on each branch ten times in "ideal" conditions (I freshly restarted my PC and ran nothing but the terminal) and neither branch was consistently faster than the other. Ultimately, the worst performance of this auto-updating branch was less than 1% slower than the worst performance of the speed_test branch.

    By default, the speedTest app is testing the speed of dynamic simulation, but it also includes a mode for testing the speed of pure forward kinematics. Comparing the results in that mode, I consistently found that the speed_test branch tends to have slightly better performance for computing all three (position, velocity, and acceleration); it seems to be a tossup when computing position and velocity (without computing acceleration); and then this auto-updating branch tends to win by a significant margin when computing only position (likely because the amount of bookkeeping overhead is minimized when only positions are being computed).


    It's important to note that the auto-updating comes with one important caveat for all DART developers now and in the future: there are certain data members that must not be modified or even accessed outside of the appropriate functions, even for internal use. Some of these include BodyNode::mWorldTransform, BodyNode::mVelocity, BodyNode::mAcceleration, and even others that might not be expected like Joint::mJacobian, Joint::mJacobianDeriv, BodyNode::mArtInertia. There are too many to list right here, but they should all be noted in the header comments. The reason these members should not be used directly is because they are carefully monitored by the auto-updating system, so anything that writes to them when it shouldn't will invalidate results, and anything that reads from them when it shouldn't might end up using outdated data.

    This raises a question that I'd like to pose: Should we append something to the names of these "untouchable" data members similar to how the Hungarian Notation encodes information in variable names? Normally I would not advocate such a naming convention, but it might help future (and even current) developers if there were a clear way of immediately knowing that they should not use a variable directly. I don't really have any good suggestions for what the code should be, though. Maybe append "_dnu" (for "do not use") to the ends of the variable names?


    Mark functions that are now deprecated (there are many…).

    Final Comment

    The changes that were necessary for the auto-updating to work fast and reliably were pretty exhaustive. Don't hesitate to ask if you find any changes peculiar, or if you're wondering why some were necessary. I had good reasons for each and every change, and I don't mind explaining those reasons.

    opened by mxgrey 25
  • CMake Error in FindBullet

    CMake Error in FindBullet

    If you're not reporting a bug, please use the forum to ask questions.

    Bug Report

    Please answer the following questions for yourself before reporting a bug.

    • [x] I checked the documentation and the forum but found no answer.
    • [x] I checked to make sure that this issue has not already been filed.


    Select the following information.

    • DART version: master and 6.9.2
    • OS name and version name(or number): Arch
    • Compiler name and version number: GCC 9

    Expected Behavior

    CMake config succeeds

    Current Behavior

    Findings in gazebosim source code:

    • No custom FindDART.cmake

    However, the find_package(DART) results in the following error:

    CMake Error at catkin_ws/install/share/dart/cmake/DARTFindBullet.cmake:15 (if):
      if given arguments:
        "WIN32" "AND" "optimized" "IN_LIST" "BULLET_LIBRARIES" "AND" "debug" "IN_LIST" "BULLET_LIBRARIES"
      Unknown arguments specified
    Call Stack (most recent call first):
    catkin_ws/install/share/dart/cmake/dart_collision-bulletComponent.cmake:6 (include)
    catkin_ws/install/share/dart/cmake/DARTConfig.cmake:63 (include)
    catkin_ws/install/share/dart/cmake/DARTConfig.cmake:123 (dart_traverse_components)
    catkin_ws/install/share/dart/cmake/DARTConfig.cmake:171 (dart_package_init)
      cmake/SearchForStuff.cmake:165 (find_package)
      CMakeLists.txt:147 (include)

    This happens for master, NOT 6.9.2 (in AUR). The change is clearly introduced in 6b023c2994294d6eb1b95e2242e39ba7e9f02427.

    Steps to Reproduce

    Steps for reproducing the issue. 0. Install DART

    1. Clone Gazebo (head) and compile
    2. Failure!!!

    I'm sorry I can't create a smaller CMakeLists.txt only Min Rep Example

    type: bug 
    opened by kunaltyagi 24
  • Transferring BodyNodes between Skeletons

    Transferring BodyNodes between Skeletons

    An extremely useful potential feature currently missing from DART is the ability to freely move BodyNodes between Skeletons. I have a proposal for how this could be added to the latest memory_management branch #369. We would use the following functions:

    BodyNode::moveTo(Skeleton* newSkel, BodyNode* newParent)
    BodyNode::moveTo<JointType>(Skeleton* newSkel, BodyNode* newParent, const JointType::Properties& jointProperties)
    BodyNode::copyTo(Skeleton* newSkel, BodyNode* newParent)
    BodyNode::copyTo<JointType>(Skeleton* newSkel, BodyNode* newParent, const JointType::Properties& jointProperties)

    The BodyNode::remove() function would remove the BodyNode and all its children (recursively) from their Skeleton, and delete them.

    The BodyNode::moveTo(~) function would move the BodyNode and all its children (recursively) to the specified Skeleton, giving it the specified BodyNode as its new parent. The specified new parent BodyNode must already be a member of the new Skeleton (or it must be a nullptr). This function can also be used to move a BodyNode around within a single Skeleton. Note that all the pointers for the BodyNodes and Joints will remain the same as they get moved from one Skeleton to another.

    The templated BodyNode::moveTo<JointType>(~) function would do the same thing as the non-templated version, except it would create a new parent Joint of the specified type. This function could also be used to simply change the existing Joint type of a BodyNode without changing its parent. Like the non-templated version, the pointers for all the BodyNodes and Joints will remain the same after being moved, except the new parent Joint will always use a new pointer.

    The BodyNode::copyTo(~) functions will behave like the BodyNode::moveTo(~) functions, except it will create clones of the BodyNodes and attach the clones to the new Skeleton instead of moving the originals. Obviously the clones will all have new pointers.

    priority: high 
    opened by mxgrey 23
  • Fixed SEGFAULTs in DartLoader

    Fixed SEGFAULTs in DartLoader

    DartLoader currently SEGFAULTs if it fails loading a mesh and, possibly, in a few other situations. This pull request adds error-handling logic that prints a dterr message and returns nullptr in that case.

    opened by mkoval 22
  • Bullet & ODE heightmaps

    Bullet & ODE heightmaps

    This adds support for heightmaps with Bullet or ODE collision detectors. I'm also planning to add FCL support by using the Octomap, but I think this should be a separate PR.

    There are a couple of things yet to discuss and agree on before this could be merged.

    1. Flipping Y values for bullet

    I still don't find the solution for flipping the Y values proposed here very pretty (flipping y is required for bullet so that it has the same pose as the heightmap in ODE). I've thought about a couple of different ways how to to do this, but all of them have something undesirable about it. The main issue is that dynamics::HeightmapShape is built (possibly externally) before the bullet collision object (and with it the bullet btHeightfieldTerrainShape) is created from it. If we create and fill dynamics::HeightmapShape externally (e.g. from within the Gazebo DARTHeightmapShape), we would need to know at this point whether the Y values need to be flipped or not, so we need to know which collision detector is used. However dynamics::HeightmapShape cannot provide this information; we could instead query World for the used CollisionDetector, and if it's bullet, then flip the Y values. But this imposes too much required knowledge about the internals for the user, and it also requires a pointer to the dart World, so I don't consider this a good idea. It's best if the flipping of Y values happens automatically "behind the scenes". Which brings up the next issue: ideally we'd like to have the option to use an existing height value buffer and pass it into dynamics::HeightmapShape::setHeightField() (at the moment, a local copy of the vector is kept, which can be a waste of memory if the caller aims to keep their height field vector as well -that's the case for gazebo's HeightmapShape). But modifying an external caller's buffer data is not such a good idea. I'm not quite sure which solution would be more desirable, they are both not so ideal. So for now, I am just copying the height values vector, and flipping the y values in BulletCollisionDetector (see also comment in the code linked).

    Any thoughts on this? Which solution would you consider more suitable, or you have other ideas?

    2. Relative transforms

    Bullet moves the origin of the heightmap to the center of its AABB (see also comment in btHeightfieldTerrainShape). This is different to ODE, so again we need to make the behavior uniform. What's not so lovely is that BulletCollisionDetector::createBulletCollisionShape() only returns a btCollisionShape, which has no information about a geometry's permanent relative transform to its parent object. So this relative transform has to be returned additionally from where it is created. For now I've solved this extra return value via an output parameter in the affected functions. This relative transform is then "dragged around" as parameter until it is remembered in BulletCollisionObject, where the relative transform can then always be applied when the shape is re-positioned.

    What's not so nice about this: We only need this extra relative transform for the heightmap shape, all other shapes don't use it. Although maybe in future there will be other shapes for which relative transforms have to be applied to the geometry in order to make it uniform with how the same shape is handled in other collision detectors (?).

    Similar issue for ODE, which uses Y as up axis instead of Z and therefore requires a rotation, but for ODE I found a solution which is less invasive (temporarily remembering the relative transform in the geometry itself, until a permanent geometry offset can be set after it is assigned to the body, which overwrites the geometry transform).

    Is the proposed solution OK, or is it totally not desirable to keep an extra btTransform in BulletCollisionObject?

    3. Target branch

    I'm not sure which branch I should submit this PR to, I've just used release-6.5 for now. It would be good to have this available for Gazebo ASAP, see also implementation in the dart_heightmap_with_bullet branch for Gazebo.

    opened by JenniferBuehler 21
  • link error with undefined reference in ubuntu20.04

    link error with undefined reference in ubuntu20.04

    Bug Report

    I clone source code to my computer then conduct:

    mkdir build && cd build
    cmake ..
    make  -j8

    the output is always like this:

    [ 98%] Building CXX object dart/gui/osg/CMakeFiles/dart-gui-osg.dir/render/ShapeNode.cpp.o
    [ 98%] Building CXX object dart/gui/osg/CMakeFiles/dart-gui-osg.dir/render/SoftMeshShapeNode.cpp.o
    [ 98%] Building CXX object dart/gui/osg/CMakeFiles/dart-gui-osg.dir/render/SphereShapeNode.cpp.o
    [ 98%] Building CXX object dart/gui/osg/CMakeFiles/dart-gui-osg.dir/render/VoxelGridShapeNode.cpp.o
    [100%] Building CXX object dart/gui/osg/CMakeFiles/dart-gui-osg.dir/render/WarningShapeNode.cpp.o
    [100%] Linking CXX shared library ../../../lib/libdart-gui-osg.so
    /usr/bin/ld: CMakeFiles/dart-gui-osg.dir/DefaultEventHandler.cpp.o: in function `osg::Drawable::EventCallback::cloneType() const':
    DefaultEventHandler.cpp:(.text._ZNK3osg8Drawable13EventCallback9cloneTypeEv[_ZNK3osg8Drawable13EventCallback9cloneTypeEv]+0x37): undefined reference to `VTT for osg::Drawable::EventCallback'
    /usr/bin/ld: DefaultEventHandler.cpp:(.text._ZNK3osg8Drawable13EventCallback9cloneTypeEv[_ZNK3osg8Drawable13EventCallback9cloneTypeEv]+0x62): undefined reference to `vtable for osg::Drawable::EventCallback'
    /usr/bin/ld: CMakeFiles/dart-gui-osg.dir/DefaultEventHandler.cpp.o: in function `virtual thunk to osg::Drawable::EventCallback::cloneType() const':
    DefaultEventHandler.cpp:(.text._ZNK3osg8Drawable13EventCallback9cloneTypeEv[_ZNK3osg8Drawable13EventCallback9cloneTypeEv]+0xf7): undefined reference to `VTT for osg::Drawable::EventCallback'
    /usr/bin/ld: DefaultEventHandler.cpp:(.text._ZNK3osg8Drawable13EventCallback9cloneTypeEv[_ZNK3osg8Drawable13EventCallback9cloneTypeEv]+0x122): undefined reference to `vtable for osg::Drawable::EventCallback'
    /usr/bin/ld: CMakeFiles/dart-gui-osg.dir/DefaultEventHandler.cpp.o: in function `virtual thunk to osg::Drawable::EventCallback::cloneType() const':
    DefaultEventHandler.cpp:(.text._ZNK3osg8Drawable13EventCallback9cloneTypeEv[_ZNK3osg8Drawable13EventCallback9cloneTypeEv]+0x1b7): undefined reference to `VTT for osg::Drawable::EventCallback'
    /usr/bin/ld: DefaultEventHandler.cpp:(.text._ZNK3osg8Drawable13EventCallback9cloneTypeEv[_ZNK3osg8Drawable13EventCallback9cloneTypeEv]+0x1e2): undefined reference to `vtable for osg::Drawable::EventCallback'
    /usr/bin/ld: CMakeFiles/dart-gui-osg.dir/DefaultEventHandler.cpp.o: in function `osg::Drawable::EventCallback::isSameKindAs(osg::Object const*) const':
    DefaultEventHandler.cpp:(.text._ZNK3osg8Drawable13EventCallback12isSameKindAsEPKNS_6ObjectE[_ZNK3osg8Drawable13EventCallback12isSameKindAsEPKNS_6ObjectE]+0x13): undefined reference to `typeinfo for osg::Drawable::EventCallback'
    /usr/bin/ld: CMakeFiles/dart-gui-osg.dir/DefaultEventHandler.cpp.o: in function `virtual thunk to osg::Drawable::EventCallback::isSameKindAs(osg::Object const*) const':
    DefaultEventHandler.cpp:(.text._ZNK3osg8Drawable13EventCallback12isSameKindAsEPKNS_6ObjectE[_ZNK3osg8Drawable13EventCallback12isSameKindAsEPKNS_6ObjectE]+0x53): undefined reference to `typeinfo for osg::Drawable::EventCallback'
    /usr/bin/ld: CMakeFiles/dart-gui-osg.dir/DefaultEventHandler.cpp.o: in function `virtual thunk to osg::Drawable::EventCallback::isSameKindAs(osg::Object const*) const':
    DefaultEventHandler.cpp:(.text._ZNK3osg8Drawable13EventCallback12isSameKindAsEPKNS_6ObjectE[_ZNK3osg8Drawable13EventCallback12isSameKindAsEPKNS_6ObjectE]+0x93): undefined reference to `typeinfo for osg::Drawable::EventCallback'
    /usr/bin/ld: CMakeFiles/dart-gui-osg.dir/DefaultEventHandler.cpp.o: in function `osg::Drawable::EventCallback::clone(osg::CopyOp const&) const':
    /usr/bin/ld: CMakeFiles/dart-gui-osg.dir/render/VoxelGridShapeNode.cpp.o: in function `dart::gui::osg::render::VoxelGridShapeNode::extractData(bool)':
    VoxelGridShapeNode.cpp:(.text+0xbc0): undefined reference to `osg::Drawable::dirtyDisplayList()'
    collect2: error: ld returned 1 exit status
    make[2]: *** [dart/gui/osg/CMakeFiles/dart-gui-osg.dir/build.make:564: lib/libdart-gui-osg.so.6.13.0] Error 1
    make[1]: *** [CMakeFiles/Makefile2:2993: dart/gui/osg/CMakeFiles/dart-gui-osg.dir/all] Error 2
    make: *** [Makefile:141: all] Error 2

    It seems that something wrong with libdart-gui-osg.so

    And there is no libdart-gui-osg in my computer as locate libdart-gui-osg return nothing.


    Select the following information.

    • DART version: master, 6.12.1
    • Ubuntu20.04
    • Compiler name and version number: gcc 9.4.0

    Expected Behavior

    Please describe the behavior you are expecting. make successfuly

    type: bug 
    opened by wumin199 0
  • HeightMap : Collision and Visual Aspect mismatch

    HeightMap : Collision and Visual Aspect mismatch


    Select the following information.

    • DART version: 6.13.0
    • OS name and version name(or number): Ubuntu 20.04
    • Compiler name and version number: gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04)


    Collision Engine used : ODE

    When creating a heightmap of a given size , the visual and collision aspects are not aligned as one would expect. Below is an image with a HeightMapShape (blue) of width = depth = 2, and a BoxShape (Green) with width = depth = 2 and balls spaced at even distance dropped on them.(Gravity is enabled and the balls are in contact with the surface) The BoxShape is translated by 1 unit in the -z direction

    Expected behaviour would be ,visual and collision aspect of heightmap should be aligned.



    The observed result is as seen, the visual aspect seem to be translated with respect to the collision aspect for the heightmap.

    This is the code for my HeightMap

      "heightmap" :
        "origin" : [0.0, 0.0, 0.0],
        "width" : 2.0,
        "depth" : 2.0,
        "minZ" : 0.0,
        "maxZ" : 0.0,
        "scale" : 2.0
    struct TerrainConfig
        Eigen::Vector3f terrain_origin;
        float tWidth;
        float tDepth;
        float minZ;
        float maxZ;
        float tScale;
    dynamics::SkeletonPtr createHeightMap(TerrainConfig& tConfig)
        dynamics::SkeletonPtr terrainSkel = dynamics::Skeleton::create("terrain");
        dynamics::BodyNodePtr terrainBody
                = terrainSkel->createJointAndBodyNodePair<dynamics::WeldJoint>(nullptr)
        Eigen::Isometry3d tf_trans = Eigen::Isometry3d::Identity();
        tf_trans.translation() = Eigen::Vector3d{tConfig.terrain_origin[0],tConfig.terrain_origin[1],
        auto terrainShape = std::make_shared<dynamics::HeightmapShape<float>>();
        std::vector<float> heights{} ;
        for(auto i=0; i < tConfig.tWidth * tConfig.tDepth ; i++)
            heights.emplace_back(math::Random::uniform(tConfig.minZ, tConfig.maxZ));
        std::cout<< "HEIGHTS " << heights.size();
        terrainShape->setHeightField(tConfig.tWidth, tConfig.tDepth, heights);
        terrainShape->setScale(Eigen::Vector3f(tConfig.tScale, tConfig.tScale, 1.0));
        return terrainSkel;

    I am not sure if this is really a bug , or if it is just me doing something wrong here. Would be great if someone with expertise on the matter could guide me with this.

    Thanks in advance.

    type: bug 
    opened by ibrahiminfinite 0
  • dart seems to return incorrect world jacobian for the translational degrees of freedom of a freejoint

    dart seems to return incorrect world jacobian for the translational degrees of freedom of a freejoint

    Bug Report

    • [x] I checked the documentation and the forum but found no answer.
    • [x] I checked to make sure that this issue has not already been filed.


    • DART version: 6.12.1
    • OS name and version name(or number): Ubuntu 18.04 and newer
    • Compiler name and version number: GCC 8.0.0 or newer
    • Using dartpy python API

    Expected Behavior

    dart::dynamics::bodyNode::getJacobian(offset, dart::dynamcis::Frame::World) or dart::dynamics::bodyNode::getWorldJacobian(offset) returning a jacobian in world coordinates also when using a dart::dynamics::freejoint as first joint.

    Current Behavior

    given a dart::dynamics::freejoint the jacobian entries corresponding to the translational degrees of freedom of the joint (q[3:6]) seem to be incorrect.

    Steps to Reproduce

    1. create a bodyNode with a freeJoint
    2. set the a rotational degree of freedom of the joint, such that the body is not well aligned with the world frame (e.g. q[0] = 1)
    3. obtain the worldJacobian for the center of the bodyNode and observe the jacobian entries corresponding to the translational degrees of freedom of the joint (e.g worldJacobian[(3:6),(3:6)])
    4. observe that the entries of the jacobian are not an identity matrix.
    5. observe that when the translational degrees of freedom q[3:6] are set , the body translates along the x,y,z coordinates of the world frame.
    6. since the worldJacobian relates the positional changes of the body given in the world frame to the changes of the generalized coordinates, the jacobian entries for these translational should be an identity matrix.

    Code to Reproduce

    A minimal example to reproduce the observed behaviour is attached as python code. (just paste code provided in the attached .txt file in a .py file and execute with python 3) It provides further explanation and visualization of what behavior is observed.

    Further a little workaround which worked for my case is presented. Solved by multiplying the part of the returned jacobian matrix which corresponds to the translational degrees of freedom with the inverse of the relative Transform's orientation of the freejoint. Unfortunately, I am not able to provide a solution or fix for the C++ implementation.


    type: bug 
    opened by markuswnuk91 1
  • 6.12.1 fails to find pagmo and flann

    6.12.1 fails to find pagmo and flann

    pagmo2-2.18.0 and flann- are installed but it fails to find them:

    CMake Warning at cmake/DARTMacros.cmake:145 (message):
      Looking for pagmo - NOT found, to use dart-optimizer-pagmo, please install
    Call Stack (most recent call first):
      dart/optimizer/pagmo/CMakeLists.txt:3 (dart_check_optional_package)
    -- Performing Test BT_USE_DOUBLE_PRECISION
    -- Performing Test BT_USE_DOUBLE_PRECISION - Failed
    CMake Warning at cmake/DARTMacros.cmake:145 (message):
      Looking for flann - NOT found, to use dart-planning, please install flann
    Call Stack (most recent call first):
      dart/planning/CMakeLists.txt:3 (dart_check_optional_package)
    type: bug 
    opened by yurivict 0
  • Capsule shapes sink through the ground with ODE collision detector

    Capsule shapes sink through the ground with ODE collision detector

    Bug Report

    • [x] I checked the documentation and the forum but found no answer.
    • [x] I checked to make sure that this issue has not already been filed.


    • DART version: main
    • OS name and version name(or number): Ubuntu 20.04
    • Compiler name and version number: GCC 9.3

    Expected Behavior

    I expect the capsule shape to stay above the ground plane/box in all orientations of the capsule.

    Current Behavior

    A capsule on it's side placed on the ground slowly sinks through the ground. This doesn't happen if the capsule is vertical and only one hemisphere is in contact with the ground.

    A similar problem was fixed in https://github.com/dartsim/dart/pull/859 for Bullet as the collision detector. Would it be possible to apply something similar to ODE?

    Related: https://github.com/ignitionrobotics/ign-gazebo/issues/1306

    Steps to Reproduce

    1. Build code and tests from fork (branch azeey/issue1654)
    2. Run test_Issue1654.

    Code to Reproduce


    type: bug 
    opened by azeey 0
  • How to visualize a `3D polyhedron`

    How to visualize a `3D polyhedron`

    I want to visualize a three-dimensional polyhedron through its vertices ( i.e., the V-representation ).

    By investigating the support polygon, I noticed that we could feed vertices to a Polygon through the following snippet:

        for(std::size_t i=0; i < poly.size(); ++i)
          const Eigen::Vector3d& v = axes.first*poly[i][0] + axes.second*poly[i][1]
                                      + up*mElevation;
          (*mVertices)[i] = ::osg::Vec3(v[0], v[1], v[2]);
          (*mFaces)[i] = i;
        mPolygonGeom->setPrimitiveSet(0, mFaces);

    This example only manages to visualize planar polygon no matter how much I tweak it. Could anyone give me a solution?

    opened by wyqsnddd 0
  • v6.12.1(Jan 20, 2022)

  • v6.12.0(Jan 20, 2022)

    • API Breaking Changes

      • DART 6.12.0 and later require compilers that support C++17: #1600
        • Increased minimum CMake version to 3.10.2
        • Increased minimum compiler versions to GCC 7.3.0, Clang 6.0, MSVC 16.0
        • Dropped Ubuntu Xenial (16.04 LTS) support
    • Build

      • Remove DART_BUILD_DARTPY option: #1600
    • Dynamics

      • Added joint force/torque getter: #1616
    • Parsers

      • Added default options to DartLoader for missing properties in URDF files: #1605
      • Allowed SdfParser to set default root joint type: #1617
    • GUI

      • Updated ImGui to 1.84.2: #1608
    • dartpy

      • Added Python bindings for ResourceRetriever and SdfParser: #1610
    Source code(tar.gz)
    Source code(zip)
  • v6.11.1(Aug 25, 2021)

  • v6.11.0(Jul 15, 2021)

    • Math

      • Added Mesh, TriMesh, and Icosphere classes: #1579
    • Collision

      • Fixed incorrect group-group collision checking for BulletCollisionDetector: #1585, #717
    • Dynamics

      • Fixed servo motor doesn't respect joint position limits: #1587
    • GUI

      • Fixed incorrect MultiSphereConvexHull rendering: #1579
      • Use GLVND over the legacy OpenGL libraries: #1584
    • Build and testing

      • Add DART_ prefix to macros to avoid potential conflicts: #1586
    Source code(tar.gz)
    Source code(zip)
  • v6.10.1(Apr 19, 2021)

    • Dynamics

      • Fixed inertia calculation of CapsuleShape: #1561
    • GUI

      • Changed to protect OpenGL attributes shared by ImGui and OSG: #1558
      • Changed to set backface culling by default: #1559
    • dartpy

      • Added Python binding for BodyNode::getBodyForce(): #1563
    Source code(tar.gz)
    Source code(zip)
  • v6.10.0(Apr 10, 2021)

    • Common

      • Removed use of boost::filesystem in public APIs: #1417
      • Changed Signal to remove connection when they're being disconnected: #1462
    • Collision

      • Added ConeShape support for FCLCollisionDetector: #1447
      • Fixed segfault from raycast when no ray hit: #1461
      • Added PyramidShape class: #1466
    • Kinematics

      • Added IkFast parameter accessors to IkFast class: #1396
      • Changed IkFast to wrap IK solutions into the joint limits for RevoluteJoint: #1452
      • Added option to specify reference frame of TaskSpaceRegion: #1548
    • Dynamics

      • Fixed friction and restitution of individual shapes in a body: #1369
      • Fixed soft body simulation when command input is not reset: #1372
      • Added joint velocity limit constraint support: #1407
      • Added type property to constrain classes: #1415
      • Allowed to set joint rest position out of joint limits: #1418
      • Added secondary friction coefficient parameter: #1424
      • Allowed to set friction direction per ShapeFrame: #1427
      • Fixed incorrect vector resizing in BoxedLcpConstraintSolver: #1459
      • Changed to increment BodyNode version when it's being removed from Skeleton: #1489
      • Changed to print warning only once from BulletCollisionDetector::collide/distance: #1546
      • Added force dependent slip: #1505
    • GUI

      • Fixed memory leaks from dart::gui::osg::Viewer: #1349
      • Added point rendering mode to PointCloudShape: #1351, #1355
      • Updated ImGui to 1.71: #1362
      • Updated ImGui to 1.79: #1498
      • Fixed refresh of LineSegmentShapeNode: #1381
      • Fixed OSG transparent object sorting: #1414
      • Added modifier key support to ImGuiHandler: #1436
      • Fixed mixed intrinsic and extrinsic camera parameters in OpenGL projection matrix: #1485
      • Enabled mouse middle and right buttons in ImGuiHandler: #1500
    • Parser

      • Allowed parsing SDF up to version 1.6: #1385
      • Fixed SDF parser not creating dynamics aspect for collision shape: #1386
      • Added root joint parsing option in URDF parser: #1399, #1406
      • Enabled URDF parser to read visual and collision names: #1410
      • Added (experimental) MJCF parser: #1416
    • dartpy

      • Added raycast option and result: #1343
      • Added GUI event handler: #1346
      • Added shadow technique: #1348
      • Added findSolution and solveAndApply to InverseKinematics: #1358
      • Added InteractiveFrame and ImGui APIs: #1359
      • Added bindings for Joint::getTransformFrom{Parent|Child}BodyNode(): #1377
      • Added bindings for BodyNode::getChild{BodyNode|Joint}(): #1387
      • Added bindings for Inertia: #1388
      • Added bindings for getting all BodyNodes from a Skeleton: #1397
      • Added bindings for background color support in osg viewer: #1398
      • Added bindings for BallJoint::convertToPositions(): #1408
      • Fixed typos in Skeleton: #1392
      • Fixed enabling drag and drop for InteractiveFrame: #1432
      • Added bindings for point cloud and contact retrieval: #1455
      • Fixed TypeError from dartpy.dynamics.Node.getBodyNodePtr(): #1463
      • Added pybind/eigen.h to DistanceResult.cpp for read/write of eigen types: #1480
      • Added bindings for adding ShapeFrames to CollisionGroup: #1490
      • Changed dartpy install command to make install-dartpy: #1503
      • Added bindings for CollisionFilter, CollisionGroup, and Node: #1545
      • Added bindings for TaskSpaceRegion: #1550
    • Build and testing

      • Fixed compiler warnings from GCC 9.1: #1366
      • Replaced M_PI with dart::math::constantsd::pi(): #1367
      • Enabled octomap support on macOS: #1078
      • Removed dependency on Boost::regex: #1412
      • Added support new if() IN_LIST operator in DARTConfig.cmake: #1434
      • Updated Findfcl.cmake to support FCL 0.6: #1441
      • Added gtest macros for Eigen object comparisons: #1443
      • Removed gccfilter: #1464
      • Allowed to set CMAKE_INSTALL_PREFIX on Windows: #1478
      • Enforced to use OpenSceneGraph 3.7.0 or greater on macOS Catalina: #1479
      • Fixed compatibility with clang-cl: #1509
      • Fixed MSVC linking for assimp and fcl: #1510
      • Fixed AspectWithState-relate compile error on Windows: #1528
      • Made dart.pc relocatable: #1529
      • Added CI for multiple Linux platforms: arm64 and ppc64le: #1531
      • Fixed Aspect/Composite-relate tests on Windows/MSVC: #1541, #1542
      • Added DART_SKIP_<dep>_advanced option: #1529
      • Replaced OpenGL dependency variables with targets: #1552
    • Documentation

      • Updated tutorial documentation and code to reflect new APIs: #1481
    Source code(tar.gz)
    Source code(zip)
  • v6.9.5(Oct 17, 2020)

  • v6.9.4(Aug 30, 2020)

  • v6.9.3(Aug 27, 2020)

    • Dynamics

      • Changed to update the Properties version of a BodyNode when moved to a new Skeleton: #1445
      • Fixed incorrect implicit joint damping/spring force computation in inverse dynamics: #1451
    Source code(tar.gz)
    Source code(zip)
  • v6.9.2(Aug 28, 2019)

  • v6.9.1(Jun 6, 2019)

  • v6.9.0(May 27, 2019)

    • Common

      • Deprecated custom make_unique in favor of std::make_unique: #1317
    • Collision Detection

      • Added raycast query to BulletCollisionDetector: #1309
    • Dynamics

      • Added safeguard for accessing Assimp color: #1313
    • Parser

      • Changed URDF parser to use URDF material color when specified: #1295
    • GUI

      • Added heightmap support to OSG renderer: #1293
      • Improved voxel grid and point cloud rendering performance: #1294
      • Fixed incorrect alpha value update of InteractiveFrame: #1297
      • Fixed dereferencing a dangling pointer in WorldNode: #1311
      • Removed warning of ImGuiViewer + OSG shadow: #1312
      • Added shape type and color options to PointCloudShape: #1314, #1316
      • Fixed incorrect transparency of MeshShape for MATERIAL_COLOR mode: #1315
      • Fixed incorrect PointCloudShape transparency: #1330
      • Improved voxel rendering by using multiple nodes instead of CompositeShape: #1334
    • Examples and Tutorials

      • Updated examples directory to make dart::gui::osg more accessible: #1305
    • dartpy

      • Switched to pybind11: #1307
      • Added grid visual: #1318
      • Added ReferentialSkeleton, Linkage, and Chain: #1321
      • Enabled WorldNode classes to overload virtual functions in Python: #1322
      • Added JacobianNode and operational space controller example: #1323
      • Removed static create() functions in favor of custom constructors: #1324
      • Added optimizer APIs with GradientDescentSolver and NloptSolver: #1325
      • Added SimpleFrame: #1326
      • Added basic inverse kinematics APIs: #1327
      • Added shapes and ShapeFrame aspects: #1328
      • Added collision APIs: #1329
      • Added DegreeOfFreedom and ShapeNode: #1332
      • Added constraint APIs: #1333
      • Added BallJoint, RevoluteJoint, joint properties, and chain tutorial (incomplete): #1335
      • Added all the joints: #1337
      • Added DART, Bullet, Ode collision detectors: #1339
    Source code(tar.gz)
    Source code(zip)
  • v6.8.5(May 26, 2019)


    • Collision

      • Fixed handling of submeshes in ODE collision detector: #1336

    Compilers Tested

    • Linux

      • GCC 64-bit: 5.4.0, 7.3.0, 8.2.0
      • GCC 32-bit: 5.4.0
    • macOS

      • AppleClang: 9.1.0, 10.0.0
    Source code(tar.gz)
    Source code(zip)
  • v6.8.4(May 26, 2019)


    • GUI

      • Fixed crashing on exiting OSG + ImGui applications: #1303

    Compilers Tested

    • Linux

      • GCC 64-bit: 5.4.0, 7.3.0, 8.2.0
      • GCC 32-bit: 5.4.0
    • macOS

      • AppleClang: 9.1.0, 10.0.0
    Source code(tar.gz)
    Source code(zip)
  • v6.8.3(May 26, 2019)


    • Parser

      • Fixed VskParker returning incorrect resource retriever: #1300
    • Build

      • Fixed building with pagmo's optional dependencies: #1301

    Compilers Tested

    • Linux

      • GCC 64-bit: 5.4.0, 7.3.0, 8.2.0
      • GCC 32-bit: 5.4.0
    • macOS

      • AppleClang: 9.1.0, 10.0.0
    Source code(tar.gz)
    Source code(zip)
  • v6.8.2(Apr 24, 2019)


    • Dynamics

      • Fixed BoxedLcpConstraintSolver is not API compatible with 6.7: #1291
    • Build

      • Fixed building with FCL built without Octomap: #1292

    Compilers Tested

    • Linux

      • GCC 64-bit: 5.4.0, 7.3.0, 8.2.0
      • GCC 32-bit: 5.4.0
    • macOS

      • AppleClang: 9.1.0, 10.0.0
    Source code(tar.gz)
    Source code(zip)
  • v6.8.1(Apr 23, 2019)


    • Build System

      • Fixed invalid double quotation marks in DARTFindBoost.cmake: #1283
      • Disabled octomap support on macOS: #1284

    Compilers Tested

    • Linux

      • GCC 64-bit: 5.4.0, 7.3.0, 8.2.0
      • GCC 32-bit: 5.4.0
    • macOS

      • AppleClang: 9.1.0, 10.0.0
    Source code(tar.gz)
    Source code(zip)
  • v6.8.0(Apr 23, 2019)


    • Kinematics

      • Added findSolution() and solveAndApply() to InverseKinematics and HierarchicalIk classes and deprecated solve(~) member functions: #1266
      • Added an utility constructor to Linkage::Criteria to create sequence Linkage: #1273
    • Dynamics

      • Fixed incorrect transpose check in Inertia::verifySpatialTensor(): #1258
      • Allowed BoxedLcpConstraintSolver to have a secondary LCP solver: #1265
    • Simulation

      • The LCP solver will be less aggressive about printing out unnecessary warnings: #1238
      • Fixed not copying constraints in World::setConstraintSolver(): #1260
    • Collision Detection

      • The BodyNodeCollisionFilter will ignore contacts between immobile bodies: #1232
    • Planning

      • Fixed linking error of FLANN by explicitly linking to lz4: #1221
    • Python

      • Added (experimental) Python binding: #1237
    • Parsers

      • Changed urdf parser to warn if robot model has multi-tree: #1270
    • GUI

      • Updated ImGui to 1.69: #1274
      • Added VoxelGridShape support to OSG renderer: #1276
      • Added PointCloudShape and its OSG rendering: #1277
      • Added grid visual to OSG renderer: #1278, #1280
    • Build System

      • Changed to use GNUInstallDirs for install paths: #1241
      • Fixed not failing for missing required dependencies: #1250
      • Fixed attempting to link octomap when not imported: #1253
      • Fixed not defining boost targets: #1254

    Compilers Tested

    • Linux

      • GCC 64-bit: 5.4.0, 7.3.0, 8.2.0
      • GCC 32-bit: 5.4.0
    • macOS

      • AppleClang: 9.1.0, 10.0.0
    Source code(tar.gz)
    Source code(zip)
  • v6.7.3(Feb 26, 2019)


    • Dynamics

      • Fixed Skeleton::setState(): #1245

    Compilers Tested

    • Linux

      • GCC (C++11): 5.4.0, 7.3.0, 8.2.0
    • Linux (32-bit)

      • GCC (C++11): 5.4.0
    • macOS

      • AppleClang (C++11): 9.1.0
    Source code(tar.gz)
    Source code(zip)
  • v6.7.2(Jan 18, 2019)


    • Build system

      • Fixed #1223 for the recursive case: #1227
      • Specified mode for find_package(): #1228

    Compilers Tested

    • Linux

      • GCC (C++11): 5.4.0, 7.3.0, 8.2.0
    • Linux (32-bit)

      • GCC (C++11): 5.4.0
    • macOS

      • AppleClang (C++11): 9.1.0
    Source code(tar.gz)
    Source code(zip)
  • v6.7.1(Jan 15, 2019)


    • Build system

      • Ensure that imported targets of dependencies are always created when finding the dart package: #1222
      • Set components to not-found when their external dependencies are missing: #1223

    Compilers Tested

    • Linux

      • GCC (C++11): 5.4.0, 7.3.0, 8.2.0
    • Linux (32-bit)

      • GCC (C++11): 5.4.0
    • macOS

      • AppleClang (C++11): 9.1.0
    Source code(tar.gz)
    Source code(zip)
  • v6.7.0(Jan 10, 2019)


    • Build system

      • Fixed compilation warnings for newer versions of compilers: #1177
      • Changed to generate namespace headers without requiring *.hpp.in files: #1192
      • Dropped supporting Ubuntu Trusty and started using imported targets of dependencies: #1212
    • Collision Detection

      • CollisionGroups will automatically update their objects when any changes occur to Skeletons or BodyNodes that they are subscribed to: #1112
      • Contact points with negative penetration depth will be ignored: #1185
    • Math

      • Consolidated random functions into Random class: #1109
    • Dynamics

      • Refactor constraint solver: #1099, #1101
      • Added mimic joint functionality as a new actuator type: #1178
      • Added clone function to MetaSkeleton: #1201
    • Optimization

      • Added multi-objective optimization with pagmo2 support: #1106
    • GUI

      • Reorganized OpenGL and GLUT files: #1088
      • Added the RealTimeWorldNode to display simulations at real-time rates: #1216
    • Misc

      • Updated Googletest to version 1.8.1: #1214

    Compilers Tested

    • Linux

      • GCC (C++11): 5.4.0, 7.3.0, 8.2.0
    • Linux (32-bit)

      • GCC (C++11): 5.4.0
    • macOS

      • AppleClang (C++11): 9.1.0
    Source code(tar.gz)
    Source code(zip)
  • v6.6.2(Sep 13, 2018)

  • v6.6.1(Aug 26, 2018)

  • v6.6.0(Aug 3, 2018)

  • v6.5.0(May 13, 2018)

    • Common

      • Added LockableReference classes: #1011
      • Added missing <vector> to Memory.hpp: #1057
    • GUI

      • Added FOV API to OSG viewer: #1048
    • Parsers

      • Fixed incorrect parsing of continuous joints specified in URDF #1064
    • Simulation

      • Added World::hasSkeleton(): #1050
    • Misc

      • Fixed memory leaks in mesh loading: #1066
    Source code(tar.gz)
    Source code(zip)
  • v6.4.0(Mar 27, 2018)

    • Common

      • Added ResourceRetriever::getFilePath(): #972
    • Kinematics/Dynamics

      • Added relative Jacobian functions to MetaSkeleton: #997
      • Added vectorized joint limit functions: #996
      • Added lazy evaluation for shape's volume and bounding-box computation: #959
      • Added IkFast support as analytic IK solver: #887
      • Added TranslationalJoint2D: #1003
      • Fixed NaN values caused by zero-length normals in ContactConstraint: #881
      • Extended BodyNode::createShapeNode() to accept more types of arguments: #986
    • Collision detection

      • Added FCL 0.6 support (backport of #873): #936
    • GUI

      • Added support of rendering texture images: #973
      • Added OSG shadows: #978
    • Examples

      • Added humanJointLimits: #1016
    • License

      • Added Personal Robotics Lab and Open Source Robotics Foundation as contributors: #929
    • Misc

      • Added World::create(): #962
      • Added MetaSkeleton::hasBodyNode() and MetaSkeleton::hasJoint(): #1000
      • Suppressed -Winjected-class-name warnings from Clang 5.0.0: #964
      • Suppressed -Wdangling-else warnings from GCC 7.2.0: #937
      • Changed console macros to use global namespace resolutions: #1010
      • Fixed build with Eigen 3.2.1-3.2.8: #1042
      • Fixed various build issues with Visual Studio: #956
      • Removed TinyXML dependency: #993
    Source code(tar.gz)
    Source code(zip)
  • v6.3.1(Mar 22, 2018)

  • v6.3.0(Feb 5, 2018)

    • Collision detection

      • Added a feature of disabling body node pairs to BodyNodeCollisionFilter: #911
    • Kinematics/Dynamics

      • Added setter and getter for WeldJointConstraint::mRelativeTransform: #910
    • Parsers

      • Improved SkelParser to read alpha value: #914
    • Misc

      • Changed not to use lambda function as an workaround for DART python binding: #916
    Source code(tar.gz)
    Source code(zip)
  • v6.2.0(May 16, 2017)

DART: Dynamic Animation and Robotics Toolkit
DART: Dynamic Animation and Robotics Toolkit
Best practices, conventions, and tricks for ROS. Do you want to become a robotics master? Then consider graduating or working at the Robotics Systems Lab at ETH in Zürich!

ROS Best Practices, Conventions and Tricks Best practices for ROS2 in the making. See the Foxy branch in the meanwhile. This is a loose collection of

Robotic Systems Lab - Legged Robotics at ETH Zürich 1.1k Jun 24, 2022
ozz-animation provides runtime character animation playback functionalities (loading, sampling, blending...)

ozz-animation open source c++ 3d skeletal animation library and toolset ozz-animation provides runtime character animation playback functionalities (l

Guillaume Blanc 1.7k Jun 27, 2022
This is a compilation of the code and images for all Arduino code in the Robotics 11 class.

Robotics 11 - Arduino This is a compilation of the code and images for all Arduino code in the Robotics 11 class. All code can be viewed in each proje

GuhBean 1 Oct 29, 2021
AWS Ambit Scenario Designer for Unreal Engine 4 (Ambit) is a suite of tools to streamline content creation at scale for autonomous vehicle and robotics simulation applications.

AWS Ambit Scenario Designer for Unreal Engine 4 Welcome to AWS Ambit Scenario Designer for Unreal Engine 4 (Ambit), a suite of tools to streamline 3D

AWS Samples 43 Jun 20, 2022
This repo includes SVO Pro which is the newest version of Semi-direct Visual Odometry (SVO) developed over the past few years at the Robotics and Perception Group (RPG).

rpg_svo_pro This repo includes SVO Pro which is the newest version of Semi-direct Visual Odometry (SVO) developed over the past few years at the Robot

Robotics and Perception Group 908 Jun 27, 2022
A ROS based Open Source Simulation Environment for Robotics Beginners

A ROS based Open Source Simulation Environment for Robotics Beginners

Sulegeyixiu 101 Jun 25, 2022
Software Running on the VEX V5 Brain for the USF IEEE VEX Robotics Team.

This is an ongoing Project at USF IEEE VEX Team for VEX Head-to-Head 2022 This is the software running on our USF Big-Bull-Bot, specified to compete i

John Koch 1 Jan 9, 2022
Decentralized architecture for loss tolerant semi-autonomous robotics

gestalt-arch Decentralized architecture for loss tolerant semi-autonomous robotics Objective We demonstrate a decentralized robot control architecture

null 4 Dec 18, 2021
Bau Bau is a DIY 4 legged quadruped robot inspired for construction robotics course.

Bau-Bau-Robot Bau Bau is a DIY 4 legged quadruped robot inspired for construction robotics course. In this course, we are looking forward to solve a p

Adithya Chinnakkonda 1 Nov 19, 2021
Card_detect and show animation

Collector 收集者 Card_detect and show animation 在全志D1上玩卡牌识别播放动画 项目来源于Kirin。其项目创意及初衷见帖下方评论:https://bbs.aw-ol.com/topic/223/ 具体实现过程也在帖子中 ?? ?? ?? 视频连接: 名字由

BedRock 8 May 23, 2022
Digital rain animation gif with glow squeezed into a raspberry pi pico and pimoroni pico-display

pico-display-matrix Digital rain animation gif with glow squeezed into a raspberry pi pico and pimoroni pico-display or how to actually use all Flash

null 28 Apr 3, 2022
A simple, modern C++ animation and timing library.

Choreograph A simple, modern C++ animation and timing library. v0.4.0 Choreograph is designed to describe motion. With it, you compose motion Phrases

David Wicks 284 Jun 14, 2022
The FastLED library for colored LED animation on Arduino.

The FastLED library for colored LED animation on Arduino. Please direct questions/requests for help to the FastLED Reddit community: http://fastled.io/r We'd like to use github "issues" just for tracking library bugs / enhancements.

FastLED 5.3k Jun 27, 2022
A custom OLED animation for QMK keyboards

superloop This animation is made for 32x128 pixel 1-bit OLED displays. Info This repository is a lightweight clone of the crkdb:default QMK configurat

hexcowboy 24 Jun 16, 2022
qmk based oled bongo cat animation

oledbongocat qmk based oled bongo cat animation step 1: append OLED enable and WPM enable to your rules.mk (see last lines of my rules.mk) step 2: in

null 69 Jun 19, 2022
OpenToonz - An open-source full-featured 2D animation creation software

OpenToonz 日本語 What is OpenToonz? OpenToonz is a 2D animation software published by DWANGO. It is based on Toonz Studio Ghibli Version, originally deve

OpenToonz 3.5k Jul 3, 2022
🎮 Plants vs. Zombies multiplayer battle, developed via reverse engineering, inline hook and dynamic-link library injection. Two online players defend and attack as the plant side and zombie side respectively.

Plants vs. Zombies Online Battle This project has two original repositories: https://github.com/czs108/Plants-vs.-Zombies-Online-Battle https://github

Liugw 71 Oct 14, 2021
The Synthesis ToolKit in C++ (STK) is a set of open source audio signal processing and algorithmic synthesis classes written in the C++ programming language.

The Synthesis ToolKit in C++ (STK) By Perry R. Cook and Gary P. Scavone, 1995--2021. This distribution of the Synthesis ToolKit in C++ (STK) contains

null 783 Jun 23, 2022
MDE is a model extraction tool that converts Destiny 2 dynamic models into fbx files supporting textures, skeletons, and all provided vertex data.

MDE is a model extraction tool that converts Destiny 2 dynamic models into fbx files. A dynamic model is one that is animated or is spawned in during the game.

Montague 31 Jun 20, 2022