Software update: Skipping blank pixels, and faster comms

Posted on April 9, 2012 by sandy

In response to Kongorilla’s request for cleverer pixel skipping routines, I’ve just uploaded some new code.

Note, if you’re going to use the controller, you also need to update the firmware too.

v1.1.6 Controller binaries / Controller source code

Firmware source code for arduino with adafruit motorshield / for arduino with serial ITead motorshield / for arduino mega

1. Pixel skipping.

Skipped pixels are ones that are masked, or that are outside of the brightest/darkest thresholds. Normally skipped pixels are simply omitted from the command queue – they just aren’t transmitted, and this is fine for ones around the outside of an image. It does mean though, that skipped pixels that are in the centre of an image get drawn as blanks – a line through them as the pen trundles towards the next drawable pixel.

So this is changed now: The default behaviour is now to lift the pen while moving over skipped pixels. For one reason or another, it does mean that even skipped pixels get transmitted so it might take longer, but the pen will be up during that time. You can still go back to the old continuous-line way by choosing the other option in the dialog. I believe this still works as before.
This works best if you use it in conjunction with masking and reducing the brightest pixel threshold a bit to weed out the false positives that are not completely blank, but are nevertheless too bright to be expressed by the machine as anything other than a straight line.

2. Faster communication

With this release (v1.1.6) I have switched over to using a CRC-based system to verify the integrity of the command. Each command has a checksum appended to it when it’s transmitted, and when the machine receives it it recalculates the sum and if it matches what’s on the end then hurray, the command was not corrupted. If it doesn’t match, then it will signal to the controller to resend the last command. This is twice as fast as before, so that’s good. But it’s not compatible with the old way of doing it. Well, it might work, but it probably won’t.

How it used to work: Basically the controller used to send a command, then the machine would acknowledge it by sending it back, and the controller would check to see if it came back unchanged, and if it did then it’d conclude the message was properly transmitted and send a final execute command. It was fairly safe, but it was slow because there are three messages exchanged for every command.

I put it in as a response to some dropped pixels I was having back in the day, where every couple of hundred commands, one would get truncated or mangled for some reason.

I’m off on holiday for a few days from tomorrow, so if it all goes wrong, goes on fire or destroys your drawings, please wait until next weekend to be cross with me.

Polargraph and Rasterbator – a slow but beautiful relationship

Posted on April 8, 2012 by sandy

I remember seeing the provocatively-named rasterbator ages ago, but was reminded of it again when Morbo linked to some work he’s done on the forum, (his pic is here – I can’t embed it from flickr).

I jumped on the bandwagon with my mooning and it came out really nice – the coarse resolution of the polargraph suits this kind of half-toning very well.

Read the whole thread for some interesting experiments. Thanks to all involved.

Kongorilla did make the point that running this in a tethered mode (as opposed to from an SD card) is deadly slow, and that’s made me look again at implementing a native circular pixel style, so look for that some time soon, hopefully for UNO-sized arduinos.

Eagle defeated!

Posted on April 7, 2012 by sandy

I always had a terrible fear of Eagle, the PCB design software. It’s been written by and for engineers, which is great if you are one, but as a beginner to PCB layout and design it’s horrifically opaque and counter-intuitive.

But it’s gotta be done, so I soldiered on and successfully produced a suite of gerber files for a little breakout board that I need for the motors.

And I think it actually worked! It’s off to the PCB makers anyway, so that’s exciting. Actually it turned out to be – like most things – pretty easy when you know how. I am positive I have done something wrong, and these will come back twice as big as expected, or with the text reversed or something.

This is a tiny board that will accept the 2mm pitch ELCO 8283 connectors that are on the end of my motors, and present a set of 2.54mm pitch pins which is a much more useful kind of connector to have. Current plans are to use this 22AWG ribbon cable with these IDC connectors on the ends to produce the motor wires.

Didn’t really need a pic for that, but it’s so adorable I couldn’t resist it. That shouldn’t be too onerous, and the mess and faff crimping the motor cables was always the main source of sore fingertips and misdirected rage for me in the past. And they are a bonny colour too.

I plan to produce a variant of the motorshield that has 2.54mm pitch connectors instead of (as well as) the screw terminals currently on there, so I won’t need to make funky breakouts for the connectors on the motorshield end. This is A Good Thing. I’m gradually moving to a “designed” machine rather than a cobbled-together one.

Polargraph SD prototypes

Posted on April 4, 2012 by sandy

I’ve made up a couple of Polargraph SD prototypes following this same kind of pattern. They are very simple.

It uses a Mega protoshield (a cheap source of which I am yet to find), an Adafruit micro-sd breakout board, and the motor driver shield of your choice.

Why yes, there is room on that protoshield to build a full motorshield itself! Hm!

The wiring itself is just a slightly neater version of this

Polargraph SD plus hoofer doofer.

Posted on March 21, 2012 by sandy

