Autonomous Navigation of a Known Map with TurtleBot Problem

Question

Hi, I'm totally new in ROS-Groovy and turtlebot 2(Kobuki) on Ubuntu 12.04(64bit). I followed TurtleBot tutorials, section 1 to 3 were OK. But I met some difficulties with basic tutorial about "Autonomous Navigation of a Known Map with TurtleBot".

I generated a my_map following the previous tutorial, "SLAM Map Building with TurtleBot". After that, I loaded my_map and "roslaunch turtlebot_rviz_launchers view_navigation.launch". I could Localize the TurtleBot using "2D Pose Estimate" and Teleoperation. But when I Clicked the "2D Nav Goal" button and set a Goal, my turtlebot didn't move anywhere. Can anyone help me?

I found some warnings when I ran "roslaunch turtlebot_navigation amcl_demo.launch map_file:=/tmp/my_map.yaml". The warnings are,

: You have set map parameters, but also requested to use the static map. Your parameters will be overwritten by those given by the map server

: Trajectory Rollout planner initialized with param meter_scoring not set. Set it to true to make your settins robust against changes of costmap resolution.

And I also checked the status by "rqt -s kobuki_dashboard", after set a Goal, I found a warning that "Using odometry instead of last command" every frame.

---

Originally posted by Nic on ROS Answers with karma: 18 on 2013-06-20

Post score: 0

Answer 1

Hi, I solved it by myself.

The reason why I could not use the autonomously plan is that I did not stop the teleoperation when I use the "2D Nav Goal" command, roslaunch turtlebot_teleop keyboard_teleop.launch

Then, after "2D Pose Estimate" and localization by teleoperation, I should stop the teleoperation command.

After stopping teleoperation, "2D Nav Goal" command works well!

---

Originally posted by Nic with karma: 18 on 2013-06-30

This answer was ACCEPTED on the original site

Post score: 0

---

Original comments

Comment by MatthiasMayr on 2013-10-23:
I just encountered the same problem and I just started teleop, because it was mentioned, that one should do that. 1 Maybe it should be mentioned on the wiki page, that one has to use roslaunch kobuki_keyop keyop.launch as teleoperation.

Comment by bit-pirate on 2013-10-23:
I filled an issue on GitHub: https://github.com/turtlebot/turtlebot/issues/105 Please feel free to report future software problems there.

Answer 2

Given your answer: There is a better solution to your problem.

If you use the standard turtlebot launch files, there should be a cmd_vel_mux set up for you. Check out the topics under /cmd_vel_mux/input/...

If you send teleop, autonomy (navi) and others that you might configure to those topics, the cmd_vel_mux should automatically switch on and off the respective topics.

---

Originally posted by dornhege with karma: 31395 on 2013-07-01

This answer was NOT ACCEPTED on the original site

Post score: 2

---

Original comments

Comment by Nic on 2013-07-01:
Thanks. I check it using "rqt_graph". But when I run the terelp, I found only /turtlebot_tereop_keyboard node communicated to /mobile_base_nodelet_manager node on /cmd_vel_mux/input/tereop topic. /map_server node, /move_base node and /mobile_base_nodelet_manager still communicate. Why don't work?

Comment by jorge on 2013-07-01:
What's terelp? Note that cmd_vel_mux selects the passing through velocity messages based on the priority assigned on param/mux.yaml, so if terelp keeps publishing zero velocity the robot will not respond to navigation goals, who has less priority. What's published on /mobile_base/commands/velocity?

Comment by Nic on 2013-07-02:
I'm sorry, there are some typo. terelp means teleop, and tereop means teleop.

Comment by Nic on 2013-07-02:
Thanks for your help. I found that after I launched "turtlebot_teleop", six zero parameters(linear and angular xyz) are published on topic "/mobile_base/commands/velocity" when I did not input any command. And in param/mux.yaml, the "Teleoperation" priority is 7.

Comment by Nic on 2013-07-02:
I could not find the priority of "2D Nav Goal" on Rviz. But I found that when I run "rosnode info /mobile_base_nodelet_manager ", then "/cmd_vel_mux/input/navi_raw" follows "topic: /cmd_vel_mux/input/teleop". on Connections. Does the writing order mean the priority?

Comment by jorge on 2013-07-02:
Nop, is the value of the priority parameter on turtlebot_bringup/param/mux.yaml file. Navigation has 5. cmd_vel_mux needs that all inputs behave politely to work, no spaming with zero-velocity messages when inactive.

Comment by jorge on 2013-07-02:
We should modify turtlebot_teleop to fit this requirement. You can alternatively use kobuki_keyop, that I find more convenient and behaves properly: roslaunch kobuki_keyop keyop.launch

Comment by Nic on 2013-07-03:
Thanks, Jorge. I found the priority parameter 5 on turtlebot_bringup/param/mux.yaml, and the priority parameter 7 on kobuki_keyop/param/keyop_mux.yaml. Then if I use kobuki_keyop, the navigation works.

Comment by RB on 2014-01-28:
This question-answer help me to sort out similar problem. I am using P3AT which don't have any switching between teleop and autonomous behavior. From above discussion I came to know that I have to write one mux.yaml file for priority setting. Will it be enough for for publishing alternate velocity commands (switching) to base controller on cmd_vel topic.. Thank you in advance

Comment by jihoonl on 2014-01-28:
It should be enough to switch between two velocity commands. check out http://wiki.ros.org/yocs_cmd_vel_mux for more details.

Comment by RB on 2014-01-28:
@jihoonl Thanks. I have one doubt, how goal position can be exchanged between two packages even if I achieve switching? For teleop (I am using http://wiki.ros.org/brown_remotelab) and for autonomous (move_base, I think). Do you have any idea regarding this?