ROBOTC.net forumshttp://robotc.net/forums/ Signal processing and sensor Inconsistancy issues.http://robotc.net/forums/viewtopic.php?f=52&t=3976 Page 1 of 1

Author:  MaxChen [ Fri Jan 06, 2012 8:05 pm ]
Post subject:  Signal processing and sensor Inconsistancy issues.

Hello all,
I'm one of the programmers for team 2856, and I was wondering if I could have the community's help solving one of our problems that has truly gotten us stumped.
Essentially, in our autonomous program we are trying to develop a method that will let us know if our robot has bumped into something while were driving around. We looked at several different methods in order to actually sense the bump, but we found that all of our options were flawed for the same reason, but before i get into that, let me tell you what we tried.
First we wanted to try and sense if we had been bumped using the accelerometer, but we found that our chassis was too bumpy and would give us noise that was "louder" than the bump of a bowling ball. We then tried changing the bump to a solid object, a wall. If the robot hit the wall, we could barely detect the bump, but the robot has to be completely stopped which is far from ideal for our uses. When we tried to average the data, the bump was lost because it was so small. [important to note here that you looked at all the acceleration data (in both x, y, z axes). Noise was very high, even so much so that we couldn’t really detect that we were going down the ramp using the z-axis data. Also important to note that we considered x might be useful for a forward bump, y might be useful for a bump while turning (since the lateral acceleration might change with a bump), we used z only really to get to get a sense of noise (z should be pretty constant on a flat surface, should change appreciably on a slanted surface)]
The next thing that we tried was measuring our robots speed and trying to detect changes. The way we did this was to take the encoder counts on our wheels and the speed of the motors to calculate about how fast we were going. After gathering some data on the wheels normal speeds, we could then average our current speed with our predicted motor speed and then look for an anomaly. Unfortunately, we ran into a similar issue with the accelerometer; the wheels actually don't change much in speed unless you are stalled against an object, not if you are simply hit by the bowling ball. Here is our code for this measuring. http://pastebin.com/msCuqAyv
Finally, we tried using the gyro for detecting if we were hit while we were turning. We created a program where we would take the past 3 measurements, and if they deviated too far from each other then the robot would stop. While it seemed like this would work in theory, in practice we found that the values were far to finicky, and sometimes the same threshold(constant) would need wildly different amounts of force to be detected.
One problem that it seems that all of our sensors have is inconsistency. Most of our valid methods couldn't be utilized because they were just too noisy, which is where i ask you, the community to come in. We are not very good at signal processing, and reduction of noise, so it would be very beneficial if someone who has a bit more experience could show us around a bit. I’ve attached our data and graphs on each method, maybe someone could find something we missed.
I was poking around the forums and I remember one team attempting to work on a simplified Kalman Filter for the accelerometer, has anyone gotten that code working?
Thank you for reading, and for any suggestions!

 Attachments: File comment: Gyro data when turning without being bumped. gyro data 100.xlsx [11.27 KiB] Downloaded 220 times File comment: Accelerometer data. Copy of accell data.xlsx [26.02 KiB] Downloaded 240 times File comment: This is the data from the software bump detection program. SpeedCheckBumpTest.xls [124 KiB] Downloaded 213 times

 Author: MHTS [ Fri Jan 06, 2012 8:54 pm ] Post subject: Re: Signal processing and sensor Inconsistancy issues. Just a quick question: is you goal to detect bumping into the bowling ball so you can capture it? If so, is there a reason why you can't use a touch sensor?

 Page 1 of 1 All times are UTC - 5 hours [ DST ] Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Grouphttp://www.phpbb.com/