Moveit: How does the sequential BenchmarkExecutor.cpp program stop instances planning computations if they exceed the countdown?

[moucrob]

Description

Hello,

in here https://github.com/ros-planning/moveit/tree/kinetic-devel/moveit_ros/benchmarks/src,

one should call RunBenchmark.cpp,

which itself calls BenchmarkExecutor.cpp (especially the method runBenchmarks(), and then runBenchmark() ).

My worry is that eventhough RunBenchmark.cpp inputs the moveit_ros_benchmarks::BenchmarkOptions to BenchmarkExecutor.cpp when calling it (including the timeout over which a plan computation should stop), I do not see any spot where the computations are stopped, except maybe within the ->solve() method. And I cannot find its source code...

So far, here are some URLs attempting to reach its source code :

• http://docs.ros.org/jade/api/moveit_core/html/classplanning__interface_1_1PlanningContext.html#af3d95dd741609c58847bd312b8b033e0
• http://docs.ros.org/kinetic/api/moveit_core/html/structplanning__interface_1_1MotionPlanDetailedResponse.html
• http://docs.ros.org/kinetic/api/moveit_core/html/classplanning__interface_1_1PlanningContext.html

Environment

• Kinetic

By any chance,

@rhaschke @beatrizleon @ryanluna @azompas could one of you enlighten me please?

By thanking you in advance

[zkingston]

Within RunBenchmark.cpp, a BenchmarkOptions class is created which reads the desired timeout from "benchmark_config/parameters/timeout" (see this line). Then, inside BenchmarkExecutor, these benchmarking options are distilled into a moveit_msgs::MotionPlanRequest in BenchmarkExecutor::runBenchmark() (see this line).

The moveit_msgs::MotionPlanRequest is then sent to the planning_interface::PlannerManager associated with each planner being benchmarked to retrieve a planning_interface::PlanningContext (see this line). The planning_interface::PlanningContext::solve() method is then called (see this line).

Different planner pipelines have different planning contexts, and handle the timeout conditions different. In the case of OMPL based planners, the timeout is finally specified within ompl_interface::ModelBasedPlanningContext (see this line, in particular the line when the timeout is passed into OMPL here).

Each OMPL planner internally manages its timeout with a ompl::base::PlannerTerminationCondition. For example, within RRTConnect's source code you can see it being used in its core loop, specifically this line.

TL;DR: The timeout conditions are generally handled internally by each planner, and not by MoveIt! itself.

[gavanderhoorn]

@zkingston: +1 for the detailed answer. For the future: please try to use permanent links. That way you avoid your post losing much of its value after some time as files get moved around and/or changed.

[zkingston]

@gavanderhoorn Thanks for the tip, updated the links!

[moucrob]

@zkingston @mamoll Hi again,

shall I ask here why the planning_interface::PlanningContext::solve() method (that asks for aplanning_interface::MotionPlanDetailedResponse as input) generates an attribute std::vector <robot_trajectory::RobotTrajectoryPtr> trajectory_ containing several trajectories?

Does the one indexed [0] is the one in the end sent to the robot?

Regards

[BryceStevenWilley]

@moucrob You can look at the solve function, specifically at what is being added to the description_ attribute. In this case, it's the planned trajectory, the simplified trajectory, and the finely interpolated trajectory. Usually, the finely interpolated trajectory (the last one) will be the one executed by the robot.