Code Monkey home page Code Monkey logo

ros_gz's Introduction

Build Status

ROS 2 version Gazebo version Branch Binaries hosted at
Foxy Citadel foxy https://packages.ros.org
Foxy Edifice foxy only from source
Galactic Edifice galactic https://packages.ros.org
Galactic Fortress galactic only from source
Humble Fortress humble https://packages.ros.org
Humble Garden humble only from source
Iron Fortress iron https://packages.ros.org
Iron Garden iron only from source
Iron Harmonic iron only from source
Jazzy* Fortress humble only from source
Jazzy* Garden ros2 only from source
Jazzy* Harmonic ros2 https://packages.ros.org
Rolling Fortress humble https://packages.ros.org
Rolling Garden ros2 only from source
Rolling Harmonic ros2 only from source
  • ROS 2 Jazzy Jalisco is slated for release on May 23rd, 2024. [Full ROS 2 release information is available in REP-2000.]

For information on ROS(1) and Gazebo compatibility, refer to the noetic branch README

Please ticket an issue if you'd like support to be added for some combination.

Details about the renaming process from ign to gz .

Note: The ros_ign prefixed packages are shim packages that redirect to their ros_gz counterpart. Under most circumstances you want to be using the ros_gz counterpart.

Integration between ROS and Gazebo

Packages

This repository holds packages that provide integration between ROS and Gazebo:

Install

This branch supports ROS Rolling. See above for other ROS versions.

Binaries

Rolling binaries are available for Fortress. They are hosted at https://packages.ros.org.

  1. Add https://packages.ros.org

     sudo sh -c 'echo "deb [arch=$(dpkg --print-architecture)] http://packages.ros.org/ros2/ubuntu $(lsb_release -cs) main" > /etc/apt/sources.list.d/ros2-latest.list'
     curl -s https://raw.githubusercontent.com/ros/rosdistro/master/ros.asc | sudo apt-key add -
     sudo apt-get update
    
  2. Install ros_gz

     sudo apt install ros-rolling-ros-gz
    

From source

ROS

Be sure you've installed ROS Rolling (at least ROS-Base). More ROS dependencies will be installed below.

Gazebo

Install either Edifice, Fortress, or Garden.

Set the GZ_VERSION environment variable to the Gazebo version you'd like to compile against. For example:

export GZ_VERSION=edifice

You only need to set this variable when compiling, not when running.

Compile ros_gz

The following steps are for Linux and OSX.

  1. Create a colcon workspace:

    # Setup the workspace
    mkdir -p ~/ws/src
    cd ~/ws/src
    
    # Download needed software
    git clone https://github.com/gazebosim/ros_gz.git -b ros2
    
  2. Install dependencies (this may also install Gazebo):

    cd ~/ws
    rosdep install -r --from-paths src -i -y --rosdistro humble
    

    If rosdep fails to install Gazebo libraries and you have not installed them before, please follow Gazebo installation instructions.

  3. Build the workspace:

    # Source ROS distro's setup.bash
    source /opt/ros/<distro>/setup.bash
    
    # Build and install into workspace
    cd ~/ws
    colcon build
    

Tip

The ros_gz library makes heavy use of templates which causes compilers to consume a lot of memory. If your build fails with c++: fatal error: Killed signal terminated program cc1plus try building with colcon build --parallel-workers=1 --executor sequential. You might also have to set export MAKEFLAGS="-j 1" before running colcon build to limit the number of processors used to build a single package.

ROSCon 2022

Project Template

A template project integrating ROS and Gazebo simulator

ros_gz's People

Contributors

adityapande-1995 avatar ahcorde avatar andermi avatar andrejorsula avatar aryaman22102002 avatar azeey avatar bperseghetti avatar caguero avatar chama1176 avatar chapulina avatar dlu avatar ejalaa12 avatar gezp avatar iche033 avatar ivanpauno avatar j-rivero avatar jmackay2 avatar livanov93 avatar luca-della-vedova avatar methyldragon avatar mjcarroll avatar nkoenig avatar scpeters avatar sea-bass avatar shiveshkhaitan avatar valeriomagnago avatar wep21 avatar williamlewww avatar yadunund avatar ymd-stella avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ros_gz's Issues

ROS -> IGN stops working after 5 minutes of inactivity

I have noticed this problem in the SubT environment, but it can be easily reproduced as follows:

  • Start roscore

  • In one terminal (Terminal 1), run the parameter bridge:

    rosrun ros1_ign_bridge parameter_bridge "test@std_msgs/String]ignition.msgs.StringMsg"
    
  • In another terminal (Terminal 2), echo the ign-transport topic

    ign topic -e -t /test
    
  • In another terminal (Terminal 3), publish on the ROS topic

    rostopic pub -1 /test std_msgs/String "data: 'Hello1'"
    
  • On Terminal 2, you should see

    data: "Hello1"
    
  • Now wait 5 minutes without publishing anything and then, on Terminal 3, run

    rostopic pub -1 /test std_msgs/String "data: 'Hello2'"
    
  • You expect to see

    data: "Hello2"
    

    but instead, you'll get nothing.

This is a strange behavior since neither ROS or ign-transport have this problem when used directly to send messages to other ros and ign-transport nodes respectively.

ros_ign_bridge error for nest model sensor topic

I create a nest model sdf which contains a camera sensor with default topic, then i publish this topic to ros by using use ros_ign_bridge.but i get a error like this.so how to solve it? i have no idea now, thank you.

what():  Invalid topic name: topic name must not contain characters other than alphanumerics, '_', '~', '{', or '}':

this is topic info i use ign topic -l to get

/world/demo/model/my_robot/link/front_camera::camera/sensor/camera/image

NavSat Ignition Gazebo ROS Bridge Update

Hello,

I am curious if anyone has been working on getting the NavSat/GPS parameter in Ignition Gazebo converted with the ign_ros bridge. Using Citadel I was able to get the NavSat Ignition Gazebo sensor message to work, but I didn't see the ROS message conversion available in the sensor list. Any tips on how I can get the GPS sensor message converted to ROS.

High CPU usage of clock bridge with stopped simulator

This a screenshot of htop on a server where SubT simulator has recently finished the 3600 seconds mission. I guess it pauses the simulation then. I noticed that in this state, the clock bridges seem to be pretty active given they have nothing to transmit...

Snรญmek obrazovky poล™รญzenรฝ 2020-12-11 13-48-26

Launch file may start wrong ign-gazebo version

ign_gazebo.launch starts Ignition Gazebo with the ign gazebo command line command:

https://github.com/ignitionrobotics/ros_ign/blob/a4bc25fde117f9ce7279c83dc419bfb0eb3983b9/ros_ign_gazebo/launch/ign_gazebo.launch.py#L34

https://github.com/ignitionrobotics/ros_ign/blob/968c31586bbe9964a3788d5970a90f88dfc3cb25/ros_ign_gazebo/scripts/ign_gazebo#L16

The problem is that, if a user has more than one ign-gazebo version installed, that will launch the latest version, which may not necessarily be what the ROS user wants. For example, if I have ros-foxy-ros-ign (which uses Citadel, i.e. ign-gazebo3) and Ignition Dome (i.e. ign-gazebo4) installed, the launch file will start a version of Ignition that may not be compatible with the rest of the things being launched.

