Thread: Is there any inclinometer sw out there?

Nice! I thought you were using the D-Pad controller, not the Analog stick (Just something I pictured because of people making remote controlled cars interfaced with Wii controllers with that part), but my parents never use that part of their Wii controller, I'd gladly "borrow" it

You're right it's a bit jittery. Wondering if the sample rate is too high, or you would have to program in a smoothing/averaging formula. You don't need it to update every 1/100 of a second. It could grab all the values in, say a 1/8 or a 1/4 second, do average and display that? Although it would be tough to program out large deviances(because it doesn't know what numbers are right and wrong), but averaging would/should really smooth out the large jitter jumps that are out of wack.

It's been many years since i've coded (VB) but you could see about rounding up the numbers that's being recieved. Not sure if how many digits and decimals it's giving you on each axis, but maybe rounding up the data to the next 10, 100, 1000's digit will smooth it out as well. You don't need to be precise to the 10th of a degree, pretty much just to the degree (for display, but no one will be using it for scientific study and need to calculate vehicle angles to precise measurements.

I know some of the clinometers have settable warning tones (some dual with a warning keep and a danger zone), another idea for you if you wish you impliment that.

Keep it up tho, you're really close. I don't think I can say "keep up the good work" enough!

Just throttled back the sampling rate and that smoothed it out a lot. I will experiment a bit to find a happy medium. Too fast and it jitters, too slow and the movement gets chunky and the discs stop moving smoothly. I will also look into implementing something like a kalman filter or just some sort of averaging. Once I move it into an environment with vibrations such as in a vehicle, I am almost certain that I will have to do some filtering to prevent it from showing a reaction to vibration. I will do some research on basic kalman algorithms and see what I can come up with that will still fit in the processor program space. The arduino feeds data by whole number degree which is what the numeric read outs display. The graphical rotation has to calculated into radians because that is what Processing uses as a variable for image rotation. I think that development using Processing is perfect for this application since it was designed mainly to display sensor data graphically. The main thing eluding me at the moment is some sort of routine to calibrate from within the program. I could probably just allow adjustment of the center point variables that are currently just declared arbitrarily in the code. I've read that there is enough variance between the sensors in different Wii Nunchucks to require it to be adjustable. My idea would be to simply have an up down arrow adjustment that increments the center point variable up or down by one with each press.

Programmable warning tones were something that I had intended to install in the program as it progresses. I eventually intend to set up an xml based config file that can be adjusted via a menu for preferences and such. The buttons will drive pop up windows for setting various preferences. At least now I know that I have a solid and viable base to work with.

Thanks, and keep the comments and suggestions coming!
.........After checking into it a bit, it looks like a basic low pass filter routine will suffice. Kalman requires both an accelerometer AND a gyro. Essentially just remove the small/fast data changes.

Very nice job .I suppose that the next step is to replace the wii remote by a specific hardware ?

Originally Posted by pierrotm777

Very nice job .I suppose that the next step is to replace the wii remote by a specific hardware ?

Currently, the only hardware is an Arduino Uno and a Wii Nunchuck with the plug end cut off. The Nunchuck cable only has 4 wires that need connected to the Arduino. Since the joystick and buttons are not required, you could open up the nunchuck and remove the two small circuit boards. The board for the joystick and buttons can easily be disconnected from the accelerometer board. Mount the arduino uno and accelerometer board inside a plastic project box with a small hole to access the USB port on the arduino and you then have some pretty specific hardware to mount in your vehicle. The project box would not need to be any larger than a pack of cigarettes. Mount the box in the proper orientation on a level surface and plug the USB into a CarPC. It would then be ready to use with the inclinometer software. If an Arduino Nano was used instead, the package would only be about the size of a pack of chewing gum.

Cool project, I had one a while go (maybe 10 years) and it uses ADXL + PIC and use the serialport. After having a bit of fun with it I never really though it was that useful, well it wasnt for me anyway so I threw it away.

Why not use :
HID - much more robust than serial emulation.
Use digital output sensor, noise/interference on analog can mess with the reading.
Send the raw digital out of the sensor to the PC and do all the filtering/processing on the PC side instead.
Drop the arduino (Im biased) and use a small part PIC. There are PICs out there that doesnt require crystal. The end product would be compact, easy and cheap to make. I got to admit I havent followed the thread so I have probaby missed something.

Good luck

Originally Posted by ibf

Cool project, I had one a while go (maybe 10 years) and it uses ADXL + PIC and use the serialport. After having a bit of fun with it I never really though it was that useful, well it wasnt for me anyway so I threw it away.

Why not use :
HID - much more robust than serial emulation.
Use digital output sensor, noise/interference on analog can mess with the reading.
Send the raw digital out of the sensor to the PC and do all the filtering/processing on the PC side instead.
Drop the arduino (Im biased) and use a small part PIC. There are PICs out there that doesnt require crystal. The end product would be compact, easy and cheap to make. I got to admit I havent followed the thread so I have probaby missed something.

Good luck

I agree with all of your suggestions. For simple proof of concept, I just used what I had available. I'm testing with a few different accelerometers to compare results. The only one I had on hand besides the MPU-6050 was the one in a Wii Nunchuck. A few others are on the slow boat from China. Right now, the Arduino simply gathers sensor data and sends the raw output to the pc software where all the math conversions are done. For the final version, I will probably use either an ATiny or a PIC. Using HID would definitely be my first choice on the finished project because, as you noted, virtual serial can sometimes be a PITA. Most of the available accelerometer modules use TWI or I2C just like the nunchuck board. There is always room for improvements and enhancements with the hardware. I've only been messing around with MPU's for about a year now and I've never programmed a PIC. The software was my first attempt at programming using Processing and actually shocked the hell out myself that I managed to pull it all together as well as I have. LOL So far, I'm only about a week into the project working on it in my spare time.

Thanks for the comments and suggestions. They are always welcome!

I finally got around to gutting the nunchuck. Here is a pic of the little board that does all the good stuff. It's about the size of a quarter.



This nunchuck had a one piece board so I cut off the button/joystick half.

Ohh, nice!

Cool,
That would be cool to have the source of your project for all guys that what to build the project !
Do you this that an interface in VB.NET or C# would be possible, the goal would be to use your project with Riderunner or another FE.