PunchBot

I have been practising various Martial Arts styles for over 15 years and have always been curious about one particularly primitive part of my pugilist pastime: how hard I can punch? More than that I want to know "pound for pound' is it all about size or does the skill factor come into it? Put simply can a small guy with skill hit as hard or harder than an unskilled big guy?

This brought me to consider developing PunchBot a machine for accurately measure the power of a human punch.

I also thought this might be an interesting way to raise money for my favourite charity "Movember". After this build is complete I intend to start an online leader board and use it generate some charitable funds from a bit of health competitions between martial artists and their clubs.

Research

First I looked into using an accelerometer to measure force but soon discovered that they have a notable downside. A quick Google search showed me that humans can generate impressive forces from a punch. I initially considered the development of an accelerometer model with high G's of 120+. I soon realised that the higher the G rating the less sensitive and more "noisy" the accelerometer signal became.

I considered that a G force measurement is relative to the weight of the object being struck, so by making a punching bag heavier it reduced the accelerometer range requirements and increased sensitivity. So a punching bag could be made heavier BUT it raised the risk probability of breaking bones in the hand.

Therefore I ruled accelerometers out.

In my research I noticed there are many existing force testing pads, bags and gloves but most seem to use a scoring system, they use a number scale that is relative only to that device. As a point of differentiation (and personal principal) I wanted to create a device that has a close to scientific validity as I can get with affordably priced electronics.

My first two requirements we established: the safety of a light punching weight and repeatable accuracy.

Design

I finally decided to design a device that worked by measuring rotational force or Torque. In the top-most picture can be seen the thin black tube, which is a swing arm. The axis of the swing arm is connected to an optical rotary encoder, a device that can accurately measure angles on a shaft. 

The theory being that by knowing the Moment of Inertia (mass) of the swing arm, I can calculate its acceleration with the encoder and derive a power figure (Torque).

My future fund raising plans required some portability but with a heavy base for stability. Also the punching pad height had to be adjustable so it could be set to individuals shoulder heights.

I sketched out every aspect of this design in my notebook in the 90 minute journey to and from work. When I was happy with a design components sketch I added it to my CAD model.

Construction

The base is made out of 89mm square mild steel tube welded to 3mm plate feet. In the pictures you can see the vertical slit on the base that is used with a bicycle quick release to hold the neck very firmly in position.

All the aluminum is from capral.com.au. The neck is aluminium not steel so that it is easy to lift when adjusting the height.

