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.

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.

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 RPerl.org.

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 :)

Moo

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.

Slowwwww

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.

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.

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.

RigidBot repairs

The sharp-witted amongst us will have noted in my previous blog that I had found the cause of all the problems with the RigidBot, but I didn't recognise it even while I was writing about it.

The open-circuit on pin 1 of the extruder flat cable is a sufficient explanation of all the problems the printer showed. I simply didn't follow an orderly chain of testing the components and cables to isolate the cable.

Anyway I've ordered some replacement cable and connectors and I will now have to wait the three or four weeks it takes will they arrive.

My hypothesis is that I will be able to return the original main board to the printer, replace the faulty cable and everything will work correctly. And if it doesn't, I now have so many replacement parts that I can replace nearly all of the fragile parts of the printer to keep it running.

RigidBot tale of woe

My pretty RigidBot(RB) was churning out pretty and occasionally useful things for a few weeks after it arrived in October. I made every mistake there is to make with the RB until I finally got it printing reasonably accurate and repeatable things. I even ordered some "crystal" ABS filament with the intention of putting a translucent cover over the CharlieCube.

Then last December the extruder died. I'm not sure if I was the cause. I had accidentally put a knot in the filament and left the printer running overnight. So it spent about 12 hours pulling the same section of filament.

Initially I thought one of the coils in the stepper motor had burnt out or partially degraded. So I ordered a replacement motor and went on to other things. But the motor I'd ordered was the wrong one and it required a higher current. So I ordered another one. But this one didn't have the flat on the shaft. D'oh!

In the meantime I tried swapping motors around and eventually realised it was the driver that was faulty, not the motor.

Pity that the RB main board is an all-in-one board. Apparently it was done to "save money". But according to the RB wiki, Invent-A-Part (IAP) had to re-work every single board because the Chinese supplier had cheated on a whole swag of parts (without mentioning it to IAP of course) and the boards were dying all over the place. So much for saving money.

A few hundred RB owners quickly realised that the RB main board was simply a RUMBA board with stepper driver modules built onto the PCB instead of being pluggable (and hence replaceable). There was sufficient demand that one enterprising chap built a (BYEBYE) breakout board for the RB extruder cable so it wasn't necessary to completely re-wire the RB to replace the main board.

So I ordered a Geeetech RUMBA board + 5 x A4988 modules (+ heatsinks) and a BYEBYE board and forgot about the RB for six weeks and worked on other stuff.

The RUMBA and BYEBYE boards arrived last week a day apart and so began my tale of woe (not actually woe, just a huge exercise in yak-shaving).

All the RUMBA connections are screw terminals. I feel happier with these. No stuffing around with crimping tools etc. First I had to unsolder the thick power cable from the power supply board and replace it with bare wires I could put in the screw terminals. I don't have a soldering iron with sufficient wattage to melt the thick layers of solder holding the wires to the PS PCB. Luckily I do have a hot air gun for SMD soldering and when I cranked it up, I was able to melt the solder enough to extract the wires.

The next task was making connections from the BYEBYE board to the RUMBA board. Last year I had purchased a 'Make your own cable' kit from SeeedStudio which proved really helpful for keeping wires in some sort of order otherwise it would have been an even bigger rat's nest. (In retrospect, I should also have purchased the 'Make your own keyed cable' kit as many of the connections would have been cleaner with a keyed plug. No harm done though.)

So after a couple of days wiring and checking and checking again, I turned on the power and waited for puffs of smoke or flames or whatever. Nothing. Just some lights which should have been on.

Then began the task of programming the RUMBA. I was following Jonathan Roscoe's excellent blog on just this exercise. I've had to learn heaps of details about the RB (and 3D printers in general).

First I had to learn how to flash the Marlin firmware into the RUMBA. Took me a while to realise the RUMBA is simply an Arduino with some pre-wired peripherals (e.g. stepper motors, thermistors, heaters etc. etc.). Once that got through my thick skull, I was able to use all I had learned playing with Arduinos.

I've been using Repetier-Host(RH) to drive the RB and the Panel tab is particularly useful for testing individual parts of the RB. Using RH I was able to work out that the wiring for the motors on the RUMBA is different from the RB main board. The X, Y and Z motors were going in reverse. Simply required swapping the Blue and Red wires. The Z-steppers weren't responding correctly and I had to tear the RB almost completely apart before I was able to isolate each Z-stepper and verify that the A4988 module was faulty. Luckily when the Geeetech package arrived, they'd included 6 x A4988 instead of the 5 which I thought I was ordering. So after swapping in one of the spares the Z-axis worked correctly. I then had to put the RB back together again.

So finally I was ready to test the extruder motor, the original cause of all this hoohah. And it didn't work. Maybe a connection wasn't working. I traced the wires and discovered the BYEBYE board is missing a trace altogether. [Ed: no it was my faulty circuit tester; the board is fine.] So I tried plugging the extruder motor directly into the RUMBA and it sat there buzzing. We've heard that before, it means a faulty A4988. Luckily I had one more spare. I swapped it in and the extruder motor now turned correctly. Two faulty A4988s! I wonder if I accidentally damaged them when I put the heat sinks on.

So back to the wiring harness. Discovered that pin 1 in flat cable is not connected. Was it always open-circuit? Presumably not, otherwise motor would never have worked.

Anyway this gives me an excuse to take the whole extruder apart and put back the original stepper motor with the flattened shaft. Talk about an exercise in futility aka yak-shaving. And now I have to find where to get a replacement flat cable.