search

ros-simulation / gazebo_ros_pkgs

Wrappers, tools and additional API's for using ROS with Gazebo
http://wiki.ros.org/gazebo_ros_pkgs
754 stars 770 forks source link

gazebo_ros_planar_move fails to publish correct time when utilizing gazebo8 (time is correct for gazebo7) with ROS Kinetic #818

Open JoepLinssen opened 6 years ago

JoepLinssen commented 6 years ago

Hi all,

I hope this is the right place for this issue/bug report. I encountered the following behavior today which I have not been able to track down and I believe is a bug:

When utilizing the gazebo_ros_planer_move library to publish the /odom topic and odom to base_link frame the time stamp fails when utilizing an installation of gazebo8, but succeeds with gazebo7.

To recreate:

bugtest.urdf


<?xml version="1.0"?>
<robot name="bugtest">
<gazebo>
    <plugin name="object_controller" filename="libgazebo_ros_planar_move.so">
        <commandTopic>cmd_vel</commandTopic>
        <odometryTopic>odom</odometryTopic>
        <odometryFrame>odom</odometryFrame>
        <odometryRate>100.0</odometryRate>
        <robotBaseFrame>base_link</robotBaseFrame>
    </plugin>
</gazebo>

<link name="base_link" >
    <collision>
        <origin xyz="-0.025 0 0.075"  rpy="0 -0 0"/>
        <geometry>
            <box size="0.74 0.65 0.15"/>
        </geometry>
    </collision>
    <visual>
        <origin xyz="-0.025 0 0.075"  rpy="0 -0 0"/>
        <geometry>
            <box size="0.74 0.65 0.15"/>
        </geometry>
    </visual>
</link>


> Environment setup A
`ros-kinetic-desktop-full`  installed (i.e. ROS Kinetic with Gazebo 7) 

> Environment setup B
Have A installed. Then execute:

sudo sh -c 'echo "deb http://packages.osrfoundation.org/gazebo/ubuntu-stable lsb_release -cs main" > /etc/apt/sources.list.d/gazebo-stable.list' wget http://packages.osrfoundation.org/gazebo.key -O - | sudo apt-key add - sudo apt update sudo apt remove ros-kinetic-gazebo- sudo apt install ros-kinetic-gazebo8-


Then, in either setup run in one terminal: `roslaunch gazebo_ros empty_world.launch`. In another terminal run after eachother: (make sure bugtest.urdf links to the path the urdf is in)

rosparam set robot_description "$(xacro bugtest.urdf)" rosrun gazebo_ros spawn_model -urdf -param robot_description -model bugtest rosrun robot_state_publisher robot_state_publisher 



Then, at least for me, I get differing behavior for environment setup A versus B. Specifically utilizing `rostopic echo /odom/header` displays the correct ROS time (which is sim time since empty_world defaults this to true) for setup A and, critically, NOT for setup B. 

For setup B, odom/header is filled with the Wall Time, however the `nsecs` is always 0. 

I hope you are able to reproduce this issue and provide some clarity!

PC setup:
Ubuntu 16.04 LTS
ROS_VERSION=1
ROS_DISTRO=kinetic
chapulina commented 6 years ago

I haven't tried reproducing yet, but some pointers which could help you debug this:

JoepLinssen commented 6 years ago

Hi, thanks for the reply!

I failed to mention in my original post that the error arose after a system update which included a ros-kinetic update.

Gazebo 9 does not work for me either; here the timestamp of the /odom topic is always 0 sec 0 nsec. The spawn_model routine now returns an error:

rosrun gazebo_ros spawn_model -urdf -param robot_description -model bugtest
SpawnModel script started
[INFO] [1536671997.663455, 0.000000]: Loading model XML from ros parameter
[INFO] [1536671997.666173, 0.000000]: Waiting for service /gazebo/spawn_urdf_model
[INFO] [1536671997.672709, 0.000000]: Calling service /gazebo/spawn_urdf_model
Service call failed: service [/gazebo/spawn_urdf_model] responded with an error: Time is out of dual 32-bit range

Regarding the population of the odom message; I found the line of code as well. Since it did not change recently I think that line is more a symptom than a cause of the issue.

