![]() ![]() ![]() There’s nothing built into eas圜 or RobotC to do this, so you have to write this yourself. Store that median in the array instead of the junky data actually returned from the sensor.Use that median in the current PID loop. ![]() Calculate the median of the 5 stored values.When the sensor value of the current iteration is sufficiently far off from your chosen target (or the previous value), you say, “Hey, that’s junk.”.Keep a running array of the most recent 5 sensor values.The programming steps for filtering the data are like so: Since these PID iterations are taking place over a VERY small period of time, using replacement values for 1 or 2 numbers every now and then does not cause undue problems (or any, in our usage of it thus far). From other research I did on the VEX Forum, people have indicated that these noisy sensors rarely produce more than 2 junky pieces of data in a row. So what is a median filter? It’s simply using the median of the previous x-number-of-values as a replacement for junky data. (For background, a Kalman filter is useful when you’ve got a complex, dynamical system with multiple sensors providing input.) A search of the VEX Forum will return many threads mentioning things like Kalman filters, and (a) from what I’ve read and (b) my experience using it with the ultrasonic sensor, I’ll confirm that a median filter worked perfectly. I’ll cut to the chase here, since you’re probably reading this article in order to save yourself some time and background reading: For simple filtering of data like this instance, a median filter is just fine. That’s when I started researching techniques for filtering sensor data. I mean, how can you adjust left- and right-side power to maintain a fixed distance from the wall, if you randomly get complete junk? You just can’t. What to Doīased on what we saw in the table above, without the ability to filter data, the concept of using the ultrasonic sensor to drive straight would be pretty much a non-starter. This fact makes the sensor distinctly less useful. Uhhhhh… problem? And that’s when I learned that certain VEX sensors-including the ultrasonic, gyro, accelerometer, and potentiometer-have a tendency to return “noisy” data. We were using the RobotC datalog (as I recommend everyone use when writing a PID loop) and looking at the error value each time through the loop. We were making use of a PID algorithm, increasing or decreasing power to one side of the drive train depending on whether the robot was further away from or closer to the perimeter than our chosen target. It started when we were trying to use an ultrasonic sensor to drive the robot straight down the field, keeping a constant distance from the field perimeter (ultrasonic sensor attached to the side of the robot). My team has been learning more-sophisticated programming of late, and I thought I’d share one topic we recently dove into: filtering noise out of sensor data. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |