Fans of the Drawbots Flickr group will have seen Olly O’Neill’s work. He uses a Polargraph hardware kit, but with custom software to produce beautifully glitchy, organic drawings. After drawing, Olly embellishes the drawing with ink, and water, adding a painterly and unique final appearance to these artworks.
Whitley Bay-based PhD student Carl Gregg has a show opening in a couple of days, featuring elements of his research made material:
Gregg has used a couple of PolargraphSD machines in his work for the last couple of months, and wrote custom software to drive them over long periods of time, presenting them as performances. I really like this experimental approach, and the materialistic artefacts (like the missing, ghosted names in the drawing above) add depth and resonance to the work.
If you find yourself in Newcastle or Shields in the next couple of weeks you should go along to The Customs House and have a deek! Thanks to Gregg for letting me know about this.
It’s great to hear from polargraph people from around the world, and I was especially pleased when it turns out they’ve had zero problems, and have added their own features to the standard kit.
You can see this is a big machine (12ft wide, 8ft tall), drawing some promo stuff for for an agency in Portland. Notice the extra pulleys that have been added to reduce the drop of the counterweights – liking that.
This isn’t merely a really big machine though: The makers, Olivier and Evan spend 55 hours drawing the motorbike above and decided they could do better, and came up with a very sweet little script that will read your optimise the saved command queue and … make it efficient!
Above is what the original pen path looks like. No surprise it took 55 hours really. The path planning has never been efficient, and just draws the file as it reads it, from top to bottom.
Running an exported command queue (previewed above) through this Polargraph Optimizer results in:
Which I think we can agree is much more sane. Evan reckons this is 3 1/2 times faster, and I don’t doubt it. Brilliant!
Thank you to Olivier, Evan and Squishymedia for supporting the project, and for giving back too. I’m going to try and pull those algorithms into the Polargraph controller at some point, but until then, I’d recommend that anyone doing really complex drawings should have a look at this.
Most of the things I end up talking with folks about about are troubleshooting and helping get things working, and I feel endlessly guilty about putting you through all that. It’s really gratifying and refreshing to hear success stories – and when someone cares enough to contribute, it means a lot. Even if it is embarrassing because it shows up all the bits I never got around to finishing…
Source: Polargraph Optimizer on github
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.
It’s the first “polargraph” style new feature for a long time, and is now quick enough to actually experiment with. Gorgeous.
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.
The same series of scribble pixel commands:
Look closely, exact same pixel shapes for each one. I know random numbers are hard to come by in the digital world, but I did expect the arduino random() function to be slightly less deterministic. Funny.
I think the differences in the line shapes can be put down to different motor speeds / accelerations.
Extremely impressed by this installation, just gawk:
Lunar Trails from Seb Lee-Delisle on Vimeo.
Organised by the inimitable Seb Lee-Delisle for the Dublin Science Gallery, this is a high quality polargraph-style machine that plots the paths, in real time, of the lunar landers as controlled on the nearby full-size arcade cabinet!
This is a cracking piece of work, a beautiful, exciting collision of engineering and programming – thanks to Seb for showing us what can be done with some string and pens! I would really love to see some more stuff about the wonderful mechanical solutions that his mechanical engineer Paul Strotten came up with to realise this installation.
Hello, please find enclosed a few fixes, an improvement, and a new feature.
Vector art that has been created from an automatic bitmap tracing process tends to be made up of loads of tiny lines. When processed through the controller and quantised to the grid of the machine, they often end up on top of each other, and duplicate points are just slow.
So I’ve added this new slider, which is essentially a lowhigh-pass filter that filters out lines below a certain length. It re-samples longer lines, and discards entirely lines that are shorter than the threshold. See these two vector previews:
The left-hand figure has only duplicate points filtered out, this brings it down from around 15,000 commands to 11,700. Quite a few of those are still just single points – just dots.
The right-hand figure has the shortest vector filter bumped way up, and only has 300 commands.
The drawing wasn’t very good because my pen was running out and it was a bit fast, but you get the point. Smaller filter values will result in more fidelity, while bigger values will have a more dramatic effect.
Polargraph v1.2.4. Code in the repo as usual, and compiled and bundled up in a zip.
The best thing about being involved in a project like Polargraph, is that you meet like-minded people. Stuart Childs is one of these people, and a good guy to know. He is one of the guys behind FriiSpray (which is another art/tech crossover project), amongst other things. He has put together a very neat new drawbot kit called the DRBO. It comes complete with arduino uno and motorshield, motors and all the bits you need, and is made of fragrant lasercut mdf. I got a kit of the hardware bits off him to try out.
As you see, it is adorable when small, but the most best thing about it is that the top bit, the drawing surface bit is pretty sacrificial, if you unbolt it, then you’ve got a good little unit that contains the motors, bobbins and microcontroller, and all you need is a couple of nails banged into a wall to hook the threads over, and you’ve got a machine as big as you want. The threads can just run down to the DRBO on the floor. No messing about with long wires or some such.
Now, when I’ve tried such shenanigans in the past, it’s never been quite as straightforward as that, but in principle at least, this is very handy. There’s a very good case for keeping the motors close to the drivers, and it’s so much neater if nothing else.
The build is easy and it’s an example of good design for lasercutting. It’s all push-out and bolt-together, well-labelled, and there’s even a little circle of sandpaper stuck on to take off the burrs, and a couple of wrenches that have enough life in them to tighten up all the nuts and bolts that you might want more than finger-tight. That’s a really nice touch. My favourite bit is that there are counter-sunk bolts at certain points on the surface, and Stuart supplies these dinky little magnetic buttons to hold the paper on! Brilliant!
The box for the microcontroller is big enough to fit an arduino mega in it, for those who mate megas with adafruit shields.
I did take other pics, but none of them are quite as good as the ones on the DRBO site. It’s also dead cheap, considering this is basically a full arduino+stepper motors dev kit, PSU, microcontroller, motorshield, motors, servo, fitments, the lot.
To mark the Edinburgh Festival(s), I’m drawing most days in the window of Spectrum Arts, 317 Cowgate, Edinburgh, with a big chalk marker.
I’ll add the pics here as they happen – any suggestions?