I’m working on this Polargraph SD machine (basically the prototype for Polargraph SDs to come) for an artist who won’t be able to run “tethered”, so it was necessary to make a little doofer to control the machine. It works!

This is just two buttons, and three little LEDs on a bit of stripboard, with a little 3D printed case. The button signals and the LED sources are on pins A1, A2, A3, A4 and A5. First click engages the motors and sets the position to preset value (i.e. the home point), and then you use the other button to select the command source to use, choosing between USB and SD card. Then once that’s changed to SD card, and the start button pressed again, then it immediately starts reading its commands from a preset file on the card.

This is a little crude at the moment, and I think the code should be more-or-less rewritten to allow things like pausing and cancel / reset, but it’ll do the job. I don’t think a remote like this will be part of the standard Polargraph SD kit, but a couple of buttons might sneak in.

I’m thinking of the custom board being something like an add-on shield for a Mega / Sanguino, with motor drivers and an SD card reader built-in, but with passthrough headers to allow an offset shield to be added without getting in the way, and using an off-the-shelf LCD+buttons shield for hardware control. Basically a mega motorshield. I can’t really decide between a L293D/SN754410 (a la adafruit) setup or a A3988 (eggbot/pololu/stepstick) based design. Any feelings either way?

Two great builds

Posted on March 19, 2012 by sandy

Morbo posted in the forum with a link to some great pics of his drawbot build. I especially like the name “politzler” – which is maybe a kind of polite scrawler, or maybe a police scrawler, I can’t decide.

Secondly, just saw this one today – very impressive build from Dealywhopper based on a old board trolley thingy – what a perfect adaptation! Brilliant write-up and so true: “Operating it is really more of a zen exercise, sort of like watching a plant grow.”

I admit though, my favourite part is on this other project that is written-up on Dealywhopper’s site: This monstrous stand for a dishwasher. I laughed out loud, that last, terrifyingly familiar line:

“It’s certainly not the most practical piece of furniture we have. Actually, it’s downright ridiculous, but I like it, and we’re sure as hell not getting rid of it, because it was a bastard to make.”

And the picture where the item is in situ, utterly dwarfing everything else around it is just gold. Go and read it and encourage the building of more dealywhoppers.

ITead motorshield in the wild

Posted on March 17, 2012 by sandy

Active forum member Woodpecker went looking for alternatives to the Adafruit motorshield, and came across this dual-stepper shield made by ITead Studios, and sold by Komputer.de in Germany. I got a couple, and they are very reasonably priced. These are pre-assembled, based on the A3967 driver chip – the same ones that Brian Schmalz uses in the EasyDriver boards. They can drive upto 750mA per motor, which is a bit more than the L293Ds in the Adafruit design (though that can be upgraded with SN754410 drivers for those that are as infatuated with adafruit as I am).

Datasheet

Schematic

The main feature of this shield is that the A3967s are serial steppers, which means they use fewer pins, and the shield happens to use pins 2 through 9 on the arduino. Which means that the magic pins 10, 11, 12 and 13 are free – and these are the pins that the SPI interface appears on in the Uno-sized boards. That opens up the possibilities of using a pre-assembled SD card reader with the Uno, which is interesting. Now I’d more-or-less given up on running an SD card with an Uno, because of the double-whammy of needing to rewire and because of the memory limitations.

HOWEVER, if this board removes one of those impediments, then the game is perhaps afoot again. I can conceive of a firmware that is very minimal – just responds to vector graphic commands only, and is optimised for standalone drawing. Is this worth having? I suppose I can’t know until I try it eh.

The other feature of the shield, is that all the spare analog pins are broken out to three-pin headers, and the motor connections themselves are exposed as four-pin headers AND screw terminals. So this could be used without the faintly comical terminal adapters that I’ve been making up so far.

The downside: There doesn’t seem to be a way to turn these off. The EasyDriver breaks all pins out so motors can be enabled / sleeped, but this shield appears not to. This is a bit of a blow, because it means the drivers and motors are energised as soon as the board has power applied, and it can’t be turned off programmatically.

The A3967 chip is also less tolerant of bad behaviour like unplugging the motors while it’s on – this is much more likely to damage the ICs than with the L293Ds, so be careful.

Oh and one other thing – these are HOT! Makes the whole arduino hot. I believe the IC will always be hot, and probably well within threshold, but I think heatsinks will be the order of the day again.

Anyway, I have released a new firmware that is built for the ITead shield. It is otherwise identical to the regular firmware, but dispenses with the AFMotor library. The servo pen lift is now also controlled from pin A0 (aka d14), which is the first three-pin header in the block on the motorshield. You can see that on the picture.

The controversial RJ45 power connectors and some big wheels

Posted on March 4, 2012 by sandy

How futuristic does this look.

Well ok, maybe not futuristic. But this is a new counterweight replacement, it uses spring-loaded take-up spools from a retractable washing line. These have power springs in them (like metal tape measures).

