ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

Hi Johannes,

This question is not trivial and I am just trying my best to give you some suggestions as I have some experiences on both humanoid robot and mobile navigation. However, I have never combined them. May I ask what platform you are using now? Your plan looks fine. Firstly you need to have amcl to get your current position, and you can definitely use navfn to get your global path. However, when you go to local planner, I think it is designed for mobile base robot. You did not mentioned what is the interface with your humanoid. If your robot can accept V_x V_y and V_theta, you can try to implement your first plan. Though mobile robot is only two DOF but humanoid robot is three DOF. As long as it is redundant, should be fine. If your humanoid does not accept velocity as input, I suggest you write a small piece of code to convert it.

For your second plan, you really need to spend a lot of time. Especially when you want to use only part of the navigation package. Last time we want to replace the costmap module with our own, finally we give up and rewrite a simple navigation module (also spend one or twon months).

Above all, depend on your focus. If navigation (just move to the goal) is the main focus, you should try first plan, let your humanoid receive velocity input. If your focus is foot step planning (place every step at a specific location), you may need to challenge the second plan.

Hi Johannes,

This question is not trivial and I am just trying my best to give you some suggestions as I have some experiences on both humanoid robot and mobile navigation. However, I have never combined them. May I ask what platform you are using now? Your plan looks fine. Firstly you need to have amcl to get your current position, and you can definitely use navfn to get your global path. However, when you go to local planner, I think it is designed for mobile base robot. You did not mentioned mention what is the interface with your humanoid. If your robot can accept V_x V_y and V_theta, you can try to implement your first plan. Though mobile robot is only two DOF but humanoid robot is three DOF. As long as it is redundant, should be fine. If your humanoid does not accept velocity as input, I suggest you write a small piece of code to convert it.

For your second plan, you really need to spend a lot of time. Especially when you want to use only part of the navigation package. Last time we want to replace the costmap module with our own, finally we give up and rewrite a simple navigation module (also spend one or twon months).

Above all, depend on your focus. If navigation (just move to the goal) is the main focus, you should try first plan, let your humanoid receive velocity input. If your focus is foot step planning (place every step at a specific location), you may need to challenge the second plan.