Patrick Wagner designed, organised and ran a workshop at the Royal Institute of Art Stockholm, using Polargraph machines to create beautiful marks on flat surfaces. Two brand new PolargraphSD v3.0 machines joined their lineup, and it was co-hosted by Christian Bazant-Hegemark.
You’ll know Chris from the Polargraph forum and also from his documentary series On Doubt. Patrick is a printmaker and has ran workshops with the Polargraph at the Royal Institute of Art Stockholm a couple of times already, but this was the most focussed so far. They are both creative visual artists in their own right.
Explaining the magic
This was a session for an international crowd of people who are practicing artists or also educators in the fine art field, to learn about what a drawing machine could bring to their process, and they had a great time making some wonderful marks. I was so pleased and excited to see the pictures coming out of that week long session, and glad to see that two fresh PolargraphSD v3.0s worked great, alongside a cast of existing machines. Seeing what happens when the tool is recognised for what it is, and put into the hands of people who value the act and the process as well as the outcome is absolutely thrilling!
Drawing with bleach onto fabric
Discussing the workshop with Chris and Patrick was also seriously enlightening, it collapsed a lot of waves and really clarifies my thinking. When I don’t talk to people much, my mind runs away into little cul-de-sacs where I’m making decisions without much information. I used to be the customer myself, after all, I built the machine for myself to do my own work as part of my own process. Now however, I don’t use the machine much for creative work, and so I’m easily disconnected from “the user”. Workshops like this, along with the advocacy from experts like Patrick and Chris are so useful. I had ideas for a bunch of features that I’m not going to take further, and learned ideas for a bunch I will. Unglamorous stuff like “longer power cables” or “a pause button that works”.
One of the things that often introduces a tension into my thought is imagining that buyers just want a plotter, or just want something quick, or just want something easy to understand. It’s easy to get into that thought pattern, but it does you all a disservice, and it runs quite counter to the ethos of the Polargraph. It’s a luxury to have an principled stance in commerce, but I think that’s really one of the things that makes Polargraph different to other kits. I’m simply not that interested in Polargraph being a general-purpose, high volume, fast and perfect machine that does repeatable, sharp, registered editions. It’s never going to be that. It is simply the wrong process if that’s your goal.
The lines in between are the interesting bit
While this sounds like making excuses for sloppy engineering, it isn’t. Entirely. The truth is that the quintessential Polargraph artwork is full of characteristic squiggles, blobs and patterns. It doesn’t need to be brilliantly engineered. Like Chris wonderfully summarised:
“… these artists are OK with a process taking time, with fine-tuning sometimes going wrong, with stuff not working right away. While it can be frustrating as well, artists also often benefit from such mistakes (a pen drying up during an overnight print; a badly-positioned gondola resulting in the drawing not being perfect on the paper, etc). So I think that while every artist would always say “make the tool perfect!”, this isn’t actually what would benefit them.”
Getting news of this workshop was such a terrific validation and a glorious piece of news that really helped my bring my full enthusiasm to the launch of the new PolargraphSD v3, which I’m finally getting some reliable stock on (see here for that: https://polargraph.bigcartel.com/product/polargraphsd-v3-0-full-assembled-kit).
Patrick Wagner is blackheartpress on most social media sites:
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.
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…
So you wait months for an update and then three come along at once:
Controller updated to v1.42
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.
The Firmware updated v1.61 for Arduino MEGA based systems (aka Polarshield / PolargraphSD).
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.
Pen lift height
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.
Finally, re-upload your machine spec
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!
Oddness on the mega line
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.
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.
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.
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.
Controller – Pulling a selection area that overhangs the bottom of an image would cause an unhandled exception. Fixed by mending the Rectangle.surrounds(..) method. Off by one, tsk.
Controller – Changing to another serial port would always set the baud rate to 57600, regardless of what was set in the properties file.
polargraph_server_mega – Rolled mbcook’s pbm format fixes into the mega branch. I’d forgotten that I had to do that. Also rejigged it a little, but cosmetic.
polargraph_server_* – All firmwares have had their straight line (C17) commands improved. The last version was ok, but seemed to work much better on polarshields than on the adafruit shield, because of a poorly scaling acceleration algorithm. It was pretty pausey. I have pinched the acceleration algorithm from Mike McCauley’s Accelstepper library, and that works much, much better. I even half understand it.
And a feature in a pear tree:
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.