Posted by Matt Rizzo.
Coach on team #349, The RoBahamas, from nternational Academy and Ford Motor.
Posted on 1/31/2000 6:08 AM MST
On the Innovation First site they have a white paper on Digital Filters for Joysticks. Could someone
explain how these filters work?
Thanks,
Posted by Michael Betts.
Engineer on team #177, Bobcat Robotics, from South Windsor High School and International Fuel Cells.
Posted on 1/31/2000 10:30 AM MST
In Reply to: Digital Filters? posted by Matt Rizzo on 1/31/2000 6:08 AM MST:
: On the Innovation First site they have a white paper on Digital Filters for Joysticks. Could someone
: explain how these filters work?
: Thanks,
: - Matt
Matt,
Kind of hard to explain without a few years of college education behind you. There are two major types of digital filters, an IIR (Infinite Impulse Response) filter and a FIR (Finite Impulse Response) filter. What they have implemented is probably the most simple filter possible… An extremely simplified IIR.
To learn more, ask the electrical engineers on your team. I can give you a couple of references:
A. Embedded Systems Programming, Vol 9 Num 5, May 1996, ‘All About Filters’ by Jack W. Crenshaw.
B. http://www.analog.com/publications/magazines/Dialogue/31-1/DSP.html
The web address for reference A is http://www.embedded.com/ but they do not have that article on-line. You might be able to e-mail Mr. Crenshaw to ask for a reprint (I’m positive he has an electronic file).
BTW, If you do contact Mr. Crenshaw, he lives in Orlando and might be interested in seeing the FIRST nationals.
You might also be able to find a web tutorial with a little searching and the information I have given you here.
One of the best ways to understand the code in the white paper is to ‘hand-crank’ through the numbers for a few iterations (say, 127 as an input), insert a noise spike on the input (say 230 on the input) and then go back to 127 as an input. What does the output do? Remember that 2-4 is not -2 in unsigned arithmetic, it’s 254!
Don’t feel bad if this stuff is over your head. It’s also over mine a lot of the time. Many engineers understand the math and do not appreciate what it actually means in the real world. Others use it all the time but cannot fathom the theoretical basis. Those who do both are very strange people indeed!
Good luck… - Mike
Posted by Rick Berube.
Engineer on team #121, Rhode Warriors, from Middletown H.S…
Posted on 2/2/2000 8:17 PM MST
In Reply to: Digital Filters? posted by Matt Rizzo on 1/31/2000 6:08 AM MST:
: On the Innovation First site they have a white paper on Digital Filters for Joysticks. Could someone
: explain how these filters work?
: Thanks,
: - Matt
Matt, how about this?..
If you stomp on the gas and have a big enough engine given the size of your car, your going to spin tires! Your robot is no different when you bang the joysticks to full throttle. Doing either will fish-tail the respective vehicles. This wears the tires prematurely and believe it or not, makes you slower in any race, because you waste valuable time not moving toward your destination, but instead sitting still spinning tires.
Now image that you can accelerate your car/robot in just the right way, such that you are always turning the tires as fast as they can go without sacraficing traction. At this point you’ll put in your fastest time in the race. When you study the problem, what you find is that you need to control the rate at which you accelerate (and decelerate, unless you plan to skid to a stop).
Now to the code in the white paper. Think of a this type filter (low-pass) as a delay! It delays the command from the joystick in such a way, as to accelerate/decelerate your robot, preventing the spinning of your tires. Its that simple.
Now looking at the code, the crucial line is:
p1_yfilt = p1_yfilt+((256+p1_y-p1_yfilt)p1_yfiltcoef/200)-(256p1_yfiltcoef/200)
This line has some things in it the StampII needs, because PBasic doesn’t handle negative numbers. PBasic also can’t handle decimal (floating point) math. The 256 values are there to address the issue of turning signed math into unsigned math for PBasic. And the p1_yfitcoef/200 term is a way to multiply by fraction (or percentage) without having to do floating point math. So I will remove this stuff for the sake of clarity and instruction. Doing so, the line simplifies to the following psuedo code:
current_motor_cmd = previous_motor_cmd+((joystick_cmd-previous_motor_cmd)*percent_of_change_allowed)
In the psuedo code, I assume signed math works for the sake of explanation. If you look closely, you’ll see that we add or subtract a percentage of the difference between what the joystick is commanding and the command sent to the motor in the previous cycle. Now, when you bang the sticks initially, this change is large. Each cycle thereafter, the change becomes smaller and smaller until the motors are being commanded at their top speed. How quickly the commands from the joystick and to the motor become equal, is determined by the p1_yfiltcoef value. The larger this value, the faster your robot will try to accelerate. Keep in mind, what is feasible is ditacted by your robot design and its physics (F=mA). You’ll be able to get away with accelerating an 80 lbs robot faster than a 100 lbs robot.
hope this helped Matt.
Regards,
Rick B.