It’s one of the few sensors we never bought. I’m considering getting one now.
But, how good are they? If it matters, we would be putting it on the base of the robot and tracking movement in the X and Y planes. Not the Vertical one.
Specifically, I want to know:
[LIST]
*]The rate at which the sensor updates (20x per second, etc.)
*]The accuracy of the sensor (to the nearest cm/second, or m/s)
*]How prone it is to drifting
*]If it is possible to reset, or recalibrate the drift during the match by coming to a dead stop
[/LIST]
If anyone has had experiences with them, good or bad, I’d love to hear stories.
analog ports only give you 12 bits of precision and have a lot of static, this isnt enough to accurately track the robot for 2 minutes
nope. the only way to recalibrate the robot’s position is for it to have a preset location, ie drive into a corner and press a button and it resets the calculated position
I, too, am curious about the accelerometer. I’ve heard a couple people say they were looking into integrating the accelerometer with the gyro, but I haven’t yet heard how they plan on doing this and why it should help on a level playing field.
in order to know the position of the robot you also need an angle, you pretty much have to put the accelerometer ontop of the gyro
im guessing they are putting the gyro and accelerometer onto a single I2C chip, this would allow high accuracy and the I2C unit can read them at high frequency, so the cortex gets the sum since the last read, hopefully it can read at 24 bits precision
this is similar to what the IMEs do
But if you’re on a level playing field and the robot is not tilted, how does the accelerometer help you with the gyro?
The only thing I can think of is that the gyro’s readings might be affected by where it’s placed on the robot. So if the gyro happens to be far away from the robot’s axis of rotation, perhaps its readings are affected by the “g-forces” caused by a turn and maybe an accelerometer could measure those “g-forces” and allow the Cortex to compensate.
It’s more about how accelerometer measures acceleration(note: change in velocity) and the gyro detects acceleration(change in direction). This way you detect your heading and velocity towards that heading, and if you knew where you started from, you could derive where you were on the field.
I understand that, in theory, an accelerometer’s output could be integrated over time to provide velocity, and that this resulting velocity integrated over time could provide position. But I’m skeptical that the Vex components could do this in any practical way, and any collisions with other robots, etc. might mess it up big time.
But is that what these teams are planning on doing? Am I wrong about the capability of these components?
That type of double integration is what leads to inaccuracies. I know of multiple teams (including my own from high school) who have tried doing this, and all have had pretty terrible results. Most teams seem to be complaining about inaccuracies in the VEX gyro, and that is only utilizing single integration to obtain a heading.
Teams are probably going to use these to get an accurate autonomous. Since robots will be fighting over balls, collisions will happen, and may mess up the position reading, but re calibrating the position by driving into a wall and then pressing a button to set it will work but can waste a good amount of time, it might be not very good during driver control. We’ll find out how teams use it later in the season…
Most IMUs (inertial measurement units) use a combination of accelerometer, gyro and magnetometer to create orientation and position vectors. There a simple explanation of one of the techniques here. http://www.pieter-jan.com/node/11
Like others, I never found the accelerometer very useful other than for tilt measurement. I’m more interested in how to improve the gyro accuracy, both of these sensors are getting a bit old, I wish we had access to newer versions. The VEXU teams can obviously do this, one of my favorites from a couple of years ago was this one. Yost engineering 3 Space sensor
I don’t have that one available anymore and even that one at $125 was marginal.
Okay, now I think I’m beginning to understand what you’re talking about. I thought they were using the accelerometer just to determine tilt, pitch, roll, and stuff like that. Thanks.
Now that’s just cheating! For $100 less you can get all the same features and learn how to design a Kalman filter all at the low cost of endless hours of your time!
For real though, it is neat to see an embedded, Kalman filtered, AHRS. I was seriously looking into doing this on the software side this summer, but I never really got a response in this thread. If it worked well enough I was going to move onto a larger filter that estimated the robot’s position as well as heading. I wasn’t sure how well the filter would handle the non-linearities so I needed a set of data to play with and I don’t have a robot this summer.
If only VEX sold a nice little NAV chip that took your encoders, accelerometers, magnometers, and gyros through a Kalman filter and spat out your position and heading…hehe one can only wish, right?
I don’t think that the accelerometer would suffice on its own for navigation. However, I do think it has an important role if you were going to use something like a Kalman filter.
The sensors you are discussing here are good to use for your work. They have the good efficiency and also the great update speed. Also it has the great accuracy. You can reset them and also they are less prone to the drifting. Check their manuals for exact details.
One of the things that came up in my teams autonomous discussions was to make a system where the robot uses 2 IMEs on our drive and an accelerometer to be able to map out where the robot is. We then talked about using it to find a way to aline the robot up to shoot a ball. We did not consider a robot bumping into us and messing up our readings, which I will surely bring up, but for a programming skills challenge, would the use of these 3 sensors be accurate enough to work? We have never used used our accelerometer and only just received them in the mail yesterday so we haven’t been able to play with it yet.
It will depend a lot on 2 factors
1.How much the wheels skip
2. How you code it.
It should be perfectly possible using the sensors to achieve your goal. The sensors should not be what is limiting you.
Alright, thank you for the reassurance. One of my team members has devoted himself solely to the programming and application of this concept. We have a code generated already and will test it next week.
I actually just recently managed to find an accelerometer in the deep dark depths of my teams supplies and I have been thinking about its potential uses. I guess the two uses that really stand out for me are accurate position tracking (with a gyro and encoders) and measuring tilt (something that should come in handy for dem unstable scissor lifts!).
For $100 less you can get all the same features and learn how to design a Kalman filter all at the low cost of endless hours of your time!