Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Preliminary] Nodes and Addons #531

Merged
merged 117 commits into from
Jan 31, 2016
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
117 commits
Select commit Hold shift + click to select a range
eeb6221
implementing Addon and AddonManager
mxgrey Jul 30, 2015
3b35ee6
finished implementation of the AddonManager -- needs testing
mxgrey Jul 30, 2015
87b3166
implementing State and Properties for AddonManager
mxgrey Jul 31, 2015
0002f94
implemented Addon mechanics and writing tests
mxgrey Aug 2, 2015
dac3ae0
finished Addon & AddonManager implementation and testing
mxgrey Aug 3, 2015
2e6b5c5
fixed documentation of macro
mxgrey Aug 3, 2015
3a00af8
altering Node management -- strange indexing bug happening
mxgrey Aug 3, 2015
29a11c0
fixed undefined behavior issue
mxgrey Aug 4, 2015
40f3fd5
changed Addon State and Properties to use less dynamic allocation
mxgrey Aug 4, 2015
9ea14a6
created Extensible class to give a common interface to all extensible…
mxgrey Aug 4, 2015
e20743d
store Nodes in a way that allows us to return vectors of Nodes by ref…
mxgrey Aug 5, 2015
84170f2
add string header to Addon.h
mxgrey Aug 5, 2015
cbde581
created ExtendedProperties for BodyNode
mxgrey Aug 5, 2015
a1edd21
implemented ExtendedProperties setting
mxgrey Aug 5, 2015
878c978
refactored Node semantics to be more extensible
mxgrey Aug 5, 2015
d9da5e9
ensuring that Nodes are copied over in the same order as the original
mxgrey Aug 5, 2015
cf511ab
making sure that Addons get cloned over
mxgrey Aug 5, 2015
839ea29
pass over test that correctly triggers assertion in debug mode
mxgrey Aug 6, 2015
f9ed758
corrected const incorrectness
mxgrey Aug 7, 2015
b17d0a0
beginning changes to allow indexing Nodes within the Skeleton
mxgrey Aug 13, 2015
468002e
generalizing Node name management
mxgrey Aug 13, 2015
7137d08
Merge branch 'grey/analytical' into grey/addons
mxgrey Aug 13, 2015
a3d30de
patching up changes
mxgrey Aug 13, 2015
4979c59
designing the machinery needed to specialize Nodes within Skeletons
mxgrey Aug 14, 2015
d01178f
created macros for specializing Nodes within Skeletons
mxgrey Aug 14, 2015
5211a7d
implemented Skeleton-scope Node access -- needs testing
mxgrey Aug 14, 2015
d58690c
debugged Skeleton-scope Node access -- appears to be working
mxgrey Aug 14, 2015
e59beb3
swapped arguments for getting tree nodes
mxgrey Aug 14, 2015
61f06c8
created test for generic nodes
mxgrey Aug 17, 2015
86c976c
changed the Support class into an official Addon
mxgrey Aug 17, 2015
521891c
merged in latest upstream changes
mxgrey Aug 18, 2015
a66fc66
made Extensibles easier to extend
mxgrey Aug 18, 2015
e7f6249
Merge branch 'grey/analytical' into grey/addons
mxgrey Aug 18, 2015
62430bd
do not attempt to clone nullptrs
mxgrey Aug 19, 2015
4134152
make analytical ik implementations clonable
mxgrey Aug 19, 2015
52ad9e5
fixed undefined behavior
mxgrey Aug 19, 2015
77e9b9c
transparency seems to work somewhat better without the transparency bin
mxgrey Aug 19, 2015
7a6aa44
unprotect the typedef
mxgrey Aug 19, 2015
00e5ec3
Merge branch 'grey/analytical' into grey/addons
mxgrey Aug 24, 2015
6c46071
Merge branch 'grey/analytical' into grey/addons
mxgrey Aug 28, 2015
06e39af
treat nullptr objective as a constant zero function
mxgrey Aug 28, 2015
7da22af
Merge branch 'grey/urdf_world_parse_fix' into grey/addons
mxgrey Sep 1, 2015
4ef6be7
Merge branch 'grey/urdf_world_parse_fix' into grey/addons
mxgrey Sep 1, 2015
3c15845
replaced ugly macro with elegant template for Extensible mixins
mxgrey Sep 11, 2015
418dc67
make sure that the ordering of cloned nodes will match the ordering o…
mxgrey Sep 11, 2015
cd0d25e
fixed recording toggle bug
mxgrey Sep 16, 2015
e98d37d
Merge branch 'master' of http://github.com/dartsim/dart into grey/addons
mxgrey Sep 17, 2015
338d2c9
finished implementing extensions for EndEffector and tested it with Hubo
mxgrey Sep 18, 2015
8425fc2
added Jetbrains directory to git ignore list
mxgrey Sep 18, 2015
8b4d73f
removed debug printouts
mxgrey Sep 18, 2015
10d5bfa
altered the default behavior for getNodeState and getNodeProperties
mxgrey Sep 18, 2015
1a79f4a
removed the move semantics for Node::State and Node::Properties, beca…
mxgrey Sep 18, 2015
1fcb734
adjusting fix for issue #499 to fit into the Node framework
mxgrey Sep 20, 2015
72f5938
merged in better approach for tracking JacobianNodes
mxgrey Sep 20, 2015
1ba3f8d
Merge branch 'grey/addons' of http://github.com/dartsim/dart into gre…
mxgrey Sep 23, 2015
1b080b1
offering performant version of copying states and properties
mxgrey Sep 23, 2015
33d77d7
implemented Skeleton configurations
mxgrey Sep 23, 2015
beaee49
fixed assignment typo bug
mxgrey Sep 24, 2015
8461bc1
merged in changes for 5.1
mxgrey Sep 30, 2015
09a60df
merged in latest analytical branch
mxgrey Sep 30, 2015
38f2f39
merged in changes to IK modules
mxgrey Oct 2, 2015
0e8261c
Merge remote-tracking branch 'origin/grey/analytical' into grey/addons
mxgrey Oct 5, 2015
3f390da
Merge branch 'grey/analytical' into grey/addons
mxgrey Oct 5, 2015
00310f3
making Skeleton::ExtendedProperties and convenience classes for creat…
mxgrey Oct 6, 2015
2612a49
Merge branch 'grey/addons' of https://github.com/dartsim/dart into gr…
mxgrey Oct 6, 2015
1ff2d54
renamed Addon::clone function to Addon::cloneAddon to avoid name coll…
mxgrey Oct 6, 2015
517bf80
further implementing Addon convenience classes
mxgrey Oct 6, 2015
3955285
defining Addon convenience classes
mxgrey Oct 7, 2015
54a14f5
continuing to implement Addon convenience classes
mxgrey Oct 8, 2015
1a50533
patching up some compilation errors
mxgrey Oct 8, 2015
52dfb53
creating more direct accessor functions using templates
mxgrey Oct 8, 2015
dedb9ce
finished implementing Addon convenience classes
mxgrey Oct 9, 2015
92108e9
including Skeleton in dynamics/Addon.h
mxgrey Oct 9, 2015
df23eab
using the specialized Skeleton Addon for the Support class
mxgrey Oct 9, 2015
85d8954
beginning to implement Joint property addons
mxgrey Oct 12, 2015
8660680
finished creating most-derived Joint property addons
mxgrey Oct 13, 2015
d711b28
created index-based set/get macro for Addon Properties
mxgrey Oct 13, 2015
3ddcbff
creating Addon for SingleDofJoint properties
mxgrey Oct 13, 2015
c8d57be
implementing SingleDofJointAddon -- not finished
mxgrey Oct 14, 2015
dd7aabf
need to work out a circular dependency
mxgrey Oct 14, 2015
7b6d6ef
finished all Joint Addons except MultiDofJoint
mxgrey Oct 17, 2015
0007532
finished implementing all Joint addons
mxgrey Oct 19, 2015
86c548e
merged in latest master changes
mxgrey Oct 19, 2015
5ad56d2
changed const unique_ptr& to const Data& argument
mxgrey Oct 19, 2015
03e7757
remove outdated comments
mxgrey Oct 19, 2015
5448d04
changed const unique_ptr& to const Data& for Node State and Propertie…
mxgrey Oct 19, 2015
6bf9bf2
corrected CRTP Addon implementations to use the new interface
mxgrey Oct 19, 2015
0304a24
fixing clang compilation errors -- still need to fix linking errors
mxgrey Oct 19, 2015
a182162
making Clang happy
mxgrey Oct 20, 2015
92b4b01
Merge branch 'grey/analytical' into grey/addons
mxgrey Oct 25, 2015
d2c3b95
implementing a CRTP method for specializing Addons
mxgrey Nov 19, 2015
336c4c4
fixed typos
mxgrey Nov 19, 2015
8f22d12
continuing CRTP implementation of Addon specialization
mxgrey Dec 8, 2015
40eef30
fixed typos in implementation
mxgrey Dec 9, 2015
e6b81f2
updated test to use CRTP instead of macros
mxgrey Dec 9, 2015
4dabe28
integrating Specialized Addon changes into the main codebase
mxgrey Dec 11, 2015
c34aa86
almost finished with implementation of SpecializedJoiner
mxgrey Dec 15, 2015
ee20d57
finished completely replacing the macro implementation of Addon speci…
mxgrey Dec 15, 2015
2716e74
renaming Addon Specialization classes to avoid collisions with Node S…
mxgrey Dec 16, 2015
747dd5c
beginning implementation of CRTP-based Node Specialization
mxgrey Dec 16, 2015
efd04d7
finished implementation of BasicNodeManager -- replaces macro-based s…
mxgrey Jan 6, 2016
4669f72
removed the need for deferred_enable_if
mxgrey Jan 6, 2016
a343d3a
implemented NodeManagerJoiner classes
mxgrey Jan 6, 2016
fadb2ec
finished implementation of SpecializedNodeManagers
mxgrey Jan 7, 2016
c07f7db
finished implementation and integration of SpecializedNodeManagers
mxgrey Jan 7, 2016
4ec1be8
Merge branch 'master' into grey/addons_merging_master
jslee02 Jan 21, 2016
2194f99
Make Visual Studio 2015 the minimum requirement
jslee02 Jan 22, 2016
b10b4a3
Use constexpr without checking compiler as Visual Studio 2015 became …
jslee02 Jan 22, 2016
bded530
Merge pull request #591 from dartsim/grey/addons_merging_master
jslee02 Jan 22, 2016
acfe8d2
making specialized managers virtual
mxgrey Jan 27, 2016
acf7573
Merge remote-tracking branch 'origin/master' into grey/addons_js_revi…
jslee02 Jan 30, 2016
4804229
Change note for developers to doxygen comment
jslee02 Jan 30, 2016
b329483
Remove _isSpecializedFor() from AddonManager
jslee02 Jan 30, 2016
b97d7f5
Do nothing when attempting to duplicate addons into itself
jslee02 Jan 30, 2016
668d334
Add missing constructor definition, and add move constructor to Joint…
jslee02 Jan 30, 2016
585cf4c
Add typename keyword to specify it's type name
jslee02 Jan 30, 2016
7b7a4b1
Merge pull request #598 from dartsim/grey/addons_js_revision
jslee02 Jan 30, 2016
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -20,6 +20,7 @@ TAGS
*.manifest
*.rsp
*~
.idea/*
/nbproject/
/doxygen/html/
docs/readthedocs/site
95 changes: 95 additions & 0 deletions dart/common/Addon.cpp
Original file line number Diff line number Diff line change
@@ -0,0 +1,95 @@
/*
* Copyright (c) 2015, Georgia Tech Research Corporation
* All rights reserved.
*
* Author(s): Michael X. Grey <[email protected]>
*
* Georgia Tech Graphics Lab and Humanoid Robotics Lab
*
* Directed by Prof. C. Karen Liu and Prof. Mike Stilman
* <[email protected]> <[email protected]>
*
* This file is provided under the following "BSD-style" License:
* Redistribution and use in source and binary forms, with or
* without modification, are permitted provided that the following
* conditions are met:
* * Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* * Redistributions in binary form must reproduce the above
* copyright notice, this list of conditions and the following
* disclaimer in the documentation and/or other materials provided
* with the distribution.
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
* CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
* CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
* AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
* ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/

#include <cassert>
#include <string>
#include <iostream>

#include "dart/common/Addon.h"
#include "dart/common/Console.h"

namespace dart {
namespace common {

//==============================================================================
void Addon::setAddonState(const State& /*otherState*/)
{
// Do nothing
}

