Laika Explorer: what it’s like to build a Raspberry Pi accessory startup

A lot of companies are building Raspberry Pi add-ons – Raspberry Pi accessory businesses have been called out by the UK’s Daily Telegraph this year as one of their top 2014 startup investments. It gives us enormous pleasure to watch people build jobs and businesses around the Raspberry Pi, and we watch the numerous companies which add to the ecosystem with great interest.

Laika Explorer was a successful Kickstarter last year, which promised a powerful robotics controller for the Pi, controlled with Scratch or Python. Last week I had mail from Andy Bakin, who has allowed us to share how he’s expanding production – and how he’s using a Raspberry Pi as part of his test rig (something we’re seeing an increasing number of factories doing; even the factory that builds Raspberry Pis tests them using a Pi now). Over to Andy!

Testing Times

I am pleased to say that the Laika Explorer is moving into its second production run: this time we are making 1000 units. This is great news but as production volumes ramp up, the efficiency of manufacturing has to increase. The first 500 units were individually inspected, programmed, and tested by hand. This took a long time and used up a fair share of my Sunday evenings when I should have been resting, sipping a glass of red and catching an episode of Breaking Bad in preparation for the week ahead. And so the need for a production tester is a priority as I move towards receiving that box of 1000 Explorers.

Now I have made quite a few production test jigs in the past when moving previous designs into manufacture. They have always been custom builds with the test program running as firmware on a bespoke PCB. This is fine if the product is stable and is not set to change much. It is also fine if you do not plan to release many new designs which will each require their own specific test equipment. The nice thing about this approach is that the test equipment can be neatly self-contained in a box, stored easily and grabbed off the shelf when needed. The problem arises when the product being tested has new functionality which needs testing and therefore requires the test jig program to be updated. Not a huge issue but it does require getting to the test jig and ‘flashing’ the new firmware to incorporate new test routines. There are concerns from a hardware point of view too as most of the test jigs I have made use a customised PCB of some kind which makes it hard to quickly put together another jig if you want to double your testing capacity.

Now, the Explorer is the first in what will be a range of products all designed to work together. Up to 32 different modules will be made, which means that I need a test set-up that can easily be replicated, updated and switched between designs depending on which one is coming off the production line. I also want to be able to get remote access to the test equipment, which will be used at the manufacturers, so I can update and add test routines from the convenience of my office and keep an eye on the pass/fail rate to quickly respond to any problems.

Let’s Get Jiggy With It!

The solution is to run the test software on a networked Raspberry Pi connected to a Laika Explorer which is housed inside a test fixture. The test fixture and test software is unique to each design as electrical connections have to be made to the PCB test points, and, of course, the test algorithm will be different for each device being tested. As the Laika uses USB it will be easy to swap the test jig hardware when a different product needs testing. The test program can very easily be selected using the software.

Probe-ably For The Best

We begin with a PCB design, in this case done in Eagle, which is used to create a .dxf file (this is an industrial format for use by CNC milling machines) containing the different layers of the board. The dxf file was then opened in a CAD program and a new layer created which would be used by the CNC machine to drill holes in a piece of 12mm MDF perfectly in line with the test points on the PCB.

Here are some of the test points on the Explorer labelled TP1, TP2 etc.

 These test points will make electrical contact with a test probe when the PCB is placed in the jig. These probes are expensive little things as they are spring loaded and gold-plated for longevity and reliability:

The Hardware

Here is the Explorer in place on the jig:

There is a bit of tidying up to do but here is what it looks like underneath:

 The wires are connected to a port expander which is then connected to the Explorer so a variety of voltages can be read and checked by the software (future Laika modules will include port expanders). The analogue inputs are connected to the motor drivers of the test jig Explorer and PWM is used to set a voltage that the ADC on the device under test must read.

I have taken the decision to program firmware on the Explorer as they come off the production line. The alternative is to have them programmed before being placed on the board but that means it is more difficult to update the firmware if I need to. After a period of time I may decide that the firmware is not going to change and move to this method of programming as it might be quicker, but for now I like the flexibility of post-production programming, and it’s pretty quick any way. To program these devices I have used an AVRDUDE connected directly to the RPi:

Controlling it all with Software

This is the best part of this project as the result is a simple graphical user interface which anyone can use to program and test a PCB. All the user has to do is click ‘RUN’ and the Python script uses the AVRDUDE to program the Explorer’s Atmel chip, and then check all functions of the device under test by reading in voltages. This was the purpose of this project: to create a ‘red light/green light’ tester which either indicates a ‘pass’ or a ‘fail’. In the case of a fail, details will be given as to the error found and the information logged for record keeping, and downloading by me remotely.

