0
$\begingroup$

I am trying to figure out why the ROS robot localization is giving me weird results from estimating motion for IMU only. It seems that when the robot is moving with constant velocity and a change in orientation is introduced, the body velocity is conserved s.t. the trajectory changes, even though there are no accelerations introduced, as if it does not allow for sideslip.

To verify results, I created a control condition where I can manually set the IMU values using dynamic reconfigure. Note that the EKF base_link_frame is set to base_link and I have manually set the static tf base_link to imu_link to zero translation and zero rotation, ensuring that a rotation does not induce accelerations.

When I initialize the robot with a constant non-zero velocity and zero angular rate, I make sure the accelerations are set to zero, and then manually change the rotational rate to a constant value, before setting it back to zero. The figure below shows the results:

Top down view of trajectory of robot during controlled imu input

As can be seen in the top-down image, it is initially traveling forwards (in the image being up) with constant velocity. When I set the rotational rate around the vertical axis (through the plane of the image) temporarily to non-zero, it changes direction, instead of rotating while keeping the same forward motion.

I tried posing the problem the other way around: When in constant forward motion, I apply a lateral acceleration, causing it to change trajectory to the side, however in this case, there is no change in rotation, as would be expected. When I furthermore apply an acceleration that is normal to the velocity vector, the robot moves in a circular motion, again all the while keeping it's initial forward orientation as expected.

This is the configuration:

imu0: ekf/imu/data
imu0_config: [false, false, false,
              false, false, false,
              false, false, false,
              true,  true,  true,
              true,  true,  true]
imu0_queue_size: 1
imu0_nodelay: false
imu0_differential: false
imu0_relative: false

I'm not sure how to fix this. Is there a way to modify the motion model of robot localization package? Or am I missing something?

Thanks

$\endgroup$
1
  • $\begingroup$ You seem to have two accounts: 1 and 2. You can merge the accounts, see this answer. It is rather irregular to gain reputation from suggesting edits to your own posts (as well as posting answers) from a different account... $\endgroup$ Sep 26, 2023 at 16:33

2 Answers 2

0
$\begingroup$

IMU-only configuration is not something I would recommend. It would be helpful if you could provide a sample sensor input message as well as a sample EKF output message after the robot has moved for some time, but without that information, I can only guess.

If you are just fusing linear acceleration and rotational velocity, then the double-integration of acceleration data into pose data is going to make your covariance explode. The correlation between linear and rotational variables in the state transition function will cause odd effects in that case.

EDIT: sorry, I think I understand what you are saying better. You are expecting the robot to continue in a straight line but rotate "in place" along that line, correct?

Assuming that is correct, the kinematic model that the EKF uses boils down to the unicycle model in 2D, so if you have some fixed linear velocity and introduce a rotational velocity, I would expect the robot to move along an arc. Apologies if this is not what your point was.

$\endgroup$
2
  • $\begingroup$ Yes that's what I meant indeed, the robot should be rotating in place along the line. I couldn't find a solution except to modify the source code in a custom UKF. Instead of have the velocity state being in the body frame, I keep track of the inertial velocity instead. Thank you! $\endgroup$
    – user36471
    Mar 12 at 20:48
  • $\begingroup$ You could also make sure your sensor data is updating the velocity to be reported in the world frame. So as the robot rotates, the velocity itself would change. $\endgroup$
    – automatom
    Mar 15 at 8:05
0
$\begingroup$

For anyone interested, I modified the transition matrix in python to use the inertial velocity instead of the body velocity (for the robot_localization package you would do the same in c++, and you would have to make more modifications to the inputting functions to accept inertial velocities instead).

enter image description here

$\endgroup$
1
  • $\begingroup$ Nice update. However, please paste any code or console output as code formatted text and not as a screenshot. Screenshots are not text searchable, amongst other things... it also makes it difficult to copy/paste. Thanks :-) $\endgroup$ Mar 12 at 21:09

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.