Archive for June, 2012

Arduino Wireless Motion Tracker

Monday, June 25th, 2012

We have lately been working on some projects that involves measuring and interpreting  motion with inertial sensors.  We have done experiments with iPods, iPhones and other dedicated motion trackers.

We also tried to create a tracker on our own using the Invensense MEMS mpu-6050 chip. It’s a 6 dof inertial motion sensor with an embedded tri-axis gyro and tri-axis accelerometer and some kind of motion processing unit  on it as well. Getting the data from this sensor on our iPhone took al little more than just ordering this chip so we decided to use the Sparkfun break out board version, together with the WiFly shield featuring a Roving Networks wifi unit and put them both on an Arduino Uno. It took some fiddling to get the wiflly board  into adhoc udp mode, but now we were able to connect an iOS device on the adhoc wifly network and transmit UDP messages containing sample data from the mpu-6050. Using a tweaked GLGravity example xcode project as a data visualization tool we had a nice prototype of this little system. Right now we are able to get 20 captured samples per second over the air to the iPhone but it appears that by forcing the UART of the wifi unit into an higher baud rate (and also the UART baudrate on the shield itself) could easily increase the framerate. We haven’t tested this yet though.

Arduino Wireless 6-dof Motion Tracker

Arduino Wireless 6-dof Motion Tracker

As you can see in this photo I’ve soldered the mpu-6050 breakout board just beneath the wifly shield onto the prototyping section on this shield. To keep things nice and compact. In a practical situation it might be not ideal to have the chip upside down. Beneath you can see the board in action ;-)

openCV experiments

Monday, June 25th, 2012

Since we are currently not developing any new iOS game title we have some time to experiment with other things. Amongst others openCV on iPhone platform.

Because of the current ongoing EK soccer tournament we had our focus on football. More specifically tracking speed of a football. The concept is as follows:

Shoot a short video from somebody kicking a football (on a soccerfield), camera standing as perpendicular as possible to the assumed trajectory of the ball.

Then, based on the size of the ball in the videofootage as detected by openCV and the traveled ball distance from 2 frames in the video (recorded at a known time difference) in pixels. These pixel sizes recalculated to real life dimensions based on the known size of a typical football gives you the ballspeed. in kilometers/hour.

In theory this all sounds ok, but then we still have some practical issues to solve. First of all it turned out out that kicking the ball at fast speed (what real soccer players would do), skewed the ball enormously.

Skewed ball as caused by rolling shutter phenomenon

Skewed ball as caused by rolling shutter phenomenon

Here you can see some of the ball skewing

Here you can see some of the ball skewing. openCV "sees" the b/w filtered image

This is caused by rolling shutter artifacts see wikipedia. iPhone camera images are captured from top to bottom (landscape) line by line and not the whole frame at once. Because of this, a fast moving object will become skewed. openCV will not detect a circle when the circle is really skewed, so that’s the first problem.

Also when in low light situations, motion blurring, because of longer exposure times becomes an issue. The latest iPhone 4S support 1280×720 @60 fps which is the best bet when capping these frames. But even then motion blur can become an issue. Also ball detection is done based on the greenness of the grass. If your whitebalance is much to blue the conversion to black and white in opencv would fail. Of course you could adjust the tolerance for the detected hues but then you’re likely to run into many false positives for ball detections.

Much of these things/issues could have been fixed with some user input (let user select the correct ball, let user adjust filters for openCV based on some kind of wizard), but all in all it was a nice experiment but not good enough to make it into a proper dummy proof app. We basically didn’t want to make an app that expects all kinds of clever input from the user. We wanted the app to do some clever stuff and return you the speed of the ball without too much hassle.

opencv ball detection on the grass

opencv ball detection on the grass