Sunday, September 27, 2015

Stamp sorter part 2

I spoke with friend about whether he'd be willing to purchase the hardware for himself and I would program it. My payment would be keeping ownership of the software. He thinks it's a good idea.

However he suggested that I get the image recognition software working first before purchasing the robot arm. No unnecessary expense if software is not feasible. I think that's a good idea.

So I'll order a BeagleBone Green and camera module and see what we can do.

Interestingly for me this device is just what I want for my Threesus robot.

Saturday, September 26, 2015

Another possible gadget to make some money.

A friend makes a few dollars by buying large quantities of stamped envelopes, soaking the stamps off and selling the used stamps to stamp collectors for various prices depending on the quality of the stamps.

However, before selling the used stamps, he culls through the batch, looking for uncancelled stamps which can be used as mint originals. He is able to sell bundles of these uncancelled stamps for half their face value to small businesses wishing to save money on their mailing costs. Small businesses, small batches, small numbers all round.

So we need a (one-off!) device to do the following:

  1. Scan the stamp
  2. Identify which stamp it is by comparison with a catalog of current issues
  3. Compare how close the image is to a mint image
  4. Put the stamp in some sort of "uncancelled" bin, ready for re-use.
Equipment needed:

  1. Raspberry Pi 2 (or BeagleBoneGreen) with camera module
  2. A pick and place arm with vacuum head to
    1. lift a stamp from an unordered pile
    2. rotate the stamp to a normalised position
    3. hold stamp in front of camera
    4. place stamp in "used" or "unused" bin depending on id
Robot arm is available as a kit already although it might be interesting to make my own with my new laser cutter. All the rest is software.

Friday, September 25, 2015

Making a gadget factory.

I've been overwhelmed by illness for the past few months. Nausea, fatigue, confuddled thoughts. Basically a write-off.

My friend Marty has been in a similar situation after coming off his motor bike. He however seems to be healing much faster than I and is madly thinking up gadgets he and I can design and assemble.

I've wanted to put together a gadget factory for a while now. It's hard to justify the cost of some of the tools you need to assemble gadgets these days. They're heaps cheaper than when I was starting out as a gadget maker in the '70s but it's still a lot of money for me now that I'm attempting to live on my pension. So it occurred to me that if we could actually sell some of these gadgets it might make the factory a bit better than a sinkhole into which I pour my dollars.

To add to the impetus to start a business is the weakening Australian dollar. Makes the gadgets even cheaper to US and EU customers. And I also discovered another effect of the weak dollar. Some Australian Ebay sellers have purchased stock from China in USD. It literally halves the price of one expensive tool I was looking at.

So some gadgets we've been toying with.

  1. Marty thinks an automatic "fall over" light for bikes would be useful. Simple, easy to design and build, a ready market among his bikie friends.
  2. Elevator music player + WiFi repeater. Repeaters are dirt cheap but if you could add a web site to the repeater which replays non-repeating, synthesised guitar music, every office can plug one in and switch people to the music site when they are on hold. No music royalties, no maintenance to change DVDs etc
  3. Credit-card-sized tin with accelerometers to act as an effect pedal. Ultra-low powered circuit (3xAAAs for a year). Basic effects by default, programmable over WiFi and/or BLE (use Apple Watch as control unit).
  4. Simplified iPhone and/or AW app to control RGB LED strips.

Perl Threesus works but not well enough.

As expected I've not been able to speed up my Perl5(or 6) version of Threesus AI to compete with the C# version. It's possible I could attempt to optimise every line of code but I really don't want to waste the time.

I think I will wait for a more usable version of

Tuesday, July 14, 2015

Coding a C# version of Threesus AI into Perl5

I mentioned back in March one of my "big" projects was to convert the Threesus AI from C# to Perl5. Many reasons for this other than sheer stupidity :). I know Perl5 well and can think in Perl. I don't know C# and I have no idea if some C# code is brilliant or simply a mistake.

Another reason is that Perl5 is much more portable than C#, which is largely Win-based. Another reason  is that RPerl  is starting to be usable but requires that I use 'vanilla' Perl. (Actually my code tends to be pretty plain. perltidy doesn't complain much :)


So my first attempt involved modelling all the C# classes with roughly equivalent Moo classes. I'm keeping the code in a Github repo, Games-Threesus.

vec vs bits

I quickly decided that all the C# bit-wrangling was not for me so I started using an unknown (to me) Perl operator called vec. It allows me to code a 4x4 Threes! board into an 8-byte string (16 cells requiring 4 bits to encode its value = 64 bits) but each nibble is individually addressable. Turns out we only need 16 values to describe each card/cell which fits into 4 bits nicely.


