Localization of A Omni-Directional 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.

[faust1706]

I hate to plant this seed in someone's brain, but it MIGHT be possible to have a robot go from (x1, y1) to (x2, y2) using just an accelerometer. It is something I am investigating in my lab at college. Basically you construct the problem in terms of acceleration and the robot learns how to make the accelerometer read that acceleration. The idea is that if the robot gets so good at going x ft/sec^2 for any possibly x and can adjust from it's current acceleration a - > x in a reasonable time, then it is possible. However, as others have pointed out in this thread, error accumulates extremely quickly. This program will have to be flawless in its transitions.

It is a deeper investigation in my original project with a robot teaching itself how to follow a path given velocities. I am without a robot until I go back to college in August, however.

This project should be finished by next fall....with a paper submitted for publication sometime late next year.

[connor.worley]

Originally Posted by faust1706

I hate to plant this seed in someone's brain, but it MIGHT be possible to have a robot go from (x1, y1) to (x2, y2) using just an accelerometer. It is something I am investigating in my lab at college. Basically you construct the problem in terms of acceleration and the robot learns how to make the accelerometer read that acceleration. The idea is that if the robot gets so good at going x ft/sec^2 for any possibly x and can adjust from it's current acceleration a - > x in a reasonable time, then it is possible. However, as others have pointed out in this thread, error accumulates extremely quickly. This program will have to be flawless in its transitions.

It is a deeper investigation in my original project with a robot teaching itself how to follow a path given velocities. I am without a robot until I go back to college in August, however.

This project should be finished by next fall....with a paper submitted for publication sometime late next year.

How are you dealing with noisy/unreliable signals? This has always been a problem in my experience.

[faust1706]

That's where it gets iffy. It relies entirely on 100% accurate sensor data as well as getting data as fast as possible. I was thinking about having *3 accelerometers and averaging them. I expect it get somewhat close to the target spot, but I wouldn't put money on it in a precision contest.

*I would like to have about 20 just to really solidify the data, but that is unreasonable. If I would do that, however, I would use a RANSAC algorithm to find the "mean" of the signals. Also, it'd look pretty silly having a tower of accerlometers on a robot that is 6 inches tall.

[AdamHeard]

I'd wager for typical FRC level precision you'd always be happier with encoders (possibly on non-driven idler wheels) and gyro.