With no access to a CNC I cut out everything out by hand using drill press, hack saw, files and taps. (I actually enjoy doing it by had but I wanted the CNC's accuracy.)

The neck was particularly tricky: to get some accuracy I printed out 2D plans of the neck in 1-to-1 scale and sticky taped then to the faces of the blank neck metal. By doing that I could measure and check that each sides holes were aligned before I centre punched.

Roller bearings and bolts are from hobbyparts.com.au. (fantastic product range, great service but their website needs some updating)

The white mounts for the rotary encoder were 3D printed at shapeways.com.

The 12mm axis shaft is from a defunct laser printer.

Electronics

In one picture you can see a blue shape with three spring contacts in wooden blocks. When the inter spring contact separates it tells the Arduino when to start logging data from the encoder.

The two outer springs are used to run power to a super-bright LED that sits atop the swing arm and is used for reaction-time measurements. I use spring contacts to power the LED because using wires would make the Moment Of Inertia calculations much harder or less accurate.

I will use my CAD model and super accurate scales to determine the Moment of Inertia figure of the swing arm.

The calculations are handled by an Arduino Uno which outputs the result to an LCD display. In future models I intend to upgrade to an Arduino Mega as the Uno can only count to the nearest 4 micro-seconds. This doesn't seem like much but the acceleration of an average punch lasts less than a few milliseconds, so processor speed is quite critical to accuracy.

Its painted only in primer and the pad doesn't yet have padding but after 11 months I have finally completed the prototype. I will now begin testing and writing the mathematical formulas. More on that in the Part 2.

AMEC 2012 Booth

In early 2012 R-Group was planning to attend that years AMEC Convention to drum up some new business. But with a tight budget and the desire to make a big impact we need to get a little DIY.

If you have even worked for a small-to-medium business you will know there is no room for a "that's not part of my job" attitude, everyone needs to do whatever they can to help ensure a successful job/project/task/event. 

By days I am a mild mannered computer programmer, by night I love to design and make things. R-Group asked me to put my design skills to use and construct them a show display. 

The brief:

• Big, bold, bright, attractive.
• Transportable by courier or small truck.
• Light-weight: one man manoeuvre or two man lift.
• Low cost.

Designed in Google Sketch Up.

After many sketches and discussions between myself and the boss we settled on a towering "Curved wall" design to feature large format graphics, lighting and loop video on HD TV's.

We chose this raised, curved look to create the illusion of a very large, very solid and effortlessly floating mass, we wanted it to appear looming, huge and massive. We wanted patrons to stop and say: "How did they...?"

Built, ready for paint.

Using Google Sketch-Up I designed a ribbed structure. Each wall is 2.4 wide 2.4 tall (built in two halves) an intentional choice as MDF timber came in 1.2m x2.4m sheets, this made efficient use of our cash and saved time in cutting.

To save more time and improve quality I had the curved "end" pieces CAD machined at mdfmagic.com.au. This ensured that the 3mm MDF face sat smooth and gap-less against the machined ends and, when painted white, really sold the illusion of a solid wall.

Adobe Illustrator CS3 was used to create the graphics that would later be printed in large vinyl stickers and applied to the head boards and wall.

We used 12 volt lighting behind the TV's and the head-boards to produce a nice looking halo effect. Flexible LED strip lights were fantastic for this purpose; bright and low cost.

I am terribly proud of how the display worked out, it drew great attention and was a real conversation starter. The curved walls work as designed with the few curious patrons actually walking up to touch and examine the wall!

CODlite

CODlite is the cut-Down, desktop version of Market United's proprietary production planning tool, very nerdishly title COD (Call Of Duty).

The user interface design was undertaken by myself, a break from the norm where the graphic designers dictate the user interface (UI). This was a request of mine as I hoped to illustrate the importance of considered UI design preceding graphic (aesthetic) design.

CODlite came about through need, the full COD system is cumbersome beast: simple & powerful but slow & too 'clicky'. Account and management staff consistently have 10,20,30 micro-tasks (phone calls, email, meeting) a day, the web interface was so slow to log all these tasks so they simply stopped using it.

Part of my UI planning process included consulting with the clients, in this case, my fellow employees to make sure I was buiding a tool that deliver on their business requirements. But I knew it also helped them to take an interest in the project so the up-take rate would be high.

The primary business requirement of CODlite is speed:

• A no frills UI makes identifying a viewing assigned tasks very easy. Key data is represented with an icon, helping make the 'story' of the task very easy to identify.
• Rapidy add new timesheets: selecting from hundreds of clients/projects is slow so the server side identify the user and only sends back relevant clients and projects to choose from.
• Data entry is completed without a 'submit' button, data is saved in real-time.
• Icons change to represent state: the notes icon (yellow pen) changes to show faint horizontal lines when text has been entered in the collapse-able text field.
• Shortcuts like the lb (lunch break) button help to minimise time-sheet entries.

Subway Sandwiches and User Interface Design

I have long held a personal mantra about UI design, that: "options are an excuse for poor UI design". This mantra was for a long while based only on experience and simmering hatred rather that clear rational. Most people would say they love options, but in truth it seems they don't. The proof lies in the pudding: You only have to compare MySpace and Facebook to know what I mean: In MySpace you can personalise everything... templates, colours, backgrounds, styles, sound, etc. Facebook has over 150 Million users and you couldn't change the background colour if you tried. MySpace has a reputation for being the internet equivalent of a back alley.

Subway sandwiches (stick with me here I am going somewhere with this!) I love a Subway sandwich, its tasty, health and fast. But I find myself with an irrational hatred of the stream of questions required to make a simple sandwich.

What do these two seemingly unrelated things have in common? Its Choice. Or, more accurately, too much choice. It wasn't until I saw this video (and soon: read this book) that it all became clear to me...

Barry Schwartz: The paradox of choice

3D Web-Cam Motion Tracking with Papervision

There has been a spattering of small internet projects over the years using Flash to track two dimensional movement via a web camera. What I am attempting here is tracking not only the X & Y but also the Z axis of an object via a web-cam, thus giving any user 3 dimensions of input.

When I recently discovered papervision 3D, I like many others was blow-away by it. It’s a whole new world, a gold vein of Flash development just waiting to be tapped. Its inspiring stuff... quite literally in this case because it inspired me into thinking: what this cool 3D environment needs is 3D control. My thought was simply this: Can a web cam be used to as a 3D input device?

This is the recording of my first foray into making this idea a reality, or if not a reality, a proof of concept at very least. I am glade to say that it does actually work, and that it is quite robust, working in a wide range of light conditions, colour variations and camera image qualities. Its works, but is by no means perfect, though I believe it is a good start.

Overview

So how does it work? Lets say we are creating a tennis style game, we want our user to be able to control the on-screen virtual tennis racket: up, down, left & right but also control the forward & back which allows the user to control the return hitting speed.

The user would be holding their own raquet-like object that the tracking software would be programmed to recognise. For this technique to work on as many computers around the world as possible there needs to be a consistent method of input to eliminate as many variables as possible. This is where the paddle comes in, a paper based, disc shape that is one half coloured green. The user would print it out on their home printer and hold it up to their web cam, the software is optimised to identify this colour.

The game is poised to start: the user has their paddle in hand and the software begins tracking the paddle…

The tracking is done by examining web-cams images, looking for the border edge & green area of our paddle. Obviously there can be other green object in the view of the web-cam (plants, painted walls, T-shirts), part of the process of tracking is determining and eliminating other objects that are not the paddle. To do this we looking for certain markers that differentiate our paddle from other green objects.

When a starting point for the paddle is identified the size of the paddle then needs to be determined, this is the key to extracting a Z axis. The software looks for the perimeters of the green area (see the yellow squiggles in the picture right), literally looking one pixel at a time for the green pixels that make up the boundary, stopping when it finds the first pixel again. When this is completed we now know the height, width, X & Y parameters of the target.

The process is repeated continuously. As the user moves the paddle around, towards the web-cam and away, the paddles image will scale in size, the scaling is easily converted to a Z axis for use with Papervision. In the case of our tennis game we could hit the virtual ball harder by moving the paddle closer to the web-cam which inturn moves the virtual tennis racket forward.

Details

Colour & brightness variation

The very first hurdle was how to handle the variety of lighting & colour conditions that would effect the web-cam’s image output. As well as the natural & room lighting some web-cams come with software that automatically adjusts the colour & brightness settings of the web-cam images. Essentially, the image received in Flex from the camera could have a brightness anywhere from dark to washed-out light, and any colour shade or tint.

Example: I was wearing a red t-shirt one day when developing this program and for some reason the tracker was going nuts, picking up green objects everywhere. The problem was the web-cam’s OEM software detected that the web-cam image contained too much red and overcompensate by upping the green. As a result everything in the web-cam image took on a shade for green, sending my motion tracking software crazy!

I got around these colour and brightness issues by coding a way to find what I call ‘truly green pixels’. These are pixels that are constituted mostly of green not just tinted green. As we all know pixel colour is made up of red, green & blues values. For a pixel to be considered truly green (In this application) its green value must always be greater than both its red and blue values. As a happy coincidence this ''true green'' idea also happened to be the best method for working with variable light conditions because no matter the brightness of the pixels colour, its RGB values are always relative.

For example: A very washed-out, over bright web-cam image many show the paddle as a green colour like this:

Light Green

With colour values of Red: 224, Green: 245 & Blue: 227.

A very dark poorly lit web-cam image many have a green paddle colour like this:

Dark Green

With colour values of Red: 13, Green: 39 & Blue: 23.

The software can easily recognise that they are acceptable shades of green because both have green values that are greater than their red and blue values.

This is the general idea, that actual coding uses a few more tricks to refine the process. As a result the tracking software can find the real shades of green it is looking for regardless of colour variation and light condition. In fact it will operation with a dimly lit web-cam image just as well as it operates with an almost washed-out over bright image. You could even flick a light switch on & off rapidly and the tracking will not be deterred.

Other green objects

How can a computer tell the difference between the game paddle and a plant or a green t-shirt? A lot thinking went into this one let me assure you! The key to this was to examine the texture of these objects: plants are quite detailed & layered, shirts have wrinkles. The paddle has one property that makes it unlike the others: It has a flat consistent surface & colour.

This means the paddle is likely to be the only flat area of colour in the web-cam image (unless the user has vivid green wall paint, lets just hope they don’t!). So the solution to this hurdle is a process of eliminating areas of the camera image that don''t match the profile of our paddle.

We do this by looking for lines of unbroken colour in the entire web-cam image. Start from the top left, pixel 1 is compared to pixel 2 which is compared to pixel 3, and so on. If each one is very similar in colour to the last then it is likely to be our paddle. Conversely if the colour varies too much then the area is clearly not part of our paddle.

If a short column of pixels (8 – 12) is found to be consistent in colour and brightness then area is temporarily stored to (perhaps) be used for the next step of finding the paddles perimeters.

Note: Within the code you will see these lines are referred to as blobRoots.

Limitations

Like the human brain at 3.30pm on any given work-day, some things just have their limitations. My web-cam 3D track project encountered some limitations to:

Camera Refresh Rate

My cheap (read: commonly available) camera only operates at 15 frames per second, Television runs at 25-30fps. I’m sure some cameras use a higher frame rate but I bet most don’t. All the programming for the software is designed for the most common or worst case scenario of 15fps.

Lag

The lag time is the time it takes for the camera to produce the image, have the code process it and render the result on screen. It is only about 1-15th’s of a second behind but is still enough to make the output feel out of sync & ‘washy’.

Blur

When the paddle is moved rapidly the web cam image of the paddle is blurred, making it nigh on impossible to collect the boundary line of the paddle and therefore we cannot retrieve the height and width.

What does this mean? It means fast paced games like our tennis example might be impractical and require a great deal of interpolation to make the game play enjoyable. However slower more precise games are in, game that can make the most of an immersive technique of object manipulation. What about a virtual game of the classic board game Operation? Using this system to guide virtual tweezers to pick up pieces of skeleton.

The future

The next step for me is to revisit the code used to find the perimeter of the paddle, it is a little too hit-n-miss and not very elegant, relying on many if statements & for loops. My next move may be to use the ‘lines of consistent colour’ (blobRoot’s) that identify the paddle texture and tie them together to find the mass of the paddle object, not just the boundary of it.

After I manage to do the impossible and make the tracking perfectly flawless (I will probably settle for ‘acceptably robust’) I will move onto the next level of craziness for this idea: detecting the rotation and pitch of the paddle! I should be able to find the rotation of the paddle by identifying the only straight line of green on the paddle (the main reason the paddle is a half moon shape) if the line can be discovered then I can measure the true height and width of the paddle, comparing the two should yield information about the pitch.

So a game of 3D Tennis is still best left to the Wii console but maybe you find a use for this code in your own way, if you do please be sure an let me know, I would love to see it.