0
$\begingroup$

Rosanswers logo

I'm trying to get our robot up and running the navigation stack. As far as I have read and can tell, everything is "correct". In the navigation stack tuning guide it says that there are a couple odometry "sanity checks". Translational involves driving the robot towards a wall and making sure that the aggregate laser scans don't spread over a large distance (~.5 meter). That seems to be going just fine for me.

However, rotation seems to be a problem, I think? With rviz's frame set to "/odom" and spinning the robot in place the scans get to be a giant swirl. When the robot rotates all the way around and returning to where it started, the scans (without aggregate) look identical to what they were before. Meaning if I start facing a wall with the wall parallel to one of the grid lines, after turning all the way around, the wall is once again parallel to the grid line.

It seems like the purpose of the odometry, in rotational terms, is working if when you spin all the way around, your pose at the end is the same as when you started? So I think it's working correctly? Is that right?

I'm hoping that I'm missing something because I'd like to run the gmapping node (which I've tried and my setup isn't working). Hopefully it's something simple. Any help is greatly appreciated.


Originally posted by skiesel on ROS Answers with karma: 549 on 2012-10-24

Post score: 1

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

I am not quite sure I understood what the problem is.

You say translation looks good and also rotating 360 degrees leads to the same results. That sounds like the odom is working fine.

You also said something about a swirl when attaching rviz' frame to odom frame. This makes sense for me as well. Since normally rviz frame is fixed and not attached to a moving frame I would expect strange results, especially when scans are also shown at the same time (because they are displaying the effects of the rotation as well).

Try to set the rviz frame to a fixed /world or /map frame (depending on what exists in your case) and have another look at it while rotating. In case of neither already exist, you can setup a tf transformation rather easily using static_transform_publisher. Just publish a frame with zero coordinated that has your odom frame as child_frame.

When the gmapping is not working there can be a lot of different other things go wrong.

Please check and put up another question in case I am right.

Good luck! :)


Originally posted by JBuesch with karma: 237 on 2012-10-24

This answer was ACCEPTED on the original site

Post score: 0


Original comments

Comment by skiesel on 2012-10-25:
I'm not running gmapping, so the odom frame is stationary. When rviz's frame is set to odom, and I rotate the robot, the laser data does not "trace out" the room, but rather causes a visible swirling. When it returns to its rotational origin, the scans match up. This is correct? Thanks!

Comment by JBuesch on 2012-10-25:
Yes, as I said, when you attach the rviz frame to odom (which is a non stationary frame by definition) it is very likely for you to get strange results. It is like you sitting on the wheel of a car expecting to see everything straight while it rotates. Attach rviz to a fixed frame and try again.

Comment by skiesel on 2012-10-26:
I really appreciate your help! I'm publishing a static transform from map to odom (0,0,0,0,0,0,) with the rviz fixed frame set to map. (map->odom->base_link->base_laser) When I rotate the points still seem to follow the rotation, which I would think is wrong?images: cs.unh.edu/~skiesel/odometry.html

Comment by JBuesch on 2012-10-26:
Well, with your pictures (great idea) my first clou doesn't hold any longer, but I have great news for you. Why do you think this is not right? I mean, since your scanner is mounted on the robot, of course it is rotating as well and its 'vision' moves along too, showing different (cont'd)

Comment by JBuesch on 2012-10-26:
...parts of the suroundings. If you'd run something like a obstacle grid, the outlines of the room would materialize. From the pics I can see though that there is a slight discrepancy which comes from a non well calibrated odom (factor >1 needed). Try to calibrate and go on. It looks alright now! :)

Comment by JBuesch on 2012-10-26:
The vision shows an angle difference of approx 45 degrees, as you also confirmed, but when you look at the odom frame it has rotated less. Good luck and have fun!

Comment by skiesel on 2012-10-28:
Thanks so much. I'll take a look at the odom publishing and see if tweaking that fixes things. Again, I really appreciate your responses and your time!

Comment by skiesel on 2012-10-30:
You were right on. I'm using the p2os stack, its publishing of the odometry and robot pose needed their rotation inverted. After that, everything seems to work great! Thanks again so much for your help!

Comment by JBuesch on 2012-11-01:
Nice to hear that. Things can be confusing when getting started with ROS. But makes still great fun though.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.