Have anyone considered how to use the accelerometer

we are going to try something different in the program and we planned to work on the accelerometer which is seldom used by most of the teams. Do you have any ideas?

The most useful thing I think you can do with them this year is antitiping code.

What is the meaning of the antitiping code:confused:

I think he means computer code that will help the robot not tip over and fall down. The accelerometer might be used to sense that the robot is leaning over too far. If it is leaning over too far, the computer code could do something like prevent the driver from commanding the robot to continue moving in that direction or the code could take over temporarily and actively move motors so the robot will not tip over.

However, you must be careful when using an accelerometer this way. You must consider the difference between the dynamic measurement and the static measurement conditions. For example, when the robot is not moving so much, the conditions are nearly static, in which case the accelerometer is measuring the gravitational acceleration vector, which can be used to sense too much of a tilt. But when the robot is rapidly moving around, it will experience accelerations in all sorts of directions and the accelerometer will measure the gravitational vector added to whatever centrifugal vectors, etc. the robot might be experiencing.

You do not want to program the robot with an anti-tipping code that might get activated simply because the robot made a fast turn and sensed an acceleration that the code interpreted as being a tilt.

i dont know how to use an anti tipping code with the accelerometer but its easy to make an anti tipping code with a gyro. maybe you can use an axis as height and if it goes below a certain height it will reverse motors

One word. Integration :slight_smile:

I think Both robot c and easy c do that for you, don’t they?

No, if you want velocity then you need to integrate. If you want displacement then you need to integrate again.

Oh, i see… accelerometer deals with acceleration… okay my mistake. We only used gyroscope but never had accelerometers.

The gyro is integrated for you, the accelerometer is not.

I’ve never used the accelerometer for anything other than a tilt sensor. Using encoded wheels has always proved to be more accurate than the double integration of acceleration to distance, however, it could be useful to detect that the robot has hit an object and is spinning it’s wheels. During roundup I remember some teams using it to detect that the robot had been pushed by another robot, there was a trend that year of sending your robot into your opponents to destroy their autonomous routine.

There have been attempts (by a user named magicode) to perform double-integration of acceleration to find position. These didn’t end too well, as doubly integrating values tends to create enormous error. I remember that part of this video gave a great glimpse into why this is the case, and some possible ways to mitegate it. That said, the simplest route is to just use wheel encoders.

In the ideal model,i don’t think that using encoded wheels is much more accurate than the accelerometer.In most of the time,the robot with encoded wheels can move accurately but if the robot hit something or was accidentally stopped by something, the value of encoder will still be accumulated while the actual the displacement is not changing.On the contrary,integrating the accelerometer to calculate the displacement will be always accurate because the displacement is determined by the actual moving distance instead of any other elements

This is a contest I would like to see: encoder-only robot vs. accelerometer-only robot, both on a straight track about 10 meters long. Which one stops closest to the goal line wins. :slight_smile:

On a straight track the error from encoders would be negligible for the purposes of a robot, and the problem with integrated position is that error will accumulate and you will see drift. The advantage to accelerometers is (as 7973A pointed out) even if they have some drift and less precision, they will have a better approximation of your position if you run into something and are spinning your wheels. I wonder if you could get a more accurate hybrid system which would go off the encoders as they are more precise if there is no significant difference (and recalibrate the accelerometer to the encoders), then if there is significant drift (e.g. hitting a wall) it will base of the accelerometer which will be more precise having been recently calibrated to the encoders. This may not be the best way of implementing it (or work in the first place), but I suspect you would want some form of hybrid to get the benefits of both.

Is that true if you ran into something that is not in line with your center of mass? In other words, if your robot were rolling along and hit a 2 cm diameter pole on the very right front of your robot, would your accelerometer (+ software) be able to tell that the robot might now be facing somewhat to the right because its mass continued to pivot around the impact point?

I’ve never played with the Vex accelerometers, so I’m wondering if you guys are talking about theory or am I hearing the voices of experience here?

You need to use a Kalman filter (linky) to deal with this. Segways use this approach, along with a gyro+accelerometer system that deals with sensor drift and error accumulation.

Aha!, wondered when that would come up, so Skyler, how about giving us an implementation in ROBOTC.

Looks like a challenge Sky. Do it.

Weeeerrrllll…I…am busy with…my internship…buuuuuuuut…youcanusethissite


As you mentioned the error accumulation of the accelerometer, i still don’t understand why and when does the error occur:confused: