Monday 29 July 2013

Farnell Wi-Fi WiFly modules

Well, Farnell have done it again. We can't help but be impressed, at Nerd Towers, about their fantastic customer service. We've just spent a week of evenings working on a high-speed audio-to-data device (ok, a cheapskate's modem) to get data into iPhones and Android phones/tablets. While the proof-of-concept worked (on a laptop and a Galaxy tablet) it wasn't consistent enough when used on different devices: presumably different devices have different microphones, and different noise-cancelling circuitry (if any) and behave differently, when you're working on an individual sound sample level.

So we gave up on trying to come up with a one-solution-fits-all device, although learned a massive amount about audio sampling, data rates and Manchester encoding along the way.

What has this got to do with Farnell? Well, after chatting online about the failure-that-was-almost-a-success, someone suggested using wi-fi. All phones and tablets these days seem to come with wifi: in fact, even with a working audio-to-data routine, the host device would still need to access the internet to share data around - so why not just make a board game controller device that uses native wi-fi?

It was almost 8pm when I found these little things:

Just the ticket!
Except on further inspection of my confirmation email, I realised I'd just bought a couple of  FTDI chips on breakout boards, with some buttons - not actual wi-fi modules (as was shown in the picture). £13 for a wi-fi development platform did seem a bit cheap......

So then, some time after 8pm, I ordered a couple of these:

It's the wi-fi drop-in module for the development/test board I'd just bought. At £18 a module it was still a reasonable price (although with the dev board on top, a rather hefty £31+VAT each - though still cheaper than the older, out-dated Arduino wifi shield)

At about 10pm I got an email from Farnell to say that stock had been allocated to my order.
Nothing to get excited about - after all, it's not like they were going to turn up the next day....

.... at 4pm a courier knocked on the door and handed over a parcel, with the familiar blue and orange squiggly logo on it.

About 18 hours between ordering and receiving the wi-fi boards - and from an order placed after 8pm at night. I couldn't believe the effort these guys go to, all day, every day. Farnell, you rock!

Friday 26 July 2013

BuildBrighton night of all nights

Something peculiar happened last night.
Maybe it was the breaking of the weather, or that with fewer people turning up it was easier to concentrate - but at BuildBrighton, the place where nerds go to drink tea, eat pizza and talk rubbish on a Thursday night, things started happening.

What was particularly unusual was that, completely independently, four or five projects all hit a success-milestone at around the same time.

CNCPaul and Scropp have been working for a while on a servo-motor controller board. Paul had a massive character LCD display which had been giving him grief for a few days and he couldn't get it to display anything onscreen.

Justin was soldering and debugging an AVR programmer, and hadn't yet got it to talk to a PC over USB.

James and Sam were fighting with the red laser cutter, which had recently started to baulk at complex cutting patterns with more than just a few simple shapes.

And we had successfully managed to create a wifi hotspot using some RN-171 modules from Farnell after spending hours trying to work out how to upgrade the firmware, without being able to connect to the (sometimes flaky) BuildBrighton internet connection.

And all this happened before the usual "witching hour" deadline of midnight. Instead of taking a break and going for a walk to clear heads and re-consider where things were going wrong, last night we broke for pizza at about 10.30pm with a list of things, all ticked-off!

It was definitely a date for the diary. The day stuff actually got done.
Maybe we'll have an anniversary celebration next 25th July.

Steve's new mug. Anyone found using it in future is likely to find a cup of tea tipped over them!

Tuesday 16 July 2013

PICKit2 not working on Windows 8? You need to disable driving signature enforcement!

The title pretty much says it all - but after getting a shiny new, touchscreen laptop with Windows 8 (which - unlike most geeky critics, we think is ace) there were a few things that just stopped working.

The most noticeable (at the time) was all our earlier USB based devices, simply no longer worked. Perhaps it was something to do with the USB stack that comes with Oshonsoft? So we tried a couple of other (branded) USB devices and they all worked fine. Except last night, we couldn't get our PICKit2 clone working...

The device was actually recognised when plugged in, but it didn't want to recognise any PIC we put onto the ICSP programming header. It would light an LED, but after much head-scratching, we tested the voltage output from the PICKit2 and instead of 5v, we were only getting about 1.7v
At first we suspected a dodgy programmer - though luckily we've always got a spare one or two knocking around - but it turns out that all our PICKit2 clones were similarly affected.

After a bit of poking around on the 'net we found the answer:
Windows8 requires all drivers to be digitally signed - and cripples any device not using a signed driver (even though, when investigating in Device Manager, Windows reported the programmer as a generic USB input device, and said it was using the Microsoft-supplied generic HID device driver!)

Anyway, this short video explains how to disable driver signature enforcement in Windows 8 quite nicely. We followed these steps, then re-installed the PICKit2 software

After writing a quick blink-LED program in Oshonsoft, we dumped the hex file onto our PIC chip:

Success! We're back in business.
There are many reports of people online who've had problems getting their microcontroller based homebrew projects working and ended up dual-booted into XP, or running a different computer with Windows7 on it. But if you've having problems getting your PIC or Arduino based projects to work, try giving this a go before doing something more drastic - it might just work for you too!

Monday 15 July 2013

Implementing line of sight (LOS) in Flash/AS3 using bitmaps - bitmapHitTest anyone?

We've already had a few questions about our AS3-based line of sight routine and how it was done.
Because we're working in Flash, the immediate temptation was to draw a line between our two playing pieces as a movieclip, then use hitTest to see if there was any overlap.

As most Flash programmers already know, the problem with this approach is that hitTest only works on bounding rectangles, not shapes within the movieclips. So we'd end up with some "false positives".

the diagram above shows a hitTest is detected, even though it can be seen that the line of sight does not pass through the obstacle.

Luckily, AS3 has a way of doing pixel-perfect collision detection and there are examples of how to use it all over the interwebs. It's a function of the BitmapData object, and it's called.... erm....hitTest.

But bitmap-based hit-testing takes two bitmaps and compares every pixel in both images together, looking for a transparency value above (or below) a specific threshold. When you're comparing bitmaps that have been rotated things can get a bit tricky, and you have to apply transformation matrices and the like, but the basic idea is that where the transparency of one bitmap is not matched by a transparent area in the second image, there's a collision. This is how Flash can perform pixel-perfect collision detection.

It's a great, easy-to-use function. But it's not without it's problems.
Firstly, it's a function that uses a lot of computing power, every time it's called. Imagine comparing two relatively small 100x100 pixel images: behind the scenes, that's 10,000 pixels to test the transparency threshold of. You don't want to be doing that too often! And that's just on a couple of small images - our playing surface could easily fill the screen (and more) when six or eight board modules are connected together.

What we need is something like BitmapData.hitTest, but without chewing through so many cpu cycles.
Here's what we came up with.

Firstly, the line of sight movieclip and the obstacles movieclips are put on their own "layers" (contained within different movieclips at stage level). This allows us to take a snapshot of just a section of each layer and dump it into a bitmapData object. So starting with the top-left-most playing piece and extending only as far as the bottom-right-most playing piece, we grab a bitmap of the obstacle layer between these two points

in this example, we've drawn the contents of the captured bitmapdata objects to the screen so we can see what we're working with - in the final version these won't be displayed

Now we've got two portions of bitmaps which are substantially smaller than the playing surface. Time to use the bitmapData.hitTest function right?

Wrong. See, when we're capturing the data between two points on the playing surface, the line of sight always cuts through the bitmap from one corner at the top to the opposite corner on the bottom (in our case, above, we're going top-left to bottom-right, but it's just as possible that the LOS goes bottom-left to top-right).

Now if we know that our line of sight always bisects the bitmap along it's diagonal, we need only to check the points along the diagonal too. In fact, since we know that a playing piece is displayed onscreen by an object about 14 pixels square, we can even do this check along the diagonal in steps of 10 or 12 pixels.

Here's an example of reading a line-of-sight bitmap that passes through an obstacle:

We test the bitmap at 0,0 (the starting point of the line of sight) then at (10,4) and at (20,8) we can see that the line of sight hits a grey pixel (part of an obstacle). Suddenly, instead of comparing tens or hundreds of thousands of pixels, we've detected a collision after reading just three pixels in our image!
In a worst case (best case?) scenario, there is no obstacle and the line of  sight test requires 10 pixels to be compared before reaching the end of the green line.

Now all this wouldn't normally be an issue, and normally we'd recommend just using whichever method you're comfortable with. After all,  using bitmapData.hitTest is just a single line of code - it's easy enough to use.

But we're planning on compiling our code for tablets and smartphones - battery powered devices. And every extra cpu clock drains that battery, so the less work we put on the processor, the happier everyone will be. We're quite happy with our line-of-sight method. It's quick, it uses far few cycles that bitmap.hitTest, and most importantly of all, it works!

Software for a digital board game

It's been almost twelve months or more since we did anything of note with it, but we're rather getting to like our old friend Flash again, these days.

A few years back, it looked like everyone had turned their back on the old Macromedia/Adobe offering, after Apple arrogantly refused to support the Flash player. So all the cool kids flocked to HTML5 and web-apps, and Flash was left with an uncertain future.

But thanks in no small part to Steve from BuildBrighton still championing Flash, as well as their rather reasonable pricing structure for firstly FlashCS6 and then FlashCC (just £17/month) Flash is looking like a decent offering. The real selling point, of course, is that the new AIR runtime allows you to compile the same project down to PC, iOS and Android at the push of a button! So there's no need to struggle with stupid DOM structures, incompatible browser versions and clunky javascript - Flash is BACK!!

And because we're planning to make our modular board game work on as many platforms as possible, what better development environment to make cool-looking software (Flash still does amazing time-line based animations) that can run on PC, Apple, iOS and Android. With the correct AIR runtime, it can even run on Linux and SmartTVs!

So we're off and running, making a simple data-driven app to track our board game pieces as they move around the different segments of the playing area. So far we've managed to implement:

Snap-to-fit board sections which automatically snap to the edges of previously placed boards. As each board needs to be uniquely identified, each one will be programmed with a serial number into eeprom. This same number will be printed onto the board so after placing each board on screen, the user can tell the software the serial number used by each module.

We've also got a simple obstacle generator - used for wargames and the like, were buildings and other structures are placed on the playing surface. So far, we've got primitives like circles/ellipses and rectangles. More complex shapes can be created by overlapping two or more shapes

And we've managed to make the whole playing surface moveable and scrollable, using home-made pinch gestures, so the same code can be compiled down for smartphones and other, small-screen devices and still be useable (Flash's inbuilt gesture libraries can be a bit "laggy" in detecting a two fingered gesture. Not that kind, idiot).

