-
Notifications
You must be signed in to change notification settings - Fork 7
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
Kinematic Trajectory Optimization Skeleton PR #8
Conversation
This commit * solves the vcs import todo on dockerfile, Dockerfile is self-contained * compilation of motion plan request to trajectory optimization in progress
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.
Looks good! I made some of the nitpicky comments.
As far as when I think we're at a mergeable state here: Ensure we can not only set up the KinematicTrajectoryOptimization
program, but that we can actually solve it. Doesn't need to have any constraints. And then return the outcome as a planning response.
While I waited an eternity for the Docker container to keep building without OOMing my machine, I filled in some more placeholder code. Hope that's okay.
src/ktopt_planning_context.cpp
Outdated
// compile into a Kinematic Trajectory Optimization problem | ||
auto trajopt = KinematicTrajectoryOptimization(plant_->num_positions(), 10); |
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.
TODO: Rather than the hard-coded 10
, the number of control points should be one of the generate_parameter_library
params defined in the YAML... or otherwise in the planner options.
src/ktopt_planning_context.cpp
Outdated
// bare minimum specification | ||
// get the frame that needs constraints | ||
// |
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.
Yep, so I think what we'll need is:
Must have:
- Constraints on initial and final joint configuration
- Joint position/velocity/acceleration limits from the joint limits params
- Collision avoidance (minimum distance constraint)
Nice to have:
- Getting position and orientation constraints from the
MotionPlanningRequest
For both the collision and the position/orientation constraints, we'll also need a hyperparameter for how many samples from s=0
to s=1
we want to use. I would roughly recommend 2-3x the number of control points.
This can all be done in follow-on PRs, BTW
src/ktopt_planning_context.cpp
Outdated
&builder, 0.0); | ||
|
||
auto robot_instance = Parser(plant_, scene_graph_).AddModels(robot_description_); | ||
plant_->WeldFrames(plant_->world_frame(), plant_->GetFrameByName("panda_link0")); |
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.
we'll need to figure out what exactly to weld here, since "panda_link0"
is, of course, hard-coded. I'm sure there's a way to just weld the base-most link name of the robot description. That, or we can make it a parameter if needed, but hopefully isn't necessary.
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.
creating issue.
Made more updates to the Dockerfile. Now I can do:
And there are still no |
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.
@sea-bass, I see that you have added the relevant bits to report the motion plan response. Were you able to test this on the demo?
I was, but it's far from complete. There are no actual costs/constraints added, and the Drake trajectory needs to be converted to a MoveIt |
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.
Lots of small comments but in general this looks good! Once they are either addressed in the code or by converting the bigger ones into issues, we should merge this
@@ -0,0 +1 @@ | |||
#pragma once |
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.
Remove until we need it?
using drake::planning::trajectory_optimization::KinematicTrajectoryOptimization; | ||
using drake::solvers::Solve; | ||
|
||
class KTOptPlanningContext : public planning_interface::PlanningContext |
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.
TODO Add documentation
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.
You mean add comments around the functions and includes?
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.
Yes
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.
creating issue.
// retrieve goal state | ||
moveit::core::RobotState goal_state(start_state); | ||
constraint_samplers::ConstraintSamplerManager sampler_manager; | ||
auto goal_sampler = sampler_manager.selectSampler(getPlanningScene(), getGroupName(), req.goal_constraints[0]); |
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 guess this will work for now, but maybe this step needs to be dropped and we let ktopt handle the goal constraints directly
|
||
// package up the resulting trajectory | ||
auto traj = trajopt.ReconstructTrajectory(result); | ||
const size_t num_pts = 101; // TODO: should be sample time based instead |
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 guess this could be exposed as a ROS parameter to let the use define the trajectory density
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.
Completely agreed! That was going to be the next step.
|
||
bool KTOptPlanningContext::terminate() | ||
{ | ||
return true; |
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.
Print a warning here that termination is not implemented by this planner
robot_description_ = robot_description; | ||
|
||
// also perform some drake related initialisations here | ||
DiagramBuilder<double> builder; | ||
|
||
std::tie(plant_, scene_graph_) = AddMultibodyPlantSceneGraph(&builder, 0.0); | ||
|
||
auto robot_instance = Parser(plant_, scene_graph_).AddModels(robot_description_); | ||
plant_->WeldFrames(plant_->world_frame(), plant_->GetFrameByName("panda_link0")); | ||
|
||
// for now finalize plant here | ||
plant_->Finalize(); |
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 wonder if this (in a follow-up PR) should be moved into the constructor or even the planner manager
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.
Again, I declared this as a function because , there could be use in resetting the robot_description once a planning_context has been set. The alternative is to expose a ros_handler and pass it to the planner_manager. I'll experiment with that in a future pass.
|
||
void KTOptPlanningContext::clear() | ||
{ | ||
// do something |
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.
Just print warning that is it not implemented for now 😉
README.md
Outdated
### Some helper commands | ||
To just build `moveit_drake` | ||
``` | ||
colcon build --packages-select mvoeit_drake |
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.
Typo: moveit_drake
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.
So I have made a few changes to the repository based on your comments and create a few follow on issues to be tracked with later commits.
@kamiradi Can you ping when you addressed all comments for another review round? You can resolve the conversation you addressed and comment on the ones where you might be unsure/ have questions or commetns |
@sjahr, I remember you pointing me towards a specific yaml file that needs to have a |
@kamiradi The file is specified per moveit config, for example in panda_moveit_config for stomp: The content is equivalent with the section you've added to the launch file and either the yaml file or the launch file section can be used (although the .yaml file is best practices for fleshed out plugins). |
Ah I see, so this is an alternative to the launch file config mentioned in the launch file. Is there a runtime requirement for the yaml file also to be present? Can I defer this to the next PR? So the requirement now is to:
|
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.
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 found a typo in the XML, that "planning_interface:PlannerManager"
needs to have ::
instead of a single :
. There was also a missing space, though unclear if that does anything.
Fixed in 2ff0c3b -- try with that?
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 pending @sjahr's final review.
My only suggestion: Rename the PR title to something like "Kinematic Trajectory Optimization skeleton"
ktopt_moveit_parameters) | ||
|
||
# Ensure that the plugin finds libdrake.so at runtime | ||
set_target_properties( |
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.
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.
Works for me now 🎉
This PR aims to transcribe a basic Kinematic Trajectory Optimization problem from Moveit to Drake
Implement an example demo to test and integrate the above classes
PS: this is a draft, and the work may be split over a sequence of PRs