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

Add constrained planning tutorial #52

Merged
merged 7 commits into from
Oct 13, 2024

Conversation

sjahr
Copy link
Contributor

@sjahr sjahr commented Oct 10, 2024

Run with

ros2 launch moveit_drake constrained_planning_demo.launch.py

@sjahr sjahr requested review from sea-bass and kamiradi October 10, 2024 07:17
@sjahr sjahr changed the title Add contrained planning tutorial Add constrained planning tutorial Oct 10, 2024
@sjahr
Copy link
Contributor Author

sjahr commented Oct 13, 2024

@kamiradi Good news: The planner is now loadable 🎉 Bad news: KTOpt fails to plan in both demos --> Maybe the problem is overconstrained? I clean-ed up the position - jerk constraint parsing, feel free to double check but it should work but I fear we introduced and error somewhere along the line that we need to debug

@sea-bass
Copy link
Contributor

Does it work if you remove the constraints?

@kamiradi
Copy link
Member

kamiradi commented Oct 13, 2024 via email

@sea-bass
Copy link
Contributor

Sorry, I keep forgetting that my computer can't handle building MoveIt from source unless I add swap/zram and I just crashed mid build, then ran out of time to try again.

Things look largely okay, the one place I would check is whether using plant.world_frame() as the "frame A" vs. something like "panda_link0", which is the base of the planning group? Or maybe those frames are coincident and it's something else.

@kamiradi
Copy link
Member

kamiradi commented Oct 13, 2024 via email

@sea-bass
Copy link
Contributor

sea-bass commented Oct 13, 2024

I can only get this to work if:

  1. I disable the Meschat visualization (to remove the waiting times)
  2. I remove the position/velocity/acceleration/jerk constraints
  3. I remove the path constraints

So I'm not really sure whether 2. or 3. is the problem here.

@kamiradi
Copy link
Member

kamiradi commented Oct 13, 2024 via email

@sea-bass
Copy link
Contributor

sea-bass commented Oct 13, 2024

OK I found the issue with the joint bounds... using -std::numeric_limits<double>::max() for the unbounded joints (in this case, gripper) could be bad -- we should be using std::numeric_limits<double>::lowest().

Also, the gripper joints limits were actually (un)initialized to garbage values, which caused failures.

Furthermore, using these std::numeric_limits extremum values for the velocity, acceleration, and jerk also caused optimization to fail. I defined constant that set it to a large finite value (I'm using 100) for all unbounded joints, and this makes things work.

So that clears issue 2 above... now for the constraints.

@sea-bass
Copy link
Contributor

sea-bass commented Oct 13, 2024

For issue 3, I was able to address this by padding the constraints to be more conservative at the optimizer level.

After fixing the above problem with joint limits, I realized that the optimization now succeeded with constraints, but failed on the validation step. This makes sense, as Drake only optimizes the constraints at the sampled points we specify... and intermediate trajectory points could (and do) therefore violate constraints.

Adding a padding distance parameter to the generate_parameter_library YAML, I could get things working!

2024-10-13.13-00-09.mp4

I could even thin the boundary further!

2024-10-13.13-01-53.mp4

Copy link
Contributor

@sea-bass sea-bass left a comment

Choose a reason for hiding this comment

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

Approving since it now runs correctly, but would be good if someone else gave my changes a look.

Comment on lines -229 to +177
// TODO: This should not hold up planning time
std::this_thread::sleep_for(std::chrono::milliseconds(static_cast<int>(params_.trajectory_time_step * 10000.0)));
}
visualizer_->StopRecording();
visualizer_->PublishRecording();
// visualizer_->StartRecording();
// const auto num_pts = static_cast<size_t>(std::ceil(traj.end_time() / params_.trajectory_time_step) + 1);
// for (unsigned int i = 0; i < num_pts; ++i)
// {
// const auto t_scale = static_cast<double>(i) / static_cast<double>(num_pts - 1);
// const auto t = std::min(t_scale, 1.0) * traj.end_time();
// plant.SetPositions(&plant_context, traj.value(t));
// auto& vis_context = visualizer_->GetMyContextFromRoot(*diagram_context_);
// visualizer_->ForcedPublish(vis_context);
// // Without these sleeps, the visualizer won't give you time to load your
// // browser
// // TODO: This should not hold up planning time
// std::this_thread::sleep_for(std::chrono::milliseconds(static_cast<int>(params_.trajectory_time_step * 10000.0)));
// }
// visualizer_->StopRecording();
// visualizer_->PublishRecording();
Copy link
Contributor

@sea-bass sea-bass Oct 13, 2024

Choose a reason for hiding this comment

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

I commented this out BTW. If you don't, then "planning takes forever" (but eventually returns), although it gives you time to hop over into Meshcat to see the results there.

Maybe the meshcat visualization flag should be a boolean parameter in our YAML file?

@sea-bass
Copy link
Contributor

sea-bass commented Oct 13, 2024

One last comment on this -- when I looked at Meshcat, the gripper fingers definitely fly all over the place (which might be why I had to bound the velocity/accel/jerk to finite values, else the gripper fingers might have flown into collision or sparked another silent failure).

I think what we need to do is take all of the joints that are not actively part of this group, and constrain their positions to exactly the starting positions + velocities and further derivatives to zero. Will let someone else try that out.

@kamiradi
Copy link
Member

Works for me as well 🥳 . I added meshcat visualise to the parameter yaml as suggested.

I'll track the panda finger as a separate issue and get to it. For now the bounding box constraint works, I'll add the orientation constraints and we can call it a ROSCon.

@kamiradi kamiradi merged commit 6851f8a into moveit:main Oct 13, 2024
2 checks passed
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.

3 participants