All communication with the board is through an extremely simple interface. The board game will simply report the changes in state of any square on the board, by reporting the serial number of the board piece, followed by the square number (and whether a piece has been lifted off, or put down onto, the board).

When a piece is put down into an empty square, a new playing piece appears on the board. In the final version of the software, we'll probably have some kind of character selection screen, to inform the software of the type of playing piece being put down. For now, we just generate a generic character.

Pieces are placed by providing the board id and square number and clicking the appropriate button to say whether the piece is being picked up, or put down, replicating the way the hardware will work.

We've got basic line of sight working between two or more pieces, including the ability for one character to "sneak up" on another. Each playing piece has a "field of vision" of 180 degrees (this can be made variable for different character types). Not only does there need to be a straight line between the two pieces, but the direction that a piece is facing is also important as to whether or not it can see other pieces on the board

And all this means that we need to be able to turn playing pieces around. This can be achieved by sending a specific serial-based message (more on this later) but the software will also track from which direction a piece has come, and update the facing automatically:

And of course, no line of sight routine is complete without a few obstacles:

In the main, getting this far in just a few days has been pretty satisfying. It's great to be coding in Flash/AS3 again, and it's even better to see such positive results, so quickly. At some point, we're going to have to get some help making it look impressive, but functionally, the software does everything we wanted it to.

