View Single Post
  #15   Spotlight this post!  
Unread 03-06-2015, 15:11
slibert slibert is offline
Software Mentor
AKA: Scott Libert
FRC #2465 (Kauaibots)
Team Role: Mentor
 
Join Date: Oct 2011
Rookie Year: 2005
Location: Kauai, Hawaii
Posts: 343
slibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud ofslibert has much to be proud of
Re: Localization of A Omni-Directional Robot

Quote:
Originally Posted by teslalab2 View Post
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.