//==============================================================================
const Addon::State* Addon::getAddonState() const
{
return nullptr;
}

//==============================================================================
void Addon::setAddonProperties(const Properties& /*someProperties*/)
{
// Do nothing
}

//==============================================================================
const Addon::Properties* Addon::getAddonProperties() const
{
return nullptr;
}

//==============================================================================
bool Addon::isOptional(AddonManager* /*oldManager*/)
{
return true;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this function is for the legality check of removing from the manager, I think it should to be determined by its manager rather than by itself. If the decision is tied to the addon, we cannot create addons of the addon type from two managers, where one is general manager (or specialized manager but not for the addon) and the other one is a specialized manager for the addon, expecting one is specialized and the other is not specialized.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was my original plan, but I had a very hard time thinking of a clean way to implement that. I found it much easier to have that information embedded in the Addon rather than trying to get it into the SpecializedAddonManager.

It should be noted that this function provides the Addon with a pointer to its manager, so the Addon can determine whether it's required for this particular type of manager. So if we have a FooAddon that's "required" only for a FooManager but we attach it to a GeneralManager, then the function FooAddon::isOptional(AddonManager* mgr) can dynamic_cast the mgr argument to a FooManager*. If the dynamic_cast fails, then FooAddon::isOptional will return true, if the cast succeeds then it will return false.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I'm not sure if we really need this function. (If there wouldn't be any additional use case,) It's currently used in AddonManager and SpecializedManager to check the legality of removing from the managers. In AddonManager, we might don't need it since all the addons in AddonManager are not specialized. For SpecializedAddonManager, we can check the legality in more simple way. For example, erase() function can be implemented as:

template <class SpecAddon>
template <class T>
void SpecializedAddonManager<SpecAddon>::erase()
{
  if (typeid( T ).name() == mSpecAddonIterator->first.name())
  {
    std::cout << "Attempting to erase specialized addon, which is not allowed.\n";
    return;
  }

  AddonManager::erase<T>();
//  _erase(type<T>());
}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The thing is, not all specialized addons are required. For example, for ShapeNode, we will have a VisualData and a CollisionData specialized addon, but neither of them are required to be there, because their absence just means that the ShapeNode doesn't want to visualize or doesn't want to collide. On the other hand, RevoluteJoint has a RevoluteJointAddon which contains axis properties, and that addon is required because the dynamics and kinematics computations can't work without it.

A specialized addon just allows us to have constant-time access to it, and does not imply that the addon is required.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It makes sense, but I wonder if there is a use case that the optionality should be checked from addon instead of from the specific manager we want to check. We can check it from FooManager and GeneralManager for FooAddon for the above case.

Even though there are use cases, isOptional() doesn't seem to work as we expect. For example, AddonWithProtectedPropertiesInSkeleton::isOptional() would always return true regardless the passed in manager type if true is passed in for the template parameter OptionalT.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as whether I expect the behavior of (1) or (2) it will depend on whether we have MandatoryAddon also specialize the addon. I think we should, because why not? If an addon is going to be mandatory, we may as well specialize it as well, because clearly we expect it to exist.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It sounds like the map can have any addons regardless of each addon is optional or mandatory. Hm, I'm more confused, haha. Here is my understanding. Please let me know which one is different from you.

  • Unspecialized addons are always optional.
  • Specialized addons can be one of optional and mandatory.

