Robot localization Ignoring IMU

edit

Thanks a lot for the response! Ill test tommorrow early in the morning and update the post.

I have already test it without luck no different appreciated,

here i am sharing what the robot localization debug returns for the imu (while wheels encoders are posting 0) https://justpaste.it/7vwyf

also here is my tf in case it is something wrong wih it

transforms.push_back(tf::StampedTransform(
     tf::Transform(tf::Quaternion(0, 0, 1, 0), tf::Vector3(0.15, 0.0, 0.15)),
    ros::Time::now(),"base_link", "laser"));
transforms.push_back( tf::StampedTransform(
    tf::Transform(tf::Quaternion(0, 0, 1, 0), tf::Vector3(0.0, 0.0, 0.0)),
    ros::Time::now(),"base_link", "imu_link"));

the imu messages and the odometry (encoders) look fine, they are in the odom and imu_link frames

Just a tip, do rosrun tf view_frames to get a graphical output of the frames. I have found many problems using this tool that I would not have otherwise. I will try to read that debug output when I have a chance today.

It doesnt let me upload the view_frame to ros anwers, but maybe my issue is with the tf, the odom_raw is an odometry message with child_frame_id "odom_raw" and frame_id "base_link", is that set up correct? since there is no parent_frame_id thats the only solution i managed to make the odom_raw (odometry from encoders) child of the base link

In order to conform with REP 105 and the best practice of the robot_localization package your odom_raw odometry message should have the frame_id=odom and child_frame_id=base_link.

More generally, the only "discretionary" frames you should have, considering that we are not super users, are the frames below base_link. Above base_link it should always be map->odom->base_link. If you are ever tempted to change this idea, by adding "odom_raw" as a frame or something else like that, you should second guess yourself.

But right now I have 2 odometry sources and the odometry filtered result from the package, all odometry sources should be in the same Odom frame?

For this case yes. Your robot only has one odom frame no matter what happens, the same way it has only one base_link or map frame.

Also, your world_frame should be odom if you are only fusing imu and encoder data :)

Sorry, I did update the code to use odom as world frame, I have tested using the same ID and child frame id but roswtf was complaining about multiple nodes publishing the same tf, should I only publish the Odom frame once? If so, with which positions data? The one returned by the filter?

Its ok, the only node publishing the odom->base_link frame should be the robot_localization node. That is really the point of the node, to publish the frame. It is not good practice to have multiple nodes publishing the same node for the general case.

Thanks! that did it, my issue was with tf i was publishing each odometry in a different frame

@nalistic I am happy to hear you found it! To make sure people can debug their own issues and take advantage of your experience you can post and accept an answer to your own question here explaining the original problem, the process you went through, and how exactly you solved it.

Thanks JackB for the help! my issue was with how my robots TF was set up. The issue had nothing to do with the IMU itself, but when fusing visual and encoders odometry, I had set up each odometry source in different frames, instead of having only once odometry frame with multiple topics.

I cant see any accept button as in other xxx.answers forumns not even to my or your answer

It is the little checkmark directly below the upvote or downvote button :)

I have one last question and mayb you could help me, I am using the rf2o package to publish the Laser data to the Odom frame as you explained me before, my issue is that the laser itself is offsetted 15cm and rotated 180 degrees but i have no way to indicate that the LaserOdommetry should be offsetted 15 cm and 180 degrees from the Odom, i am not sure if i am being clear enough