You probably have to get a book on some pretty good math here.
It's called integration. If I know I've been accelerating for 10 seconds and a rate of 10 feet per second, then I know at the end of 10 seconds I'll be moving 100 feet per second and I'll have travelled 50 ft ('cause I started at 0 and now I'm at 100 and the acceleration was constant).
The big thing with integration is the speed at which you integrate. It doesn't do any good if you look at a signal once a minute 'cause you may have been going 100 mph for 50 seconds of that minute, but may have started and ended that minute at 0 mph. Make any sense? Same thing goes with an angular sensor. If I know I started the time at 0 degrees position and zero degree per second of rotation, and now I know I'm rotating at 10 degrees per second, and now it's one second later, then I should know that I've rotated 5 degrees and I'm rotating at 10 degrees per second. So, in another second, I'll be at 15 degrees position, and still be rotating at 10 degrees per second, assuming I haven't had a change in rotational speed.
Problem with this, is that no matter how good you think your math is, over time, your position will be off (especially using integer math like in PBP). You need some way to reset your position to zero (or some known angle). In the Nintendo Wii, the WiiMote uses those 2 IR LEDs from the sensor bar and the small sensor in the front of the WiiMote for just that...to reset the 'level angle' (for lack of a better term).
So, for this to work effectively, you need, at the very least, a few things:
A tight A/D with lots of bits, a fast sampling rate of your sensor, good floating point math, fast processing speed (a PIC is ok, but a dsPIC would be much better).
But if you're just playing around, trying to get something to work...heck ya, a PIC and all it's internals should be perfect. You just have to write some integrating code like I described above and you're set.
Hope you got a couple of ideas out of this...good or bad![]()





Bookmarks