Dion Moult Seriously who ever reads this description.

Motion tracking with Javascript, HTML5 and a webcam

Why would you use the web for motion tracking? Simple. HTML5 Canvas is exciting. Javascript is (pretty) cool. Combined with a lazy afternoon, we can create an ultra simple hand motion tracking and colour recognition system.

This isn’t entirely true. It doesn’t track the hand, it tracks a bright blue bottle cap I found on the floor. Even more truthful is to say that it tracks anything bright blue. But enough chat, here’s a demonstration. Just click the small button with the dash in it to get started, grab something blueish and wave it in front of your camera. It won’t be as good as we got it since we adjusted it for specific lighting conditions, but it’s enough as a proof of concept.

We’ve also got pretty pictures to show. Here’s one of the quick n’ dirty strap we used to embed the bottle cap in.

php_hand_motion_tracking

And here is one of it in action.

php_hand_motion_tracking1

You can see the (bad, hackish, thrown together) code for it in my playground repository on GitHub.

Hello SevenStrokes: Building websites … a little differently

A few months ago, Chris Paplinski, Nathan Charrois, Kaushal Inna, Andre Brokman, Kelsie Rose and I, Dion Moult, gathered to create a company. Today, we would like to present to the world: SevenStrokes.

Sevenstrokes web development

SevenStrokes is a web development company but with a few key differences.

  1. Firstly, we see websites as a service, not a product. We don’t just build a website, we treat it as part of your larger corporate strategy.
  2. We build systems that mirror your day-to-day domain issues. We use a combination of behavior-driven development and code architecture that employs the same daily language that you do. This ensures our system makes sense not just in the software world, but in real life, and thus always move a step towards achieving your corporate goals.
  3. We follow many aspects of the open-source business model, ensuring that we assign the most motivated staff that want your site to succeed just as much as you do, and that full inspection guarantees your system integrity.
  4. We push for the latest industry standards and keep on pushing, even after launch. Websites are usually short-lived, but we’re changing that with a system architecture that maximises long-term life.

So what are you waiting for? Do you need a website built? Do you need somebody to help spearhead your latest online initiative? Check out SevenStrokes: Building websites … a little differently

sevenstrokes unique web design

DraftSight: a free and cross-platform alternative to AutoCAD

Whilst Linux is an excellent system for programmers, it’s certainly a little wanting for people who deal with creative graphics. There are tools like Krita, GIMP, Inkscape, Blender and Digikam and so on to help fill this gap, but one area which isn’t talked about so often are CAD tools. As an architecture student and a Linux user, I can safely say that the options are disappointing. It certainly is possible to have a complete graphics workflow on Linux, but it’s not as good as on Windows.

There were always CAD packages around such as FreeCAD and QCAD (I believe rebranded to LibreCAD) and its various derivatives, but they were all slow and not particularly powerful. However for the past few years, I’ve enjoyed DraftSight.

DraftSight - a free and cross-platform alternative to AutoCAD

Firstly, a disclaimer: DraftSight is not open-source. It is certainly free to use and works very well on all platforms, but it is backed by a commercial company (Dassault Systemes), is financed through an enterprise license, and certainly has no obligation to the community.

However perhaps the reason DraftSight is so much more powerful than the open-source alternatives is because it has a very clear goal: it wants to clone AutoCAD. Unlike GIMP, which has tried to define a new paradigm for itself, DraftSight keeps users in a familiar environment.

If you are on Gentoo Linux, I am maintaining the DraftSight package and as of May earlier this year, it is available in the betagarden overlay. For more information, you can see this bug.

A Beaglebone, a Blender, a Board, and a Swarm.

Hardware isn’t generally my thing. When it comes to software, I like to break and create. But in my opinion, hardware should just work. But even though that’s another story altogether, it did explain my apprehension when I greeted the UPS guy one morning delivering a BeagleBone Black.

beagleboneblack

Let’s begin with the BBB. It’s a computer the size of a credit card, which isn’t that impressive if you realise that your phone is a computer. I find the best way to explain it is in terms of two other products, the Arduino and the Raspberry Pi. The Arduino is a similarly sized (comes in multiple sizes though) controller where you can upload scripts, plug in a hardware circuit (wires and lightbulb, that sort of thing), and have it control the circuit. Despite its power in hardware control, it only has a small scripting interface for you to do your programming. The Raspberry Pi is the opposite. It’s a full Linux computer (based off Debian), but does not have proper hardware controls out of the box. The BBB provides the best of both worlds: a full Linux system (Angstrom Linux, but of course you can flash your own), and a ridiculous number of IO pins to control circuits. All this awesome power at 45USD.