The next step is to keep a track of which playing pieces have been "seen" at the start of each turn, and only reveal the opposing player's pieces once they come into your line of sight. Then onto the juicy stuff that makes a tabletop war game - shooting things!

Thursday 4 July 2013

Preparing Inkscape files for laser cutting

We were quite excited, the other day, to see the laser cutter at BuildBrighton up and running again after a period of inactivity. We love our LS3020 laser cutter and although it's not the best software in the world, NewlyDraw does a half decent job of controlling it. We also quite like Inkscape - so were quite surprised when Adam said he was having problems getting his image to cut out properly on the laser cutter.

One of the reasons we like Inkscape is that it opens a vast array of different file types - and can export to a variety of file formats too; including .dxf (which NewlyDraw likes).

We use ExpressPCB to create PCB layouts, and often print to a pdf file using the virtual printer CutePDF. Inkscape loves PDF files and consistently opens them correctly - so with a bit of tweaking inbetween, it's perfectly possible to get any image, from a PDF, into .dxf format for laser cutting (or even CNC routing).

But there are a few gotchas - and it looks like Adam has hit one (or more) of these.
A quick look at his artwork revealed the problem:

Firstly, his image doesn't look like just an outline or a filled shape. It's on a grey background but there are bits of white in the image too.

When selecting the image, rather than appear as a number of separate shapes, it's just one big "group" of objects. So the first thing to do is keep ungrouping until we have more than one shape/object on the screen (and selecting and ungrouping each of these if necessary)

