Accuracy with the Accelerometer?

I was thinking about getting an accelerometer but first I wanted to ask anyone who owned one about the accuracy of the sensor.

Could an accelerometer measure distance more accurately than a pair of encoders?

Could it be used to calculate yaw with reasonable accuracy?

I have never liked codes that use only encoders because even with good coding your robot will run the routine a little differently every time. Could an accelerometer fix this problem?

Thanks,

Our team did quite a bit of work with the accelerometer in an attempt to use it for Clean Sweep. In the end we abandoned using it for this past year. Many of the problems we encountered may be resolved with the use of the Cortex. We have not tried it since we bought our new Cortex processors, since we have taken a month off after Dallas.

I am actually not involved with the programming to any great extent, but I know the problems we encountered last year were that the V.5 PIC processor did not support floating point math, and the accelerometer provided very noisy data. The lack of floating point math made most acceleration and distance calculations very difficult to impossible, and it did not allow us to implement any type of filter algorithm to smooth the noisy data. The sensor seems to be plenty sensitive, and is therefore susceptible to vibration that made the data noisy. We tried approximations for some math functions, which turned out to be very cumbersome, inaccurate and caused us to run out of memory on the V.5 processor.

Hopefully the Cortex will make the accelerometer much more useful.

cc4hldr mentioned that vibrations gave faulty readings. Why not create a suspension system out of that Vex foam stuff? Also, I’m pretty disappointed to read about the code. I just got an accel. Sorry :frowning:

Thanks for the info,
-FutureInventions

One idea for a mechanical low pass filter:
-fasten the accel firmly to the battery (a high mass concentration)

  • locate the battery near the center of mass of the robot
  • use rubber/foam/etc to isolate the battery from robot vibrations

To clarify, to say it gave faulty readings implies the sensor is no good. A good, sensitive sensor operating in a dynamic environment is subject to noise and outliers in the raw data that requires some sort of filtering and processing. There may be nothing wrong with the sensor. My point was that it was not of much use when using the old V.5 processor. When used with the new Cortex, it may a great asset. We just have not had an opportunity to try it yet.

Everyone,

My campus of Lockheed Martin has been specializing in digital signal processing (submarine sonar systems) for roughly 35 years.

Those sonars are built around supercomputer-sized arrays of CPUs; but even with all of the processing power we manage to cram into them, we still want more.

That means (especially in the earlier systems we deployed) that we have often relied on carefully crafted integer-arithmetic filtering routines to efficiently process fixed-length, high-bandwidth streaming data.

Bottom line - I you want me to ask some of my friends to recommend filtering routines that can be fit into a Vex V.5 microcontroller - Just ask - There are a lot resources available through these forums…

Blake

You could interface a floating point math co-processor or even a Microchip dsPIC C30 to the VEX Microcontroller using the SPI interface. It would handle the digital filtering in either fixed point or floating point and return the results to the VEX Microcontroller. The dsPIC30F6014 even has DSP capabilities that are ideal for processing digital filters.

I think I can take up this challenge…

I posted code for Fixed Point math routines with the Vex Controller V.5, see Using Fixed Point values in Integer Variables.

I see a lot of “noisy data” from the Vex Accelerometer, and some sort of Physical Isolation System might need to be implemented, as well as Software Filtering.

I have been very busy with School, and Underwater ROV, until the end of June… But I will have time this summer to work on Vex…

Could you post the source in a text file for us that don’t have EasyC?

My Bad!!! I should have been more generic:wink:

CODE

#include "UserAPI.h"

int loop; 
int value; 
int characteristic; 
int mantissa; 
int incrementer; 

void main ( void )
{
      //  I "borrowed" the Terminology from Logarithms for the
      //  Whole Number and Decmal Number variables.
      //
      //Example with Two Decimal Places
      PrintToScreen ( "Example with Two Decimal Places\n\n" ) ;
      value = 1111 ; // Value of 11.11
      incrementer = 1234 ;
      for ( loop = 0 ; loop < 10 ; loop ++  )
      {
            characteristic = value / 100 ;
            mantissa = value - (characteristic * 100) ;
            PrintToScreen("Pass # %2d --> %3d.%2d <-- %5d\n", loop, characteristic, mantissa, value);
            value += incrementer ;
      }
      PrintToScreen ( "\n\n\n" ) ;
      //Example with Three Decimal Places
      PrintToScreen ( "Example with Three Decimal Places\n\n" ) ;
      value = 1111 ; // Value of 1.111
      incrementer = 2345 ;
      for ( loop = 0 ; loop < 10 ; loop ++  )
      {
            characteristic = value / 1000 ;
            mantissa = value - (characteristic * 1000) ;
            PrintToScreen("Pass # %2d --> %2d.%3d <-- %5d\n", loop, characteristic, mantissa, value);
            value += incrementer ;
      }
}

OUTPUT



VEX - Master v7, User v5
Example with Two Decimal Places

Pass #  0 -->  11.11 <--  1111
Pass #  1 -->  23.45 <--  2345
Pass #  2 -->  35.79 <--  3579
Pass #  3 -->  48.13 <--  4813
Pass #  4 -->  60.47 <--  6047
Pass #  5 -->  72.81 <--  7281
Pass #  6 -->  85.15 <--  8515
Pass #  7 -->  97.49 <--  9749
Pass #  8 --> 109.83 <-- 10983
Pass #  9 --> 122.17 <-- 12217



Example with Three Decimal Places

Pass #  0 -->  1.111 <--  1111
Pass #  1 -->  3.456 <--  3456
Pass #  2 -->  5.801 <--  5801
Pass #  3 -->  8.146 <--  8146
Pass #  4 --> 10.491 <-- 10491
Pass #  5 --> 12.836 <-- 12836
Pass #  6 --> 15.181 <-- 15181
Pass #  7 --> 17.526 <-- 17526
Pass #  8 --> 19.871 <-- 19871
Pass #  9 --> 22.216 <-- 22216


Here is where the magic happens:


            characteristic = value / 100 ;
            mantissa = value - (characteristic * 100) ;

If you need Two Decimal Places, ALL your Integers are Multiplied by 100, and placed into the variable value and use the above code to break them apart into the characteristic and mantissa.

The more Decimal Places you need, the Less Range you have because the Integer Variable still only hold 65536 different values, 0 to 65535. So the above variable with Two Decimal Places with Unsigned Value would hold a number between 0 and 655.35.

This will only help with implementing math with NO Floating Point variables… The Averaging and Jitter Correction will still need to be dealt with…

More Questions??? Please ask… :wink:

(Note: Using Fixed Point values in Integer Variables Page now updated to show Source Code and Output.)