Obstacle avoidance with octomap

[Teresa Seco]

Hello,

I am working with Gazebo and UR10 robot model. There is an asus camera in the enviroment that generates the octomap. RVIZ shows this octomap.

I put a cylinder in Gazebo between two possible positions of the robot because I want to check the planner with an without the cylinder in the scene. The octomap shows the cylinder.

Depending on the location of the cylinder and the limits of the robot, some times the planner can not  plan a valid trajectory and in other cases there is a valid trajectory and the the robot reaches the final target without hitting the cylinder. In other tests, the planner returns a trajectory but the robot hits the cylinder.

I am a little confuse about all these behaviours and I would like to know:

1- How many trajectories are attempted by the planner before find a solution (in case it exits a solution)?

2- What are the possible reason for these different behaviours?

Find attached a image of the gazebo scene and rviz to clarify.

Thanks in advance,

Teresa

[Teresa Seco]

Any suggestions about this topic?

[Simon Schmeißer]

Hi Theresa,

which planer are you using? I recommend to select rrtconnect in the path planning plugin in rviz. It will run till it finds the first valid solution (or till the planning time ends, set this really high). Results will look quite funny but you can work on that later. Check if inverse kinematics work properly (can you move around the goal position as expected). Maybe try without gazebo first. look at the command line output of move_group, it's quite verbose.

Generally you should provide more info, maybe if you create a github repo with a demo scene someone will look at it. Right now it is just guessing.

Good luck :)
Simon

[Teresa Seco]

Hi Simon,

Thank you for your suggestion. I selected RRTConnect as the planner and it finds a valid solution for the movement of the robot but it is not the most "logical" movement. As you mentioned in your previous mail, the result is quite strange. I am trying to limit the movements of the joints, but, is there any parameter that I could set to improve the planned trajectory? Could I set any criteria to select the trajectory with a shorter path for example?

We work both with Gazebo and real UR10 robot.

Thanks in advance,

Teresa

[Simon Schmeißer]

There is a parameter for how many tries it should do, it will then select the best of those. But I don't think it will ever look that "great" or "logical". However it always seems to give some result. You could try one of the optimizing planners (ending on -star) or try out chomp

[Teresa Seco]

I will try with different planners.
Where is the parameter to change the number of attemps? I revised the ompl_planning.yaml parameters and I do not find it.

Thank you very much for your help!

[Simon Schmeißer]

Actually you will have to search one layer above that. There is for example a field in rviz moveit dialog ("Planning attempts" or something similar), or a field in the MotionPlanRequest

moveit_msgs::MotionPlanRequest request;
    request.num_planning_attempts = 10;

etc.

There is some piece of code that will start as many planning threads (completely independent planners) as you have cpu cores until num_planning_attempts is reached. So for 10 tries on 4 cpu cores you will have 4 + 4 + 2 planners running etc, then the best solution will be reported.

[Teresa Seco]

We have checked with different ompl planners (LBKPIECE, RRT, RRT*) and different parameter values (num_planning_attemps is one of them) and we got best results, but not enough for our application because we need to avoid strange robot movements.

For this reason, we have started to check STOMP planner but there is not much information about this planner. We downloaded the package from https://github.com/ros-industrial/industrial_moveit and we can move it our UR10 robot (gazebo) with RVIZ using this planner but we need to adjust some parameters and try to understand how it works. We would like to know the meaning of stomp_planning.yaml pararameters for example.

We use move_group interface (C++) with setTargetPose and asyncExecute but it does not work the STOMP planner returns this error:  Invalid goal definition, STOMP can only accept joint goals.

Any suggestions?

[Simon Schmeißer]

Nice to hear, it is still on my todo list to try out stomp. Maybe you want to ask on the ros-industrial mailing list as well

https://groups.google.com/forum/?pli=1#!forum/swri-ros-pkg-dev