[Navigation stack] self defined Actionlib or move_base?

asked 2014-09-30 16:34:35 -0500

Andromeda
875 ●38 ●50 ●65

updated 2014-10-01 01:49:34 -0500

Hi, I have a crucial question about the realization of a navigation for my robot model. The robot is already moving very well and as expected in a simulative environment (RViz). Given a target point, it is able to calculate the desired trajectory and moves to the point autonomously.

One drawback in my design is: I have implemented everything on my own and since the dynamic model was really difficult to realize and I never did use the move_base package or something like that. In my code reads the controller points and not velocities commands (like the output of move_base, which is /cmd_vel ) Now I want to implement a navigation stack for my robot but I m a little bit confused about which way should I consider:

Option: I could take inspiration from the tutorials about move_base and leave it putting out velocities commands which I ll later feed into my robot's model. Pro: exaustive tutorials about move_base on this website and lot of explanations. Contra: my robot reads goals defined as points and moves accordingly to reach them. Feeding velocities commands instead of positions will not work.
Option: I feed the goal's position into the model and write an actionlib (server + client) to track the progress to the goals. At the goal it will trigger to the next goal. Pro: it sounds much easier and logic than the above idea. Contra: no idea on how to start developing such a server/client application and mostly important I could not use implement something like the base_local_planner if I need to generate a simple map to avoid obstacles (till now not necessary).

UPDATE #1: The controller reads the published points (goals) respect to the /odom frame and the controller drive the robot there. Since fthe only transformation is between /odom and /frame_link I made the assumption that goals are "fixed" respect to the world (in RViz). Later I m going to publish them respect to /map.

I hoe my question is clear enough. It not I will update it!

Thanks in advance

edit retag flag offensive close merge delete

Comments

So the robot controller takes in points? In what reference frame?

David Lu ( 2014-09-30 18:23:59 -0500 )edit

add a comment

1

answered 2014-10-02 13:26:25 -0500

paulbovbel

4518 ●12 ●49 ●80 http://www.bovbel.com/

updated 2014-10-03 12:39:59 -0500

It looks like you partially replicated the functionality of move_base - specifically the goal-to-trajectory part. However, in a navigation context, the usefulness of this part is somewhat limited without processing the additional data you need for obstacle avoidance (costmaps for move_base).

As David suggests, you can pipe the output path of local planner into your trajectory generator, however you'll have a lot of wasted cycles there - the path is created because the local planner has already evaluated sensory data, generated the trajectories, and calculated the endpoints for the paths (someone correct me if I'm wrong). So you'll be doing the same work twice.

While it's really going to hurt, I'd suggest stripping out the trajectory generation, and accepting cmd_vel input instead. It's a learning experience to try to use the tools available and not reinvent the wheel :) Besides, the ROS way would have been to develop these parts as seperate modules in the first place, so that you could connect your robot's driver (which accepts cmd_vel and outputs odom) to any number of navigation implementations.

Also, I know nothing about your robot. If your trajectory generator is very well suited to your system, and performs better than the two already implemented in the navigation stack, you should totally rewrite it to use the base_local_planner interface (processing costmap data and outputing velocity commands), taking advantage of the infrastructure provided by move_base as a state machine, and publish it to contribute back to the ROS ecosystem!