ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

My robot rotates in rviz slower than in Gazebo

asked 2020-10-13 07:48:51 -0600

asdfg123 gravatar image

updated 2020-10-17 03:02:12 -0600

I'm using Ros kinetic, ubuntu 16.04, gazebo 7.16

I want to do navigation. Yet, first of all, I needed to manage tf_tree and rviz. I made tf_tree (odom->base_footprint-->base_link) by using 'ekf_localization' and 'robot_state_publisher' as a transformation respectively. However, When I use ground_truth_to_tf instead of ekf_localization, the problem is solved automatically. Therefore, I think there is a problem about ekf_localization. When I command my robot to move forward or back, there are no problems. But when I order to turn right or left. Gazebo turns more than rviz.

If you need, here is ekf_localization.yaml: For parameter descriptions, please refer to the template parameter files for each node.

ekf_se_odom: frequency: 50 sensor_timeout: 0.1 two_d_mode: false transform_time_offset: 0.0 transform_timeout: 0.0 print_diagnostics: false debug: false

map_frame: map odom_frame: odom base_link_frame: base_link world_frame: odom

odom0: jaguar_velocity_controller/odom odom0_config: [false, false, false, false, false, false, true, true, true, false, false, false, false, false, false] odom0_queue_size: 10 odom0_nodelay: true odom0_differential: false odom0_relative: false

odom2: zed/odom odom2_config: [true, true, false, false, false, false, false, false, false, false, false, false, false, false, false] odom2_queue_size: 10 odom2_nodelay: true odom2_differential: false odom2_relative: false

imu0: imu/data imu0_config: [false, false, false, true, true, true, false, false, false, true, true, true, true, true, true] imu0_queue_size: 10 imu0_nodelay: true imu0_differential: false imu0_relative: false imu0_remove_gravitational_acceleration: true

# use_control: false

# process_noise_covariance: [1e-3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, # 0, 1e-3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, # 0, 0, 1e-3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, # 0, 0, 0, 0.3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, # 0, 0, 0, 0, 0.3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, # 0, 0, 0, 0, 0, 0.01, 0, 0, 0, 0, 0, 0, 0, 0, 0, # 0, 0, 0, 0, 0, 0, 0.5, 0, 0, 0, 0, 0, 0, 0, 0, # 0, 0, 0, 0, 0, 0, 0, 0.5, 0, 0, 0, 0, 0, 0, 0, # 0, 0, 0, 0, 0, 0, 0, 0, 0.1, 0, 0, 0, 0, 0, 0, # 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.3, 0, 0, 0, 0, 0, # 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.3, 0, 0, 0, 0, # 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.3, 0, 0, 0, # 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.3, 0, 0, # 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.3, 0, # 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.3]

# initial_estimate_covariance: [1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, # 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, # 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0 ... (more)

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
3

answered 2020-10-17 07:23:29 -0600

duck-development gravatar image

this is often the problem of real robots.

gazebo is the real robot

rviz show you the internal state of the robot, what does the robot think it is.

what kind of kinematik do you use. diff drive mecanum or just simulation the robots motors?

check if you weel diamters are the same in gazebo and ros that you wheel distance is the same on both systems.

every filter is in some case a low pass filter so you often get less then real.

edit flag offensive delete link more

Comments

gazebo is the real robot

Yes. I cannot upvote this enough.

People should really consider Gazebo just another robot and not some special program which is integrated into ROS.

All too often I've seen nodes make assumptions about "talking to Gazebo", and then having two versions of nodes: one for Gazebo and the other for "the real robot".

Do not do this.

gvdhoorn gravatar image gvdhoorn  ( 2020-10-17 07:25:30 -0600 )edit
1

I typically add a ground truth retrieved from gazebo to get some reference of how well the localization is working.

Is discussed here: https://answers.ros.org/question/246440/husky-perfect-localization-gazebo-positioning-system/?comment=247207?comment=247207#post-id-247207

bob-ROS gravatar image bob-ROS  ( 2020-10-17 14:10:35 -0600 )edit

First of all, thank you for the answers. @duck-development: I'm using diff_drive and when I checked the wheel separation it really helps. Yet still not quite proper since the laser(obstacles) shaking too much. I believe it is because I use "ekf_localization" as a broadcaster instead of "ground_truth_to_tf". Is there any way of solving this problem without using "ground_truth_to_tf"?

@bob-ROS: I tried "ground_truth_to_tf" and it was perfect. However, I could not find a way of closing ekf_localization that broadcast from odom to base_footprint( only if I kill, it closes but as I know it will help navigation later. So I cannot kill it.) Do you know any way closing ekf_localization broadcaster without killing it?If I manage to do that, I will use ground_truth_to_tf.

Thanks for your patience.

asdfg123 gravatar image asdfg123  ( 2020-10-18 03:34:39 -0600 )edit

Question Tools

1 follower

Stats

Asked: 2020-10-13 07:48:51 -0600

Seen: 429 times

Last updated: Oct 17 '20