Localization of A Omni-Directional Robot

[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.

[faust1706]

Or a vision program that solves for the pose of a static object in the field, which gives you your position on the field.

But yes, encoders and gyro would be the easiest, and probably the most accurate, approach by far.

[teslalab2]

lol put a spinning radar satellite on your robot...

[slibert]

Originally Posted by teslalab2

lol put a spinning radar satellite on your robot...

There are sub-$100 LIDAR units like the LIDARLite which if put on a servo can scan the field at every 2 degree increment in about 2-3 seconds. Advantage is they are very fast, and can range up to 40 meters w/an accuracy of +/1 one inch. Unfortunately, the side panels of the FRC field are polycarbonate and most of the IR passes through, so getting a return on significant portions of the field is problematic. If the side-walls of a FRC field were IR opaque, this could potentially yield enough data to triangulate with, assuming the software were to know the field dimensions.