The second new thing is using RJ45 network cables as motor power leads. This is basically a way of getting cheap extension leads I don’t have to make up myself. Making up the cables was the really onerous bit about kitting, so this is the solution to that, as well as probably being more reliable.

The connections are very neat, and the cables are very affordable, and the extra conductors means that it’ll be quite easy to piggy-back endstop detectors on the same cable.

I’ve used the little sparkfun breakouts with 90 degree pin headers to connect into the screw terminals on the motorshield. The network cables are a lot stiffer than the old ones, so I’m a bit worried about the strength of the connections, but I’m pretty pleased with it.

Now, shepherds pie and carrots for dinner – rock on.

State of the art tangle

Posted on February 17, 2012 by sandy

In case anyone’s interested, here’s my current brain.

It’s a DFRduino Mega (1280) (ebay) with an adafruit motorshield (oomlout) on top, and an adafruit micro sd breakout (also oomlout) on the side.

This is the jalopy currently running my standalone drawings. The circuit is shown a little better here:

Running commands off the SD card eliminates the pause in between commands completely, it’s brilliant. Currently no way to interrupt it once it’s started, but I plan to add a rudimentary physical interface, a pause/run button at least. Will will be testing various endstop / limit detectors at some point.

I also have a sanguino and a couple of stepstick drivers to test out this weekend. I think that hardware combo is likely to be the basis of future polargraph machines – the chip in the mega is awful expensive.

-EDIT – Firmware
I realised I didn’t mention anything about the firmware I’m using in the MEGA. It’s available from this branch of the repository. It broadcasts its version in it’s READY statement, saying READY_100 instead, and the controller will spot that and the new buttons will appear:

Signal store… This pops up a window that lets you input a filename that any new commands issued will go into instead of being executed. This will create a file on the sd card on the machine, and fill it command-by-command. This is still pretty slow. It puts the machine into store mode.
Signal play This signals the machine that it should go back into play mode, and start executing commands again, instead of storing them.
Exec from store… This pops up a window to input the name of a file that contains your commands and when you hit submit it starts executing all the commands from that file.

A better way to do it is to hit export queue and save your queue to the card directly using a usb card reader – same result, and much faster, then swap the card back into the machine once you’re done.

So I still need to use the controller.

I layout my artwork, then make sure I have an empty, paused queue before generating all my drawing commands.
Then plug my sd card into the pc so it appears as a drive. Now export queue to a text file on the sd card.
Take the card out and put it into the polargraph machine and reset it. It needs to be reset to initialise the card.
Connect the controller and start the queue.
Set home and move the gondola to the home point.
Queue->Exec from store and enter the name of the file I just saved onto the sd card.
The machine gets that message and starts drawing. Now I can just close the controller and turn the computer off if I want to.

Remember that the machine still needs power, and depending on how you have your machine set up, part of it might be being powered by USB. So if you turn the pc off, it might lose that power. It might not! Because you might have a powered hub or something. But If you have a power supply that plugs into your arduino board rather than your motorshield you will be ok to remove the usb entirely.

This works great for vector graphics where there’s thousands of little lines. Not such an issue for bitmap stuff, but still might be useful for bigger things.

Safer vectors

Posted on February 5, 2012 by sandy

Have just been working on making vector drawing a bit safer, thanks to prompting from Matt. Still no resize or zoom, but this drawing with 14,000 commands has just finished successfully.

This SVG was one that used to send the machine into a mad spinning fit, off searching for a coordinate it could never reach. Well, now the machine will only attempt to draw to points that it believes fall within its own machine space, and it superstitiously avoids any 0 coordinate. There are a couple of changes to the embedded (server, firmware, whatever you like to call it) software to support that, and there is a slightly new acceleration behaviour for C17 (draw straight line) commands. This essentially turns off acceleration for C17. Because the line is chopped into such small pieces with C17, it doesn’t work anyway, so doing without makes for a much faster line, at the expense of noise, maybe a bit of wobble. It’s a slightly harsher process.

Ok, so those are the updates to the machine code, not completely essential, but it can be found, as usual in the repository.

The controller has a couple of minor changes to support vector drawing, mainly that only vertices that fall on the page are sent to be drawn. I know it makes sense to have the select area tool able to select the lines to draw, but that’s all a bit tied up with bitmaps and regenerating the density maps to do that easily at the moment. In future though, definitely, along with svg resizing and moving.

The controller now has a separate window to select the pixel rendering options, and choose which corner you want the drawing to start from.

The other change in the controller is that it now supports the new Arduino MEGA firmware, and the few new features that are available in that (namely saving to / drawing from SD cards). It recognises what kind of board you have plugged in because the mega version broadcasts its nature in its READY shoutout. Shouldn’t make any difference to anyone because standard behaviour is the same. I’ve noticed an oddity with the way the control panel wraps when it detects the machine has changed to a different type, but nothing problematic.

Available from the repo, or the downloads section, v1.1.2.

Polargraph

drawing by robot

Category Archives: machine