The command line tool accepts the --force-version argument to specify what version to launch. But that is quite strict at the moment, and requires passing the fully qualified version, including minor and patch numbers (see gazebosim/gz-tools#36). This makes it complicated to hardcode the version on the launch file.

ROS2 galactic, ign fortress, find_package(geometry_msgs REQUIRED)

I found that in order to compile (colcon build) successfully on ROS2, ros_ign_gazebo/CMakeLists.txt needs to be modified:

find_package(geometry_msgs REQUIRED)
ament_target_dependencies(create
  rclcpp
  ignition-math6
  geometry_msgs
)

Otherwise, it results in a linking error:

undefined reference to `rosidl_message_type_support_t const* rosidl_typesupport_cpp::get_message_type_support_handle<std_msgs::msg::String_<std::allocator<void> > >()'

`ros2 run ros_ign_gazebo create` crashes ignition gazebo

Environment

  • OS Version: Ubuntu 20.04
  • Ignition binary version 5
  • ros Foxy

Description

  • Expected behavior: ros2 run ros_ign_gazebo create -file test.urdf works similar to ros2 launch gazebo_ros spawn_entity_demo.launch.py
  • Actual behavior: ignition gazebo crashes

Steps to reproduce

  • In terminal 1 run: ros2 launch ros_ign_gazebo ign_gazebo.launch.py
  • In terminal 2 run: ros2 run ros_ign_gazebo create -file <path to URDF>.urdf
    (will upload urdf shortly after i clean it up for public release)

Logs

Terminal 1 logs:

$ ros2 launch ros_ign_gazebo ign_gazebo.launch.py 
[ign gazebo-1] [libprotobuf ERROR google/protobuf/descriptor_database.cc:58] File already exists in database: ignition/msgs/actor.proto
[ign gazebo-1] [libprotobuf FATAL google/protobuf/descriptor.cc:1358] CHECK failed: GeneratedDatabase()->Add(encoded_file_descriptor, size): 
[ign gazebo-1] terminate called after throwing an instance of 'google::protobuf::FatalException'
[ign gazebo-1]   what():  CHECK failed: GeneratedDatabase()->Add(encoded_file_descriptor, size): 
[INFO] [ign gazebo-1]: process has finished cleanly [pid 444360]

Terminal 2 logs:

$ ros2 run ros_ign_gazebo create -file /home/aderic/maidbot/gohan_ws/src/gohan/don_description/urdf/test.urdf
[INFO] [1619977088.223243063] [ros_ign_gazebo]: Requesting list of world names.
[INFO] [1619977088.424361784] [ros_ign_gazebo]: Requested creation of entity.
[INFO] [1619977088.424403865] [ros_ign_gazebo]: OK creation of entity.

[ros2] Different interpretation of xacro/urdf files between igniton-gazebo3 and igniton-gazebo4/5

Environment

  • OS Version: Ubuntu 20.04
  • Source or binary build: igniton-gazebo3 igniton-gazebo4 igniton-gazebo5

Description

Don't know if I should report here or there: https://github.com/ignitionrobotics/ign-gazebo
I have a ROS / Ignition robot simulation working well with citadel, I did few tests with the newly released edifice and run into an issue on how my xacro/files are interpreted by gazebo when spawning with ros_ign_gazebo create.
More specifically on how a lidar sensor is positioned by gazebo.
When interpreting the following xacro/urdf file:

<?xml version="1.0" ?>
<robot name="will_be_ignored" xmlns:xacro="http://www.ros.org/wiki/xacro">

<gazebo>
  <plugin filename="ignition-gazebo-sensors-system" name="ignition::gazebo::systems::Sensors">
    <render_engine>ogre2</render_engine>
  </plugin>
</gazebo>

<link name="base_footprint">
  <visual>
    <geometry>
      <sphere radius="0.5"/>
    </geometry>
  </visual>
  <collision>
    <geometry>
      <sphere radius="0.5"/>
    </geometry>
  </collision>
  <inertial>
    <mass value="1"/>
  <inertia ixx="1" ixy="0.0" ixz="0.0" iyy="1" iyz="0.0" izz="1"/>
  </inertial>
</link>

<link name="link">
  <visual>
    <geometry>
      <sphere radius="1.0"/>
    </geometry>
  </visual>
  <collision>
    <geometry>
      <sphere radius="1.0"/>
    </geometry>
  </collision>
  <inertial>
    <mass value="1"/>
    <inertia ixx="1" ixy="0.0" ixz="0.0" iyy="1" iyz="0.0" izz="1"/>
  </inertial>
</link>

<gazebo reference="link" >
  <sensor name="link" type="gpu_lidar">
    <topic>scan</topic>
    <update_rate>30</update_rate>
    <lidar>
      <scan>
        <horizontal>
          <samples>2800</samples>
          <resolution>1</resolution>
          <min_angle>-2.09</min_angle>
          <max_angle>2.09</max_angle>
        </horizontal>
        <vertical>
          <samples>1</samples>
          <resolution>0.1</resolution>
          <min_angle>0.0</min_angle>
          <max_angle>0.0</max_angle>
        </vertical>
      </scan>
      <range>
        <min>0.05</min>
        <max>30.0</max>
        <resolution>0.01</resolution>
      </range>
    </lidar>
    <alwaysOn>1</alwaysOn>
    <visualize>true</visualize>
  </sensor>
</gazebo>

<joint name="base_footprint_joint" type="fixed">
  <origin xyz="0 0 3.0" rpy="0 0 0" />
  <parent link="base_footprint"/>
  <child link="link" />
</joint>

</robot>

igniton-gazebo3 places properly the lidar sensor at the origin of the link "link", whereas igniton-gazebo4 and igniton-gazebo5 place it at the origin of the link "base_footprint"

And indeed, if I use the gazebo GUI feature "Save world as..." I get a different sdf file between igniton-gazebo3 and igniton-gazebo4/5. With igniton-gazebo3, the sensor has the attribute <pose>0 0 3 0 -0 0</pose>, whereas with igniton-gazebo4/5, the sensor has no pose attribute. Full sdf files below:

igniton-gazebo3 :

<sdf version='1.7'>
  <world name='empty'>
    <physics name='1ms' type='ignored'>
      <max_step_size>0.001</max_step_size>
      <real_time_factor>1</real_time_factor>
      <real_time_update_rate>1000</real_time_update_rate>
    </physics>
    <plugin name='ignition::gazebo::systems::Physics' filename='ignition-gazebo-physics-system'/>
    <plugin name='ignition::gazebo::systems::UserCommands' filename='ignition-gazebo-user-commands-system'/>
    <plugin name='ignition::gazebo::systems::SceneBroadcaster' filename='ignition-gazebo-scene-broadcaster-system'/>
    <plugin name='ignition::gazebo::systems::Contact' filename='ignition-gazebo-contact-system'/>
    <light name='sun' type='directional'>
      <cast_shadows>1</cast_shadows>
      <pose>0 0 10 0 -0 0</pose>
      <diffuse>0.8 0.8 0.8 1</diffuse>
      <specular>0.2 0.2 0.2 1</specular>
      <attenuation>
        <range>1000</range>
        <constant>0.9</constant>
        <linear>0.01</linear>
        <quadratic>0.001</quadratic>
      </attenuation>
      <direction>-0.5 0.1 -0.9</direction>
      <spot>
        <inner_angle>0</inner_angle>
        <outer_angle>0</outer_angle>
        <falloff>0</falloff>
      </spot>
    </light>
    <gravity>0 0 -9.8</gravity>
    <magnetic_field>6e-06 2.3e-05 -4.2e-05</magnetic_field>
    <atmosphere type='adiabatic'/>
    <scene>
      <ambient>0.4 0.4 0.4 1</ambient>
      <background>0.7 0.7 0.7 1</background>
      <shadows>1</shadows>
    </scene>
    <model name='ground_plane'>
      <static>1</static>
      <link name='link'>
        <collision name='collision'>
          <geometry>
            <plane>
              <normal>0 0 1</normal>
              <size>100 100</size>
            </plane>
          </geometry>
          <surface>
            <friction>
              <ode/>
            </friction>
            <contact/>
          </surface>
        </collision>
        <visual name='visual'>
          <geometry>
            <plane>
              <normal>0 0 1</normal>
              <size>100 100</size>
            </plane>
          </geometry>
          <material>
            <ambient>0.8 0.8 0.8 1</ambient>
            <diffuse>0.8 0.8 0.8 1</diffuse>
            <specular>0.8 0.8 0.8 1</specular>
          </material>
          <plugin name='__default__' filename='__default__'/>
        </visual>
      </link>
      <plugin name='__default__' filename='__default__'/>
      <pose>0 0 0 0 -0 0</pose>
    </model>
    <model name='my_custom_model'>
      <link name='base_footprint'>
        <inertial>
          <pose>0 0 1.5 0 -0 0</pose>
          <mass>2</mass>
          <inertia>
            <ixx>6.5</ixx>
            <ixy>0</ixy>
            <ixz>0</ixz>
            <iyy>6.5</iyy>
            <iyz>0</iyz>
            <izz>2</izz>
          </inertia>
        </inertial>
        <collision name='base_footprint_collision'>
          <pose>0 0 0 0 -0 0</pose>
          <geometry>
            <sphere>
              <radius>0.5</radius>
            </sphere>
          </geometry>
          <surface>
            <friction>
              <ode/>
            </friction>
            <contact/>
          </surface>
        </collision>
        <collision name='base_footprint_fixed_joint_lump__link_collision_1'>
          <pose>0 0 3 0 -0 0</pose>
          <geometry>
            <sphere>
              <radius>1</radius>
            </sphere>
          </geometry>
          <surface>
            <contact>
              <ode/>
            </contact>
            <friction>
              <ode/>
            </friction>
          </surface>
        </collision>
        <visual name='base_footprint_visual'>
          <pose>0 0 0 0 -0 0</pose>
          <geometry>
            <sphere>
              <radius>0.5</radius>
            </sphere>
          </geometry>
          <plugin name='__default__' filename='__default__'/>
        </visual>
        <visual name='base_footprint_fixed_joint_lump__link_visual_1'>
          <pose>0 0 3 0 -0 0</pose>
          <geometry>
            <sphere>
              <radius>1</radius>
            </sphere>
          </geometry>
          <plugin name='__default__' filename='__default__'/>
        </visual>
        <gravity>1</gravity>
        <velocity_decay/>
        <sensor name='link' type='gpu_lidar'>
          <topic>scan</topic>
          <update_rate>30</update_rate>
          <lidar>
            <scan>
              <horizontal>
                <samples>2800</samples>
                <resolution>1</resolution>
                <min_angle>-2.09</min_angle>
                <max_angle>2.09</max_angle>
              </horizontal>
              <vertical>
                <samples>1</samples>
                <resolution>0.1</resolution>
                <min_angle>0</min_angle>
                <max_angle>0</max_angle>
              </vertical>
            </scan>
            <range>
              <min>0.05</min>
              <max>30</max>
              <resolution>0.01</resolution>
            </range>
          </lidar>
          <visualize>1</visualize>
          <pose>0 0 3 0 -0 0</pose>
          <alwaysOn>1</alwaysOn>
          <plugin name='__default__' filename='__default__'/>
        </sensor>
      </link>
      <static>0</static>
      <plugin name='ignition::gazebo::systems::Sensors' filename='ignition-gazebo-sensors-system'>
        <render_engine>ogre2</render_engine>
      </plugin>
      <pose>1.2 0 0.5 0 -0 -2.88319</pose>
    </model>
  </world>
</sdf>

and with igniton-gazebo5 :

<sdf version='1.8'>
  <world name='empty'>
    <physics name='1ms' type='ignored'>
      <max_step_size>0.001</max_step_size>
      <real_time_factor>1</real_time_factor>
      <real_time_update_rate>1000</real_time_update_rate>
    </physics>
    <plugin name='ignition::gazebo::systems::Physics' filename='ignition-gazebo-physics-system'/>
    <plugin name='ignition::gazebo::systems::UserCommands' filename='ignition-gazebo-user-commands-system'/>
    <plugin name='ignition::gazebo::systems::SceneBroadcaster' filename='ignition-gazebo-scene-broadcaster-system'/>
    <plugin name='ignition::gazebo::systems::Contact' filename='ignition-gazebo-contact-system'/>
    <light name='sun' type='directional'>
      <cast_shadows>1</cast_shadows>
      <pose>0 0 10 0 -0 0</pose>
      <diffuse>0.8 0.8 0.8 1</diffuse>
      <specular>0.2 0.2 0.2 1</specular>
      <attenuation>
        <range>1000</range>
        <constant>0.90000000000000002</constant>
        <linear>0.01</linear>
        <quadratic>0.001</quadratic>
      </attenuation>
      <direction>-0.5 0.1 -0.9</direction>
      <spot>
        <inner_angle>0</inner_angle>
        <outer_angle>0</outer_angle>
        <falloff>0</falloff>
      </spot>
    </light>
    <gravity>0 0 -9.8</gravity>
    <magnetic_field>6e-06 2.3e-05 -4.2e-05</magnetic_field>
    <atmosphere type='adiabatic'/>
    <scene>
      <ambient>0.4 0.4 0.4 1</ambient>
      <background>0.7 0.7 0.7 1</background>
      <shadows>1</shadows>
    </scene>
    <model name='ground_plane'>
      <static>1</static>
      <link name='link'>
        <collision name='collision'>
          <geometry>
            <plane>
              <normal>0 0 1</normal>
              <size>100 100</size>
            </plane>
          </geometry>
          <surface>
            <friction>
              <ode/>
            </friction>
            <bounce/>
            <contact/>
          </surface>
        </collision>
        <visual name='visual'>
          <geometry>
            <plane>
              <normal>0 0 1</normal>
              <size>100 100</size>
            </plane>
          </geometry>
          <material>
            <ambient>0.8 0.8 0.8 1</ambient>
            <diffuse>0.8 0.8 0.8 1</diffuse>
            <specular>0.8 0.8 0.8 1</specular>
          </material>
          <plugin name='__default__' filename='__default__'/>
        </visual>
      </link>
      <plugin name='__default__' filename='__default__'/>
      <pose>0 0 0 0 -0 0</pose>
    </model>
    <model name='my_custom_model'>
      <link name='base_footprint'>
        <inertial>
          <pose>0 0 1.5 0 -0 0</pose>
          <mass>2</mass>
          <inertia>
            <ixx>6.5</ixx>
            <ixy>0</ixy>
            <ixz>0</ixz>
            <iyy>6.5</iyy>
            <iyz>0</iyz>
            <izz>2</izz>
          </inertia>
        </inertial>
        <collision name='base_footprint_collision'>
          <pose>0 0 0 0 -0 0</pose>
          <geometry>
            <sphere>
              <radius>0.5</radius>
            </sphere>
          </geometry>
          <surface>
            <friction>
              <ode/>
            </friction>
            <bounce/>
            <contact/>
          </surface>
        </collision>
        <collision name='base_footprint_fixed_joint_lump__link_collision_1'>
          <pose>0 0 3 0 -0 0</pose>
          <geometry>
            <sphere>
              <radius>1</radius>
            </sphere>
          </geometry>
          <surface>
            <contact>
              <ode/>
            </contact>
            <friction>
              <ode/>
            </friction>
            <bounce/>
          </surface>
        </collision>
        <visual name='base_footprint_visual'>
          <pose>0 0 0 0 -0 0</pose>
          <geometry>
            <sphere>
              <radius>0.5</radius>
            </sphere>
          </geometry>
          <plugin name='__default__' filename='__default__'/>
        </visual>
        <visual name='base_footprint_fixed_joint_lump__link_visual_1'>
          <pose>0 0 3 0 -0 0</pose>
          <geometry>
            <sphere>
              <radius>1</radius>
            </sphere>
          </geometry>
          <plugin name='__default__' filename='__default__'/>
        </visual>
        <gravity>1</gravity>
        <velocity_decay/>
        <sensor name='link' type='gpu_lidar'>
          <topic>scan</topic>
          <update_rate>30</update_rate>
          <lidar>
            <scan>
              <horizontal>
                <samples>2800</samples>
                <resolution>1</resolution>
                <min_angle>-2.0899999999999999</min_angle>
                <max_angle>2.0899999999999999</max_angle>
              </horizontal>
              <vertical>
                <samples>1</samples>
                <resolution>0.10000000000000001</resolution>
                <min_angle>0</min_angle>
                <max_angle>0</max_angle>
              </vertical>
            </scan>
            <range>
              <min>0.050000000000000003</min>
              <max>30</max>
              <resolution>0.01</resolution>
            </range>
          </lidar>
          <visualize>1</visualize>
          <alwaysOn>1</alwaysOn>
          <plugin name='__default__' filename='__default__'/>
        </sensor>
      </link>
      <static>0</static>
      <plugin name='ignition::gazebo::systems::Sensors' filename='ignition-gazebo-sensors-system'>
        <render_engine>ogre2</render_engine>
      </plugin>
      <pose>1.2 0 0.5 0 -0 -2.88319</pose>
    </model>
  </world>
</sdf>

How to release and run different flavours of ros_ign packages

The original request is from @chapulina. This issue speaks only about the issue of having binary packages supporting different ROS distros and different Ignition distros. A source build for these combinations seems to be possible after changes in pr #72

A release of ros_ign code should ideally fulfill the following requirements:

  1. Package names in code repository should be maintain
    i.e: do not modify ros_ign or ros_ign_bridge
  2. Multiple ROS distributions and multiple ROS packages for the different distributions
    i.e: ros-melodic-ros-ign and ros-noetic-ros-ign
  3. Multiple Ignition versions and multiple packages for the different ignition versions
    i.e: ros-melodic-ros-ign-citadel and ros-melodic-ros-ign-blueprint
  4. Packages must be co-installable
    problem: filesystem paths are the same within the same ROS distribution since package names are the same
  5. Packages should install ROS code in the way that versions can be selected at launch/runtime
    problem: how to rosrun/roslaunch different code if package name is the same

Pose_V to TFMessage conversion lacks the headers

Environment

  • OS Version: Ubuntu 20.04
  • Source or binary build?
    Edifice - Binary
    ros_ign - Latest Source

Description

  • Expected behavior: TFMessage with child_frame_id and frame_id
  • Actual behavior: child_frame_id and frame_id values are empty in TFMessage

Steps to reproduce

  1. Spawn any world in Ignition and add at least 1 object to it. For eg: ign gazebo and add a sphere to the world via UI.
  2. Convert /world/default/dynamic_pose/info or /world/default/pose/info topic to TFMessage via bridge: ros2 run ros_ign_bridge parameter_bridge /world/default/dynamic_pose/info@tf2_msgs/msg/TFMessage[ignition.msgs.Pose_V
  3. Listen to the message from ROS2 ros2 topic echo /world/default/dynamic_pose/info

Geometries not found when defined inside ROS package

Loading a robot description from the ROS parameter server works nicely, but mesh-files are not found.
In our URDF-files we include meshes like so:
<geometry>
<mesh filename="package://my_package/meshes/frame.stl" />
</geometry>

But these result in file not found errors:
[GUI] [Err] [SystemPaths.cc:357] Unable to find file with URI [model://my_package/meshes/frame.stl]
[GUI] [Err] [SystemPaths.cc:444] Could not resolve file [model://my_package/meshes/frame.stl]
[GUI] [Err] [MeshManager.cc:172] Unable to find file[model://my_package/meshes/frame.stl]
[GUI] [Err] [MeshDescriptor.cc:56] Mesh manager can't find mesh named [model://my_package/meshes/frame.stl]

Changing the paths to absolute paths works fine, but this makes the URDF not portable unfortunately. Would it be possible to use the rospkg tooling to resolve these paths?

Melodic upgrade

It seems to me that the binary packages ros-melodic-ros-ign-* from packages.osrfoundation.org started to target Dome instead of Blueprint after the changes from mid-December.

In my opinion, this is a pretty disruptive change - running apt-get dist-upgrade would install a newer version of Ignition Gazebo if I wouldn't have noticed. And then a lot of surprises would come. This really isn't a pleasant user experience, and it doesn't make me feel safe about using the ROS-Ign bridge in the future.

I think a better process needs to be defined. My idea is that it would be helpful if the binary packages would contain both the ROS and Ignition version in their name - e.g. ros-melodic-ros-ign-blueprint-bridge, ros-melodic-ros-ign-bridge-blueprint or ros-melodic-ign-blueprint-ros-ign-bridge. This way, no unintentional upgrades would happen. And transitional packages not bound to particular Ignition releases by their name could be created for the meantime - until people adopt the new names. Or they could be there forever, just pointing to one of the version-bound packages.

ros_ign_gazebo create.cpp usage message incorrect

and misleading

Environment

  • OS Version: Ubuntu 20.04
  • Source build, ros2 branch

Description

  • Expected behavior:
  • gflags::SetUsageMessage(
    R"(Usage: create -world [arg] [-file FILE] [-param PARAM] [-topic TOPIC]
    [-string STRING] [-name NAME] [-x X] [-y Y] [-z Z]
    [-R ROLL] [-P PITCH] [-Y YAW])");
  • Actual behavior:
  • gflags::SetUsageMessage(
    R"(Usage: create -world [arg] [-file FILE] [-param PARAM] [-topic TOPIC]
    [-string STRING] [-name NAME] [-X X] [-Y Y] [-Z Z]
    [-Roll ROLL] [-Pitch PITCH] [-Yaw YAW])");

Remap in ros_ign_bridge ?

In order to be able to set the output ROS topic of my simulated depth sensor configurable (see gazebosim/gz-sim#360), I thought about having the possibility to have a different topic name on the ign side and on the ROS side.
Would this be useful or create some confusion?

What about using the := operator with for instance, the following syntax:
/chatter_in_ign:=/chatter_in_ros@std_msgs/[email protected]

Bridge services

Ignition offers several services. It would be good to bridge them directly to ROS (1 and 2) so users can do things like spawning entities directly from ROS.

robot_description_publisher

hi in the ros_ign ->robot_description_publisher,i see the doc , i'm finding the robot_description_publisher.launch.py,but i can't,pls help me .thanks very much :)

Provide a package that pulls the default Ignition version for each ROS distro

Each ROS distro is paired with a specific Ignition version as described on REP-2000. It's the same for Gazebo Classic.

We make sure that ros_ign releases match the official version. But since multiple Ignition rosdep keys may be available to packages across ROS distros (because those distros target the same platforms, i.e. Foxy and Galactic are on Ubuntu Focal), there's the potential for users mixing up versions unintentionally.

In order to make downstream maintainers' lives easier, we could provide a package whose sole purpose is to pull the correct Ignition version for a given ROS distro. Another advantage is that as long as the underlying APIs don't change, users can seamlessly upgrade from one ROS distro to another without editing their packages.

Desired behavior

Instead of depending directly on a Gazebo version, i.e.

<depend>ignition-gazebo5</depend>

Depend on the wrapper:

<depend>ros_ign_dev</depend>

Alternatives considered

  • Keep the status quo: depending on specific versions of the simulator
  • Instead of offering a single package that installs all of Ignition, we could have one per library, i.e.
    • ros_ign_math
    • ros_ign_gazebo
    • ros_ign_rendering
    • ...

Implementation suggestion

This suggestion is inspired by the gazebo_dev package:

https://github.com/ros-simulation/gazebo_ros_pkgs/tree/noetic-devel/gazebo_dev

Here's some history on it:

Feature Request: Add Float64 support in ros_ign_bridge

We are trying to implement a pan/tilt mechanism in ignition-gazebo (for SubT). We have the pan/tilt working using ignition messages, but the ignition joint controller expects an ignition::msgs::Double and ros_ign_bridge does not currently support double conversion from std_msgs::Float64 to ignition::msgs::Double.

I am starting to go through the ros_ign_bridge code to see how difficult it will be to implement this conversion. Is there any reason that this hasn't yet been implemented? An alternative place to fix this would be in ign-gazebo joint controller where we could have it accept a float instead of a double...any reason to prefer one fix over the other?

[ros2] Enable ROS (or system) time header stamps in ROS Bridge

Environment

  • OS Version: Ubuntu 20.04
  • Source or binary build? Latest source of ros_ign, commit: Latest-fff2dbf4801cbe2116defb817f8a122536bb79d6
  • Ignition: Edifice (Binary)
  • ROS2: Foxy

Description

  • Expected behavior: All the messages that are bridged from ignition to ros2 are stamped with either real time or sim time. Having an option to use the bridge with ros (or system) time. Being able to only pull data with sim or real time is problematic due to time disagreements between ros nodes and ignition for some packages such as moveit2.
  • Actual behavior: There is only sim or real time available stamps on ignition messages that are communicated through ros_ign_bridge

Steps to reproduce

I currently use vatanaksoytezer#1 to work around this issue. I didn't bothered to open up a PR since this wouldn't get merged and breaks the sim time. But I would love to contribute if you point me out some ways through a parameter to add this functionality. I think I could also create and publish clock messages from ros2 to ignition, but that seems unintuitive and I am not even sure that would work.

Move installation instructions to top-level README

For historical reasons, the ros_ign_bridge tutorial has requirements and installation instructions:

https://github.com/ignitionrobotics/ros_ign/tree/dashing/ros_ign_bridge#prerequisites

But now that this repository has multiple packages, I think that the installation instructions should be moved to the top-level README, and only package-specific information should be on each package's READMEs. This should make it easier to maintain the installation instructions up-to-date.

lidar scan is infinite

Hello, I don't know if this is the please to ask questions, but here it goes.
When I publish a lidar scan over the ignition ros bridge it gives me "inf" if there is no obstacle. I was wondering what the easiest way to just have it publish the max lidar range when this is the case. Pretty important since I want to simulate gmapping. I could create a note that subscribes to the ros topic and change the values and then publish it on another topic but that seems like a lot of work for such a minor thing.

Cheers.

README from ros_ign_bridge Example 2 issue

Desired behavior

I was trying Example 2 in the README and I initially didn't get any images. I was trying and trying to see what I did wrong, only to realize I hadn't pressed play yet in Ignition.

Now, maybe I'm the idiot here. However, since it's an example that is linked in the ros2 integration tutorial (so it could attract newbies like me), would it be smart to add a (don't forget to press play) reminder somewhere?

Implementation suggestion

Perhaps it would be wise to change the line in example 2 from:

First we start Ignition Gazebo.

To:

First we start Ignition Gazebo (don't forget to hit play, or Ignition Gazebo won't generate any images).

Additional context

If I'm the idiot here and it's just me, then feel free to close this issue. If it's a good idea, let me know and I'll make a PR for it.

[ros2] Joint states publisher and Create from param

Environment

In ROS + gazebo invoking <node name="urdf_spawner" pkg="gazebo_ros" type="spawn_model" args=" -urdf -model robot -param robot_description" respawn="false" output="screen" /> statement opens up gazebo, spawns the model and starts to publish /joint_states.

I am currently trying to replicate a similar behaviours with ROS2 Foxy. My setup is a docker image with ROS2 Foxy, Ubuntu 20.04, source build of ros2 branch of ros_ign and Binary install of Ignition Edifice.

This how my launch file looks like:

import os
import yaml
import xacro
from ament_index_python.packages import get_package_share_directory
from launch import LaunchDescription
from launch.actions import IncludeLaunchDescription
from launch.launch_description_sources import PythonLaunchDescriptionSource
from launch_ros.actions import Node

def load_file(package_name, file_path):
    package_path = get_package_share_directory(package_name)
    absolute_file_path = os.path.join(package_path, file_path)

    try:
        with open(absolute_file_path, "r") as file:
            return file.read()
    except EnvironmentError:  # parent of IOError, OSError *and* WindowsError where available
        return None


def load_yaml(package_name, file_path):
    package_path = get_package_share_directory(package_name)
    absolute_file_path = os.path.join(package_path, file_path)

    try:
        with open(absolute_file_path, "r") as file:
            return yaml.safe_load(file)
    except EnvironmentError:  # parent of IOError, OSError *and* WindowsError where available
        return None

def generate_launch_description():

    # Import model
    # gazebo_pkg_path =  os.path.join(get_package_share_directory("stretch_gazebo"), "urdf", "stretch_gazebo.urdf.xacro")
    # gazebo_pkg_path =  os.path.join(get_package_share_directory("stretch_description"), "urdf", "description_test.urdf.xacro")
    gazebo_pkg_path =  os.path.join(get_package_share_directory("stretch_description"), "urdf", "stretch_main.xacro")
    robot_description_config = xacro.process_file(
        gazebo_pkg_path
    )
    robot_description = {"robot_description": robot_description_config.toxml()}

    # Robot state publisher
    robot_state_publisher = Node(
        package="robot_state_publisher",
        executable="robot_state_publisher",
        name="robot_state_publisher",
        output="both",
        parameters=[robot_description],
    )

    # Ignition gazebo
    pkg_ros_ign_gazebo = get_package_share_directory('ros_ign_gazebo')
    gazebo = IncludeLaunchDescription(
        PythonLaunchDescriptionSource(
            os.path.join(pkg_ros_ign_gazebo, 'launch', 'ign_gazebo.launch.py')),
        launch_arguments={'ign_args': '-r empty.sdf'}.items(),
    )

    # RViz
    pkg_stretch_gazebo = get_package_share_directory('stretch_gazebo')
    rviz = Node(
        package='rviz2',
        executable='rviz2',
        arguments=['-d', os.path.join(pkg_stretch_gazebo, 'config', 'stretch_gazebo.rviz')],
        parameters=[robot_description]
    )

    # Spawn
    spawn = Node(package='ros_ign_gazebo', executable='create',
                arguments=[
                    '-name', 'robot',
                    # '-file', gazebo_pkg_path
                    # '-topic', '/robot_description'
                    '-param', robot_description
                    ],
                output='screen')

    # Ign Bridge
    bridge = Node(
        package='ros_ign_bridge',
        executable='parameter_bridge',
        arguments=['/cmd_vel@geometry_msgs/msg/[email protected]',
                '/model/robot/odometry@nav_msgs/msg/[email protected]',
                # '/model/robot/tf@tf2_msgs/msg/[email protected]_V',
                '/joint_states@sensor_msgs/msg/[email protected]',
                '/clock@rosgraph_msgs/msg/[email protected]'
                ],
        remappings=[
            # ("/model/robot/tf", "tf"),
            ("/model/robot/odometry", "odom")
        ],
        output='screen'
    )

    return LaunchDescription([
        robot_state_publisher,
        rviz,
        gazebo,
        spawn,
        bridge,
    ])

Description

  • Expected behavior: Launching ign gazebo and publishing joint states
  • Actual behavior: It fails to read the params from robot_description. I tried a similar behaviour with sdf files too. I manage to give cmd_vel commands and read odom from ign. Though I didn't get any joint_states. I can confirm that this is not a bridge issue by issuing ign topic -l command and there is no joint_states. My initial goal is to spawn the robot on ign, and show the robot movements on rviz. With ros_ign_bridge of tf I can show the frames in rviz but since I don't have the joint_states I can't show the model of the robot. Also in tf messages I can only see the base_link but no other links. I think this is mostly because diff_drive_plugin publishes it, not the ign gazebo. I would be happy to share any information you would like and would be happy to contribute with some PRs if there are any bugs / missing features related to these issues if you can brief me.

Steps to reproduce

You should be able to reproduce by sourcing the workspace and launching the file provided. I think it can be reproduced with any xacro file. If you want to take a deeper look I can send the full description file as well.

Output

[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [robot_state_publisher-1]: process started with pid [4724]
[INFO] [ign gazebo-2]: process started with pid [4726]
[INFO] [create-3]: process started with pid [4728]
[create-3] [INFO] [1620676458.214857039] [ros_ign_gazebo]: Requesting list of world names.
[robot_state_publisher-1] Parsing robot urdf xml string.
[robot_state_publisher-1] The root link base_link has an inertia specified in the URDF, but KDL does not support a root link with an inertia.  As a workaround, you can add an extra dummy link to your URDF.
[robot_state_publisher-1] Link caster_link had 0 children
[robot_state_publisher-1] Link link_left_wheel had 0 children
[robot_state_publisher-1] Link link_mast had 0 children
[robot_state_publisher-1] Link link_right_wheel had 0 children
[robot_state_publisher-1] [INFO] [1620676458.215944360] [robot_state_publisher]: got segment base_link
[robot_state_publisher-1] [INFO] [1620676458.215994193] [robot_state_publisher]: got segment caster_link
[robot_state_publisher-1] [INFO] [1620676458.216001299] [robot_state_publisher]: got segment link_left_wheel
[robot_state_publisher-1] [INFO] [1620676458.216005618] [robot_state_publisher]: got segment link_mast
[robot_state_publisher-1] [INFO] [1620676458.216009563] [robot_state_publisher]: got segment link_right_wheel
[ign gazebo-2] QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
[create-3] [ERROR] [1620676458.590403867] [ros_ign_gazebo]: Failed to get XML from param [robot_description].
[ERROR] [create-3]: process has died [pid 4728, exit code 255, cmd '/root/ws_stretch/install/ros_ign_gazebo/lib/ros_ign_gazebo/create -name robot -param robot_description --ros-args'].

Regression in ROS Noetic on armv8 and armhf

@mjcarroll FYI

ros_ign_bridge is no longer building on Ubuntu Focal armhf and Debian Buster armv8 jobs due to #137

On these platforms it appears to find ign-msgs5.

Compiler error failure to find OccupancyGrid message
00:20:32.201 [  5%] Building CXX object CMakeFiles/ros_ign_bridge_lib.dir/src/convert.cpp.o
00:20:32.287 /usr/lib/ccache/c++  -DROSCONSOLE_BACKEND_LOG4CXX -DROS_BUILD_SHARED_LIBS=1 -DROS_PACKAGE_NAME=\"ros_ign_bridge\" -Dros_ign_bridge_lib_EXPORTS -I/tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/include -I/opt/ros/noetic/include -I/opt/ros/noetic/share/xmlrpcpp/cmake/../../../include/xmlrpcpp -isystem /usr/include/ignition/msgs5 -isystem /usr/include/ignition/math6 -isystem /usr/include/ignition/transport8 -isystem /usr/include/ignition/cmake2 -isystem /usr/include/uuid  -g -O2 -fdebug-prefix-map=/tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1=. -fstack-protector-strong -Wformat -Werror=format-security -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC   -Wall -Wextra -I/usr/include/uuid -std=gnu++17 -o CMakeFiles/ros_ign_bridge_lib.dir/src/convert.cpp.o -c /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp
00:20:32.294 In file included from /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp:19:
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/include/ros_ign_bridge/convert.hpp:310:3: error: โ€˜ignition::msgs::OccupancyGridโ€™ has not been declared
00:20:55.500    ignition::msgs::OccupancyGrid & ign_msg);
00:20:55.500    ^~~~~~~~
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/include/ros_ign_bridge/convert.hpp:315:25: error: โ€˜OccupancyGridโ€™ in namespace โ€˜ignition::msgsโ€™ does not name a type
00:20:55.500    const ignition::msgs::OccupancyGrid& ign_msg,
00:20:55.500                          ^~~~~~~~~~~~~
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp:541:3: error: โ€˜ignition::msgs::OccupancyGridโ€™ has not been declared
00:20:55.500    ignition::msgs::OccupancyGrid & ign_msg)
00:20:55.500    ^~~~~~~~
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp: In function โ€˜void ros_ign_bridge::convert_ros_to_ign(const ROS_T&, IGN_T&) [with ROS_T = nav_msgs::OccupancyGrid_<std::allocator<void> >; IGN_T = int]โ€™:
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp:543:48: error: request for member โ€˜mutable_headerโ€™ in โ€˜ign_msgโ€™, which is of non-class type โ€˜intโ€™
00:20:55.500    convert_ros_to_ign(ros_msg.header, (*ign_msg.mutable_header()));
00:20:55.500                                                 ^~~~~~~~~~~~~~
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp:545:11: error: request for member โ€˜mutable_infoโ€™ in โ€˜ign_msgโ€™, which is of non-class type โ€˜intโ€™
00:20:55.500    ign_msg.mutable_info()->mutable_map_load_time()->set_sec(
00:20:55.500            ^~~~~~~~~~~~
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp:547:11: error: request for member โ€˜mutable_infoโ€™ in โ€˜ign_msgโ€™, which is of non-class type โ€˜intโ€™
00:20:55.500    ign_msg.mutable_info()->mutable_map_load_time()->set_nsec(
00:20:55.500            ^~~~~~~~~~~~
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp:550:11: error: request for member โ€˜mutable_infoโ€™ in โ€˜ign_msgโ€™, which is of non-class type โ€˜intโ€™
00:20:55.500    ign_msg.mutable_info()->set_resolution(
00:20:55.500            ^~~~~~~~~~~~
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp:552:11: error: request for member โ€˜mutable_infoโ€™ in โ€˜ign_msgโ€™, which is of non-class type โ€˜intโ€™
00:20:55.500    ign_msg.mutable_info()->set_width(
00:20:55.500            ^~~~~~~~~~~~
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp:554:11: error: request for member โ€˜mutable_infoโ€™ in โ€˜ign_msgโ€™, which is of non-class type โ€˜intโ€™
00:20:55.500    ign_msg.mutable_info()->set_height(
00:20:55.500            ^~~~~~~~~~~~
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp:558:17: error: request for member โ€˜mutable_infoโ€™ in โ€˜ign_msgโ€™, which is of non-class type โ€˜intโ€™
00:20:55.500        (*ign_msg.mutable_info()->mutable_origin()));
00:20:55.500                  ^~~~~~~~~~~~
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp:560:11: error: request for member โ€˜set_dataโ€™ in โ€˜ign_msgโ€™, which is of non-class type โ€˜intโ€™
00:20:55.500    ign_msg.set_data(&ros_msg.data[0], ros_msg.data.size());
00:20:55.500            ^~~~~~~~
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp: At global scope:
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp:566:25: error: โ€˜OccupancyGridโ€™ in namespace โ€˜ignition::msgsโ€™ does not name a type
00:20:55.500    const ignition::msgs::OccupancyGrid & ign_msg,
00:20:55.500                          ^~~~~~~~~~~~~
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp: In function โ€˜void ros_ign_bridge::convert_ign_to_ros(const IGN_T&, ROS_T&) [with ROS_T = nav_msgs::OccupancyGrid_<std::allocator<void> >; IGN_T = int]โ€™:
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp:569:30: error: request for member โ€˜headerโ€™ in โ€˜ign_msgโ€™, which is of non-class type โ€˜const intโ€™
00:20:55.500    convert_ign_to_ros(ign_msg.header(), ros_msg.header);
00:20:55.500                               ^~~~~~
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp:571:44: error: request for member โ€˜infoโ€™ in โ€˜ign_msgโ€™, which is of non-class type โ€˜const intโ€™
00:20:55.500    ros_msg.info.map_load_time.sec = ign_msg.info().map_load_time().sec();
00:20:55.500                                             ^~~~
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp:572:45: error: request for member โ€˜infoโ€™ in โ€˜ign_msgโ€™, which is of non-class type โ€˜const intโ€™
00:20:55.500    ros_msg.info.map_load_time.nsec = ign_msg.info().map_load_time().nsec();
00:20:55.500                                              ^~~~
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp:573:37: error: request for member โ€˜infoโ€™ in โ€˜ign_msgโ€™, which is of non-class type โ€˜const intโ€™
00:20:55.500    ros_msg.info.resolution = ign_msg.info().resolution();
00:20:55.500                                      ^~~~
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp:574:32: error: request for member โ€˜infoโ€™ in โ€˜ign_msgโ€™, which is of non-class type โ€˜const intโ€™
00:20:55.500    ros_msg.info.width = ign_msg.info().width();
00:20:55.500                                 ^~~~
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp:575:33: error: request for member โ€˜infoโ€™ in โ€˜ign_msgโ€™, which is of non-class type โ€˜const intโ€™
00:20:55.500    ros_msg.info.height = ign_msg.info().height();
00:20:55.500                                  ^~~~
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp:577:30: error: request for member โ€˜infoโ€™ in โ€˜ign_msgโ€™, which is of non-class type โ€˜const intโ€™
00:20:55.500    convert_ign_to_ros(ign_msg.info().origin(), ros_msg.info.origin);
00:20:55.500                               ^~~~
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp:579:31: error: request for member โ€˜dataโ€™ in โ€˜ign_msgโ€™, which is of non-class type โ€˜const intโ€™
00:20:55.500    ros_msg.data.resize(ign_msg.data().size());
00:20:55.500                                ^~~~
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp:580:36: error: request for member โ€˜dataโ€™ in โ€˜ign_msgโ€™, which is of non-class type โ€˜const intโ€™
00:20:55.500    memcpy(&ros_msg.data[0], ign_msg.data().c_str(), ign_msg.data().size());
00:20:55.500                                     ^~~~
00:20:55.500 /tmp/binarydeb/ros-noetic-ros-ign-bridge-0.111.1/src/convert.cpp:580:60: error: request for member โ€˜dataโ€™ in โ€˜ign_msgโ€™, which is of non-class type โ€˜const intโ€™
00:20:55.500    memcpy(&ros_msg.data[0], ign_msg.data().c_str(), ign_msg.data().size());
00:20:55.500                                                             ^~~~
00:20:55.500 make[4]: *** [CMakeFiles/ros_ign_bridge_lib.dir/build.make:66: CMakeFiles/ros_ign_bridge_lib.dir/src/convert.cpp.o] Error 1

Here are a few options to consider

  1. Revert #137 and release a new version
  2. Revert #137 temporarily, backport gazebosim/gz-msgs#138 to Blueprint and Citadel, then release this feature again
  3. Remove Blueprint and Citadel support and blacklist this package on the platforms that don't have Dome support.

How to load plugin from URDF in ignition ?

Transitioning from Gazebo to Ignition, I am trying to use the spawner #60
I can successfully load an URDF which spawn a model in Ignition, but in don't understand how to load a plugin from the URDF.
More precisely I am trying to start the DiffDrive plugin, I put the following :

  <plugin
    filename="libignition-gazebo-diff-drive-system.so"
    name="ignition::gazebo::systems::DiffDrive">
    <left_joint>left_wheel_joint</left_joint>
    <right_joint>right_wheel_joint</right_joint>
    <wheel_separation>1.25</wheel_separation>
    <wheel_radius>0.3</wheel_radius>
    <!-- no odom_publisher_frequency defaults to 50 Hz -->
  </plugin>

below under robot tag but nothing seems to be loaded. However when using a sdf file and putting it under the model tag, it works properly. Maybe there is an equivalent to the urdf gazebo tag for ignition but I cannot find any example.

ros_ign in ROS 2 Rolling has not been released on Ubuntu Jammy

The ROS 2 Rolling Ridley distribution recently migrated to Ubuntu 22.04 Jammy using the rosdistro migration tool.

This repository is one which failed to bloom during the migration because the ignition dependencies are not yet available in Ubuntu Jammy. Once the Jammy repositories and the rosdep database are updated it should be possible to release this repository in Rolling again by running bloom normally.

Packages which are not released in Rolling may not be automatically added to future stable ROS 2 distributions.

Invalid Inertia when loading a URDF

Environment

  • OS Version: Ubuntu 18.04
  • Ignition Release: Fortress (binary)
  • ROS1: Melodic
  • Binary build: version 0.9.5
[Msg] Ignition Gazebo Server v6.0.0~pre1
[Msg] Ignition Gazebo GUI    v6.0.0~pre1
[Msg] Loading SDF world file[/home/hubble-02/stochlite/src/stochlite_ros/stochlite_gazebo/worlds/flat.sdf].
[Msg] Loaded level [3]
[Msg] No systems loaded from SDF, loading defaults
[Msg] Create service on [/world/flat/create]
[Msg] Remove service on [/world/flat/remove]
[Msg] Pose service on [/world/flat/set_pose]
[Msg] Light configuration service on [/world/flat/light_config]
[Msg] Physics service on [/world/flat/set_physics]
[Msg] Serving world controls on [/world/flat/control] and [/world/flat/playback/control]
[Msg] Serving GUI information on [/world/flat/gui/info]
[Msg] World [flat] initialized with [default_physics] physics profile.
[Msg] Serving world SDF generation service on [/world/flat/generate_world_sdf]
[Msg] Serving world names on [/gazebo/worlds]
[Msg] Resource path add service on [/gazebo/resource_paths/add].
[Msg] Resource path get service on [/gazebo/resource_paths/get].
[Msg] Resource paths published on [/gazebo/resource_paths].
[INFO] [1622050945.025013]: Controller Spawner: Waiting for service controller_manager/load_controller
[ INFO] [1622050945.098393860]: Requested creation of entity.
[stochlite/create-7] process has finished cleanly
log file: /home/hubble-02/.ros/log/bacf86ae-be49-11eb-8e3e-9c2976c9ae3c/stochlite-create-7*.log
[GUI] [Msg] Loading config [/home/hubble-02/.ignition/gazebo/gui.config]
[GUI] [Msg] Video recorder stats topic advertised on [/gui/record_video/stats]
[GUI] [Msg] Transform mode service on [/gui/transform_mode]
[GUI] [Msg] Record video service on [/gui/record_video]
[GUI] [Msg] Move to service on [/gui/move_to]
[GUI] [Msg] Follow service on [/gui/follow]
[GUI] [Msg] View angle service on [/gui/view_angle]
[GUI] [Msg] Move to pose service on [/gui/move_to/pose]
[GUI] [Msg] Camera pose topic advertised on [/gui/camera/pose]
[GUI] [Msg] View wireframes service on [/gui/view/wireframes]
[GUI] [Msg] View collisions service on [/gui/view/collisions]
[GUI] [Msg] Camera view controller topic advertised on [/gui/camera/view_control]
[GUI] [Msg] Added plugin [3D View] to main window
[GUI] [Msg] Loaded plugin [GzScene3D] from path [/usr/lib/x86_64-linux-gnu/ign-gazebo-6/plugins/gui/libGzScene3D.so]
[GUI] [Msg] Using world control service [/world/flat/control]
[GUI] [Msg] Listening to stats on [/world/flat/stats]
[GUI] [Msg] Added plugin [World control] to main window
[GUI] [Msg] Loaded plugin [WorldControl] from path [/usr/lib/x86_64-linux-gnu/ign-gui-6/plugins/libWorldControl.so]
[GUI] [Msg] Listening to stats on [/world/flat/stats]
[GUI] [Msg] Added plugin [World stats] to main window
[GUI] [Msg] Loaded plugin [WorldStats] from path [/usr/lib/x86_64-linux-gnu/ign-gui-6/plugins/libWorldStats.so]
[GUI] [Msg] Added plugin [Shapes] to main window
[GUI] [Msg] Loaded plugin [Shapes] from path [/usr/lib/x86_64-linux-gnu/ign-gazebo-6/plugins/gui/libShapes.so]
[GUI] [Msg] Added plugin [Lights] to main window
[GUI] [Msg] Loaded plugin [Lights] from path [/usr/lib/x86_64-linux-gnu/ign-gazebo-6/plugins/gui/libLights.so]
[GUI] [Msg] Added plugin [Transform control] to main window
[GUI] [Msg] Loaded plugin [TransformControl] from path [/usr/lib/x86_64-linux-gnu/ign-gazebo-6/plugins/gui/libTransformControl.so]
[GUI] [Msg] Screenshot service on [/gui/screenshot]
[GUI] [Msg] Added plugin [Screenshot] to main window
[GUI] [Msg] Loaded plugin [Screenshot] from path [/usr/lib/x86_64-linux-gnu/ign-gui-6/plugins/libScreenshot.so]
[GUI] [Msg] Added plugin [Component inspector] to main window
[GUI] [Msg] Loaded plugin [ComponentInspector] from path [/usr/lib/x86_64-linux-gnu/ign-gazebo-6/plugins/gui/libComponentInspector.so]
[GUI] [Msg] Added plugin [Entity tree] to main window
[GUI] [Msg] Loaded plugin [EntityTree] from path [/usr/lib/x86_64-linux-gnu/ign-gazebo-6/plugins/gui/libEntityTree.so]
[Wrn] [SimulationRunner.cc:643] Found additional publishers on /stats, using namespaced stats topic only
[Wrn] [SimulationRunner.cc:676] Found additional publishers on /clock, using namespaced clock topic only
[GUI] [Msg] Loading plugin [ignition-rendering-ogre2]
[Err] [UserCommands.cc:602] Error Code 18: [:L-1131947072]: Msg: A link named bl_abd_link has invalid inertia.
[Err] [UserCommands.cc:602] Error Code 18: [:L-1131947040]: Msg: A link named bl_thigh_link has invalid inertia.
[Err] [UserCommands.cc:602] Error Code 18: [:L-1131947008]: Msg: A link named bl_shank_link has invalid inertia.
[Err] [UserCommands.cc:602] Error Code 18: [:L-1131946976]: Msg: A link named br_abd_link has invalid inertia.
[Err] [UserCommands.cc:602] Error Code 18: [:L-1131946944]: Msg: A link named br_thigh_link has invalid inertia.
[Err] [UserCommands.cc:602] Error Code 18: [:L-1131946912]: Msg: A link named br_shank_link has invalid inertia.
[Err] [UserCommands.cc:602] Error Code 18: [:L-1131946880]: Msg: A link named fl_abd_link has invalid inertia.
[Err] [UserCommands.cc:602] Error Code 18: [:L-1131946848]: Msg: A link named fl_thigh_link has invalid inertia.
[Err] [UserCommands.cc:602] Error Code 18: [:L-1131946816]: Msg: A link named fl_shank_link has invalid inertia.
[Err] [UserCommands.cc:602] Error Code 18: [:L-1131946784]: Msg: A link named fr_abd_link has invalid inertia.
[Err] [UserCommands.cc:602] Error Code 18: [:L-1131946752]: Msg: A link named fr_thigh_link has invalid inertia.
[Err] [UserCommands.cc:602] Error Code 18: [:L-1131946720]: Msg: A link named fr_shank_link has invalid inertia.
/usr/lib/ruby/ignition/cmdgazebo6.rb:431: [BUG] Segmentation fault at 0x00007f00a31b0720
ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux-gnu]

-- Control frame information -----------------------------------------------
c:0007 p:---- s:0076 e:000075 CFUNC  :call
c:0006 p:0017 s:0054 e:000053 METHOD /usr/lib/ruby/ignition/cmdgazebo6.rb:431
c:0005 p:0160 s:0048 e:000047 BLOCK  /usr/lib/ruby/ignition/cmdgazebo6.rb:460 [FINISH]
c:0004 p:---- s:0045 e:000044 CFUNC  :fork
c:0003 p:0675 s:0041 e:000040 METHOD /usr/lib/ruby/ignition/cmdgazebo6.rb:456
c:0002 p:0695 s:0020 E:001900 EVAL   /usr/bin/ign:275 [FINISH]
c:0001 p:0000 s:0003 E:000210 (none) [FINISH]

-- Ruby level backtrace information ----------------------------------------
/usr/bin/ign:275:in `<main>'
/usr/lib/ruby/ignition/cmdgazebo6.rb:456:in `execute'
/usr/lib/ruby/ignition/cmdgazebo6.rb:456:in `fork'
/usr/lib/ruby/ignition/cmdgazebo6.rb:460:in `block in execute'
/usr/lib/ruby/ignition/cmdgazebo6.rb:431:in `runServer'
/usr/lib/ruby/ignition/cmdgazebo6.rb:431:in `call'

-- Machine register context ------------------------------------------------
 RIP: 0x00007f00a31b0720 RBP: 0x000055bcbc87dd40 RSP: 0x00007ffe6adf78a8
 RAX: 0x0000000000000000 RBX: 0x000055bcbc87dbc0 RCX: 0x0000000000000003
 RDX: 0x000055bcba908010 RDI: 0x000055bcbc8dbd90 RSI: 0x000055bcba908040
  R8: 0x000055bcbc87d0d0  R9: 0x0000000000000008 R10: 0x0000000000000200
 R11: 0x0000000000000000 R12: 0x00007ffe6adf7930 R13: 0x000055bcbc87dd40
 R14: 0x0000000000000000 R15: 0x00007ffe6adf7920 EFL: 0x0000000000010206

-- C level backtrace information -------------------------------------------
[GUI] [Msg] Loading plugin [ignition-rendering-ogre2]
================================================================================REQUIRED process [ign_gazebo-2] has died!
process has finished cleanly
log file: /home/hubble-02/.ros/log/bacf86ae-be49-11eb-8e3e-9c2976c9ae3c/ign_gazebo-2*.log
Initiating shutdown!
================================================================================
[stochlite/stochlite_gazebo-6] killing on exit
[stochlite/linear_policy_controller-5] killing on exit
[stochlite/controller_spawner-4] killing on exit
[stochlite/robot_state_publisher-3] killing on exit
[ign_gazebo-2] killing on exit
[WARN] [1622050946.497910]: Controller Spawner couldn't find the expected controller_manager ROS interface.
[rosout-1] killing on exit
[master] killing on exit
shutting down processing monitor...
... shutting down processing monitor complete
done

Description

  • Expected behavior: The URDF to be loaded normally (works with Gazebo Classic)
  • Actual behavior: Invalid Inertia of links

This is what I'm doing to spawn the robot ("stochlite" is the name of my robot)

<node pkg="ros_ign_gazebo" type="create" name="create" output="screen" 
args="-world $(arg gazebo_world) -file $(find stochlite_description)/urdf/stochlite.urdf -name spawned 
-x $(arg world_init_x) -y $(arg world_init_y) -z $(arg world_init_z) -Y $(arg world_init_heading) -R $(arg world_init_ang)">
</node>

The world file is loading properly (tried it without the model), So I doubt it's an issue on that front.

Steps to reproduce

The behavior also happens with the sphere sdf example given in this repo (again, works with Gazebo Classic)

  1. Inside the sphere.sdf in the demo folder replace the interial parameters with below
<mass value="0.037"/>
<inertia ixx="0.00043261" ixy="-0.00067195" ixz="3.147E-05" iyy="0.0010929" iyz="-1.979E-05" izz="0.0051879"/>

Output

Inertia parameters of one of the links (which work perfectly fine with URDF spawner of Gazebo classic)
image

Allow exporting IGN_GAZEBO_RESOURCE_PATH, etc... in the package.xml file of a ROS package

Desired behavior

I am using ROS2 foxy and Ignition Gazebo to write/simulate a package for my robot.
On Gazebo Classic, I am able to avoid modifying manually my .bashrc by inserting an export tag <gazebo_ros> in my package.xml .
This way, when someone build my package, the robot files are automatically available and the package can be tested immediately without having to touch the .bashrc .
I would like to see something similar implemented for ros_ign (I have searched for it, but I did not find this feature).

Implementation suggestion

Probably, something like https://github.com/ros-simulation/gazebo_ros_pkgs/blob/foxy/gazebo_ros/scripts/gazebo_ros_paths.py would be enough.

[ros2] Ignition Transport message duplication caused by bidirectional bridge

Environment

  • OS Version: Ubuntu 20.04
  • Ignition: Edifice, built from source
  • ROS 2: Foxy, binary install
  • ros_ign branch: ros2 (54e12e2), built from source

Note: Tested inside Docker container. I would appreciate someone to reproduce this issue to ensure it is not caused by my setup.

Description

  • Expected behaviour: Running a bidirectional parameter_bridge with Ignition publisher (separate) should generate only ROS 2 messages.
  • Actual behaviour: Running a bidirectional parameter_bridge with Ignition publisher (separate) generates both ROS 2 messages and duplicate versions of ignition-transport messages.
    • What could happening?:
      • Bidirectional bridge creates Node A: Ignition subscriber + ROS 2 publisher, and Node B: ROS 2 subscriber + Ignition publisher.
      • Once an ignition-transport message is published, Node A receives it and generates ROS 2 message. Subsequently, Node B receives this message generated by Node A and generates a duplicate ignition-transport message. (problem with ROS 2 subscriber configuration?)
      • This is just a speculation, I have not investigated the code. I am sure the original developers thought of this, otherwise there would be an infinite recursion happening if this issue occurred in both directions/multiple times.
  • Workaround: Use unidirectional bridge (99% of the use cases) to prevent message duplication that both decreases performance and could potentially break something. Updating examples to use unidirectional bridge instead of bidirectional bridge might also be an idea.

Note: Issue does not seem to occur for ROS 2 messages, i.e. bridge does not duplicate any ROS 2 messages.
Note: I have not tested this with ROS 1, so I am not sure if it experiences the same problem.

Steps to reproduce

Shell 1:
ros2 run ros_ign_bridge parameter_bridge /chatter@std_msgs/msg/[email protected]

Shell 2:
ign topic -e -t /chatter

Shell 3:
ign topic -t /chatter -m ignition.msgs.StringMsg -p 'data:"This message should be received only once"'

Output

root@P5550:~# ign topic -e -t /chatter
data: "This message should be received only once"

data: "This message should be received only once"

Expected output (same as without running any bridge)

root@P5550:~# ign topic -e -t /chatter
data: "This message should be received only once"

Expose ignition::msgs::Contact through ROS 2 msgs

Contact sensors are working nicely in Ignition through ignition::msgs::Contact. But they are not exposed through ros_ign.

I don't mind adding another conversion to the ros_ign_bridge, but I am not %100 sure what ROS message type I should use. I couldn't fit this to any existing ROS2 message. I can of course define a custom message type or create a new message package (ala gazebo_msgs), but I just want this to be mergeable contribution, so this issue is to discuss what you would be happy to do. Let me know which option would be better to expose this and I will be happy to implement it @chapulina.

For reference ignition::msgs::Contact has type:

header {
  stamp {
    sec: 6
    nsec: 884000000
  }
}
contact {
  header {
    stamp {
      sec: 6
      nsec: 884000000
    }
  }
  collision1 {
    id: 96
  }
  collision2 {
    id: 7
  }
  position {
    x: -0.38790994410051866
    y: -0.21047000000004118
    z: -3.3862761483760551e-09
  }
  position {
    x: -0.38790994409679119
    y: -0.15047000000004118
    z: -3.4019649319816381e-09
  }
}

Ros->Ign Bridge stops with signal 245 when JointStatePublisher is run

If you run a bridge to publish joint_states from Ros2 to ignition with ros run ros_ign_bridge parameter_bridge /joint_states@sensor_msgs/msg/[email protected] it works.

However if you run JointStatePublisher or JointStatePublisherGui with ros run joint_state_publisher joint_state_publisher and a Urdf file the bridge stops with no visible error beside signal 245 beeing sent
image

I tried changing the source topic and it still breaks. And using another data type for the bridge still works fine (float, int) with the JointStatePublisher

TF2 msgs not implemented in ros2 branch

PR #67 was merged in the melodic branch but has not been ported to the ROS2 branch.
This means there is no way to send tf messages to ignition for Ros2

Is there any plans to merge the melodic branch in the Ros2 branch sometime soon ?

If not I'm going to try and port in and will do a pull request

Branch off for Galactic

We're ready to default to Fortress for Rolling. Since bloom doesn't allow the injection of custom environment variables (see ros-infrastructure/bloom#517), the release will always take the default conditionals on package.xml and CMakeLists.txt. This means we need to branch off just so each branch defaults to a different version:

  • galactic defaults to Edifice
  • ros2 (rolling, future humble) defaults to Fortress

Desired behavior

The galactic branch can be released using Edifice and the ros2 branch can be released using Fortress.

Alternatives considered

I can't think of anything besides bloom allowing the injection of environment variables, or another way of passing parameters.

Implementation suggestion

  • Create the galactic branch off ros2 and enable branch protection
  • Open PRs for all versions updating the README with the new branch
    • melodic: #202
    • Merge melodic to noetic
    • galactic: also remove Rolling support: #201
    • foxy: #203
    • ros Update #195 so the ros2 branch is only for Rolling
  • Make a new release of galactic and update the rosdistro branch to galactic
  • Make a new release of ros2 for Rolling using Fortress

Additional context

Previous tickets which provide more context:

spawn robot from topic


Create the robot model from topic

Since the parameter server is no more used in ros2, the robot description is now published as a string message. Tools like rviz2 can subscribe to this message and load the robot definition.
I wanted to get a feedback if spawning a robot given the name of the topic could be a new feature to add inside create.cpp in the ros_ign_gazebo package.

Currently the model can be loaded from different source (param, file...) and I would propose to add a new argument that let user specify the name of the topic from which to load the robot model.

It would be sufficient to run

rosrun ros_ign_gazebo create --topic /robot_description

I am starting to port some simulation in ros2 and ignition gazebo citadel and this feature could make my actual code cleaner, but I am not sure if maybe I am missing something.

ros_ign_bridge with contact sensor fails

Environment

  • OS Version: Ubuntu 20.04
  • Source or binary build?
    Binary, Galactic
# Failed to create a bridge for topic [/model/robot/bumper_contact] with ROS2 type [ros_ign_interfaces/msg/Contacts] and Ignition Transport type [ignition.msgs.Contacts]

Description

  • Expected behavior: ros_ign_bridge created, bumper_contact topic is published in ros2
  • Actual behavior: Bridge fails to be created, nothing is published on ros2

Steps to reproduce

Node(package='ros_ign_bridge', executable='parameter_bridge',
                                 namespace=namespace,
                                 name='bumper_contact_bridge',
                                 output='screen',
                                 parameters=[{
                                     'use_sim_time': use_sim_time
                                 }],
                                 arguments=[
                                     'model/robot/bumper_contact' +
                                     '@ros_ign_interfaces/msg/Contacts' +
                                     '[ignition.msgs.Contacts'
                                 ],
                                 remappings=[
                                     ('model/robot/bumper_contact', '/bumper_contact')
                                 ])

I have the bridge working correctly for other sensors, its just contact which is giving me problems.

Bridge parameters

Desired behavior

ROS parameters provide a convenient way to manipulate properties of a node at runtime. It would be convenient for users to be able to alter simulation properties through ROS parameters.

Alternatives considered

All configuration could be exposed through topics, which can be bridged using ros_ign_bridge.

Implementation suggestion

It would be interesting to provide a generic "parameter bridge" that provides a parameter interface on the ROS side, and an Ignition Transport service interface on the simulation side.

Additional context

ROS 2 parameters themselves are built using services under the hood. So I think we can translate the same idea to ros_ign_bridge.

Trouble launching GPU_lidar

Hello,

The demo gpu_lidar.launch doesn't work.
The diff_drive and air pressure demos does work.
Ignition_gpu_lidar_error

I tried using "ogre" instead of "ogre2" for the rendering (it worked for other demos like depth cameras) but the trouble persists :

ruby: /build/ogre-1.9-B6QkmW/ogre-1.9-1.9.0+dfsg1/OgreMain/include/OgreSingleton.h:80: Ogre::Singleton::Singleton() [with T = Ogre::LogManager]: Assertion `!msSingleton' failed.

The full console print is attached gpu_lidar_console.txt

I am trying to transfer my simulation from Gazebo to Ignition gazebo.
I installed Igntion Gazebo and this package following your documentation.
I am using ROS Melodic with Ubuntu 18.04.1

parameter_bridge echos back when it receives ROS messages

When publishing to the ROS side of the parameter_bridge node, it echos back the message. To test, with roscore running, in one terminal I ran

rosrun ros1_ign_bridge parameter_bridge test@std_msgs/[email protected]

In another (terminal 2),

rostopic echo /test

And finally

rostopic pub /test std_msgs/String "data: 'Hello'"

I expect to see one message in terminal 2, but I get:

data: "Hello"
---
data: "Hello"
---

Memory Overflow on ROS2 Rolling

Environment

  • OS Version: Ubuntu 20.04
  • Source or binary build? Source

Hi,
I'm facing issue while building ros_ign_bridge on Ubuntu 20 with ROS2 Rolling with Ignition Fortress. Memory on my PC is overflowing everytime i try to build the package. I tried building older commit which had a CI check. But faced the same issue with that commit.

Specifications:
CPU: AMD Ryzen 7 3700x 8-core processor ร— 16
RAM: 16GB

Fatal Error when building ros_ign_bridge

Environment

  • OS Version: Ubuntu 20.04
  • Source or binary build?
    Source: ROS2 Galactic and Ignition Edifice

Following the documentation released here: https://github.com/ignitionrobotics/ros_ign/tree/ros2, the build fails with a fatal error when trying to build the ros_ign_bridge. In particular it cannot find the nav_msgs / msg / odometry.hpp file or directory.
The file in question, however, appears to be present in the ROS2 Galactic workspace.
The error is present in the test_utils.hpp

# paste log here
```Starting >>> ros_ign_bridge
--- stderr: ros_ign_bridge                             
In file included from /home/ggiuliano/ros_ign_ws/src/ros_ign/ros_ign_bridge/test/subscribers/ign_subscriber.cpp:22:
/home/ggiuliano/ros_ign_ws/src/ros_ign/ros_ign_bridge/test/subscribers/../test_utils.hpp:42:10: fatal error: nav_msgs/msg/odometry.hpp: No such file or directory
   42 | #include <nav_msgs/msg/odometry.hpp>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
In file included from /home/ggiuliano/ros_ign_ws/src/ros_ign/ros_ign_bridge/test/publishers/ign_publisher.cpp:25:
/home/ggiuliano/ros_ign_ws/src/ros_ign/ros_ign_bridge/test/publishers/../test_utils.hpp:42:10: fatal error: nav_msgs/msg/odometry.hpp: No such file or directory
   42 | #include <nav_msgs/msg/odometry.hpp>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [CMakeFiles/test_ign_subscriber.dir/build.make:63: CMakeFiles/test_ign_subscriber.dir/test/subscribers/ign_subscriber.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:327: CMakeFiles/test_ign_subscriber.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
make[2]: *** [CMakeFiles/test_ign_publisher.dir/build.make:63: CMakeFiles/test_ign_publisher.dir/test/publishers/ign_publisher.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:300: CMakeFiles/test_ign_publisher.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
---
Failed   <<< ros_ign_bridge [0.84s, exited with code 2]
Starting >>> ros_ign_bridge
--- stderr: ros_ign_bridge                             
In file included from /home/ggiuliano/ros_ign_ws/src/ros_ign/ros_ign_bridge/test/subscribers/ign_subscriber.cpp:22:
/home/ggiuliano/ros_ign_ws/src/ros_ign/ros_ign_bridge/test/subscribers/../test_utils.hpp:42:10: fatal error: nav_msgs/msg/odometry.hpp: No such file or directory
   42 | #include <nav_msgs/msg/odometry.hpp>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
In file included from /home/ggiuliano/ros_ign_ws/src/ros_ign/ros_ign_bridge/test/publishers/ign_publisher.cpp:25:
/home/ggiuliano/ros_ign_ws/src/ros_ign/ros_ign_bridge/test/publishers/../test_utils.hpp:42:10: fatal error: nav_msgs/msg/odometry.hpp: No such file or directory
   42 | #include <nav_msgs/msg/odometry.hpp>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [CMakeFiles/test_ign_subscriber.dir/build.make:63: CMakeFiles/test_ign_subscriber.dir/test/subscribers/ign_subscriber.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:327: CMakeFiles/test_ign_subscriber.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
make[2]: *** [CMakeFiles/test_ign_publisher.dir/build.make:63: CMakeFiles/test_ign_publisher.dir/test/publishers/ign_publisher.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:300: CMakeFiles/test_ign_publisher.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
---
Failed   <<< ros_ign_bridge [0.84s, exited with code 2]







## Description
* Expected behavior: No build errors
* Actual behavior: nav_msgs/msg/odometry.hpp not found

Failed to load xml from ROS param [ros_ign_gazebo create]

Test environment

  • Ubuntu 20.04
  • ROS2 Foxy
  • ignition citadel

Test launch file

<?xml version="1.0"?>
<launch>
  <group>
    <include file="$(find-pkg-share ros_ign_gazebo)/launch/ign_gazebo.launch.py">
      <arg name="ign_args" value="empty.sdf" />
    </include>
  </group>

  <node pkg="ros_ign_gazebo" exec="create" args="-world empty -param robot_description" output="screen">
    <param name="robot_description" value="$(command 'cat $(find-pkg-share test_robot_ign_gazebo)/urdf/my_robot.urdf')" />
  </node>
</launch>

This failed for "Failed to get XML from param".

How I resolved

Before

https://github.com/ignitionrobotics/ros_ign/blob/94a719adcf6005fae657a174489cb99349c33ced/ros_ign_gazebo/src/create.cpp#L44-L52

After

   ros::init(_argc, _argv, "ign_create"); 
   ros::NodeHandle nh; 

   gflags::AllowCommandLineReparsing(); 
   gflags::SetUsageMessage( 
       R"(Usage: create -world [arg] [-file FILE] [-param PARAM] [-string STRING] 
                        [-name NAME] [-X X] [-Y Y] [-Z Z] [-Roll ROLL] 
                        [-Pitch PITCH] [-Yaw YAW])"); 
   gflags::ParseCommandLineFlags(&_argc, &_argv, true);   

This change works good for me.

[ROS1] No TF published from Ignition with DiffDrive plugin

As opposite to gazebo classic, no tf from frame_id to child_frame_idis published with ignition when using the DiffDrive plugin.
What would be the best implementation strategy ?
Adding in ros_ign_bridge a tf publisher when converting Odom messages ?
Or adding in Ignition DiffDrive plugin the publication of the newly added 7b06c21 ignition.msgs.Pose_V that ros_ign_bridge will then convert to TF ? Btw, these new commits were only pushed to the melodic branch, would it be possible to port them to noetic (as I am working with noetic) ? @chapulina
Edit: I confused ROS2 branch and melodic

URDF Spawner

Hello,
I am trying to use Gazebo ignition instead of gazebo and I would like to know if there exists a model spawner that takes urdf input like in gaezbo-ros ?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.