In that sense, it seems the mandatory addons should be a subset of specialized addons. So I stored the optionality value within specialized addon map (that is stored in the basic addon manager) in the code, and worried the attemptions to set the optionality when the associated addon hasn't added yet.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really agree with the subset relationship. Here's how I think it should work:

  • A manager that is specialized for an addon type will offer zero-overhead access to that addon
  • If an addon is mandatory for a certain manager type, then there must be no possible way to remove the addon from that manager

These are two completely independent concepts. The only point at which they overlap is that if an addon is mandatory for a certain manager type, then we may as well also specialize the manager for that addon.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see your point. What I'm not clear is why we open the case that an addon is mandatory but not specialized. Wouldn't it be too strong restriction if we enforce the user to use specialized manager for every mandatory addons so that the user can always take the advantage of the zero-overhaed access to that addon?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, I agree. I think the concepts of specialized and mandatory are inherently independent, but if an addon is important enough to be mandatory, then we may as well have the API also specialize it, especially since it would be as easy as having MandatoryAddon virtually inherit SpecializedAddonManager.

}

//==============================================================================
Addon::Addon(AddonManager* manager)
{
if(nullptr == manager)
{
dterr << "[Addon::constructor] You are not allowed to construct an Addon "
<< "outside of an AddonManager!\n";
assert(false);
}
}

//==============================================================================
void Addon::setManager(AddonManager* /*newManager*/, bool /*transfer*/)
{
// Do nothing
}

} // namespace common
} // namespace dart
Loading