Our suspicions were confirmed when, after ungrouping everything, we moved the main shape slightly and revealed another shape underneath - it's no wonder Adam was having problems getting this to import into NewlyDraw for cutting, correctly.

So we got rid of all but the required shape then made sure this was ready for cutting. Remembering that our laser cutter is going to follow the path around the outside of all shapes, it is often easier to view the image with just the "stroke" set to a solid colour, and no fill - this will show up any potential problems that may otherwise be masked by a dark background. We swapped the fill and stroke settings, so that the shape had an outline but no fill:

Ta-da! The resulting image shows the path that the laser cutter is going to follow in order to cut out the shape(s)

In this particular instance, all the shapes were already defined as "paths" in the image. While most CNCs and laser cutters can deal with rudimentary shapes like rectangles, arcs and circles, it's often best to force all shapes in an image to be a "path" type (rather than a "shape" or "object" type). To do this, select all the shape(s) in the image, then Menu - Path - Objects to Path.

Lastly, save the image as .dxf (avoiding splines if possible - not all CNC/laser drivers handle these properly) and it's ready to import into NewlyDraw.

Hope this helps, Adam!

Hardware Meetup in Brighton

I went to the first (hopefully of many) Hardware Meetups in Brighton last night. It was both an interesting, but - sadly - slightly demoralising evening. There were four speakers and the evening was billed as follows:
If you're interested in the future of manufacturing, being a pro or semi-pro maker, and making a living, by making what you love ... join us for the first Hardware Startup event in Brighton.

BuildBrighton's own Jason Hotchkiss was one of the speakers, explaining how he has taken the step from working full-time to becoming self-employed by selling electronics kits online.

Also speaking was Alice Taylor, inventor behind the Makie Lab and dolls

... as well as Andy Huntington of BERG, talking about his miniature thermal printer called LittlePrinter

... and David Stoughton, a digital futures consultant and advisor.
David inspired us with news that the micro-business (one-man bands and groups of three or four people) was the fastest growing sector in the UK economy. Digital products have the most potential over the coming years. But then, rather peculiarly at a meeting aimed at hardware makers, he went on to say that purely digital (ie software) based businesses were better placed to thrive, grow and become "scaleable" and this was were the opportunity for business lies.

The other three people who actually make stuff had interesting stories and were all local start-ups, on the face of it. But they all had something in common, each to a lesser or greater degree - and that was outsourcing the actual manufacturing.

Jason does the least of the three - getting PCBs made in China for a fraction of the cost of having them made locally (by a UK-based company - though not as cheaply as printing and etching them at the local hackspace!). He sources all the components online (although these too most likely originate from the Far East, such is the nature of the electronics supply chain) but actually puts in the assembly work himself. Having sourced the components for his products, he doesn't use cheap overseas labour for assembly and manufacture - he's in there, rolling up his sleeves and doing the manual work to actually produce a product for someone to buy.

What's nice about Jason's business is that it acts like a small-scale start up: that's not a bad thing - quite the opposite in fact - in that he sources materials, makes something himself (with his own hands, assembling and packaging his electronics kits) and sells a product for a profit. The perfect "classic" business process!

Andy started out telling us about his miniature thermal printer, LittlePrinter: a high-end product that users either love or hate. For those who hate it, they would never be converted to customers; but those who love it are quite prepared to pay a high-end premium for one of his little printers. He mentioned a retail price of about £200. It seemed a little steep for what the final product actually does, but his customers are prepared to pay this premium. His first production run was "only" 1,000 units - so each customer was buying into a limited edition product too.

But this is where it started to get a little bit depressing.
Because Andy then showed us photos and slides of  his visit to China, to see the tools being made and the factory set-up. He explained about the £15k cost of getting a 650kg lump of aluminium formed into a mould for injection moulding and about the repeated iterations of production, as the factory kept changing the spec and finish of the prototype before they could go into production. It was a bleakly familiar story to everyone who has had products manufactured in China - you give them one thing and a whole set of plans, they agree to make it, and what comes back is completely different.

The short version of his tale is that they successfully sold all 1,000 units, learned a lot about manufacturing along the way and made a few quid to boot.

But Andy's story sounded like it was more about the learning experience of dealing with a factory in China - not actually getting a product manufactured and out on the shelf. Because the final cost of producing each little printer was somewhere in the region of about £100 (and that's why they had to sell at a premium price of £200).

And all the while, I was thinking that the finished product is still an injection moulded bit of plastic with some clever electronics inside it.

