Localization of A Omni-Directional Robot

[Ether]

Originally Posted by cad321

What about 2 omni wheels placed perpendicular to each other that drag along the floor. As the one in the y axis moves, it gives you your position in the y axis

That's true only if there is no vehicle rotation. If there is going to be vehicle rotation, you need either a) a gyro, or b) a third follower wheel... and you'll need to integrate (vector sum) the vehicle movements.

You might find this post of interest (and also the rest of the post in that thread).

[cad321]

Originally Posted by Ether

That's true only if there is no vehicle rotation. If there is going to be vehicle rotation, you need either a) a gyro, or b) a third follower wheel... and you'll need to integrate (vector sum) the vehicle movements.

You might find this post of interest (and also the rest of the post in that thread).

I corrected my post to include the gyro. I was thinking of it in my head but forgot to add it in. The third follower wheel for rotation is a good idea as well.

[vrcprogrammer]

This all looks great, how would you recommend using a gyro with the three follower wheels.
Thanks

[AlexanderTheOK]

Originally Posted by vrcprogrammer

This all looks great, how would you recommend using a gyro with the three follower wheels.
Thanks

Well first of all, what is your issue with simply putting encoders on all four of your wheels? If you are going for the X/killough/omni/whateveryouwishtocalllit drive you already have TWO sets of "mouse wheels". Theyre your drive wheels! Even without the gyro you can get rotational odometry. (I have tried this when we were prototyping swerve code on a vex base and it wasn't all too terrible. A gyro is still better, but odometry can determine your angle)

Ether's papers on controlling an omnidirectional drive apply in the reverse direction in order to find your movement based on encoders.

[cad321]

Originally Posted by AlexanderTheOK

Well first of all, what is your issue with simply putting encoders on all four of your wheels?

The biggest issue with this method is wheel slippage. Say I accelerate to quickly, or I get into a pushing match and my wheels start to spin because they lost traction. All of a sudden my robot thinks it's 5 feet further forward than it actually is. By getting feedback from unpowered wheels or a laser, you know that whatever movement you detect should in theory be the exact actual movement of your robot.

[vrcprogrammer]

Originally Posted by "cad321"

The biggest issue with this method is wheel slippage. Say I accelerate to quickly, or I get into a pushing match and my wheels start to spin because they lost traction. All of a sudden my robot thinks it's 5 feet further forward than it actually is. By getting feedback from unpowered wheels or a laser, you know that whatever movement you detect should in theory be the exact actual movement of your robot.

This is the exact reason I am trying to use the follower wheels, but I would like a way to use the gyro/ultrasonics, to check the data, is this needed, or are the followers accurate enough?

[Ether]

Originally Posted by vrcprogrammer

This is the exact reason I am trying to use the follower wheels, but I would like a way to use the gyro/ultrasonics, to check the data, is this needed, or are the followers accurate enough?

If you have only two followers, you will need a way (such as a gyro) to get rotation.

If you have three followers in the correct configuation, you can get rotation from the follower encoders. If you want, you can compare that to a gyro reading to see how well they agree.

My guess is that a properly installed, calibrated, and initialized gyro will give better accuracy in most cases.

[slibert]

Originally Posted by vrcprogrammer

This is the exact reason I am trying to use the follower wheels, but I would like a way to use the gyro/ultrasonics, to check the data, is this needed, or are the followers accurate enough?

As far as an accurate gyro, the navX MXP plugs into the RoboRIO MXP port, features automatic gyro/accelerometer calibration and sensor fusion, and has a yaw drift of about 1 degree per minute when moving (.2 degrees/minute when still) - which exceeds the quality typically achievable w/the gyro in the Kit of Parts. The navX MXP is being used by many teams for accurate field oriented drive and many are able to get it working in a few hours including installation. The navX MXP interfaces to the RoboRio via several protocols including SPI, and has RoboRio libraries in C++, Java and LabView, as well as sample program code, a 3d-printable enclosure and it's open source hardware/software. Please feel free to send me a private message if you have any questions about that.

I think it'd be helpful and educational for many FIRST teams if there were to be a documented project (w/hardware diagram, sample code and statistical results) which details accuracy findings w/the localization approach using encoders and follower wheel you're looking into. If you're interested in taking on that scope of a project, I'd be happy to give you a navX MXP board for free that you can use for this work.

I realize this may not work because you're asking about VEX, but if it sounds interesting to you let me know, and I can try to help w/some advice on getting it to work on a Vex robot.

P.S. I was speaking this year with a mentor on the "Thunder Down Under" (team 3132 from Australia, they made it to Einstein this year), and they were using a similar approach (encoders for X/Y displacement, navX MXP for rotation); I don't have any statistics on how well that worked, but I know it's been attempted and believe it appears promising. Of course, it all comes down to your accuracy requirements, as Ether said earlier....

[teslalab2]

mount an accelerometer and take the second anti-derivative of the data and that will give you the position in the x and y axis off of origin.

[Ether]

Originally Posted by teslalab2

mount an accelerometer and take the second anti-derivative of the data and that will give you the position in the x and y axis off of origin.

You need to be careful with posts like that.

Someone might take it seriously.

[teslalab2]

https://www.khanacademy.org/math/int...e-acceleration

thats how gyro's calculate the the position from rate, although that might get a bit tricky(er) taking the second riemann sum , would have to come up with way to find the constant definitively.

[Aren Siekmeier]

Originally Posted by teslalab2

https://www.khanacademy.org/math/int...e-acceleration

thats how gyro's calculate the the position from rate, although that might get a bit tricky(er) taking the second riemann sum , would have to come up with way to find the constant definitively.

While the theory is sound, this is impractical with an accelerometer. Even the integration of gyroscope signals accumulates error over time due to the limitations of the noisy signal and the discrete Riemann sum. Accelerometers are even noisier, from any vibrations, and also easily saturated. You also have to deal with errors in orientation, so computing just velocity, let alone position, from an accelerometer signal is not that easy.

[teslalab2]

dang thats a shame, I was hoping we could use that for autonomous

[GeeTwo]

Originally Posted by teslalab2

dang thats a shame, I was hoping we could use that for autonomous

For 15 seconds, you can possibly get away with it, depending on how precisely you need to hit your mark (1/4" or 6") to succeed. It would probably be better than "50% power for 3 seconds" but nowhere near as good as encoders on the wheels.

[slibert]

Originally Posted by teslalab2

dang thats a shame, I was hoping we could use that for autonomous

Here's a really great youtube video that provides some good insights into the issues that occur when attempting to derive displacement (position change) from acceleration (this discussion is at 22:32 into the video). It's telling to note that at one point in the video (at 26:30) when discussing double integration, the speaker says "... double integrate and pray".

[As an aside, I think this video is really instructive in general about MEMS inertial sensors/magnetometers and sensor fusion like that used in navX MXP. If you're interested in this kind of thing, I think it's worth watching the entire video.]

As discussed in the video, the errors are not only due to accelerometer noise, but also because gravity must be removed from the acceleration data, and there can be errors in this process too.

This still leaves this question: how accurate is it?

The latest firmware of the navX MXP implements the algorithms described in this paper: "Implementing Positioning Algorithms Using Accelerometers", and was used to run some tests. Note that this paper also discusses that this approach is not expected to be high accuracy.

We're still reviewing all the data, but with the navX MXP we see times when the displacement calculated is accurate to a centimeter, but at other moments in time the displacement calculation is not at all accurate (in fact in certain cases instead of indicating forward motion, the displacement is in the opposite direction, this is seen even in the integrated velocity data). So this is not promising for use in Autonomous.

However, there are a few things to keep in mind as we move ahead. First, at some point in time accelerometer technology will likely be sufficient/affordable to make this viable. We're definitely not there yet, though.

Second, since the first derivative of acceleration is velocity, and there will be less error in velocity estimates since integration only occurs once, the velocity estimation data may be useful for certain things. For instance, velocity estimation could be used to detect wheel slip, in case one wasn't able to measure the motor current to do that. Velocity estimation could also be used to attempt to maintain a consistent velocity even when wheel slippage is occurring. There are surely many applications for velocity estimation beyond that.

Third, given that sometimes the accelerometer displacement data is valid, this indicates potential for additional sensor fusion. Given that the encoders are widely believed to be more accurate at displacement estimation than accelerometer-derived displacement - but encoders are unreliable during cases of wheel slip - a reasonable approach (I saw this suggested awhile ago on ChiefDelphi) may be to detect wheel slip, then verify the current inertial velocity estimates are realistic and if they are fall back to the accelerometer-based displacement data during this time. In cases where both are deemed unreliable, a best guess based upon interpolation from last valid estimates of velocity would be required. Sounds kinda complicated, but sounds plausible enough that it's worthy of some research.

If there's more interest in this area of research, please feel free to private message me.