-
Notifications
You must be signed in to change notification settings - Fork 102
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
Use first trajectory point as start state for visualization #49
Use first trajectory point as start state for visualization #49
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This already looks good to me, perhaps you could still emit a warning or an info message that the start state should be defined.
I've restarted the CI jobs, 3/3 "succeeded", 2/3 failed on a post-build timeout :-/ |
Travis error:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you looked into the failing GPU test?
@henningkayser can you compare .travis.yml from /moveit repo to this repo? maybe there are some changes we need to bring in to fix travis? |
@davetcoleman, there is an open PR (#47) to address the Travis issues waiting for your approval since a month or so. |
I had forgot about that PR, thanks Robert! |
Closing & re-opening to trigger Travis rebuild. |
When visualizing trajectories of subgroups the previous implementation would use the shared initial robot state for populating the joint values outside the group. This can have strange effects like apparent link collisions even though the original trajectory is collision free. If we have a robot trajectory with fully populated robot states we should use these instead.