pmukherj's profile - activity

Sweet! No worries, and honestly, how robot_localization handles wheel odometry is probably how it was always "classically" done. It may not be necessary to make a "real" differential option available. Just a note on migration from robot_pose_ekf maybe enough!

Hey!

I'm just testing out the robot_localization package with our robots. Loving the level of documentation :). However, I realized that it handles the data streams differently from robot_pose_ekf. For instance, robot_pose_ekf, expected wheel odometry to produce position data that it then applied differentially i.e. it took the position estimate at t_k-1 and t_k, transformed the difference to the odom frame, and applied it to the state estimate.

However as per the discussion about yaw velocities here, it seems robot_localization would rather just apply wheel velocities generated by the wheel odometry and generate a position information itself. I know robot_localization has a "differential" tag on each dataset but that seems to be removing initial static offsets (i.e. subtract the position estimate at t_0 , not t_k-1). I have two questions:

1. Are my assumptions above correct?
2. Am I losing anything by not doing the integration myself and relying on robot_localization to do the integration?

Hello! This maybe because the "real" husky is running in open loop mode while the simulated one is not. I can verify this but just so I understand the problem well. I am assuming the "real" husky has an IMU? So the 1080 degree you turn you saw in rviz is something you observed physically as well?

A skid steer vehicle like the Husky skids when its turning i.e. the wheel slips momentarily. Unfortunately, the encoders do no capture this slippage. This means the wheel odometry will typically report more rotational motion than is actually achieved. To compensate for this slippage we suggest that you combine this data with IMU data which is much better at estimating heading. This can be done with something like robot_pose_ekf which you have clearly done.

As for the accuracy of the robot_pose_ekf output, I'd love to hear about what specific accuracy and precision you are achieving. What kind of results are you seeing?

Just to clarify how fast is the GPS information coming in?

How have you modified the launch files? Has robot_pose_ekf started up (it should output a message saying so if it did). The output_frame parameter in the launch file should be set to what you need, which in your case is 'odom'?

You should use something like robot_pose_ekf (http://www.ros.org/wiki/robot_pose_ekf ). This outputs a tf between odom_combined and base_footprint. The example launch file shows you how to configure it so that the tf is between odom and base_footprint.

Hope this helps!

Yes. My guess is also Karma. I can comment on my own answer. Just not the original question!

Hello!

Could you just elaborate on what happens to the odometry when you turn the vehicle in simulation? Does the yaw angle not follow a frame convention you expect? Or does the position information not look right?

-PJ

PS: I fully realize this should really be a comment to the question and not an answer. Apologies. I don't seem to have the option (permission?) to write a comment :S. If anyone has a clue why, I'd love to hear it (maybe a bug fix?).