Re: Filtering out Vibration while using a KOP Accelerometer
 

Your calculations look very wrong, i would check them first.

<R68> is what i was referring to, the beginning makes it sound like they are not allowed, because they are not COTS. But if all of the components are COTS and you put them on the PCB is that OK?

Re: Filtering out Vibration while using a KOP Accelerometer
 

Let's look at R68:

So as long as your custom electronics is either COTS (such as an encoder) or assembled from COTS items, it's allowed. A separate PIC, resistors, capacitors, PCBs, etc, are all examples of COTS items which can be assembled to your own circuit.

Re: Filtering out Vibration while using a KOP Accelerometer
 

As for data. I guess one question I have is: what motion (if any) was occuring while this data was recorded.

The next question is how to interpret your accelerometer values, which are in the range of 475 to 569 or so. How does this relate to millivolts coming out of the accelerometer? Sorry, I havn't played with the controller in a while... and when I did, back in 2002... well... everything was different :)

Anyways, according to the Sensor Manual, it would appear that horizontal orientation under no acceleration should be outputting 2.5 volts.

According to the Data Sheet, it would appear that the 0g corresponds to 1.65V given a 3.3V input. I think first is driving it with a 5V input. So a 0g output of half of Vs seems to be self consistent here.

So the first thing we want to verify: is the meaning of your numbers there somehow consistent with the ~2.5V +/- 1.7V that we expect to see from the output of the device?

Re: Filtering out Vibration while using a KOP Accelerometer
 

my concern stems from the fact that I cannot come up with something that would be in violation of this rule if it is not a drive circuit which are explicitly prohibited. So if I fully design my own integrator and PCB, then I am ok?

Re: Filtering out Vibration while using a KOP Accelerometer
 

The RC's analog inputs have ten bits of precision. That gives results from 0-1023 for a voltage from 0-5 volts. A value of 475 translates to about 2.32 volts, and 569 represents about 2.78 volts.

Re: Filtering out Vibration while using a KOP Accelerometer
 

Try a Kalman filter. There is source code to some optimized versions floating around on the internet. (The full filter is a bit labor intensive.) This filter was designed to read noisy signals and make estimates of true value based on it.

http://en.wikipedia.org/wiki/Kalman_filter

Re: Filtering out Vibration while using a KOP Accelerometer
 

Hey, that's a safety feature we're having in hybrid mode! We're using one of the programmable comparators to detect (and generate and interrupt) if we get a G-spike indicating a crash (a lot like a car with airbags) and in the event of a crash will kill all the motors to protect the robot. Now if we can just get it to call OnStar... :D

-q

Re: Filtering out Vibration while using a KOP Accelerometer
 

uhhhhh..... just put an encoder on one of the wheels you already have? I realize this can slip, but its probably a better probability of it working than an accelerometer with error squaring... eh... i mean double integration. :rolleyes:

-q

Re: Filtering out Vibration while using a KOP Accelerometer
 

First of all, Kalman Filters are great :)

Second of all, the rest of this post will likely sound like non-sense unless you've read a couple articles in Kalman Filters. If you think you're interested in Kalman Filtering, this is a good place to start.

Now onto what I was going to say: I've never had a Kalman treat the accelerometers as direct measurements in a nav system before. There are a couple reasons for this. Keep in mind, I use a full 6DOF system where all of this is more complicated. For one, it requires running the Kalman faster than we want to (at the full 400Hz IMU rate). Additionally, doing so requires the linearization of a fairly gnarly prediction function (since the prediction function is doing an implicit double-integration).

Finally, and I think this is the most important one: if your state vector includes acceleration and you are Kalman filtering your acceleration. You need a MODEL of how you expect your acceleration to change from one time-sample to the next. It's comparing this prediction to what you actually measure that allows a Kalman to function well. You have no means of acquiring such a prediction, especially when you want to measure things like crashes and bumps (outside the scope of your controlled values). So basically, to tune your Kalman to reflect the unpredictable nature of your accelerations, the process noise will have to be high enough that very little smoothing will actually happen.

What we tend to do is leave acceleration out of our state vector. We track position, orientation, and velocity inside the Kalman. We then integrate the accels/gyros using the inertial nav equations essentially as part of the prediction phase, and use this to update our predicted position/orientation/velocity values. Then, we use the Kalman measurement update to incorporate additional sensors such as GPS/IMU and correct these terms.

Calibrating and working out bugs in this kind of system is the kind of nightmare that can take an experienced engineer months (or years) to get right. At work, the Kalman Filter we use for our nav system has a state vector with 150 elements in it. Needless to say, it is still being debugged.

But you guys are working in 3DOF and I expect the problem is likely more tractable in that case. Maybe I'll review the equations when I get a chance this afternoon.

Where a Kalman would really shine is fusing measurements from your accelerometers with measurements from your shaft encoder or other sensors.

Anyone, please feel free to contact me if you would like to discuss Kalman filtering in more details.

Re: Filtering out Vibration while using a KOP Accelerometer
 

Some people might find this article of interest.
http://www.freescale.com/files/senso...ote/AN3397.pdf

Re: Filtering out Vibration while using a KOP Accelerometer
 

Definitely a great starting point for anyone looking at doing this. Thanks for the great find, comphappy!

Re: Filtering out Vibration while using a KOP Accelerometer
 

Yeah, my calculations were off a bit... I forgot to keep track of the stupid velocity constant when I did the first integration... Now the data is better, but still bad... I think we might go with the encoders... We even shock mounted the accelerometer, and that didn't help all that much. (Magnetic shock)

Re: Filtering out Vibration while using a KOP Accelerometer
 

you may consider low pass filtering out the freq range from the motors and/or compressor.

Re: Filtering out Vibration while using a KOP Accelerometer
 

I looked at the data in the spreadsheet. I plotted the dx values and the dy values (I assume these were the result of double integration and represented position). Each seems to have a recognizable trend. If this roughly corresponds to the movements you were applying to the robot (you didn't say), I'd be encouraged that the data could be useful. Sure, it's a little fuzzy. The trick is to filter out the fuzzyness without delaying the data so much that it's no longer useful.

If you need instantaneous location to within an inch, it's probably not going to be useable. But if you just need to know if you are probably past the wall and should turn left, it might work.

Re: Filtering out Vibration while using a KOP Accelerometer
 

Hi, I'm currently trying to decide between using wheel odometry and a double integration of accelerometer data. So this is a very interesting conversation!

One thing that I've failed to see is any mention of the gyroscope data used in conjunction with the accelerometer data. I see this as important because the robot's frame of reference translates and rotates with respect to the absolute coordinate frame of the field. Pretty much what I am saying is that the x and y coordinates of the accelerometer won't always remain parallel to the x y axes of the field therefore the orientation of the robot must also be monitored. Has anyone considered this as a probably source of error? I might've missed something, but there is my two cents!

windell
#2477