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

PropertyMap implementation #11

Merged
merged 16 commits into from
Feb 17, 2018
Merged

PropertyMap implementation #11

merged 16 commits into from
Feb 17, 2018

Conversation

rhaschke
Copy link
Contributor

@rhaschke rhaschke commented Dec 13, 2017

Replacement for #9, implementing the PropertyMap we discussed a while ago.
Using this PropertyMap I also generalized the grasp frame specification for GenerateGraspPose - getting rid of hard-coded YPR angles. This allows for our PA10 example to be included easily.
I merged already with master to fix conflicts due to reordering of source files in cmake.

@rhaschke rhaschke requested a review from v4hn December 15, 2017 11:01
@rhaschke
Copy link
Contributor Author

@v4hn Could you please have a look?

replacing scalar graspOffset and hard-coded Euler angles with arbitrary graspFrame
Use different function names for different semantics.
setValue() also updates the default value.
reset() reset to the default value.
setCurrentValue() only updates the current value, keeping current default.
Thus setCurrentValue() can be reverted (to default) using reset().
First from INTERFACE, second from PARENT.

INTERFACE initialization only makes sense for Propagating stages.
Connecting stages should ensure that interfaces define identical
properties which is not possible with boost::any.
throw std::logic_error on type errors
throw std::runtime_error on undeclared property
don't expose generic PropertyMap::declare()
@rhaschke rhaschke mentioned this pull request Feb 5, 2018
@v4hn
Copy link
Contributor

v4hn commented Feb 17, 2018

ok, so this request has a number of small issues, but you already addressed and reworked some of them in the latter requests.

It compiles (up to one vector include on my machine) and runs, so I will merge it to get on with the other requests.

@v4hn v4hn merged commit c68c4cb into master Feb 17, 2018
@v4hn
Copy link
Contributor

v4hn commented Feb 17, 2018

I should have fast-forwarded. This made the history even harder to read... sigh

@v4hn v4hn deleted the wip-properties branch February 17, 2018 17:02
@rhaschke
Copy link
Contributor Author

rhaschke commented Feb 17, 2018

I should have fast-forwarded. This made the history even harder to read... sigh

Oh no. Really? This will become a nightmare now. I have put so much effort to keep a clear history tree.
Why not fast-forwarding in hind-sight, i.e. force-pushing master to e936391? Nobody else than us is using this repo.

sea-bass added a commit to sea-bass/moveit_task_constructor that referenced this pull request Dec 8, 2022
sea-bass added a commit to sea-bass/moveit_task_constructor that referenced this pull request Mar 10, 2023
sjahr pushed a commit to sjahr/moveit_task_constructor that referenced this pull request May 3, 2023
sjahr pushed a commit to sjahr/moveit_task_constructor that referenced this pull request May 30, 2023
mechwiz pushed a commit to mechwiz/moveit_task_constructor that referenced this pull request May 30, 2023
mechwiz pushed a commit to mechwiz/moveit_task_constructor that referenced this pull request Jul 19, 2023
mechwiz pushed a commit to mechwiz/moveit_task_constructor that referenced this pull request Jul 21, 2023
mechwiz pushed a commit to mechwiz/moveit_task_constructor that referenced this pull request Jul 24, 2023
mechwiz pushed a commit to mechwiz/moveit_task_constructor that referenced this pull request Jul 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants