-
Notifications
You must be signed in to change notification settings - Fork 9
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
Conversation
@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 |
Does it work if you remove the constraints? |
It is most definitely the box constraints. I tried it with the jerk
constraints and the pipeline benchmark was working. I knew this was going
to be an issue, bit waited for the constrained planing Tut to work.
…On Sun, 13 Oct, 2024, 12:41 pm Sebastian Castro, ***@***.***> wrote:
Does it work if you remove the constraints?
—
Reply to this email directly, view it on GitHub
<#52 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFNFZJASJLV7Q35PT4JAEA3Z3JMANAVCNFSM6AAAAABPWDELVGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBYHE2DINZRGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
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 |
Yeah no worries. I'll have a look tomorrow morning
…On Sun, 13 Oct, 2024, 1:13 pm Sebastian Castro, ***@***.***> wrote:
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.
—
Reply to this email directly, view it on GitHub
<#52 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFNFZJEY2V4IVVQH2KOG4JLZ3JPXFAVCNFSM6AAAAABPWDELVGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBYHE2TKNRQGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I can only get this to work if:
So I'm not really sure whether 2. or 3. is the problem here. |
Having a look at this now
…On Sun, 13 Oct, 2024, 4:11 pm Sebastian Castro, ***@***.***> wrote:
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.
—
Reply to this email directly, view it on GitHub
<#52 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFNFZJGFUNANP3OB6DC7CI3Z3KERRAVCNFSM6AAAAABPWDELVGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBZGAYTKNZRG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
OK I found the issue with the joint bounds... using Also, the gripper joints limits were actually (un)initialized to garbage values, which caused failures. Furthermore, using these So that clears issue 2 above... now for the constraints. |
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 2024-10-13.13-00-09.mp4I could even thin the boundary further! 2024-10-13.13-01-53.mp4 |
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.
Approving since it now runs correctly, but would be good if someone else gave my changes a look.
// 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(); |
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.
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?
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. |
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. |
Run with