leggedrobotics / art_planner

Local Navigation Planner for Legged Robots
BSD 3-Clause "New" or "Revised" License
137 stars 20 forks source link

Error: LazyPRMstar: There are no valid initial states! #11

Closed xin111222 closed 1 year ago

xin111222 commented 1 year ago

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.

Grid map does not have "traversability" layer. Assuming traversable. Invalidated 0 vertices Invalidated 0/0 edges [ INFO] [1684482996.122158127]: Get robot poseing

[ 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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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?
QQ截图20230527093107 QQ截图20230527095440

xin111222 commented 1 year ago

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

lorenwel commented 1 year ago

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 commented 1 year ago

OK,it works now.Thank you very much.

xin111222 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.