# skid_steer_drive_controller and diff_drive_controller odom frame

How are they different in terms of enabling the odom tf? because I was using ski steer and everything was fine with my frames but I started using diff_drive_controller and now my costmap is moving with my robot (using movebase). After a bit of debugging I noticed that the only thing that is changing is the odom frame which is controlled by the controller. I can post my config for movebase but the problem is not movebase as my robot works completely fine when I use skid_steer but everything starts acting strangely as soon as I change to diff_drive_controller and the only difference between them is the odom frame.

edit retag close merge delete

@DevWhoDat, first of all, what is your type of robot? Theskid_steer_drive_controller kinematics equations are not the same as the diff_drive_controller ones since the robots (mechanically) are not the same. If I remember correctly you can change the odom target frame name to adjust to your platform in the controller params.

( 2020-08-05 04:59:51 -0500 )edit

@Weasfas I found out that the odom topic was actually the issue at hand I had to get the ground truth pose information using a script I wrote publish it to a topic and then I subscribed to that odom topic and broadcasted my own frame based on the raw info and now everything is alright and back to normal. I triple checked my odom target frame and parameters so the issue is not from there. I guess I'll post an answer to my own question explaining how I fixed it but I still don't know why the problem was there to begin with, is diff_drive_controller suppose to have a different odom topic than skid steer drive? and if so WHY?

( 2020-08-05 10:07:46 -0500 )edit
1

@DevWhoDat, controller odometry is not the same as ground truth odometry. It is very simple to understand that both controllers outputs diffirent odometries because they are based on different kinematics equations. Another different thing is the output tf_tree from each of the controllers; since they are implemented in different ways it is understandable that produce different frames connections.

( 2020-08-06 07:46:17 -0500 )edit

I don't really understand what you mean by output tf_tree from each of the controllers, because when I check my tftree of my robot the connections are the same as before, is there a way to check the tf tree of the controllers alone?

( 2020-08-06 10:50:42 -0500 )edit

What the controllers are doing, if enable, is publishing not only the odom topic from the controller calculations but also the tf between base frame and odom frame. I think that is the point in which both controllers may differ so maybe you did not set up the odom frame param properly and thats why it differs.

( 2020-08-06 13:21:19 -0500 )edit

But that is the exact problem, the odom topic they were publishing were wrong, if you bring up those topics in rviz and look at the tf you will see the diff_drive_controller's topic moves with respect to the cmd/vel what I'm trying to say is that for example if you try to go left and just hold that for a couple of seconds, in reality your robot or at least my robot (depending on how you configure it) is slowly trying to move to left no matter how many times I press left but the odom in rviz just does a 360 degree turn when in reality the actual position of the robot changed by maybe 30 degrees, so however they are publishing the odom they are not calculating the actual position of the robot based on where the robot is, they are calculating it based on ...(more)

( 2020-08-06 14:31:54 -0500 )edit

" they are not calculating the actual position of the robot based on where the robot is, they are calculating it based on the robot's movement", that is exactly what the controller odometry should to do. As I already said, the ground truth (that is what I think you want) is not the same as the controller odometry. The controller odometry is calculated from the kinematics equations of the platform in real time as an accumulation of the robot movements and is a kind of expected value about how the robot thinks it moved. If you really want a good odometry you will need to use a efk or ukf to filter several odometry sources and get one with high accuracy. But you cannot expect having a good odometry just from the controller, since it always accumulates errors, you may want to use sensors like, gps, imu, lidar to localize ...(more)

( 2020-08-07 05:34:51 -0500 )edit

Interesting, thanks for this as I honestly had no idea how this odometry worked but my robot works fine now and I'm guessing skid steer controller's odometry just publishes the ground truth because the odom that I get from the ground truth is literally the same thing as the skid steer's controller odom. So I guess my question here is do I need the controller's odom for anything? should I not do what I do right now (replace controller odom with ground truth odom) and instead use the controller odom and then use something like amcl or efk to actually fix that?

( 2020-08-07 09:23:38 -0500 )edit