So I have been trying to make use of the vex accelerometer to calculate distance travelled but after working on it for a short amount of time, I ran into difficulties. First of all, I will describe my set up.
I am currently only working with the x-axis and to create a controlled acceleration, I mounted the accelerometer onto a sliding rail powered by a single motor and rack and pinion gears. This way, all I have to do is hit a button and it will go for a second and a half (the length of time needed to hit the end of the rail).
I am programming in RobotC.
It is only meant to return data into an array after every millisecond. Here is a graph of what I theorized the data to look like.
If you think about it, the acceleration should increase at first until it can no longer accelerate at a faster rate, then it should drop down to zero and flat line as the slider is moving at a constant velocity; then it should slope downwards into the negatives as it decelerates and hits the end of the rail where it quickly jumps back up to zero and flat line as there is zero acceleration.
After running this test and entering the data into an excel spreadsheet, I got data that looked like this.
As you can see, there is absolutely no patterns or interpretable data in this graph. According to the data, the accelerometer is accelerating and decelerating quite randomly.
Does anybody have any ideas as to what is causing this useless data? Is it just a poor quality sensor? In case it matters, we were running it with both jumpers on it.
A real experiment, with real data; how unusual and admirable.
You need a low-pass mechanical filter on the accelerometer sensor.
For example, hard-mount fasten it to a battery (high mass),
and soft-mount (foam, tractionmat padding) the battery to the moving carriage.
Sometimes just padding it helps damp enough, without the added mass.
Can you post your code?
For example, how do you know your data points are 1ms (or any other time) apart?
I hadnāt thought of adding a mechanical filter, that could definitely help. Here is the code, it actually takes a reading after every 10 milliseconds. Perhaps it needs to take readings more often?
There might be a spec for how often the Accel updates.
Waiting 10ms is not same as 10ms between reads, but Iām just picking nits.
You might try reading the accel, then reading the timer, and saving both, then wait 10ms.
then using XY graph in excel to plot the accel vs timer, instead just line graphā¦
That will also show how close to 10ms the times are spaced.
Less time between reads wonāt make the reads less jittery, only the lowpass filter can do that.
If the jumpers set the scale, you could try using the other scale as well.
You did connect to analog port 1, thatās how you seem to have configured it.
polarity of the connection is correct.
You are moving in X and not Y.
Assuming you are connected correctly, I would check the sensor is working using the debug window, create a loop in the code that does nothing for a few seconds, move the accelerometer about whilst watching the value in the debug window change. Get that working first.
Iāve done a a little (read hours of hair pulling) work with VEX accelerometers, and I havenāt had too much success with calculating distance with them. I hope other people have had more luck. Hereās a link to a ROBOTC forum topic with my test code: ROBOTC
Have you tried the āSimpsons Ruleā math as suggested in the April post?
I didnāt follow the early post about using gravity to find a position of 4.2 meters(?). If you are moving the accel by hand, up and down, the apparent gravity is not constant, so you should have the same issues as X,Y movement.
If you are just using the accel to find a stable x,y,z pointing orientation by using the gravity vector, then I understand. One use in Vex would be a ātip-overā detector.
In the DIYdrones site forum, there is talk about 9 degree of measurement sensors, and using an entire ATmega processor to do Kamen filtering.
We work on VEX on Tuesday so I will spend more time working with it then. Thank you very much everyone for your help so far. I will update you all with any progress I make or any further difficulties I encounter.
I have tried to do that, but I do not have access to the accelerometer anymore (itās at school, and Iām on summer break)
I simply left the accelerometer on the desk, and told it to start counting how far it was falling. Since acceleration is the same whether you are actually falling or not, the accelerometer determined that it had fell a distance of 4.2 meters after 1 second.
I have tried to use the new VEX v1.0 accelerometer to measure tilt angles using Easy C Pro. It seems to read each axis and return values which increase or decrease depending upon the orientation. I point accelerometer in the x direction using the arrow on the board to get a reading which I expected to be 1 G (1000 millig(s) ) but the value I get is around 800.
How can I obtain consistent readings?
Is there any calibration information available for this VEX product?
jg Bold Emphasis added:
Hopefully this is just ambiguously worded, rather than fuzzy thinking.
āThis is why an accelerometer in free-fall doesnāt register any acceleration; there isnāt any.ā
A robot free-falling (driving off a table?, fast elevator or rollercoaster?) in a 1g gravity field will show a z-axis acceleration of zero. It is this type of zero-g detection that some notebook computers use to retract the disk heads to avoid wrecking the disks when the inevitable multi-G āhitting the floorā event follows.
Interesting to consider that this feature would have to be tweaked or disabled for those computers to work in orbit on the International Space Station.
āThis is why an accelerometer in free-fall doesnāt register any acceleration; there isnāt any.ā
A robot free-falling (driving off a table?, fast elevator or rollercoaster?) in a 1g gravity field will show a z-axis acceleration of zero. It is this type of zero-g detection that some notebook computers use to retract the disk heads to avoid wrecking the disks when the inevitable multi-G āhitting the floorā event follows.
You are right, Iām sorry. Let me reword my original statement. An accelerometer at rest on the surface of the earth will display the acceleration that it would appear to be accelerating at if it were in a free-fall in a vacuum.
I always seem to trying to answer questions for which I have no real knowledge, lets hope this one will not cost me yet another $40
The best way to go about debugging this sort of this is to write test code to look at raw data values before starting to try and use the sensor in a real application
Looking at the datasheet the sensor has two different sensitivities, either +/- 2g or +/- 6g, the VEX product page says these are jumper selectable. Lets assume you have the set it for +/- 2g. The datasheet also tells us that the sensitivity is Vdd/5 V/g, however, even though this is a 3.3 v part VEX has placed an amplifier on the board (LMV824, datasheet here http://www.national.com/ds/LM/LMV821.pdf). We could take an educated guess and assume VEX has amplified the output to be 5V and suitable for the A-D input on the Cortex. So this probably means a 1V output from the sensor corresponds to a 1g acceleration. The datasheet also tells us that for 0g the sensor outputs Vdd/2 or, after our amplified signal 2.5V. This would make our 1g output more like 3.5V. The range of the A-D converter is 0-4095 so each 1V change corresponds to approx 820 when reading raw data. We could therefore estimate our raw sensor data value to be 2866 if we told the firmware it was, for example, a potentiometer. I have no idea what additional processing RobotC ( or EasyC ) then adds if it knows it is an accelerometer, however, if the processing is as simple as to just make the output signed a reading of 800 (digitized +3.5V - 2.5V offset ) would not be unreasonable. Do some experiments and post back the results for us.
