Well, I try to get the x and y value using the GetPositionY() and GetPositionX() methods. The issue is that I cannot get any valid value yet.

The process is that I do the NavigationBegin() first, then call one of the three methods: SimpleGyroNavigation(), SimpleNavigation(), NavigationXY() before the GetPositionY() function. However, the problems arise. The SimpleGyroNavigation() will not update the X/Y value, the SimpleNavigation() keeps incrementing the y value even when the ringo is just sitting there, and the value get from NavigationXY() is just like arbitrary, will increase or decrease in either direction. (I just check the Y values for most cases, but assume that it should show similar performance on x)

Any comments on how to select and understand these methods or how to get the correct y position?

I've always been a bit confused about the low level details of the navigation functions. They were written by a friend a while back. I'm hoping to be able to go over them in detail soon as we'll be using the same code on the new Spirit rover.

If you can send me some actual code examples I'll try to have a look. This is good feedback to see how people are actually using the navigation. The basic driving navigation works pretty well but the functions to query specifics like you're trying to do - I haven't fully tested those myself.

Contact me via the Contact form on the plumgeek website so we can email back and forth and share code. If you did figure it out on your own, please share any details. I'm sure they'll be helpful for everyone.

I kind of figure out the problem. Looks like the accelerometer is very sensitive, if ringo is a little bit of tilt when moving, the reading of accelerometer will drastically increase and the GetPosition functions will fail.

I try to resolve this problem from programming side, like cut off the enormous reading but still not sure how to really avoid it.

I wanted to add a few more notes on this... this is a paste of a response I just sent to a user via email that discusses this. You are correct that slight tilt differences will be seen as movement because the accelerometer is picking up the acceleration of gravity which of course is a constant 1G straight down. When the angle changes, so does the direction of gravity's pull which is then interpreted as movement. I hope to re-visit the use of these functions as we're using the same code on Spirit now and I know with a few minor tweaks to how the nav functions work, this can be made much more user friendly.

Anyway, here's the email - hopefully it's helpful to some of you in the short term.

==========

I'd also like to re-visit how the navigation functions work. They were written by a friend of mine a few years ago and they are generally over my head as I'm more of a hardware guy. Seeing how he actually uses them will give me good feedback to improve them.

A quick note is that the acceleration of gravity pulling downward is much greater than the movements around the table, so if the robot is tilted forward or backward, the accelerometer will see the direction of gravity change some and will see this as movement.

To help sort this out, you can use the functions PauseNavigation() and ResumeNavigation(), and only have the navigation running during the movements (and a short duration after the movement to give the robot a chance to skid to a stop and settle).

I believe you can also call CalibrateNavigationSensors() when the robot is at a dead stop, no vibration on the table, and it will measure at that specific angle the present direction of gravity and will cancel it out of future readings. I think this works fine as long as the front/back tilt angle of the robot doesn't change, which normally it won't change as it should usually come to rest at the same angle each time.