Polargraphstamatic

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.

New polargraph experiments

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.

Hanging-V myths, or I’m not very good at geometry

Well, I am stupid.

Martian Sharpie polargraph

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:

hanging-v-fig1There’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!:

hanging-v-fig2

 

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:

hanging-v-fig3

 

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!

hanging-v-fig4

 

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.

hanging-v-fig5

 

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.

The reason it took so long to 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!

 

Polargraph at the Edinburgh Mini Maker Faire

So I’m going to have a couple of machines running at the Edinburgh Mini Maker Faire, which is on on the 7th of April, 2013 at Summerhall in Edinburgh.  I hope to have one or two big slow machines that will be drawing all day, and a little, webcam-driven machine that will be drawing quick (ish) portraits for anybody who wants them.

If you’re in Edinburgh, please come along, and get a scribble that looks somewhat like you! Needless to say, there’s lots of other exciting things afoot at the Faire too, even if drawing machines don’t float your boat (what’s wrong with you?!).

I’m not exhibiting at the main Maker Faire in Newcastle at the end of April, but I will probably be attending, and am hoping to meet up with a few folks then.  If anyone is planning on being around, drop me a line.

 

Assemble your own Polarshield.

I’m not sure how many more of these polarshields I’ll be making, I’ve got nine left that I’ve just soldered up, and need a couple for my stand at the Edinburgh Mini Maker Faire at the beginning of April.

nine polarshields, SMT'd

Amazingly, that means I’ve made up and sent out 70 (SEVENTY!!!) Polarshields! Almost exactly half polarshield vitamin kits, and half PolargraphSD full machines.  It’s so weird!

In case I never order up another batch of PCBs, I’ve made a couple of videos that show the technical build process, soldering etc.  They are long, and very very boring.

Soldering:

Testing:

Making cables:

What about that?!

Random scribbles

The same series of scribble pixel commands:

Polargraph scribble pixel not so random!

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.