So, I had this kind of a job posting earlier, and I have made some improvements since, but I've been thinking I try putting up a price-limited job instead, as the other way felt it could get too expensive for what I wanted made. Especially if I plan releasing it for free later (or at least parts of it). I'm quite busy and I figured people here could probably do this better initially, so I thought I give this a shot and see the interest. Besides, I want this to come up to a certain quality so I can start selling the PCB for those that wants it. Reason I haven't started doing that yet is because I'm not satisfied with the software yet.
So, as a hobby project I've been working on this: http://treadgaming.blogspot.com
I've already done most of the hard work with the firmware for it, such as the SPI communication, USB interfaces/endpoints and interrupts. It's all in pure "AVR C", no dependencies on LUFA or anything like that. Ready to build using avr-gcc and flash by having it connected with USB and pressing a few buttons and use dfu-programmer. Shouldn't be hard to make it work in Atmel Studio either I suppose, but I haven't used that. I'm using the ATMega32U2.
Now, what I want to help with is adding a filter such as an (Extended) Kalman filter (which really isn't a filter, I know) and a calibration mode option. The filtering of the data is the most important part, but I figured that you guys here know what you are doing, so it might be a quick thing to add the calibration mode as well. This way, I'm pretty much done with what I would like to have done before I start marketing it.
The firmware I have uses the HWB button to enter a "calibration" mode, which currently doesn't do anything besides indicating the mode-change by blinking the "Power" LED. So, nothing fancy at all here yet. Still it's pretty much set up just to get started on filtering the data and handing that in the "calibration" mode.
So, what I want have finished here is code that can filter the raw, noisy ADNS 9500 sensor motion data I get and make it useful. Even for fast jogging/running speeds where the surface also might be rough (or at least not totally flat). So, please try the filter on different surfaces. I've noticed with the tests I've made that overall one can see the differences between walking and jogging/running speeds, but it's only noticeable when plotting the data (see http://treadgaming.blogspot.com/2012/10/simple-low-pass-filter.html for example). But, as you can see, it's still little too noisy to be useful and able to work with. It's also super delayed, taking a while before reaching 0 for instance, which also makes it hard to work with. Since I'm using a microcontroller, I want to use as little memory and CPU as possible, which is why an (Extended) Kalman filter really seems like a great option. Naturally, if anyone of you use something else even better that is fine too. As long as the data is nicely filtered and have as low delay as possible.
"Calibration" mode is basically only about taking the now more smoother filtered data, and let the device "learn" between what values is walking and what values represent jogging/running speeds. This way, we can then map the values to what values it should send over the USB as a game controller or whatnot.
So, this is about:
1. Filter noisy data. (Supporting higher speeds (the sensor can handle speeds up to 150 (inches per second) = 3.81 m/s = 13.71600 km/h) and surfaces not being totally flat).
2. Calibration mode using that filtered data.
Oh, and I suppose you would need the hardware, so I will send you one of mine here for you to test with. Then you only need a USB cable and a moving surface.
Estimated end date isn't set in stone. Especially since it can take a while before you get the hardware.
I really want someone dedicated to this as I really want what comes out of this is quality!
Feel free to also improve anything else in the firmware. I'm little flexible with both time and money, so if you prove yourself better than expected I wouldn't mind increasing both for even better firmware! :)