Robotics StackExchange | Archived questions

robot-localization ekf-se configuration. /odometry/filtered reflect wrong direction when robot is reversed

Hello,

I am using the following configuration for robot-localization ekf filtering, outlined below. It does work, to my purposes. When I command the robot go in reverse with the joystick, the ekf_se filter fails to identify the motion change, continuing in forward motion and reflecting those on /odometry/filtered. Is this a bug, or design feature? Is it designed to calculate ekf odometry only when robot is in forward motion? Or have I done a misconfiguration in the ekf configuration?

Best Regards, C.

frequency: 20
sensortimeout: 0.1
twod_mode: true

transformtimeoffset: 0.0
transformtimeout: 0.0
printdiagnostics: true
debug: false
debugoutfile: /tmp/ekf_debug.txt

publishtf: true
publishacceleration: false

mapframe: map
odomframe: odom
baselinkframe: basefootprint
worldframe: odom

odom0: odom

odom0_config: [false, false, false, false, false, false, true, true, false, false, false, true, false, false, false]

odom0queuesize: 2
odom0nodelay: false
odom0differential: false
odom0_relative: false

odom0poserejectionthreshold: 5
odom0twistrejectionthreshold: 4

usecontrol: true
stampedcontrol: false
controltimeout: 0.1
controlconfig: [true, false, false, false, false, true]

imu0: imu/data

imu0_config: [false, false, false, true, true, true, false, false, false, false, false, true, true, false, false]

imu0nodelay: false
imu0differential: false
imu0relative: true
imu0queuesize: 5
imu0poserejectionthreshold: 0.8
imu0twistrejectionthreshold: 0.8
imu0linearaccelerationrejection_threshold: 0.8

imu0removegravitational_acceleration: true

accelerationlimits: [1.3, 0.0, 0.0, 0.0, 0.0, 3.4]
decelerationlimits: [1.3, 0.0, 0.0, 0.0, 0.0, 4.5]

accelerationgains: [0.8, 0.0, 0.0, 0.0, 0.0, 0.9]
decelerationgains: [1.0, 0.0, 0.0, 0.0, 0.0, 1.0]

Asked by wintermute on 2022-02-21 07:16:13 UTC

Comments

The IMU data / IMU configuration is one of the major culprits in these cases. So, check if the IMU data follows REP-105. One thing that I noticed is for odom0 topic - is it under any namespace? if it is in the root namespace then could you try odom0: /odom ?

Asked by VineetPandey on 2022-02-22 15:51:45 UTC

I am getting imu data from gazebo, so I am in simulation. How can I indeed verify that the IMU data is ENU? I know ekf_se will not work correctly if the imu data is not in ENU, but I could not verify.

Asked by wintermute on 2022-02-23 03:49:35 UTC

A hacky method (If you have an IMU) would be to tilt each axis in the direction of gravity to check the sign of the data generated. In Gazebo the best that I can think is to check the TF of the IMU frame in RVIZ

Asked by VineetPandey on 2022-02-23 12:56:46 UTC

suppose i am able to turn the robot to different axes in simulation, and read the orientation data. then how can we verify it is indeed ENU?

Asked by wintermute on 2022-02-24 02:42:03 UTC

When you tilt the robot w.r.t the ground, one of the axes would report the acceleration due to gravity (including the sign). Try this for all the axes to check for the signs and compare it against NED or ENU representations to verify.

Asked by VineetPandey on 2022-02-25 16:56:41 UTC

Answers