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

Correct way to add optimization progress plotting callbacks #204

Closed
cpetersmeier opened this issue Jun 24, 2022 · 9 comments
Closed

Correct way to add optimization progress plotting callbacks #204

cpetersmeier opened this issue Jun 24, 2022 · 9 comments

Comments

@cpetersmeier
Copy link
Contributor

Hello everyone,

I would like to use the plotting callbacks to visualize optimization progress. A few approaches I have tried are forwarding the callbacks through the solver profile (all member functions are const though), as well as constructing them manually in the TrajOptMotionPlanner class (circular dependency when creating a plotter with tesseract_rosutils).

Is there a recommended way to approach this?

@Levi-Armstrong
Copy link
Contributor

Unfortunately, I have not used these in a long time but I will see if I can find an examples of using them that works.

@Levi-Armstrong
Copy link
Contributor

Update, Now that a solver profile exist this can be implemented. I will have PR against TrajOpt and Tesseract planning to support this very soon.

@Levi-Armstrong
Copy link
Contributor

The trajopt PR

@Levi-Armstrong
Copy link
Contributor

The tesseract_planning PR

@Levi-Armstrong
Copy link
Contributor

Now you can add a solver profile where you add a callback for plotting

TrajOptDefaultSolverProfile solver_profile;
solver_profile.callbacks.push_back(trajopt::PlotCallback(tesseract_ros::ROSPlotting(root_link, topic_namespace));

Then add this profile to the profile dictionary and make sure to use this profile in your composite instruction.

@cpetersmeier
Copy link
Contributor Author

Awesome! Thanks a lot. Interestingly, I observe the following behaviour:

When setting the display mode to 'trail', the first callback call plots the entire environment (including collision geometries), but the pose of the links are all over the place. When switching from 'loop' to 'trail' mode during optimization, I do not encounter this phenomenon.

@Levi-Armstrong
Copy link
Contributor

Are you able to share a screen shot of what is happening?

@Levi-Armstrong
Copy link
Contributor

@cpetersmeier Can this be closed?

@cpetersmeier
Copy link
Contributor Author

cpetersmeier commented Jul 13, 2022

I was able to reproduce the effect with the basic_cartesian_example by adding a collision object to the lbr_iiwa_14_r820_macro.xacro file like so:

<!-- Plotter Debug -->
<link name="${prefix}box">
    <visual>
    <origin rpy="0 0 0" xyz="0 0 0"/>
    <geometry>
      <box size="2.0 2.0 0.5"/>
    </geometry>
    <material name="ex_material">
      <color rgba="1.0 0.0 0.0 0.2"/>
    </material>
  </visual>
  <collision>
    <geometry>
      <box size="2.0 2.0 0.5"/>
    </geometry>
  </collision>
</link>

<joint name="${prefix}box-world" type="fixed">
  <origin xyz="2 2 2" rpy="0 0 0"/>
  <parent link="${prefix}base"/>
  <child link="${prefix}box"/>
</joint>
<!-- Debugging end -->

Then I added the plot callback to the basic_cartesian_example.cpp file:

    auto trajopt_solver_profile = std::make_shared<tesseract_planning::TrajOptDefaultSolverProfile>();
    trajopt_solver_profile->opt_info.max_iter = 500;
    trajopt_solver_profile->opt_info.min_approx_improve = 1e-3;
    trajopt_solver_profile->opt_info.min_trust_box_size = 1e-3; 
    trajopt_solver_profile->callbacks.push_back(trajopt::PlotCallback(plotter_));
    planning_server.getProfiles()->addProfile<tesseract_planning::TrajOptSolverProfile>(
        tesseract_planning::profile_ns::TRAJOPT_DEFAULT_NAMESPACE, 
        "cartesian_program", 
        trajopt_solver_profile
    );

I removed the manual inputs for pausing the solver here:

  // plotter->waitForInput();

When I plot the trajectory using the trail setting I get:

image

Edit:
The impression of 'random' positioning was most likely due to my model origins not being at the center of the collision models like it is the case with this box.

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

No branches or pull requests

2 participants