Well I knew it was going to be slow. The C# code compiles down to very efficient binary code and also takes advantage of multi-CPUs if they are present. The Perl code is big and slow. The recursive calling of the major methods adds hugely to the memory consumption.

First move!

Despite all the huge overhead involved it actually gave me a move command ('SWIPE Up') in a reasonable time. But at this stage there are so many warnings and error messages that I don't know if it worked or not. Single-stepping through the code allowed me to verify that the game simulation is accurate.

Time to rip out the plumbing

I used Moo to model the C# classes because I have a basic knowledge of its use. However it became apparent while single-stepping the code that I don't have enough knowledge of Moo's internals and I wasn't able to follow large swathes of Moo utility code. 

However when I stand back a bit and look at what I'm using Moo classes and methods for, it's not actually very much and the down side is a lot of overhead code which I don't understand. With an eye to RPerl, replacing Moo with 'bless'ed objects will allow me to pinpoint bottlenecks quicker.

Also, I realised I've been using 'constant' for no good reason. Simply using upper-case names is all I really need for the constants in this code.

Wednesday, April 1, 2015

Practically everything that could go wrong with my RigidBot 3D printer went wrong.

After replacing the main circuit board with a RUMBA to no effect, replacing the extruder motor to no effect, replacing the extruder flat cable to no effect and burning filament dregs out of the extruder nozzle to no effect, I happened to notice a small electrical flash in the connector from the extruder motor to the circuit board socket.

So I chopped off the extruder motor socket and soldered on individual sockets for each of the four wires. Finally, at last, I got a proper response out of the extruder motor. So I ran tests for a few hours and it all seemed to be OK and then the extruder stopped for no obvious reason.

Well the only piece in the whole extrusion chain that I hadn't replaced or repaired was the teflon tube in the filament pre-heater. And sure enough when I extracted it I found it had partially melted to partially fill the filament hole, making proper extrusion impossible. A bit of creative gouging with a small drill bit restored the hole sufficiently to allow filament to pass through.

And finally, after more hours of testing, I have a working 3D printer. I put all the original parts back in and it still worked :).

So I've started trying to catch up on my backlog of needed enclosures. Obviously I don't need a special enclosure for a RUMBA board because I've put the original board back into the enclosure already supplied.

I tried making an enclosure for my Parallella. This required me to re-construct the SolidWorks example on Thingiverse here into a parametric model I could change to suit my requirements, specifically I only had a 40mm x 40mm fan and I wanted to continue using the existing 5V power socket.

Yak-shaving to make a 3D model

I wondered if OpenSCAD was the quickest and easiest open source 3D modelling program. I wasn't prepared to pay the SolidWorks licence fee considering how infrequently I would be likely to use it. I looked at FreeCAD and it seems an interesting parametric design program. Then quite fortuitously I found SolveSpace which has only recently been made open-source but seems much more powerful and capable than FreeCAD. And there is a Mac OS X version as well. The trouble was, for the simple box enclosures I want to make OpenSCAD simply makes better sense to me. I suppose it appeals to my programmer background.

Plan B

In the meantime, I ordered an enclosure and cooling fan for the Parallella from Ground Electronics just in case I found making a usable enclosure too tedious or too difficult. The Plan B case arrived today and although I was very close to a working enclosure, I couldn't get the correct screws so it seemed easier to use this enclosure and get on with other things.

Tuesday, March 3, 2015

RigidBot projects

The list of 3D printed artefacts I need is growing longer each week. In no particular order:

  1. If I decide to continue with the RUMBA controller board, I will need an enclosure for it.
  2. I need an enclosure for the Parallella which will hold the fan over the Zynq chip.
  3. I want a translucent enclosure for the CharlieCube I made late last year.
  4. My "grand project" is a Perl 6 implementation of the Threesus project. The original project has a video camera watching an iPad screen, OCRing the image it sees, deciding the best next move then activating one of two stepper motors to swipe the iPad screen up or down, left or right. Not sure if I want to get to the stage of using the stepper motors (although I have a couple in my spares box). I want to use my Raspberry Pi with camera module for the video processing, so I would like to build an enclosure to hold the RPi and camera in a config which makes it usable for OCRing an iPad (or iPhone).
  5. An enclosure for a reflow oven controller.
  6. An enclosure for a coffee bean roaster controller I am designing for an Elektor competition.