Well these took a long time, but here they are now. I’ve gone into soldering overdrive.
Thanks for being patient!
Well these took a long time, but here they are now. I’ve gone into soldering overdrive.
Thanks for being patient!
After a long wait, Polargraph machine are finally available for sale again!
I am pleased with the last batch of Polarshields I had made, so I’m waiting for a Big Batch coming in the next week or so, and I already have all the other stuff I think. But in the meantime, I am taking orders – I find having the anxiety of holding onto peoples cash focusses the mind wonderfully.
So I was excited to get the sample for the “final” version of the polarshield v1.5 through today, very nice… Except I noticed it only had traces on one side of the board! No traces on the bottom!
To have a board made, I produce a bunch of files, each one containing information about one layer of the board – silkscreen printing, soldermask, copper traces, cutting outline, drill holes etc – and zip them up (they’re also on github). I raced to check the files I had sent, and – crestfallen – spotted that I’d somehow managed to miss the bottom copper files.
Infuriating! The wasted money stings a bit, but the main penalty is that production is knocked back another two weeks, and it’s already been too long. I’m getting anxious, and making stupid mistakes like that really doesn’t help.
Well that’s a nice surprise – the new v1.4 boards work! I shouldn’t be surprised I guess, since they are just the 1.3 boards with less stuff on, but it’s always nice when something just works.
I had a thought when soldering this up though: Because the pins for motor A protrude through the board, they need to be filed down and insulated so that they don’t short against the housing of the USB-B connector on the arduino underneath (a blog about it). This is a pain, and in principle (if not in practice), makes for a weaker connection. This has never been a problem for building the full kit, because the arduino mega I use has a mini-USB connector, but for everyone else (and all the vitamin kit parts), it’s a glaring issue.
So I think I will swap motor A with motor C, so that by default, for polargraph, that filing doesn’t need to be done. Will still be wise to put a bit of electrical tape on it because it could still contact, given the right pressure.
Motor C was added because I had the space, and also because I have a few plans for things that might like to have a third axis of control. The parts for motor C will be unpopulated by default, for Polargraph products anyway.
So, I think I’m immediately going to revise this to swap A and C, but also I might try to move the servo and endstop pins, and add some more lights. I’ve got all these LEDs to use up!
Another fortnight for v1.5.
The building where I have my studio has a exhibition of work on all through August, so I’m in it too. I’ve got a cabinet of jewellery and a polargraph drawing! Why don’t you come and see it?
My photograph is dismal, the reality is better. I might have some live drawing at some point, but I failed to move fast enough (and ran out of parts) to get it sorted out for the launch.
I’ll be at the preview tonight, Friday 2nd of August at Arts Complex, St Margaret’s House, 151 London Road Edinburgh EH7 6AE, but the show runs all month, and there’s three massive galleries of stuff across a range of budgets, so call in. My stuff is in Gallery 3.
If you want to come down, drop me a line and I can come and meet you! And show you some other stuff if you want to see it. Or not, if you don’t want to, that’s fine too.
So there are no more 2.2 inch panels left in the world! I have a couple of 2.4s, and a little fix for the firmware to get it working with that resolution panel. I have just found a new source of 2.2 inch panels! But no cases to fit the new panel PCBs.
Orders for full kits are suspended until I get the new boards through and can work up a case, and vitamin kits have that caveat attached.
I will be working up a new design for v1.4 of the Polarshield shortly, stay tuned.
The 2.2 inch screen that I use for the Polarshield is now unavailable, so I’m switching to the 2.4 inch screen instead. Not much difference, but it does mean the PCB needs to be revisited so that it fits in the same footprint. I only have a couple of the 2.2 inch panels left.
The 2.4 inch screen has a higher resolution, so in principle it can fit more stuff on. But in practice, I will keep the two designs aligned for as long as possible.
So I am planning to remove the XBee socket, and the hardware that goes with it. I don’t think anybody uses it, and I’ll leave some pins open so that I can wire it up again in the future.
I would quite like to have space for a third stepper driver, for doing some like this lissograph drawing machine which I covet deeply. If that happened it would be a mostly unpopulated blank, cos it’s a pretty niche idea. It’s also true that a machine like that could easily fit into an arduino uno sized board, and there’s already plenty of multi-stepper shields out there to choose from.
Apart from that, I’m blank. Does anybody have any feelings about the direction of the cables, locations of the sockets, or the types of connectors, things like that? Drop me an email (sandy dot noble at gmail), or go on the forum.
So you wait months for an update and then three come along at once:
Main new feature is live drawing from webcam. This is pretty cool actually, almost better than I expected. There is a new tab in the controller, labelled CAMERA, and by default, it’ll show a vectorised version of your webcam’s live feed. There are a couple of settings that simplify the raw video in order to make for faster drawings.
It works by grayscaling, then posterising each frame, then performing a vector trace on each layer of colour.
The simplify control works to remove complexity from the resulting vectors, and creates some amazing abstracted forms at higher levels. Posterise controls how many different layers of colour the image is reduced to, and blur reduces the actual detail.
Hit capture to snap a frame, and get to see (to some extent) the drawing sequence too – darker lines are drawn first. Cancel capture discards the snap and returns to the live feed. Add caption doesn’t work yet! Oops! Draw capture confirms the snap and converts it to commands, and packs them into the command queue. It also saves the image as a SVG somewhere too, in case you need to repeat it.
The drawing is scaled to fit into the picture frame. You know, the picture frame. Everyone uses that, right?
Path length cutoff throws away paths below a certain number of points. This was intended as a way of trying to filter out rubbish single point, or single line paths, but actually simplify works better. The problem with the cutoff is that it counts points in the path rather than actual path length, so you could have a path that forms one whole edge of the snap, but it’d get thrown away because it only had two points in it. Doesn’t make much sense.
Good fun, and good results, I took and gave away portraits all day at the Mini Maker Faire here in Edinburgh week before last, people seemed to like it.
On windows it can be a bit of a cow to get running, it requires the infernal Quicktime, and WinVDIG.
So, Accelstepper, the wonderful library that I use to control the stepper movements in Polargraph got a couple of fixes, unfortunately fixing bugs it looks like I was relying on! So at least one person encountered issues using the new versions, and the main part of this update is to fix that. Vector drawing works again, three cheers.
It was a bit of a weird problem (that I went into briefly on the forum), but while I was there I “fixed” a few other things, the main one being the spiral pixel drawing style (aka circular pixel)! It is very working, very quick, and very handsome indeed.
The code no longer fits on an Arduino Duemilanove, and I think probably not on an Uno either, so I have not included any updates for polargraph_server_a1.
The servo positions were hard-coded into the firmware previously, but not all servos are created equally, and what was logically a 90 degree move often only turned out to be a 45 degree move (or less!). I have made the servo up and down positions settable and saveable. There is a test lift range button on the setup tab of the controller, along with two number spinners to set up and down position. The test lift range will wiggle to both extremes a couple of times. Once you are happy with the range, press save lift range to load it to the non-volatile EEPROM on the machine. Remember to test it with pen lift and pen drop on the input tab to make sure you’ve got them the right way around. There might be some foibles around that.
Maybe you always do this anyway after loading new firmware, but the EEPROM addresses of the various values that get saved there has changed, so they’ll be all over the place. So you need to upload machine spec after updating the firmware.
The serial comms handling on the arduino end is now significantly quicker. Very good!
The version of firmware for the Arduino MEGA using the adafruit shield (polargraph_server_mega) is almost identical to the polarshield variety, but I was getting some really weird results when doing vector drawings on my little machine here last night. It was badly dropping or gaining steps. It works fine on the polarshield machine, but on this one, with a adafruit motorshield, no dice. I think it must be down to the speed that I was driving it at (too high), but I’d be interested to hear if anyone has success with it, or otherwise. Drop me a line please. Thanks!
All the cool kids are using github now, so I am too. The main code packages (polargraph_server_* and polargraphcontroller) are there at https://github.com/euphy. For the time being, the google code project will continue to be the official hub of the project though, but that might change.
Get the bundle at https://code.google.com/p/polargraph/downloads/list
Just a preview of the quality of scribbling that you will encounter if you stumble past the Polargraph stall at the Mini Maker Faire in Edinburgh next weekend.
The portrait is created from a webcam video feed, is A5 sized, and takes about 10 or 15 minutes. I’ve added functions to do that, and to control it with a wireless gamepad to the controller so you can stand back. I was going to do a whole page feed thing, but one thing didn’t lead to another (though I have a dismembered printer here as evidence of trying).
I’ve also been updating the github project rather than the google code SVN repo. Still getting used to github. Github for windows seldom works for me, but tortoisegit is doing ok. This project now requires JMyron, Diewald CV kit and Procontroll as dependencies.
The other drawing on that image is an export of an image created with Abel Dewitz’s beautiful Silk Blossom processing sketch. I would love to have something like that algorithm built in as a polargraph roving feature.
Well, I am stupid.
When I designed the first polargraph gondola (above) I thought I was being clever by making the gondola arms (the cords) pivot around a central axis. So this is what I did:
There’s no room for error. The physical machine reflects the mathematical model. Sure it’d be much easier to make the cords pivot from points just outside the pen itself. Easier to design, easier to build, and cheaper, far, far cheaper. But surely, says I, to do that would end in madness! Dogs and cats living together indeed!:
I mean! How could anyone accept that. The distance from the notional tip of the hanging triangle and the actual pen itself changes constantly! Puny humans!
Well, I knew that couldn’t really be true, otherwise how come those gondolas didn’t exhibit hideous geometric distortions? Like when I used Stuart Childs’s gondola on the Spectrum Arts window? Ah, don’t think about that, revel in your technical superiority with your elegant radially symmetrical design. It must have been some weird abberation to do with the size of the surface. Well done lad.
And maybe just think for a moment, or better still, draw some diagrams to prove the theory:
Aw nuts. The offset arms fallacy (as I’m calling it) relies on a deeply brainless piece of thinking. The idea that the hanging triangle always exists, but that the gondola is somehow squeezed up the cords until it finds equilibrium, suspended in that V (fig 2). As fig 3 shows, that’s cart-before-horse stuff.
AHA, but I still have you! The gondola won’t hang straight all the time – as it traverses the surface, its orientation will change. It’ll be all over the place! HA!
Double nuts. BUT, well. Ha, you thought you had me. Well, what happens when you’ve got one swing arm joint slightly looser than the other? Now that’s dangerous territory.
Ok, that’s the worst case I can think up. With an offset swing-arm design, for any given pair of cord lengths, the actual position of the axis could be off by half the intra-arm-pivot distance.
So forgive me. This was prompted by Makerblock’s lucid response to my childish chest-beating on his blog. I don’t know why it took me so long to actually figure this out.
Well, the reason this fallacy stuck so long in my head is that I was thinking badly. I worked on the basis that the machine knows the shape of the triangle. Therefore it knows the angles of the sides, and the positions of the intersections. But of course it doesn’t. All it knows is the length of the sides, and it’s got to figure the rest out from that.
If it somehow knew the angles of the hanging strings, then my misconception would be entirely apt. It would entirely miscalculate the position of the gondola, based on where it thought the tip of the triangle way. So it does make sense, after a fashion.
This is an interesting case that illustrates one of the problem with the kind of naive (or isolated) engineering that I do. It provides the opportunity to simplify things, and get by on “just good enough to work”, but also tolerates faulty thinking (for better or for worse), and if anything gets built on top of faulty thinking, that can end up messy.
I’m still not changing it though. Central axis FTW!