Two Explorers: One Pi

To use an Explorer to effectively test another Explorer meant I had to add some functionality to the Laika drivers so that more than one board can be plugged into the Raspberry Pi without conflict, and be independently controlled. By giving the test jig Explorer a different USB device descriptor, I was able to write software which could differentiate the two Explorers on the same USB connection. This opens up the possibility of connecting many Explorers all on the same USB.


The GUI was designed in Glade and Gtk+3 was used to interface to Python. This is a great way of creating an event driven program to control the test jig. As Laika can easily be controlled through Python, it was quite straightforward to build the test jig software.

It Came To Pass

Hopefully most of the Explorers off the production line will pass these production tests without any issues, but inevitably there will be the odd one that doesn’t for some reason. This is expected and target failure rates are typically around 1% for builds of this size. The important thing is to detect these failures and extract the problematic PCB from the batch. For low-cost designs being manufactured in millions as opposed to thousands, then testing in this way becomes far too time consuming and would probably cost more in time and labour than the product itself. In this case the production is so finely tuned that the failure rate becomes more like 0.1% and the fact that someone will occasionally receive a defective piece of electrical equipment is accepted- we’ve all been that 0.1% at some point I’m sure.


Jim Manley avatar

Thanks for making this info public, Andy and Liz – we can’t expose folks who are going to be working in the 21st Century to enough of this sort of description, as manufacturing of increasing numbers of customizable devices marches onward in many sectors. This is no longer limited to purely electronics firms as computing continues to pervade many products and services. Young people looking for employment or starting their own firms need to be keenly aware of testing and quality control, which often becomes an afterthought to business people thinking they can cut costs by just shipping as soon as fabrication is completed. Business schools need to be teaching the importance of this step as much as technically-oriented educational institutions. Of course, being an engineer of hard stuff as well as the soft variety means I believe kids should watch the “How It’s Made” series where cameras are allowed to roam factory floors to reveal the fascinating automated processes for making everyday things. Let’s see more of this here, Liz!

Mark Daniels avatar

@Jim, you have echoed my thoughts perfectly. I have been running a manufacturing company for many years and testing is probably the most important step in our process. I also think the Foundation should publish more stuff like this as it is relevant in every area of manufacturing. Andy seems to have nailed it and has written an excellent guide here for anyone wishing to production test. To aid our own testing I am currently working with a team of software developers to interface some of our test instrumentation to the Raspberry Pi which will ultimately print test reports for each machine off production. Hopefully, we will have a live demo of the software available on the web very shortly.

liz avatar

We’d love to publish more stuff like this, but it’s actually pretty unusual that companies are happy to have any of their manufacturing process revealed online; we know of many, many industrial applications that the Pi’s being used in, but we’ve not been able to write about any of them because the companies concerned don’t want to show the competition what they’re up to. Understandable, but it’s a shame!

Mark Daniels avatar

Hi Liz, I totally understand both your frustration and their reluctance when it comes to publicising this sort of stuff. Hopefully, in a few weeks time we will have a story for you to publish and software to give away. If you’d care to drop me an email, I’ll send you to a demo of the alpha version immediately.

liz avatar

I can’t guarantee we’ll publish it, but it’d be great to have a look; you can find my email address on the contacts page under the “About” tab above. Thanks!

tim Rowledge avatar

How fortuitous; I had a partly written forum post asking about this board just about to submit. Hopefully I can now pop over to the forums and find a lively discussion about what cool things it can do.

Andy Bakin avatar

Tim, I’d be pleased to answer any questions you have. The next version will have some more features I haven’t published yet.

tim Rowledge avatar

Andy, I started a forum thread (since I just ordered an Explorer board) over at

Andy Bakin avatar

There are some good comments here and the write-up seems to have struck a chord. I agree with Jim and Mark and see testing as equally important as product development. In fact, I strive to define the test algorithm first and design to a known set of test criteria: it never quite works out this way though. Personally I think that there are at least a couple of reasons why a company may not publish information on their usage of a Raspberry Pi in industrial settings. Firstly, as Liz has commented, the company may not want to reveal commercially sensitive information to the world, but once the product has been put on the market, I think that the information could be documented in such a way as to not reveal any secrets at a design level. Secondly, the company will be putting efforts into marketing, promotion and sales and will not spare any resource for writing blogs on the details of their product design unless there is an obvious benefit. Spurred on by your comments, I will contribute as much as possible to similar posts and would be happy to advise anyone wanting to make a test jig for their product.

tim Rowledge avatar

Secrecy , or at least a certain economy with the details, can be very important, but when selling a decidedly geeky widget I suspect that info like you present above might be some of the best marketing you could do.

Comments are closed