The next step upon receiving this wonderboard was obvious. Let’s build a swarm of robots. Along with two university friends, Lawrence Huang and Gloria Nam, we set out planning the system.

world

The base was to be constructed out of a 1200x1200mm wooden plywood board and cut it into a circle with a hole in the middle. This would be the “world” where the robot swarm would live on. This world would operate like a Lazy Susan, and would have a two depots filled with some sort of resource. One at the center, and one at the perimeter. This gave the colony a purpose: it would need to collect resources. Above the board was where we would put the computer, BBB, power supply, and cables to hook up to all the bots below.

We then had to determine the behavior and movement capabilities of the swarm. It had to act as one, but still remain separate entities. It also had to disperse to discover where the rotated resource depots were, and the swarm as a whole had a set of goals and quota limitations. Five movement types (along with the math) were worked out to allow the bots smooth and flexible movement across the terrain.

rules

The overmind was next. We would use Blender‘s very flexible boid simulator along with custom Python scripts using Blender’s Python API to simulate the swarm behavior on the computer and set swarm goals. At the same time, a real-time top-down view could be generated and displayed. Due to budget reasons, we couldn’t build the entire swarm of robots, but instead settled on building just one bot in the swarm, and having this bot track the motions of a single bot on the computer screen, but still behave as part of the full 32-robot swarm on the screen. Viewers could then see on the screen the full swarm behavior, and physically see a single bots behavior in front of them.

swarmscreenshot

The car itself was then built. It was relatively small and was barely enough to fit the two continuous-rotation servo motors that were required to power its left and right treads. It had a little tank on its top to hold resources, a depositing mechanism at its front, and dragged along a massive conveyor belt to collect resources behind it.

car

Now the fun part – calibrating the simulated swarm with the actual physical swarm behavior, and doing all the physical PWM circuits. Many sleepless nights later it was a success. Here we see the bot doing a weird parking job into the depot and collecting resources, going back to the center, and depositing it. Apologies for the lack of video.

collect

And there we have it. A swarm of robots. Did it curb my fear of hardware? Not entirely.

frontshot

For those interested in the actual system, here’s a macro overview:

system

A few extra fun things from the project:

Project success. I hope you enjoyed it too :)

In order to discuss BDD, as a blogger, I need to talk about Behat

If you’re developing a web application, especially one that uses PHP, you should know about Behat.

Behat introduces itself as “a php framework for testing your business expectations”. And it does exactly that. You write down your business expectations of the application, and it automatically tests whether or not your application achieves them.

You begin every feature description with a three liner following the form:

Feature: Foo bar
    In order to ... (achieve what goal?)
    As a ... (what target audience?)
    I need to ... (use what feature?)

This is then split up into individual scenarios of using this feature, all of which are described using natural English following the Gherkin syntax. It then uses Mink which is a browser abstraction layer to run these tests.

I’ve been enjoying Behat for quite some time now, and I’ve noticed certain tests I need to write that come up again and again which aren’t included in the default Mink definitions.

The first is to check whether or not an element is visible. These days, Javascript heavy UIs use a lot of hiding and showing, and often this is vital to the business expectations of how the website should work. These sorts of tests need a non-headless browser emulator, such as Sahi. Simply prefix your test with the line @mink:sahi, and now we can use the following definition:

    /**
     * @Then /^"([^"]*)" should be visible$/
     */
    public function shouldBeVisible($selector)
    {
        $element = $this->getSession()->getPage()->find('css', $selector);
        if (empty($element))
            throw new Exception('Element "'.$selector.'" not found');

        $display = $this->getSession()->evaluateScript(
            'jQuery("'.$selector.'").css("display")'
        );

        if ($display === 'none')
            throw new Exception('Element "'.$selector.'" is not visible');
    }

… so you can now write …

Then "div" should be visible

Worth highlighting is the ->evaluateScript() function that is being called. This means that anything you can check with JQuery can be tested. This is pretty much everything.

Another useful query is dealing with images. Modern web apps have to handle image uploading quite a bit, and often this comes with resizing or cropping (for avatars, keeping to layout widths, thumbnails). Wouldn’t it be great if you could just write…

Given I have an image with width "500" and height "400" in "/tmp/foo.png"
Then the "img" element should display "/tmp/foo.png"
And the "img" element should be "500" by "400" pixels

… and of course, now you can. All this code is included in vtemplate under the FeatureContext file.

Happy testing!

← Back in Time Back to the Future! →