I have not been able to discover the source of the error by myself the past day - did you have any luck reproducing it?

P.S. pressed enter at the wrong time, apologies for the clutter on the issue.

chapulina commented 6 years ago

Unfortunately I won't have time to look into this any time soon. If you're willing, I'd suggest you try putting some print statements on the relevant lines to narrow down where the error could be coming from. Is clock wrong? Is now wrong? Is the plugin doing something wrong? Has something changed upstream which is causing this...?

JoepLinssen commented 6 years ago

So.. I installed this repo from source, branch kinetic-devel, (instead of from apt) and I no longer experience the issue. Setup was as follows:

Have environment setup B as explained in my original post.

  • sudo apt remove ros-kinetic-gazebo8-*
  • make a catkin workspace with this repo cloned in the src dir (following this tut, branch kinetic-devel)
  • the rosdep check yields missing dependencies on gazebo7 and libgazebo7-dev -- however, I want it compiled against gazebo8 so I ignored the missing deps. (The environment setup explained here ensures I have the right packages installed; like `libgazebo8-dev' etc)
  • build the ws and source the setup.bash

Now redo the test in the original post and the /odom/header actually provides the correct timestamps.

I wouldn't consider this issue fixed, but at least I have a working configuration now; and since I really do not have time to investigate further, I will leave it at this.

rubenanapu commented 5 years ago

Over the past few days I've been facing the same problem, but I found a solution today.

What I was trying was basically to run ROS Kinetic + Gazebo 9.

My setup:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.5 LTS
Release:    16.04
Codename:   xenial

$ sudo dpkg -l| grep gazebo
ii  gazebo9                                            9.4.1-1~xenial
ii  gazebo9-common                                     9.4.1-1~xenial
ii  gazebo9-plugin-base                                9.4.1-1~xenial
ii  libgazebo9:amd64                                   9.4.1-1~xenial
ii  libgazebo9-dev:amd64                               9.4.1-1~xenial
ii  ros-kinetic-gazebo9-dev                            2.5.15-0xenial
ii  ros-kinetic-gazebo9-msgs                           2.5.15-0xenial
ii  ros-kinetic-gazebo9-plugins                        2.5.15-0xenial
ii  ros-kinetic-gazebo9-ros                            2.5.15-0xenial
ii  ros-kinetic-gazebo9-ros-control                    2.5.15-0xenial
ii  ros-kinetic-gazebo9-ros-pkgs                       2.5.15-0xenial

My errors were only with /gazebo/spawn_urdf_model and /gazebo/delete_model services, as far I could see. The :

The service rosservice call /gazebo/get_world_properties "{}" worked without any problem.

After looking http://gazebosim.org/tutorials?tut=ros_installing&cat=connect_ros I saw the message:

Kinetic is using the gazebo 7.x series, start by installing it:

Since I'm running gazebo9, I think this was a good clue. Although I'm using ros kinetic, I've just cloned gazebo_ros repository and compiled the melodic-devel branch, because I suppose it's prepared for gazebo9. After that, the problem has gone. The process was basically the following:

cd ~/catkin_ws/src
git clone https://github.com/ros-simulation/gazebo_ros_pkgs.git -b melodic-devel
cd ~/catkin_ws
catkin_make --only-pkg-with-deps gazebo_ros
source ~/catkin_ws/devel/setup.bash

After this, I've tried to call the services /gazebo/spawn_urdf_model and /gazebo/delete_model and the errors didn't appear anymore.

I've also confirmed that the gzserver process was now using /home/user/catkin_ws/devel/lib/libgazebo_ros_api_plugin.so instead of /opt/ros/kinetic/lib/libgazebo_ros_api_plugin.so

PS: The last commit when I compiled the gazebo_ros was:

~/catkin_ws/src/gazebo_ros_pkgs$ git log | head
commit 2e0d83597b390d43e559d1ad21a5eb56c20d98ad
Author: Paul Bovbel <paul@bovbel.com>
Date:   Wed Sep 12 12:18:42 2018 -0400

    Lower minimum cmake version (#817)