Calculate position using robot_localization

asked 2017-01-23 15:22:22 -0600

b-sriram
105 ●24 ●27 ●33

updated 2017-01-26 07:27:11 -0600

spmaniato

1788 ●40 ●56 ●69 http://www.spmaniato.me/

Hi,

I have a cart which has a base ( with four wheels) thats front wheel driven by two motors and fitted with encoder (one for each front wheel).

I calculate the distance traveled by counting the ticks and with the help of the heading angle. Hence the distance covered and angle are in Global coordinate frame.

I also calculate the instantaneous X velocity and angular rate which are in the kart co ordinate frame (forward and right is positive).

I also have an IMU razor_imu which gives me the orientation, linear velocity and linear acceleration in the Kart frame (I think??).

When I use the robot_localization package to calculate odom_comined using the following launch file robot_localization.png the orientation seems to be right but my position keeps on adding even when my cart is turned 180. The problem is the code is only accepting velocity values and not the position itself as input from odom message. So if the Cart turns 180, my instantaneously velocity is still positive.

Can someone please suggest a solution?

The measuremnt co variance of the imu is imu_covariance.png and for the encoders encoder_covariance.png

Thanks Sriram

edit retag flag offensive close merge delete

Comments

I see at least a few areas for improvement. I would start here: http://docs.ros.org/indigo/api/robot_...

spmaniato ( 2017-01-23 15:31:15 -0600 )edit

I already read that. That's why I've set the initial co variances as follows and other params

b-sriram ( 2017-01-23 15:34:48 -0600 )edit

And also take a look at this example: https://github.com/cra-ros-pkg/robot_...

spmaniato ( 2017-01-23 15:34:55 -0600 )edit

Hi thanks for the help. but I have not posted the question here without trying all possible solution.

b-sriram ( 2017-01-23 15:37:12 -0600 )edit

The documentation I linked to suggests that (in most cases) you shouldn't be fusing both (x, y) and (vx, vy) from odometry. Rather, you should only fuse the linear velocities instead of the position. I would personally do the same for the orientation and angular velocity from odom.

spmaniato ( 2017-01-23 15:45:04 -0600 )edit

I tried exactly the same but it didn't help. So I tried with only (x, y) but the node for some reasoon doen't accept it. So I included both.

b-sriram ( 2017-01-23 15:47:30 -0600 )edit

OK. The other thing that jumped at me from your question is: "IMU ... gives me the orientation, linear velocity and linear acceleration in the Kart frame" The IMU is most likely reporting data in its own frame. Whether that happens to coincide with your vehicle's frame is a matter of placement.

spmaniato ( 2017-01-23 15:54:11 -0600 )edit

Ya what I meant was that was not in the global frame. I have a transform which tells me where the imu is located from the base

b-sriram ( 2017-01-23 15:56:47 -0600 )edit

see more comments

answered 2017-01-26 02:53:06 -0600

Tom Moore

flag of United Kingdom of Great Britain and Northern Ireland

13689 ●74 ●240 ●232 http://github.com/ayrton04

Started out as a comment, but will add a few things:

Can you please post (a) your launch files and (b) some sample input messages (as text)?
You said your coordinate frame has forward and right as positive, which is incorrect. REP-103 specifies +X as forward and +Y as left.
Instantaneous velocity, if driving forward, will always be positive, no matter which way your robot is facing. This is correct. The filter converts velocities from the robot's body frame to the world frame internally. As far as the EKF output goes, the ROS nav_msgs/Odometry message specifies that the output pose data is in the world frame (header.frame_id in the message) and the velocities are in the body frame (child_frame_id in the message).
Looking at your configuration image, you are fusing both your calculated pose and velocity from your wheel encoders, but those both come from the same source. You're effectively feeding the filter the same information twice. It doesn't hurt it necessarily, but I'd give it one or the other.
You are fusing yaw from both your IMU and odometry. Those are going to diverge, so you'll have to turn one of them off.

Comments

Hi Tom,

Sorry for the late response. Firstly thanks a ton. My co-ordinate system was defined wrong. I corrected it as you said (+X as forward and +Y as left) and now it seems much better. I'm working on the co-variance matrices to get a better result.

b-sriram ( 2017-02-12 11:58:36 -0600 )edit

add a comment

Calculate position using robot_localization

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

Calculate position using robot_localization edit

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

Calculate position using robot_localization