0
$\begingroup$

Rosanswers logo

Hey folks,

I've got a Husky in a Gazebo world that's been generated from an existing floor plan. The floor plan is also published using map_server. For my purposes right now, it's fine if the robot is perfectly localized in Gazebo and I was planning on using /gazebo/model_states to set the required transformations of the robot so that the map in RVIZ stays fixed and doesn't slide when the robot runs up against walls.

I'm still figuring out ROS, so I'm not sure what exactly would be needed for that. In RVIZ the map visualization tells me there's an error saying that "No transform from [map] to [odom]" but to be honest I'm not sure what this transformation would entail for the Husky.

I really appreciate any help with this. Thanks!


Originally posted by alexsb92 on ROS Answers with karma: 23 on 2016-10-25

Post score: 2

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

The libgazebo_ros_p3d plugin as used here provides ground truth pose information as a nav_msgs/Odometry message. That topic could be fed into message_to_tf or a robot_localization node to generate the appropriate tf data.

Another related approach is using the ground truth information as odometry and then just adding a static publisher that publishes a additional identity map->odom transform. This is for instance done here: spawn_tracker_with_ground_truth.launch, publish_ground_truth_state.launch


Originally posted by Stefan Kohlbrecher with karma: 24361 on 2016-10-26

This answer was ACCEPTED on the original site

Post score: 6


Original comments

Comment by paulbovbel on 2016-10-27:
+1, ros_p3d and message_to_tf works great

Comment by alexsb92 on 2016-11-02:
Thanks! I tried the second method first. It's actually similar to something that I had tried. The problem that still exists with that method is that if the robot runs into a wall, while it doesn't move in Gazebo it goes through the wall in RVIZ. Is that related to odom being the fixed frame in rviz?

Comment by alexsb92 on 2016-11-02:
I will also attempt the first method. Maybe that will solve the issue i still have, although it would be fantastic if you could shed some light on why the running in the wall problem still exists. Thanks!

Comment by paulbovbel on 2016-11-03:
It really depends on your configuration. In the 'odom' frame of reference, then normally driving 'through the wall' in rviz would be expected, since the wheels would slim and the /odom frame is calculated primarily from wheel odometry.

Comment by paulbovbel on 2016-11-03:
If you unhook the wheel odometry from husky's robot_localization instance, and feed in the 'perfect odometry' from gazebo instead, then driving through the wall would not be expected.

Comment by bc12345 on 2019-07-22:
Hi do you mind please explaining when you say "Another related approach is using the ground truth information as odometry and then just adding a static publisher that publishes a additional identity map->odom transform," do we have to manually determine what the static transformation is from map->odom to be able to visualize the robot's true path in Rviz? e.g. guess the translational and rotational offset? Thanks

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.