Abhy,<br><br><div class="gmail_quote">On Mon, Jan 24, 2011 at 10:04 AM, abhy <span dir="ltr"><<a href="mailto:abhy.12354@gmail.com">abhy.12354@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Thanks for the clarification. So, going forward is it helping AMCL to<br>
localize robot in the world?<br></blockquote><div><br></div><div>Yes, odometry helps AMCL to localize the robot in the world and, if you don't have very good odometry, AMCL will likely give you bad pose estimates.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
I am asking this because, after building a map we tried to set a destination<br>
for the robot. We could see global plan is properly set but robot is not<br>
following a local plan.<br>
For e.g.: If robot physically pointing towards say north side (sensor north<br>
side)  but in rviz it is not showing properly oriented and not even at the<br>
same location in the map where it is physically located. so, position and<br>
orientation both are differing to the real robot and while moving it is<br>
giving jerks and drops the plan since local planner is getting failed. It<br>
seems it is some localization related stuff which is not allowing robot to<br>
get localize properly into the map inspite of giving initial x,y, theta<br>
values in amcl parameters. so, we thought it can be related to /odom.<br>
<br>
Is there any settings we have to follow other than this to get localize<br>
robot in to the world and move as per the plan?<br></blockquote><div><br></div><div>Before you work on tweaking the navigation stack, you'll want to make sure that both your odometry and AMCL-localization are working well. The first thing to check is odometry. There are a number of tests you can perform to see how well your odometry is working:</div>
<div><br></div><div>Test 1: Open up rviz and make sure that you're subscribed to the laser scan topic for your robot. Next, set the decay time to something like 30 seconds. Perform an in-place rotation with the robot and look at the laser scans. If odometry is fairly accurate, you should see scans from the previous rotation overlap with those generated on the current rotation. You'll want to do this in an area where you have distinctive features in your laser scan.</div>
<div><br></div><div>Test 2: Set up rviz the same way as the previous test. Point the robot at a wall and drive it towards it. With good odometry, the wall should stay in about the same place as the robot moves towards it. If you see a lot of movement in the positions of the scans relative to the wall that means odometry is poor.</div>
<div><br></div><div>Test 3: Drive the robot straight down a hallway. The laser scans of the hallway should stay straight. If you see them move a lot, it means your odometry is poor.</div><div><br></div><div>Once you've performed these tests, you should have a pretty good idea of whether or not your odometry is to blame for the poor localization of the robot. Then, we can move on to AMCL and tuning the navigation stack..</div>
<div><br></div><div>Hope this helps,</div><div><br></div><div>Eitan</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
-Abhy<br>
<font color="#888888">--<br>
View this message in context: <a href="http://ros-users.122217.n3.nabble.com/Odom-in-rviz-tp2320561p2321499.html" target="_blank">http://ros-users.122217.n3.nabble.com/Odom-in-rviz-tp2320561p2321499.html</a><br>
</font><div><div></div><div class="h5">Sent from the ROS-Users mailing list archive at Nabble.com.<br>
_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
</div></div></blockquote></div><br>