What an amazing product could have been manufactured, locally, for £100?
With an order book of 1,000 units, they could probably have employed the services of a few local artisan cabinet makers, and used really good quality materials - had a hand-polished finish, exotic looking materials, customised each individual printer.... the end product could have been so much more exciting.
Even if the thing had cost £150 to manufacture, is £200 a price-break point?
Would someone willing to pay £200 for effectively a high-end novelty item suddenly baulk at £250? Why was the default option to go to the Far East first? (Andy had the electronics made in somewhere like Singapore - and more electronics companies are finding that even China is not the cheapest place on the planet to get things hand-assembled).

But when the alternatives to manufacturing overseas are considered, it's the loss of skills and opportunities back home that are most depressing. Firstly, and most obviously, is the lack of work - outsourcing manufacturing means fewer people need to be employed locally. But worse than this, is the lack of opportunity: the inability to pass on skills and ideas to the next generation, because our current crop of artisans and skilled people aren't getting the work to enable them to teach their skills to anyone else.

If these printers were made in the UK, someone assembling these printers would have had an opportunity to learn new skills - to be introduced to electronics and even just soldering; to learn that when something doesn't work as expected, it can be debugged and fixed. People making the enclosures could teach either hand-crafts (if it were made from a natural material, such as wood) or more technical skills, like how to use a cnc/laser/3d printer to the next generation of micro-business entrepreneurs.

While I'm sure the whole process was very exciting for Andy and his friends, I can't help but feel that they missed a trick - for such a niche product, at such a high retail price, having a (let's be honest about it) cheap bit of injection moulded plastic as an enclosure seems like a missed opportunity.

Alice told us all about the dolls and how their business had exploded from just an idea 12 months ago, to being on the verge of featuring in major toy stores across the UK, and even opening her own retail outlet in London.
The original idea was a website where people could design their own fully-articulated dolls, and they would be 3d-printed and sent within a few weeks.

So far, so good. These dolls, too, are sold for a premium price (about £60) because the cost of production was so high (about £45 per doll) and each took a long time to print.
Alice explained how she won a grant from the local bank and had to match the funding of £100,000 (which they managed) and bought a super, top-of-the-range 3d printer. It sounded like the perfect example of how to start up a business in the hardware/technology sector.

But then talk turned to scaleability, growing the business and investment funding.
Alice admitted that this is very difficult to achieve - but with a lot of determination, and a few lucky breaks, is possible. To date, Makies has received three rounds of funding, to grow very quickly. Little was discussed about what this has done to the company, what is needed to pay it back, how the business could have grown without this investment etc.
Then there was talk of having pre-made body parts for the dolls, which - once again - means going to China, getting tools made, injection moulded parts and so on.....

The talk was great for people aspiring to set up and run massive globally competing companies. It was quite inspiring to see what other people have managed to achieve from a design on the back of a fag packet, to a professionally manufactured retail product at the end of it.

But two of the three gave the impression that at the core of the business was money. As stupid as this sounds (since businesses need to make money to survive) it would be easy to leave the meeting with the idea that without a massive cash injection, and access to overseas manufacturing, hardware start up projects would struggle to get off the ground. And this seemed rather "old-school" for a meetup group to discuss the future of business in general, in hardware specifically, and how recent technological advances can be used to aid businesses. For all the talk of factories, manufacturing, capital investment and all that, there was only one person who addressed how to actually get a (hardware/tech) business up and running, in a way that is available to all.

For me, the most inspirational speaker of the evening was Jason.
He said that he took and idea, spent $20 on getting some PCBs made up and got ten orders in for his product. For an initial outlay of about £50 he made and sold his first batch of products, which gave him the money to buy components for more kits. He made the whole process accessible - at the end of his presentation, you genuinely believed that this was possible for anyone with even the most meagre of start-up funds. Of course, he's not living the lavish lifestyle, flying over to the other side of the world, nor (I'm sure he won't mind me saying) making a fortune from his business. But he's got the basics in place - he bought something, added some value, and sold it at a profit.

He's making stuff with his hands - not outsourcing it (all) and in return, has kept his start-up costs low enough for his model to be copied by anyone with a bit of know-how and inclination. I think that this model - rather than the VC/investor funding route - is the way that businesses of the future should - and will - thrive.

Just as every corner shop can't (and probably shouldn't) aspire to be the next Tesco's, sometimes there's a lot to be said for filling a niche, serving a relatively small community (whether in interest or locality) and just making a living. In the UK, we used to be called a nation of shopkeepers. Maybe sometime soon, with Tindie, eBay and etsy, we will be again?