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

Arrows are in a wrong direction when showing odometry/filtered

asked 2018-10-25 15:37:43 -0500

harry jiang gravatar image

updated 2018-10-26 08:42:41 -0500

I am using the robot localization node to fuse IMU and GPS data. When I view odometry/filtered in RVIZ in the odom frame the arrows don't point to direction of movement,but perpendicular to.the movement. What's wrong with it? Besides, when EKF node gets data from GPS, the odometry/filtered jumps discretely. Anyone had this problem before? Seems like I'm missing something simple. Thanks in advance.

Launch file:

<launch>

  <rosparam command="load" file="$(find robot_localization)/params/sensor_fusion.yaml" />

  <node pkg="robot_localization" type="ekf_localization_node" name="ekf_se_map" clear_params="true">

  </node>

  <node pkg="robot_localization" type="navsat_transform_node" name="navsat_transform" clear_params="true">

  </node>

</launch>

yaml file:

ekf_se_map:
  frequency: 30
  sensor_timeout: 0.1
  two_d_mode: true
  transform_time_offset: 0.0
  transform_timeout: 0.0
  print_diagnostics: true
  debug: false
#debug_out_file: /home/jiang/catkin_ws/src/robot_localization/params/debug.txt

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

  odom0: odometry/gps
  odom0_config: [true, true, false,
                 false, false, false,
                 false, false, false,
                 false, false, false,
                 false, false, false]
  odom0_queue_size: 10
  odom0_nodelay: false
  odom0_differential: false
  odom0_relative: false

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

  use_control: false

  process_noise_covariance: [1.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,    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: [1.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,    1e-9, 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 ...
(more)
edit retag flag offensive close merge delete

Comments

I don't see a screenshot; maybe it didn't attach correctly. And can we see your EKF, IMU, and GPS configurations?

In my exerience, depending on which IMU and GPS you have, they don't necessarily produce output in the same coordinate frame. And are you using a navsat_transform_node?

mogumbo gravatar image mogumbo  ( 2018-10-25 16:11:09 -0500 )edit

Sounds like you haven't set it up properly - if you add more information (screenshots, your r_l config file, and example messages from your IMU & GPS) that would help with debugging.

stevejp gravatar image stevejp  ( 2018-10-25 18:56:33 -0500 )edit

@harry jiang: you didn't have enough karma to attach images. I've fixed that for you. You should now be able to attach your screenshot.

Don't use image hosting websites for this. It is not needed.

gvdhoorn gravatar image gvdhoorn  ( 2018-10-26 04:56:13 -0500 )edit

@mogumbo: I add the screenshoot now. I use mpu6050 and neo-7m and by rosserial to publish the IMU and GPS topics. I run one kf_localization_node and one navsat_transform_node to fuse IMU and GPS. I set all frame_id of GPS and IMU to "base_link" when I don't need to tf.

harry jiang gravatar image harry jiang  ( 2018-10-26 05:33:49 -0500 )edit

@gvdhoorn: Thanks, and I also want to add my yaml file but I don't know how to do that...

harry jiang gravatar image harry jiang  ( 2018-10-26 05:35:31 -0500 )edit

Thanks, and I also want to add my yaml file but I don't know how to do that...

just copy-paste the contents it into your question. There is no need to attach it, as it is just text.

After you've pasted, make sure to select all the text and press the Preformatted Text button though. It's the ..

gvdhoorn gravatar image gvdhoorn  ( 2018-10-26 05:44:13 -0500 )edit

.. the one with 101010 on it.

That will make sure the yaml renders correctly.

Alternatively, you could press ctrl+k after selecting the text.

gvdhoorn gravatar image gvdhoorn  ( 2018-10-26 05:45:01 -0500 )edit

@gvdhoorn: thanks a lot!!!

harry jiang gravatar image harry jiang  ( 2018-10-26 06:04:31 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted
0

answered 2020-01-27 10:46:41 -0500

For what its worth: Once I got my ydlidar x4 working with hector_mapping, I noticed the ODOM pose was facing backward! It turns out that I had mounted my YDLIDAR x4 backward, so everything was working as designed! To resolve I was able to use the ydlidar calibration tool mentioned in the ydlidar x4 user manual to calibrate the lidar 180 deg from normal. The instructions for adjusting the angle are at the bottom of the doc. Do note that the the default password in the user manual did not work for me, I found online that eaibot is the correct password. I did this calibration on windows. There may be a better way, via a transform manipulation, but I'm new to ROS and haven't yet figurted that out.

edit flag offensive delete link more
0

answered 2018-10-26 08:33:34 -0500

stevejp gravatar image

When I view odometry/filtered in RVIZ in the odom frame the arrows don't point to direction of movement,but perpendicular to.the movement.

This is pretty much guaranteed to be because of how your imu is reporting orientations. You should verify the following:

  1. You have your imu reporting measurements in the base_link frame - can you verify that the sensor/body frame of the imu actually does line up with your base_link frame?
  2. Can you verify whether your imu is reporting orientations in an ENU or NED global frame?

Also, did you intentionally set the yaw_offset param in the navsat_transform config to be 1.57?

As we can see, there is some purple area. What's wrong with it?

That is a covariance ellipse, you can turn it off in the drop down for the odometry object in the rviz display tree.

Besides, when EKF node gets data from GPS, the odometry/filtered jumps discretely.

This is expected behavior based on the information you're fusing and how r_l works.

edit flag offensive delete link more

Comments

Thanks for your answer. Because I don't have a robot yet, I just connet the IMU and GPS to my computer, so I set all frame_id "base_link" , is that right? And I use the imu_filter_madgwick package to produce orientaton of IMU and the parameter what I set in this package is "ENU".

harry jiang gravatar image harry jiang  ( 2018-10-26 09:07:09 -0500 )edit

so the yaw _offset is 1.57 when IMU is "ENU"? And I also want to know, why are so many arrows produced when the device doesn't move or just moves several steps? It seems very unstable and drift...

harry jiang gravatar image harry jiang  ( 2018-10-26 09:10:51 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2018-10-25 13:50:46 -0500

Seen: 791 times

Last updated: Oct 26 '18