hector_gazebo
hector_gazebo copied to clipboard
GPS Plugin not working in Foxy
I am curious what the state of the gps plugin is in foxy-devel
.
I've added the minimal amount of information in a xacro file:
<plugin name="gps" filename="libhector_gazebo_ros_gps.so">
<bodyName>gps_link</bodyName>
</plugin>
but when I spawn the entity nothing appears, no topic is published and no debug information regarding the gps is printed to the terminal.
Ubuntu 20.04, ros foxy, gazebo-11.
Please note that the port to ROS2 is currently a community effort. See #92. Judging from the PR, GPS should be ported, though. Maybe @davidorchansky can help?
Hi @mnissov, The GPS plugin has been migrated to foxy and should work ok. I'm not sure what the minimal configuration is for this plugin, however you can find a working example in this other repo: https://github.com/osrf/vrx/blob/master/wamv_gazebo/urdf/components/wamv_gps.xacro https://github.com/davidorchansky/vrx/blob/foxy/wamv_gazebo/urdf/sensors/wamv_gps.xacro
<gazebo> <plugin name="gps_plugin_${name}" filename="libhector_gazebo_ros_gps.so"> <updateRate>${update_rate}</updateRate> <alwaysOn>true</alwaysOn> <bodyName>${namespace}/${name}_link</bodyName> <!-- Manually prepend namespace to tf frame. --> <frameId>${namespace}/${name}_link</frameId> <topicName>${namespace}/${sensor_namespace}gps/gps/fix</topicName> <!-- Note that the hector_gazebo_ros_gps plugin uses NWU coordinates for reporting velocities. This may cause problems if localization requires velocity in ENU. See Issue #64 in VRX project for details https://bitbucket.org/osrf/vrx/issues/64 --> <velocityTopicName>${namespace}/${sensor_namespace}gps/gps/fix_velocity</velocityTopicName> <!-- Tell the plugin to use the spherical_coordiantes parameters from SDF. https://github.com/tu-darmstadt-ros-pkg/hector_gazebo/blob/melodic-devel/hector_gazebo_plugins/src/gazebo_ros_gps.cpp#L101 --> <useWorldSphericalCoordinates>true</useWorldSphericalCoordinates> <offset>0.0 0.0 0.0</offset> <drift>0.0 0.0 0.0</drift> <gaussianNoise>0 0 0</gaussianNoise> <velocityOffset>0.0 0.0 0.0</velocityOffset> <velocityDrift>0.0 0.0 0.0</velocityDrift> <velocityGaussianNoise>0.0 0.0 0.0</velocityGaussianNoise> </plugin> </gazebo>
In my setup I have separate files for links and sensors, perhaps it could have something to do with using
<gazebo reference="gps_link">
<plugin name="gps" filename="libhector_gazebo_ros_gps.so">
<updateRate>10.0</updateRate>
<bodyName>gps_link</bodyName>
<frameId>gps_link</frameId> <!-- <frameId>wgs84</frameId> -->
<topicName>gps/fix</topicName>
<velocityTopicName>/gps/velocity</velocityTopicName>
<referenceLatitude>55.877627</referenceLatitude>
<referenceLongitude>8.463545</referenceLongitude>
<referenceAltitude>0.0</referenceAltitude>
<referenceHeading>0.0</referenceHeading>
<offset>0 0 0</offset>
<drift>0 0 0 </drift>
<!-- <gaussianNoise>0.05 0.05 0.05</gaussianNoise> -->
<velocityDrift>0 0 0</velocityDrift>
<!-- <velocityGaussianNoise>0.01 0.01 0.01</velocityGaussianNoise> -->
</plugin>
</gazebo>
I've just found that without the "reference" part of the gazebo tag it works fine. Which is funny because as far as I can see the opposite is ture when using gazebo's imu plugin.
@mnissov Hi, I used the above code plug-in in the noetic version, but there is no topic output. I want to ask, what is the reason? Does it need to install dependencies separately.
**/clock /gazebo/link_states /gazebo/model_states /gazebo/parameter_descriptions /gazebo/parameter_updates /gazebo/performance_metrics /gazebo/set_link_state /gazebo/set_model_state /rosout /rosout_agg **
I ran into a similar issue, and noticed that the plugins were being built as .a files as opposed to .so files. This is because an add_library
cmake command without specification can default to different things depending on the build. In particular if you use this docker image you get .a files but if you use this docker image then you get .so files.
(I am aware these are galactic
images, but the foxy branch seems to work fine in them)
I suggest explicitly adding to that add_library
command that we want shared libraries, since both images should work (both actually published by OSRF). Happy to make this change, but it'll probably be a tomorrow thing for me.