Wii Remote Force Calculator

Recently, I’ve been doing a fun side project. It’s always fun when you can come up with an excuse to combine your hobbies or interests. So I came up with the idea of using a Wii remote to calculate the force of a strike on a heavy bag.


I’ve had to dredge up old memories from my college physics classes, and I’m not entirely sure what I’ve got is hundred percent accurate, but I feel with proper setup it’s pretty good. The calculation is easy enough, to get the force you just multiply the mass times the acceleration of the object. The accelerometers in the Wii remote are accurate to about +/- 3 Gs with about a ten percent range of error. Not too terrible for a fifty dollar bluetooth enable accelerometer you can pick up at any store in town. The problem is, if you try to hold it in your hand you can generate massive amounts of acceleration well above 3 Gs. So instead, I tied the remote onto a heavy bag. Much more mass, means you get the same amount of force with acceleration levels well within the remotes acceptable range.

Force = mass * acceleration

Because I’m not punching any harder, the force stays the same. The heavy bag has a lot more mass, so the acceleration has to be a lot less to equal the same force.

The thing I’m not sure of is whether I have to take into account the fact the bag is on a chain so it actually swings up in an arc. I don’t know how much that affects the calculations, but I don’t think it would be a lot with the small amount of time range we’re talking about.

My next steps are to try and rig up some testing system to try to determine the accuracy of the measurements. I also want to get the opinion of some physics people to get my calculations even more accurate. It’s been a fun project so far and I’d like to get it to the point where I could bring it into the gym and have my students play around with it a little bit.

The application itself is written in C#, using WPF, MVVM, and Wiimote Lib

I’ll try to post any updates here as they develop.

Hosting WPF in WinForms

I’ve done a lot of WPF and Silverlight, but always as standalone apps. In one project, we actually embedded Silverlight inside a WPF application using a browser control.

I’ve been firmly convinced that XAML is the way of the future for some time now. But recently I’ve gotten to see a very real, tangible benefit of hosting WPF inside a windows form application.

A lot of time businesses will want some fancy visualization or way to view their data. In Windows Forms if you want anything “cool” out of the box you’ve got one of these options: paying for a 3rd party set of controls, finding a half-baked control online at CodePlex or CodeProject, or writing it yourself.

Most of the time the project budget and plan don’t include time or money for options 1 and 3. Option 2 is Russian roulette. Sometimes you get some really cool stuff, sometimes the control you find is garbage. In WPF, it becomes almost trivial to do the sort of complex control customization that was such a pain in WinForms. At the same time, most business probably don’t want to start off by rewriting their existing app in WPF.

Using the ElementHost control and some custom WPF UserControls you can embed some very cool UI functionality with minimal effort and impact to your existing application. My WPF UserControls don’t look like “WPF”. At least not all the LOB demos you see where there are fancy transitions and gradients slapped in everywhere. But it’s blowing away the end users. The integration is seamless, it looks like WinForms, but simply using some stylish DataTemplates and the WPF TreeView we’ve improved the customers user experience ten-fold. We’re using it 3 critical places of the app where the user needed some better visualization of the data that was coming in. With WPF we could do that much faster and better with minimal impact to the rest of the application.