osrf / rosbook

Example code to accompany the book Programming Robots with ROS

rosbook

This repository contains example code to accompany the book Programming Robots with ROS

Errata

We are grateful to the readers who have found and reported errata in the book. There is an official Errata page on the O'Reilly website which lists the known errata in the printed book. The code available in this Github repo has the errata corrected, and therefore may be slightly different from the code listings provided in the book.

rosbook's Issues

CougarBot Gazebo simulation

Hi!

I follow your cougarbot instructions to the t trying to get my robot to simulate. I make it through everything fine, however I cannot get my gazebo simulation to ever not fall over like in Figure18-4. I've modified the urdf file and added the transmissions and gazebo plugin code.

However, I get the following

[WARN] [WallTime: 1452193711.932180] [29.116000] Controller Spawner couldn't find the expected controller_manager ROS interface.

which troubleshooting on answers.ros tell me its a problem with the gazebo plugin/control_manager. I have the gazebo files and gazebo_ros_pkg. Is there something else I need to install for the control plugin to work?

When I run the exact code from this repo I get the previous error as well as

[ WARN] [1452194495.412454939, 0.123000000]: GazeboRosJointStatePublisher Plugin (ns = //) missing , defaults to 100.000000

I am on ROS jade and installed ros_control from source.

Thanks.
Steve

Update: When I rostopic list, it does not come up with any of the /arm_controller/... topics but has the rest as listed on page 405.

[Text improvement] Chapter 4: Confusing description of Python modules

The wording in paragraph 3 on page 55 could confuse the reader into thinking there is a file called "basics.srv", due to the collision between the generated .srv submodule of the (ROS) package module and the .srv extension for service definition files. The wording could be improved, particularly by not calling the submodule an extension, but also by just calling it what it is (a services-containing submodule of the basics Python package?).

Can't run basics topic publisher.

After creating a package name basics (with rospy, roscpp, std_msgs) and added the src, sourced, launched a roscore and tried to run the topic_publisher this was the output:
I assume there needs to be a queue size? That is not explained in the book or in the code.

rosrun basics topic_publisher.py                       
/home/bpinaya/tmp_ws/src/basics/src/topic_publisher.py:19: SyntaxWarning: The publisher should be created with an explicit keyword argument 'queue_size'. Please see http://wiki.ros.org/rospy/Overview/Publishers%20and%20Subscribers for more information.
  pub = rospy.Publisher('counter', Int32) 

[Text improvement] Chapter 3: Uninformative description of data type

In Table 3-1 on page 40, the "duration" note for the time ROS type is not particularly informative.

[Text correction] Chapter 3: Wonky grammar

In paragraph 6 of page 33, "between all publishers and of all subscribers" should be "between all publishers and all subscribers".

Wander-bot issue

In the exercise in chapter 7 I have a problem when I send the command "roslaunch turtlebot_gazebo turtlebot_world.launch" I get some errors and warnings.

Msg Connected to gazebo master @ http://127.0.0.1:11345
Msg Publicized address: 192.168.1.37
Error [Param.cc:181] Unable to set value [1,0471975511965976] for key[horizontal_fov]
Error [Param.cc:181] Unable to set value [0,100000001] for key[near]
Error [SDF.cc:788] Missing element description for [pointCloudCutoffMax]
[ INFO] [1453359094.565551428, 0.400000000]: Camera Plugin (robotNamespace = /), Info: Using the 'robotNamespace' param: '/'
[ INFO] [1453359094.743534238, 0.400000000]: Camera Plugin (ns = /) <tf_prefix_>, set to ""
[ INFO] [1453359094.862222063, 0.400000000]: Starting plugin Kobuki(ns = //)!
[ WARN] [1453359094.862647699, 0.400000000]: Kobuki(ns = //): missing default is na
[ INFO] [1453359094.868740176, 0.400000000]: Kobuki(ns = //): <tf_prefix> =
Dbg Plugin model name: mobile_base
[ INFO] [1453359094.870111584, 0.400000000]: Will publish tf. [mobile_base]

[ INFO] [1453359094.876919980, 0.400000000]: Kobu

Then when I sent the command rostopic echo scan I get nothing.
nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan]

intensities: []

Please help me, I am trying to learn ROS

Chapter 21: src/code/cpp example code has errors

Chapter 21 provides sample c++ code (code/cpp in this repo) that cannot be built because it has errors. service_client.cpp has an error redefining argv when it should just be passed. service_server.cpp also does the same thing but with argc and argv, also this code does not declare l or count as integers before using them. Actions for c++ are not covered in the book at all, and it is not clear that Action is appended to the generated header include file. Finally, action_server.cpp does not declare the SimpleActionServer correctly so it does not compile, it needs to at least provide some parameters. The lines following should not include Action in the class names, as those are the wrapper classes for publishing.

[Text improvement] Chapter 3: Differing arguments to find_package() call

On page 42, the find_package() call arguments do not match what catkin generates for a Python node. It only adds rospy, not roscpp (since we are creating a Python-only package). Also std_msgs was not added earlier when the dependency was added to the package.xml file. This is confusing for the reader.

Suggestions to improve explanations and text

The below suggestions are based on considering the book from the point of view of someone completely new to ROS, and my own experience teaching students to use new software frameworks.

• Chapter 5, Defining an action (page 63): This example mentions that the action file is already present in the basics package. Although one hopes it is obvious, the statement should be specific that the package referred to is the provided example code. This is especially true given that the topic and service examples don't mention that their message/service definition files are already present in the provided example code.
• Chapter 5, Defining an action (page 63): The find_package() call's arguments are, once again, different from previous chapters. They need to be made consistent with the previous two chapters and built up as though the reader is building their own basics package as they go through the book. The same goes for the call to catkin_package().
• Chapter 5, Implementing a basic action server (page 64): The node name in init_node() is not the same as the file name. While not a technical problem, this may be confusing for the reader because it is different from everything so far. Perhaps add a note along the lines of, "note that the node name and the file name do not need to be the same," or perhaps, "we'll be making a more advanced version of this server soon, so we'll call this one 'simple'".
• Chapter 5, Using an action (page 67): The node name in init_node() is not the same as the file name. This may be confusing.
• Chapter 5, Implementing a more sophisticated action server (page 70): The text mentions that preemption can also occur when a new goal is sent, but it doesn't mention what happens to the new goal. A short note (or link to the relevant documentation) should be added.
• Chapter 5: Earlier in the chapter, the text mentions that error handling by actions will be added later. The fancy action server has error handling, but only for checking parameters at the start. It would be good for people new to ROS to know that an abort can be performed at any time during an action's run. A brief note about this during the explanation of the fancy_action_server.py code would be enough.
• Chapter 6, Actuation: Mobile platform (page 79): The statement "which means that they cannot move in any direction at any given time" can be interpreted as "they cannot move". It should be re-worded to make it clear that the intent is that only certain directions are available at any given moment. (Even with the example given immediately after, readers often stop and re-read a sentence if they find it confusing, rather than moving on to the next sentence and hoping for enlightenment.)
• Chapter 6, Actuation: Manipulator arm (page 81): A note about the ROS messages used for manipulators needs to be added. Refer to the previous section if appropriate.
• Chapter 6, Laser scanners (page 85): "around 10 to 80 times per second (typically 600 to 4,800 RPM)": "typically" is not needed here, unless your definition of the length of a minute is variable.
• Chapter 6, Shaft encoders (top of page 86): Is it really good to say, without qualification, that counting how many times the wheels turn is often the most accurate estimate of robot motion? A shaft encoder is one of the most accurate measures of motor/axel/wheel rotation, true, but not robot motion in the case of mobile platforms (as the text itself states further on). The statement should be made more specific (i.e., state that it is "for certain robot types" or "for manipulators").
• Chapter 7, Creating a package (page 100): Example 1 is a good place to explain the concept of the simulator clock. The first light_change_time value will probably be zero, which is not what would be expected by a reader unaware that something other than the wall clock is being used.
• Chapter 7, Summary (page 108): "This brought together all of the aspects of the book thus far". Except for services and actions. Perhaps say "This has demonstrated a simple but complete robot using ROS."
• Chapter 8, Keyboard driver (page 113): Why is this example suddenly checking if the file is main? None of the previous samples did that. This might confuse someone unfamiliar with Python.
• Chapter 8, Example 8-2 (page 114): This is the first instance in the book of a subscriber callback that receives an argument other than the message. Some explanation should be given of where this argument's value is coming from.
• Chapter 8, Motion generator (page 115): The explanation of /rosout and /rosout_agg should come much, much earlier in the book (and should reference the chapter that explains them). Those two topics have been present since the first mention of "rostopic list".
• Chapter 11, Installing and running a simulated R2 (page 174): In the sample code, the reason for the "anonymous" parameter being passed to init_node() should be given.
• Chapter 11, Moving R2 around a chessboard (page 179): The hard-coded position of the chessboard is not highlighted in the code, making the connection to the discussion of hard-coding these values weak. Point out which lines in the code it occurs on at the start of the discussion.
• Chapter 11, Modelling a chessboard (page 182-4): The use of the SDF files is the ideal opportunity to teach the reader about where to put resources such as these. The reader should be given some direction on where to put SDF files in their package and shown how to find them in the spawn_chessboard node.
• Chapter 11, Example 11-8 (page 184): Although nice and short, 's' is not a good name for a service proxy variable in example code.
• Chapter 12, Acquiring images (page 194): My version of turtlebot_gazebo/turtlebot_world.launch (in Indigo) does not have the compressedDepth or theora topics. Probably just an update, but something to check for when making the 2nd edition.
• Chapter 12, Acquiring images (page 195): After 11 chapters of running Python programs, it seems a little late to mention that changing their permissions to make them executable is only one option.
• Chapter 12, Acquiring images (page 196): The discussion of the rosnode command belongs earlier in the book with rostopic, etc. It would be better to be referenced and used here the way rostopic is (this would make the book a better reference book).
• Chapter 12, Acquiring images (page 199): There is no mention that the followbot package is in the sources provided online, and will not be installed in the reader's system by default (nor is it actually installable). Actually, this would have been a great chance to introduce the tools for working with other people's packages, particularly as the code does not follow the "standard" layout described in this book.
• Chapter 13, Defining state machines with smach (page 214): The note about adding dependencies to package.xml could do with a reference to the appropriate chapter, to remind the reader.
• Chapter 13, Defining state machines with smach (page 215): The line "State 'ONE' is missing transitions: {}" in the output is probably confusing for those new to smach; a quick note about it would be welcome.
• Chapter 13, Summary (page 224): The second paragraph of the summary feels like it should be part of the body text rather than a note.
• Chapter 14, Note (page 231): Another option, which is guaranteed to be installed (since we just installed imagemagick along with ALVAR) is "display". If you're working from a command prompt, it's lighter and quicker.
• Chapter 14, page 238: The reader should be instructed to test their script to make sure it works. Otherwise they may run into problems later on.
• Chapter 14, page 239: No instructions are given for how to drive the Fetch robot. So far, the book has only talked about driving the TurtleBot using its own dedicated teleop package, and with the program written by the reader provided they have read that chapter. Most of the students I've worked with would spend an entire day trying to figure out how to teleop Fetch in this example. At least some guidance on how to teleop Fetch should be given, even if it is just "Use the program you wrote in chapter 8." A better solution, given we are using the Fetch robot simulation provided by Fetch Robotics, would be to do what their documentation suggests and use the teleop_twist_keyboard package. Then the reader would know that there is a general package available for teleoperation, and promote re-use. Yay, re-use!
• Chapter 15, Design 4 (page 266): It has been a while since the user wrote their own service, so remind them to add it to CMakeLists.txt, call catkin, etc.
• Chapter 15, Design 4 (page 267): Give the reader some brief instructions to test that their service works.
• Chapter 15, Example 15-6 (page 269): The comments are unnecessary, since much of the code we have seen before and there is a description in the body text anyway.
• Chapter 16, Simulation in Gazebo (page 290): Is it wise to use a Bitly link for the moments of inertia page? Maybe this is an O'Reilly policy, but to me Wikipedia seems likely to have more stable addresses than Bitly, which is a commercial entity in a crowded market.
• Chapter 17, Verifying transforms (page 302): Knowing about the Gazebo plugin for publishing joint states is important, but the reader also needs to know how to do this for their own hardware. Since chapter 15 didn't show how to do it for the FakeActuator, this chapter should probably at least mention where to find out how to do so. It may seem obvious how to publish joint states, but beginners with ROS will probably struggle with this - especially since sensor_msgs/JointState contains some non-obvious fields.
• Chapter 17, Configuring the navigation stack (page 311): It would be good to have a note here that the map should not be matched to the robot's laser scans yet because localisation is not yet being performed (a nice transition into the next part). I've seen questions on ROS Answers where people are confused by the map not being where they expect it to be.
• Chapter 17, Configuring the navigation stack (page 313): Loading parameters from a YAML file into the parameter server (and into a specified namespace) is newly introduced here. A brief note about what is happening would be good. I can see some beginners getting confused about topic name spaces and parameter name spaces here.
• Chapter 18, Configuring MoveIt (page 341): A one-line description of what each section of the assistant means would be good. Just saying "Nothing to do here" does not teach the reader much.
• Chapter 20, Testing a many-node system (page 368): As amazing as it may seem, some students will try to run the example test system using roslaunch, not rostest. It might be worth adding a one-liner from the shell showing launching it using rostest to illustrate that rostest is not just a library.
• Chapter 23, page 405: The third paragraph feels a little redundant.

Please help me understand the origin tag in URDF

Hi folks,

I have been struggling with how the origin tag means in URDF files.

In the chapter 18, there is a snippet of URDF as the following:

      <link name="base_link">
        <visual>
          <geometry>
            <cylinder length="0.05" radius="0.1"/>
          </geometry>
          <material name="silver">
            <color rgba="0.75 0.75 0.75 1"/>
          </material>
          <origin rpy="0 0 0" xyz="0 0 0.025"/>
        </visual>
      </link>

The origin tag xyz = 0 0 0.025 puzzles me. The books says the 0.025 is meant to "... offset in z the point of reference for the base link from its default in the cylinder's center to its bottom." What I don't understand is that if we need to push the origin to the bottom, shouldn't we use -0.25? Why would increase the z value make the origin go down instead of going up?

What's more perplexing is that, later in the joint, it seems using a positive z value in origin actually makes the origin go up:

      <joint name="hip" type="continuous">
        <axis xyz="0 0 1"/>
        <parent link="base_link"/>
        <child link="torso"/>
        <origin rpy="0 0 0" xyz="0.0 0.0 0.05"/>
      </joint>

Here my understanding is that the z value 0.05 is meant to push the origin of the joint to be top of the base link so the next link can start there.

Why does positive value in link's origin push origin downward but push origin upward in joints?

No motion plan found

In the pick_up_item.py the bot is not able to find any plan for the motion. Can you please suggest anything.

Can't install ros-indigo-fetch*?

Guys,

I have been following the tutorial in chapter 14 Stockroom-bot. It seems that I can't download the fetch model by following the instructions in the book:

roy@RoysMacUbuntu:~/ws/src/stockroom_bot$ sudo apt-get install ros-indigo-fetch*
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package ros-indigo-fetch*
E: Couldn't find any package by glob 'ros-indigo-fetch*'

I also tried ros-kinetic-fetch* (because I am using ROS kinetic). Didn't work either:

roy@RoysMacUbuntu:~/ws/src/stockroom_bot$ sudo apt-get install ros-kinetic-fetch*
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package ros-kinetic-fetch*
E: Couldn't find any package by glob 'ros-kinetic-fetch*'
E: Couldn't find any package by regex 'ros-kinetic-fetch*'

Any idea how I can get the Fetch model?

Many thanks for your time.

controllers.yaml with move_group and gazebo

Hi!

For the cougarbot section, there is a yaml file you make with the controller_manager_ns: / etc... to interface the moveit config and gazebo, rviz.

The format as it appears, it fails to work in the gazebo cougarbot launch file. To make it work, the controller_list: line must be deleted and the rest one indent less. Otherwise, an error about not loading the arm_controller into the namespace or that it doesn't exist.

Could not load controller 'arm_controller' because the type was not specified. Did you load the controller configuration on the parameter server (namespace: '/arm_controller')?
[ERROR] [WallTime: 1452296250.613456] [2.923000] Failed to load arm_controller

Further, when you try to open move_group.launch it complains that there is no controller_list.

MoveitSimpleControllerManager: No controller_list specified.

These seem to be mutually unworkable.

I am in ROS indigo

General "Custom Message" Issues

I've created a basics package in my ROS kinetic that depends on rospy and actionlib_msgs, however, any code that has: from basics.msg import <insert msg name here> I get this issue:

ImportError: No module named basics.msg

Do you know what might be the case?

[Text improvement] Chapter 4: Differing arguments to find_package() call (again)

On page 52, the find_package() call has slightly different arguments from the one given in chapter 3 (on page 42). It should be made consistent. Similarly, the package.xml additions listing includes the rospy dependency in this chapter, but did not in chapter 3.

key_publisher.py does not work

The code related with key_publisher does not work.
It has two issues

1. The keystrokes are not captured
2. After Ctrl-C the keystroke capturing is not restored so it makes the terminal unusable.

Possibly incorrect wheel arrangement on Tortoisebot

This assumes that the front of the Tortoisebot robot is the end with the caster (based on Figures 17-7 and 17-9).

Code sample 16-10, in chapter 16, adds a differential drive controller to the simulated tortoisebot. But when the reader controls the robot, it turns left when told to turn right and vice versa. This leads on to the navigation system getting very confused and the examples towards the end of chapter 17 failing.

This is caused by the following two lines in the URDF file (from the differential_drive_controller plugin part):

<leftJoint>left_wheel_joint</leftJoint>
<rightJoint>right_wheel_joint</rightJoint>

It looks like the differential_drive_controller counter-intuititvely expects the left and right wheel joints to be around the other way:

http://gazebosim.org/tutorials?tut=ros_gzplugins#DifferentialDrive

Changing the above two lines accordingly makes the robot steer correctly, and allows the navigation examples to work.

<leftJoint>right_wheel_joint</leftJoint>
<rightJoint>left_wheel_joint</rightJoint>

aisle.world file need correcting

when I run "roslaunch stockroom_bot stockroom.launch" it Don't launch the simulator and gives "Error [parser.cc:581] Unable to find uri[model://bin]"

in aisle.world.em file "model://bin" lines should be "model://models/bin"

I solved it this way

Laser plug-in publishes abnormal scan results.

I have added the laser plug-in to my URDF file and launched the model successfully in gazebo. when i tried to visualize the behavior of laser plug-in in rviz after the doing the basic settings as instructed, i couldn't find any results. I read the topic using the command "rostopic echo /scan" and obtained the result below

Below is my URDF file:

   <?xml    version="1.0"?>
   <robot
   name="JMbot1.1">
    <link
     name="Base_plate">
     <inertial>
     <origin
     xyz="9.28103095721513E-18 -0.00236910483921667 1.69476737537172E-19"
      rpy="0 0 0" />
   <mass
    value="0.553781193313651" />
  <inertia
    ixx="0.00613802647719325"
    ixy="-5.56633892187664E-20"
    ixz="1.95355359086701E-19"
    iyy="0.0102825986842358"
    iyz="3.22575373206078E-19"
    izz="0.00414996381570526" />
</inertial>
<visual>
  <origin
    xyz="0 0 0"
    rpy="0 0 0" />
  <geometry>
    <mesh
      filename="package://jmbot1_description/meshes/Base_plate.STL" />
  </geometry>
  <material
    name="">
    <color
      rgba="0.749019607843137 0.749019607843137 0.749019607843137 1" />
  </material>
</visual>
<collision>
  <origin
    xyz="0 0 0"
    rpy="0 0 0" />
  <geometry>
    <mesh
      filename="package://jmbot1_description/meshes/Base_plate.STL" />
  </geometry>
</collision>
      </link>
     <link
      name="Wheel_R">
       <inertial>
        <origin
    xyz="-0.0394771489417549 -5.20417042793042E-18 1.73472347597681E-18"
    rpy="0 0 0" />
  <mass
    value="0.450643534719172" />
  <inertia
    ixx="0.000916081598048295"
    ixy="1.48930401404157E-20"
    ixz="-9.81573335914851E-21"
    iyy="0.000533948766711724"
    iyz="0"
    izz="0.000533948766711724" />
</inertial>
<visual>
  <origin
    xyz="0 0 0"
    rpy="0 0 0" />
  <geometry>
    <mesh
      filename="package://jmbot1_description/meshes/Wheel_R.STL" />
  </geometry>
  <material
    name="">
    <color
      rgba="0.749019607843137 0.749019607843137 0.749019607843137 1" />
  </material>
</visual>
<collision>
  <origin
    xyz="0 0 0"
    rpy="0 0 0" />
  <geometry>
    <mesh
      filename="package://jmbot1_description/meshes/Wheel_R.STL" />
  </geometry>
</collision>
   </link>
 <joint  name="Wheel_R"
  type="continuous">
<origin
  xyz="0.135 0.015 0"
  rpy="1.4389236251236 -2.11732407237853E-18 3.14159265358979" />
<parent
  link="Base_plate" />
<child
  link="Wheel_R" />
<axis
  xyz="1 0 0" />
   </joint>
  <link
name="Wheel_L">
<inertial>
  <origin
    xyz="-0.0394771489417549 1.21430643318377E-17 8.67361737988404E-18"
    rpy="0 0 0" />
  <mass
    value="0.450643534719172" />
  <inertia
    ixx="0.000916081598048295"
    ixy="2.90916462871053E-20"
    ixz="-2.96782618561828E-20"
    iyy="0.000533948766711724"
    iyz="5.42101086242752E-20"
    izz="0.000533948766711724" />
</inertial>
<visual>
  <origin
    xyz="0 0 0"
    rpy="0 0 0" />
  <geometry>
    <mesh
      filename="package://jmbot1_description/meshes/Wheel_L.STL" />
  </geometry>
  <material
    name="">
    <color
      rgba="0.749019607843137 0.749019607843137 0.749019607843137 1" />
  </material>
</visual>
<collision>
  <origin
    xyz="0 0 0"
    rpy="0 0 0" />
  <geometry>
    <mesh
      filename="package://jmbot1_description/meshes/Wheel_L.STL" />
  </geometry>
</collision>
   </link>
   <joint
  name="Wheel_L"
  type="continuous">
<origin
  xyz="-0.135 0.015 0"
  rpy="0.928716950811488 0 0" />
<parent
  link="Base_plate" />
<child
  link="Wheel_L" />
<axis
  xyz="-1 0 0" />
 </joint>
 <link
name="Castor_F">
<inertial>
  <origin
    xyz="-4.16333634234434E-17 0 0.03116425205832"
    rpy="0 0 0" />
  <mass
    value="0.0565552012132997" />
  <inertia
    ixx="2.44755054701354E-05"
    ixy="-6.23799465703127E-37"
    ixz="-1.01877548447475E-20"
    iyy="2.44755054701354E-05"
    iyz="8.40860868946448E-21"
    izz="7.43413937311511E-06" />
</inertial>
<visual>
  <origin
    xyz="0 0 0"
    rpy="0 0 0" />
  <geometry>
    <mesh
      filename="package://jmbot1_description/meshes/Castor_F.STL" />
  </geometry>
  <material
    name="">
    <color
      rgba="0.752941176470588 0.752941176470588 0.752941176470588 1" />
  </material>
</visual>
<collision>
  <origin
    xyz="0 0 0"
    rpy="0 0 0" />
  <geometry>
    <mesh
      filename="package://jmbot1_description/meshes/Castor_F.STL" />
  </geometry>
</collision>
   </link>
   <joint
name="Castor_F"
type="continuous">
<origin
  xyz="0 0 0.15"
  rpy="-1.5707963267949 -0.957338804063555 8.69652688200404E-17" />
<parent
  link="Base_plate" />
<child
  link="Castor_F" />
<axis
  xyz="0 0 1" />
    </joint>
   <link
name="Castor_R">
<inertial>
  <origin
    xyz="0 -1.11022302462516E-16 0.0311642520583196"
    rpy="0 0 0" />
  <mass
    value="0.0565552012132997" />
  <inertia
    ixx="2.44755054701354E-05"
    ixy="-1.69406589450864E-21"
    ixz="-3.77743078318297E-20"
    iyy="2.44755054701354E-05"
    iyz="2.51661046244309E-22"
    izz="7.43413937311511E-06" />
</inertial>
<visual>
  <origin
    xyz="0 0 0"
    rpy="0 0 0" />
  <geometry>
    <mesh
      filename="package://jmbot1_description/meshes/Castor_R.STL" />
  </geometry>
  <material
    name="">
    <color
      rgba="0.752941176470588 0.752941176470588 0.752941176470588 1" />
  </material>
</visual>
<collision>
  <origin
    xyz="0 0 0"
    rpy="0 0 0" />
  <geometry>
    <mesh
      filename="package://jmbot1_description/meshes/Castor_R.STL" />
  </geometry>
</collision>
   </link>
 <joint
name="Castor_R"
type="continuous">
<origin
  xyz="0 0 -0.15"
  rpy="1.5707963267949 -0.931442561406784 3.14159265358979" />
<parent
  link="Base_plate" />
<child
  link="Castor_R" />
<axis
  xyz="0 0 1" />
 </joint>


 <link name="hokuyo_link">
<collision>
  <origin xyz="0 0 0" rpy="0 0 0"/>
  <geometry>
    <box size="0.1 0.1 0.1"/>
  </geometry>
</collision>
<visual>
  <origin xyz="0 0 0" rpy="0 0 0"/>
  <geometry>
    <box size="0.1 0.1 0.1"/>
  </geometry>
</visual>
<inertial>
  <mass value="1e-5" />
  <origin xyz="0 0 0" rpy="0 0 0"/>
  <inertia ixx="1e-6" ixy="0" ixz="0" iyy="1e-6" iyz="0" izz="1e-6" />
</inertial>
     </link>
      <joint name="hokuyo_joint" type="fixed">
<axis xyz="0 1 0" />
<origin xyz="0 -0.055 0.2" rpy="0 0 0"/>
<parent link="Base_plate"/>
<child link="hokuyo_link"/>
  </joint>


   <gazebo>
 <plugin    name="differential_drive_controller"
filename="libgazebo_ros_diff_drive.so">
<leftJoint>Wheel_L</leftJoint>  
<rightJoint>Wheel_R</rightJoint>
<robotBaseFrame>Base_plate</robotBaseFrame>
<wheelSeparation>0.235</wheelSeparation>
<wheelDiameter>0.12</wheelDiameter>
<publishWheelJointState>true</publishWheelJointState>
</plugin>
  </gazebo>
   <gazebo>
   <plugin  name="joint_state_publisher"
filename="libgazebo_ros_joint_state_publisher.so">
<jointName>Castor_F, Castor_R</jointName>
</plugin>   
    </gazebo>


  <gazebo reference="hokuyo_link">
<sensor type="gpu_ray" name="hokuyo">
  <pose>0 0 0 0 0 0</pose>
  <visualize>false</visualize>
  <update_rate>40</update_rate>
  <ray>
    <scan>
      <horizontal>
        <samples>100</samples>
        <resolution>1</resolution>
        <min_angle>-1.570796</min_angle>
        <max_angle>1.570796</max_angle>
      </horizontal>
    </scan>
    <range>
      <min>0.10</min>
      <max>30.0</max>
      <resolution>0.01</resolution>
    </range>
  </ray>
  <plugin name="laser" filename="libgazebo_ros_gpu_laser.so">
    <topicName>/scan</topicName>
    <frameName>hokuyo_link</frameName>
       </plugin>
         </sensor>
         </gazebo>

    </robot>    

NASA R2 repositories have moved

NASA appears to have moved all their code for the R2 simulation to gitlab.

https://gitlab.com/nasa-jsc-robotics/robonaut2/wikis/R2%20Gazebo%20Simulation

The bitbucket repositories have all been marked as deprecated and renamed, meaning that the instructions on page 172 no longer work.

https://bitbucket.org/nasa_ros_pkg/

Additionally, the install process appears to have changed (probably the code has been reorganised); see the above page.

Robot model not properly oriented with map frame in Rviz

I have launched my roslaunch file (created following tortoisebot). I have reused the willow world and willow map since i got problem in building my own map which was raised as another issue in this repository.
Then i visualized the navigation in Rviz the robot model was improper when i select "map" as fixed frame. The orientation was improper (wheels are not landed on ground surface) also when i choose other links as fixed frame. It is perfectly oriented only when i choose odom as fixed frame. Please find my result in the images.

[Text improvement] Chapter 2: Improve tf descriptions

In the first paragraph on page 28, "contains a list of transforms" should be "contains a list of transforms, each between two coordinate frames" and "referred to as parent and child" should be "referred to as the parent and child" to improve clarity.

rosparam set the wrong name

Page 240
user@hostname$ rosparam set use_time_time true
parameter name should be use_sim_time
SUMMARY

PARAMETERS

• /rosdistro: indigo
• /rosversion: 1.11.20

NODES

"basics" directory in the topics chapter.

There's a line in the book on topics, page 34, it states "Remember that the basics directory has to be in your catkin workspace...". However as far as I can tell this is the first mention of the basics directory, previously the user was directed to create a directory to store code in called "my_awesome_code" (p.15). I believe these are equivalent but it can cause confusion (well it confused me).

Robot model fails to reach goal in navigation stack.

I followed the instructions of the book and built a map using slam_gmapping node. I have configured navigation stack to my gazebo robot and created a launch file as below.
Everything went fine with out error, of-course there are some warnings. When i launched the stack and gave initial pose & goal, the robot fails to trace the goal. It wanders with confusion and executes the rotary recovery mode.
The localization of the robot was poor and the navigation getting aborted often. In some cases the robot moves till 50% of goal path and fails there.
I understand there is some problem with my configuration and needs some fine tuning. Where should i apply patches to fix this. Below is my launch and config codes.

PS: I am using non-gpu laser sensor because i got some problem with my gpu_ray laser.

<launch>
  <!-- Load the TortoiseBot URDF model into the parameter server -->
  <param name="robot_description" textfile="$(find jmbot2_description)/urdf/jmbot1.2.urdf" />
  <!-- Start Gazebo with a world containing a large building-->
  <include file="$(find gazebo_ros)/launch/willowgarage_world.launch"/>
  <!-- include file="$(find gazebo_ros)/launch/empty_world.launch"/ -->
  <!-- Spawn a TortoiseBot in Gazebo, taking the description from the
       parameter server -->
  <node name="spawn_urdf" pkg="gazebo_ros" type="spawn_model" 
    args="-param robot_description -urdf -model jmbot1.2 -x 8 -y -8" />

<!-- Convert /joint_states messages published by Gazebo to /tf messages,
       e.g., for rviz-->
  <node name="robot_state_publisher" pkg="robot_state_publisher"
        type="robot_state_publisher"/>
  <node name="map_server" pkg="map_server" type="map_server"
        args="$(find mapping2)/src/maps/mapnew.yaml"  />

<include file="$(find amcl)/examples/amcl_diff.launch"/>

  <node pkg="move_base" type="move_base" respawn="false" name="move_base" output="screen">
    <rosparam file="$(find jmbot2_description)/src/costmap_common_params.yaml" command="load" ns="global_costmap" />
    <rosparam file="$(find jmbot2_description)/src/costmap_common_params.yaml" command="load" ns="local_costmap" />
    <rosparam file="$(find jmbot2_description)/src/local_costmap_params.yaml" command="load" />
    <rosparam file="$(find jmbot2_description)/src/global_costmap_params.yaml" command="load" />
    <rosparam file="$(find jmbot2_description)/src/base_local_planner_params.yaml" command="load" />
    <param name="controller_frequency" value="5.0"/>
  </node>

</launch>

base_local_planner_params.yaml

TrajectoryPlannerROS:
  holonomic_robot: false
  meter_scoring: true

costmap_common_params.yaml

obstacle_range: 2.5
raytrace_range: 3.0
robot_radius: 0.5
inflation_radius: 0.55
observation_sources: laser_scan_sensor
laser_scan_sensor: {sensor_frame: hokuyo_link, data_type: LaserScan, topic: scan, marking: true, clearing: true}

global_costmap_params.yaml

global_costmap:
  global_frame: /map
  robot_base_frame: base_link
  update_frequency: 2.0
  static_map: true

local_costmap_params.yaml

local_costmap:
  global_frame: /odom
  robot_base_frame: base_link
  update_frequency: 2.0
  publish_frequency: 1.0
  static_map: false
  rolling_window: true
  width: 10.0
  height: 10.0
  resolution: 0.0

I get these warnings occasionally but these are not consistent

[ WARN] [1454605148.779801697, 21.830000000]: Failed to transform initial pose in time (Lookup would require extrapolation into the future. Requested time 21.825000000 but the latest data is at time 21.821000000, when looking up transform from frame [base_link] to frame [map])

[ WARN] [1454605512.623590430, 69.784000000]: Map update loop missed its desired rate of 2.0000Hz... the loop actually took 0.6400 seconds

[Text improvement] Chapter 2: Use rosrun to execute nodes

On page 22, all the examples are executing the nodes directly, even though rosrun has been introduced. If the intent is to show that the remapping arguments are part of the node rather than rosrun, then one example should be sufficient. The rest should use rosrun, encouraging the reader to use the ROS tools.

Trouble running red_light_green_light.py

Hello,
When I try to run red_light_green_light.py I get a few errors.

line 3: import: command not found
from: can't read /var/mail/geometry_msgs.msg
/home/william/catkin_ws/src/wanderbot_ws/src/wander/red_light_green_light.py: line 6: syntax error near unexpected token (' /home/william/catkin_ws/src/wanderbot_ws/src/wander/red_light_green_light.py: line 6:cmd_vel_pub = rospy.Publisher('cmd_vel', Twist, queue_size=1) #<1>'

I am trying to learn ROS and any help would be greatly appreciated!

[Text improvement] Chapter 4: Move description of using rosservice

The description of using rosservice call on page 57 could be moved to the "checking that everything works" section (on page 56) and referenced from here as "We previously used rosservice to call the service. This is the simplest way to use a service." This would make the "checking" section include actually checking that the service works, and not just that it exists. Particularly as the next section after the "checking" section changes the node source code.

[Text improvement] Chapter 2: Provide an example for rostopic

On page 19, the paragraph talks about how anazingly useful rostopic is, then suddenly asks the reader to run rqt_graph. This is a jarring disconnect. The reader should be asked to run rostopic first, then, with a connecting statement like "but GUIs are easier to understand for this sort of thing", introduce rqt_graph.

Corrections to text and code samples

• Chapter 6, Robonaut 2 (page 90): Missing closing bracket after "Figure 6-3".
• Chapter 7, all examples: The examples in this chapter vary by whether they create publishers and subscribers before or after the call to init_node(). All the previous chapters consistently create the publishers and subscribers after calling init_node(). This may be confusing for some readers.
• Chapter 7, Creating a package (page 100): The example title doesn't indicate the file name (unlike example 2). For a reader typing the code themselves, you are relying on them reading past the example before they start creating files and entering source code to get the same file name as you. It's also harder to guess which source file in the provided source matches the example when the file name is not given in the example title (this goes for all examples).
• Chapter 7, Creating a package (page 100): "W must include these": Does 'W' refer to the wanderbot package?
• Chapter 7, Reading sensor data (page 106): The text says that the simulation will keep running while models are being dragged and rotated, and so the output range values will continue to be updated. This wasn't exactly correct for me; when I dragged or rotated the simulated turtlebot, Gazebo stopped publishing range data until I released the mouse, even though the simulation kept running (or, at least, the simulated clock kept going up).
• Chapter 8, Example 8-5 (page 123): There is an error in this example. At the top, a global variable "g_last_send_time" is created (and given the value None). However, the rest of the code refers to the global variable "g_last_twist_send_time".
• Chapter 8, Example 8-5 (page 123): The global variable "g_last_twist" is declared in the function keys_cb(), but not used.
• Chapter 8, Velocity ramps (page 124): The command to launch the keys_to_twist_with_ramps.py node is missing a space between two of the parameters.
• Chapter 8, rviz (page 127): The text instructs the reader to select the cell to the right of "Fixed Frame", but because there is an error regarding the fixed frame (map doesn't exist with the Turtlebot sim at its defaults), there are two cells named "Fixed Frame". The text should specify that the user should work with the one under "Global Options". It would also be worth adding a note about the error in the global status entries and confirming that it has gone green when the reader selects a fixed frame correctly.
• Chapter 9, Maps in ROS (page 136): "the length of each grid cell" -> "size" might be better than "length", since it's not a one-dimensional entity.
• Chapter 9, Maps in ROS (page 137): Is it correct that the cell value thresholds are truncated (49.98 -> 49) rather than rounded (49.98 -> 50)? (Are they cast to an int? I've never really looked...)
• Chapter 9, Building maps (page 141): The text instructs the reader to zoom out on the simulator (Stage) to see something like Figure 9-3, but Figure 9-3 shows rviz, not Stage.
• Chapter 9, Starting a map server... (page 148): My Indigo install doesn't have a mapping package or a file called "willow.yaml". I also couldn't find any "willow.yaml" on the web except the online sources for the book (and in the rtm-ros-robotics repository, oddly). I do have "turtlebot_navigation/maps/willow-2010-02-18-0.10.yaml", which appears to be the same map as that shown in Figure 9-7, although it lacks the blacked-out room. If the reader is expected to use the map provided with the book, they should be instructed specifically to do so.
• Chapter 10, What's going on behind the scenes (page 155): The text states that "rviz subscribes to a topic called initialpose" and then goes on to describe what amcl does. The first word should be "amcl", not "rviz" (rviz is publishing on that topic, not subscribing to it).
• Chapter 11, Installing and running a simulated R2 (page 173): The robot_state_publisher looks like it was already running from the r2_gazebo.launch file; when I started it manually it complained about a new node registered with the same name.
• Chapter 11, Installing and running a simulated R2 (page 174): What does "cd" mean?
• Chapter 11, Examples 11-2, 11-4, 11-5 and 11-9: These samples don't use the random module, but they continue to import it.
• Chapter 11, Moving R2 around a chessboard (page 178): The usage line in the example calls the file "r2_chessboard.py" but the example is titled "r2_chessboard_cli.py".
• Chapter 11, Example 11-5: None of the imports from geometry_msgs are needed in this example.
• Chapter 11, Example 11-5: This example doesn't have the moveit shutdown command, unlike the previous examples.
• Chapter 12, Example 12-2: Missing space between the arguments on the first line of image_callback()
• Chapter 12, Example 12-4: The values for the yellow filter in this example are different from those used in Example 12-3.
• Chapter 12, Example 12-5: Missing blank line before image_callback() definition.
• Chapter 13, Examples 13-2, 13-3 and 13-4: Missing space between "State," and "StateMachine". rospy is imported but not used.
• Chapter 13, Summary (page 224): wiht -> with
• Chapter 14, Stockroom simulation (page 226): The instructions for creating the package here are confusing. They imply that by making the directory and a package.xml, catkin will do the rest of the package initialisation automatically. When I followed the instructions as written, this didn't happen and catkin complained about missing CMakeLists.txt files. The instructions should stay consistent with what the reader has been taught so far and use catkin_create_pkg, then ask the reader to edit the package.xml template, rather than having them write one from scratch.
• Chapter 14, Examples 14-2 and 14-3 (page 227): The model's name is different in these two sources. 14-3's name ("box") is also different from the model directory name.
• Chapter 14, Example 14-3 (page 228): The model shown in Figure 14-1 and given by this source is different from the one produced by the online source. The figures need to be updated for the next edition of the book.
• Chapter 14, Example 14-4 (page 231): The book doesn't actually say where to put the script, where to execute it, or where to put the generated files. I had to read the EmPy template samples to figure out that they go in a "tags" directory under the bin model. Looking at the online source wasn't enough help, as it only showed where to put the script, not where to execute it or put the results.
• Chapter 14, Example 14-5 (page 232): This example lacks guidance on where to place the file or what to call it.
• Chapter 14, Example 14-5 (page 232): The world name in the book is "stockroom", but in the online source, it is "aisle". (The file name in both is "aisle".)
• Chapter 14, page 233: Missing '<' in explanation 10. It should be ''.
• Chapter 14, Example 14-7 (page 234): The first collision is given the name 'visual'. Should this be 'collision'?
• Chapter 14, Example 14-7 (page 235): The sizes for the walls give heights of 1 for all except the wall under the counter in the book, but the online source specifies 0.7 for all walls. The book's sizes look better and are probably more realistic.
• Chapter 14, Example 14-8 (page 237): Guidance on where to put the file is missing. The reader is likely to guess "src/ under my package directory" based on the previous chapters, but the online source does not follow this convention.
• Chapter 14, page 238: The reader gets to the end of creating their stockroom world without the book mentioning the need to download the product model from the online sources and put it in the correct place.
• Chapter 14, page 239: Chapter 13 does not mention anything about building or using maps. The reference should probably point to chapter 10, which describes navigation and how it uses maps in detail.
• Chapter 14, Driving to bins (page 240): The rosparam command should be setting "use_sim_time", not "use_time_time".
• Chapter 14, Driving to bins (page 240): The extra parameter to gmapping, "_odom_frame:=odom_combined", does not appear to be necessary for Fetch. If it is provided, the tf tree goes wonky and gmapping fails to process any data.
• Chapter 14, Driving to bins (page 241): The book does not instruct the reader to create the "initial_localization.py" script.
• Chapter 14, Example 14-12 (page 242): Stray semi-colons at line ends.
• Chapter 14, Example 14-15 (page 248): CollisionObject does not need to be imported.
• Chapter 14, Example 14-15 (page 248): It is not clear who is supposed to be providing the /clear_octomap service (it apparently comes from MoveIt, which I don't have much experience with), but it isn't being provided by all the stuff launched so far. It turns out that the moveit.launch launch file needs to be started to get it, but the text does not instruct the reader to do so.
• Chapter 14, Example 14-15 (page 249): Commented out rosservice call should be deleted?
• Chapter 14, Example 14-16 (page 254): tf does not need to be imported.
• Chapter 15, Example 15-1 (page 261): The API to access the sensor's value is not correct. The FakeSensor class does not expose the "value()" accessor of the ActualFakeSensor class. To make this example run, the value must be accessed as "sensor.sensor.value()" or the FakeSensor class needs an additional property to expose the value() method from its ActualFakeSensor member.
• Chapter 15, Example 15-2 (page 263): This example has the same bug as 15-1: The necessary sensor API is not exposed by the FakeSensor class. I also got fun race conditions when I added the necessary API because the ActualFakeSensor instance is created when the thread starts. (It must be, of course, because of Qt.) The fake_sensor.py file needs a significant overhaul.
• Chapter 15, Example 15-2 (page 263): The pub variable needs to be marked global to be accessible from the callback. Even better would be to create a closure, although that may be too complex for an example that is supposed to be teaching.
• Chapter 15, Example 15-3 (page 265): Same API problem as the previous examples.
• Chapter 15, Example 15-4 (page 266): The reader should have been told what package to put their nodes in (in this case, "stuff") to have their services be available properly.
• Chapter 15, Example 15-4 (page 266): There is a name collision between the imported FakeSensor class and the imported FakeSensor service request.
• Chapter 15, Designing the ROS wrapper (page 268): "For our fake sensor" -> "For our fake actuator"
• Chapter 15, Example 15-6 (page 268): The package name for the services is "sensors". This doesn't match the previous package in this chapter ("stuff"). This isn't necessarily a bad thing, but the reader should be told what package to put their source in, for those who copy it by hand. For those who use the provided source, they will run into the same problem because the package in the provided source that the fake actuator stuff is placed in is also "stuff".
• Chapter 15, Example 15-6 (page 269): Unnecessary semi-colon after break
• Chapter 15, Example 15-6 (page 269): The node's name should probably be "fake_actuator" rather than "fake".
• Chapter 15, Designing the ROS wrapper (page 270): The text states that the Light service and the action have been previously defined and discussed, but they have not. The Light service is defined/described lower down in Design 2, and the action is defined/described in Design 3.
• Chapter 15, Example 15-6 (page 268): Bug in fake_actuator.py, line 47: change called method to "isChecked()".
• Chapter 15, Example 15-6 (page 268): No GUI is displayed by the sample.
• Chapter 16, Modelling the robot (page 282): The urdf_to_graphiz tool has moved to the liburdfdom-tools package (since Indego?). The text needs to be updated to mention this.
• Chapter 16, Modelling the robot (page 284 bottom): "As you can already," -> "As you can already see," ?
• Chapter 16, Modelling the robot (page 286): "read the URDF" -> "reads the URDF" (in 2 places)
• Chapter 16, Example 16-3 (page 287): The material "black" is used here but not defined until Example 16-4. Not that you would notice, since an undefined material gets rendered as black anyway.
• Chapter 18, Example 18-2 (page 325): The "silver" material is getting re-defined here. It was already defined in example 18-1.
• Chapter 18, Simulation in Gazebo (page 330): "like a in rag doll" -> "like a rag doll"
• Chapter 18, Configuring MoveIt (page 342): The file to create should be called "config/controllers.yaml".
• Chapter 18, Using rviz to send goals (page 343): Funky text: "bring up rviz in a? with a? suitable configuration"
• Chapter 21, Logger levels/Figure 21-1 (page 380): The reader will only see something like the window shown if they have a system running, which they have not been told to do. Perhaps provide a complete source listing for battery_monitor and have the reader run it? Then they can try rqt_console on page 381 easily, too.
• Chapter 22, Finding and sharing code (page 404): Missing closing bracket in the second paragraph.
• Chapter 23, catkin_make (page 408): The example directory listing should include a src/ directory for the packages, to match the description in the text.
• Chapter 23, Example 23-5 (page 413): There are many errors in this example, beginning with a missing include for so strlen() can be used (perhaps req.words.length() would be better) and the variable "l" in the callback not having a type declaration.

Missing deps in actions example

Forwarded from O'Reilly:

*My Book:*

*December 2015:  First Edition*

*Revision History for the First Edition*
*2015-11-18 first Release*

*Correction:*

*Chapter 5 Actions*

*  Defining an Action*

*    adding some lines to CMakeList.txt*



*    MISSING -> we also need to add two lines to
package.xml
<build_depend>actionlib_msgs</build_depend>
<run_depend>actionlib_msgs</run_depend>*

*The code works only after i added these two lines to the package.xml*

chapter 12 codes freezing

When I run the codes in followbot package the window doesn't show up and freeze, but when I comment cv2.namedWindow("window", 1) line as in this link :: http://answers.ros.org/question/257440/python-opencv-namedwindow-and-imshow-freeze/
it works this's happening when I run any node in followbot package

Error in Chapter 8 Page 126 under rviz heading line 6

Under the rviz heading, a node with the "keys_to_teleop_with_rates.py" is mentioned which helps to create a suitable environment for rviz to work for the first time but this node or node name is only mentioned here only and can't be found anywhere in the entire book. I believe it is a printing error, so i would kindly request you to please assist me in this as i am facing difficulty in rviz specially setting up my fixed frame.

Thank You.

slam_gmapping parameter prefix error

Page 240,
user@hostname$ rosrun gmapping slam_gmapping scan:=base_scan
odom_frame:=odom_combined
prefix of odom_frame should be '~' instead of ''.

SUMMARY

PARAMETERS

• /rosdistro: indigo
• /rosversion: 1.11.20

NODES

Bug in chapter 7.

Hi,

I found some bug from example code for chapter 7, which is about Wanderbot.
Most of the code was good though, some inequality sign should be opposite in my thought.

Could you check p.101 and 107 as the attached images?

Compatibility with Tiago

Hello,

Not sure where else to leave a message, but I just did the wanderbot tutorials as listed in the rosbook. I wanted to know if there was a way to use the wander.py or the red_light_green_light.py scripts on a Tiago Titanium Mobile Manipulator. This is to be run within Gazebo, but I'm not sure I can match the nodes exactly. Is there a place where I should leave this message/request support?

Regards,

tushariyer

is it possible to simulate Nasa's R2 on ROS Noetic?

Unable to run the python file red_light_green_light.py

Hello
My Gazebo simulation is running already and the topic /cmd_vel_mux/input/teleop is there but when I run ./red_light_green_light.py cmd_vel:=cmd_vel_mux/input/teleop there is displayed nothing. Like this:

ibrahim@ibrahim-aspire-v5-591g:~/catkin_workspaces/ros_python_ws/src/wanderbot/src$ ./red_light_green_light.py cmd_vel:=cmd_vel_mux/input/teleop
ibrahim@ibrahim-aspire-v5-591g:~/catkin_workspaces/ros_python_ws/src/wanderbot/src$ 

Can anyone help me to point out the problem ?
Thanks

p.204, example 12-4

The code needs to import Twist module as below image.
(from geometry_msgs.msg import Twist)

Error while building map in slam_gmapping.

I have recorded the rosbag data by simulating the robot in gazebo. I played back the logged bag file and tried to build the map using slam_gmapping node and i ended up in error below

[ WARN] [1453398305.145461344]: Laser has to be mounted planar! Z-coordinate has to be 1 or -1, but gave: -0.03982

After few iterations, i was able to build the map by modifying laser scanner joint origin in my URDF file from

origin xyz="0 -0.040 0.2" rpy="-1.5708 -1.5708 0"
to
origin xyz="0 -1 0.2" rpy="1.5708 -1.5708 0"
but my robot model become weird as below (laser scanner is away from the robot).

How to get around the issue without relocating the laser scanner
Below is my original robot model also fine my URDF file here https://www.dropbox.com/s/af99gstvnv1e3s0/jmbot1.1.urdf?dl=0