Error: LazyPRMstar: There are no valid initial states!

[xin111222]

Hi,I encountered the same problem as # 4, but his solution does not apply to me.
I did not notice anything around the starting point, so I had to create a new problem and seek your help.

[ INFO] [1684482995.882166198]: planFromCurrentRobotPoseW
Grid map does not have "traversability" layer. Assuming traversable.
Invalidated 0 vertices
Invalidated 0/0 edges
[ INFO] [1684482996.122158127]: Get robot poseing
[ INFO] [1684482996.122209804]: getCurrentRobotPose
[ INFO] [1684482996.122242194]: pose_robot finished
Invalidated 0 vertices
Invalidated 0/0 edges
Initial start state not valid. Trying to sample around it.

Epic fail, dude
Warning: LazyPRMstar: Skipping invalid start state (invalid state)
at line 248 in /home/xin/下载/ompl-1.4.2/src/ompl/base/src/Planner.cpp
Debug: LazyPRMstar: Discarded start state Compound state [
RealVectorState [-1.81222 -0.475486 -0.475]
SO3State [0 0 0 1]
]

[lorenwel]

Hi Xin,

thanks for checking existing issues first.
This message occurs, if the current pose of the robot is invalid. This usually is caused by one of two reasons:

1. Your elevation map is wrong/bad
   1.1 You have some artifacts in the map (like the lidar self-hits of issue #4)
   1.2 Your map has no data
   1.3 Your elevation layer name is set wrong
2. You use a different robot, with a different nominal stance height. You need to configure your robot parameters in the params.yaml file to fit your robot. Most important here is the feet/offset/z. You can visualize this in Rviz, with the /art_planner/collision_boxes topic. The red boxes need to intersect the elevation map, otherwise the planner will think the robot is flying.

If none of this appears to fix your problem, please post a screenshot of Rviz with /art_planner/collision_boxes and your elevation map visualized.

[xin111222]

Think you for your reply.I think i need to tell you some situations about my robot.
I have only one lidar on my robot back.So this lead to it can not see the environment beneath its feet，is lead my question?Can you help solve this issue?

[lorenwel]

That would explain the issue.
You either need to teleoperate your robot until it stands on parts of the elevation map it has seen, or you set the unknown_space_untraversable parameter to false. This will make the planner assume that unknown space is traversable. It will then use image painting to fill these parts of the elevation map. This will reduce safety, though, so make sure that all obstacles are always seen by your lidar (especially negative obstacles, like holes or cliffs).

[xin111222]

hello, I have set unknown_space_untraversable parameter to false as you said, but it doesn't work.
So i Increase start_radius of start_goal_search and it doesn't repot error"There are no valid initial states!".
But there is no data from the path topic and i seem to see a path in rviz .
i don't know what's wrong, can you help me solve?

[xin111222]

And sometime "there are no solutions "or assume "There are no valid initial states!"

[lorenwel]

Your robot in the Rviz picture above is standing in a narrow corridor and can see the walls on the side, but not the floor under its feet. Therefore, image inpainting will "interpolate" between the two walls and assume a high surface where the robot is.
Can you please try walking the robot forward via joystick for about a meter, until it stands on observed terrain in the elevation map, before planning. I assume that will fix your issue.
You can also try using our elevation_mapping_cupy package. It supports initializing the area underneath the robot from TF frames located at each foot: https://github.com/leggedrobotics/elevation_mapping_cupy/blob/main/elevation_mapping_cupy/config/parameters.yaml#L96

[xin111222]

OK,it works now.Thank you very much.

[xin111222]

And i have a question : does D the motion cost node needs to be used with PRM_ Motion_ Cost used ,and other method does not need cost?
What is the difference between them?
Thank you for your work.

[lorenwel]

Happy to hear that it works.

The biggest difference is that prm_motion_cost uses a learned motion cost, while lazy_prm_star_min_update uses a simpler shortest path cost. As you say, only prm_motion_cost needs the motion cost node.
For details, please check the paper.

[xin111222]

I have another question.I would like to know how you enable robots to fully explore independently in DARPA without the need to manually specify endpoints.

[lorenwel]

For exploration, please check out GbPlanner.

The planner in this repo can run on CPU, without GPU, just fine. Simple change the planner/name parameter to lazy_prm_star_min_update. It's the planner published in this paper.
In fact, you were already running this planner on CPU alone as your screenshots show, so I'm confused by your request.

[xin111222]

I'm so sorry I didn't express myself clearly.
I just don't know how lazy_prm_star_min_update to computation cost. Because i use elevation map with cpu .So i don’t know if it can plan with cost.

[lorenwel]

In lazy_prm_star_min_update the planning cost is shortest-path. It does not support a cost-map. It uses a traversability map to restrict where the robot can go, but it is not used in the optimization objective.

[xin111222]

So if i want to use a cost map to planner with cpu ,how can i do?
Can this paper give me some help？
M. Wermelinger, P. Fankhauser, R. Diethelm, P. Kr¨usi, R. Siegwart,
and M. Hutter, “Navigation planning for legged robots in challenging
terrain,” in IROS. IEEE, 2016, pp. 1184–1189.