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!

 

Slow delivery and buggy interrupts

Hello, thank you to the couple of you who have been waiting a long time for your machines, and are very patient.  I’m behind, for a couple of reasons: 1) New job means less flexibility in the short-term (don’t want to give a bad impression you know). 2) Worrying problem with the touch-screens.  They weren’t working.  Touches being registered, but position mangled, and then locking up the whole machine.  Not good.

Thanks to dc42 on the arduino forum, I think I have a solution.  Now, the real question that I am going to shy away from asking myself is “why did this only start happening now”.  I thought the lines that I find were causing the issue were inserted as a response to this problem in the first place.  But I could be wrong, lost in the mists of time now.  I wonder if slightly different manufacturing tolerances on the LCDs or the megas have led to a slightly different behaviour.  I have moved to using the new UTouch libraries instead of the ITDB02_Touch ones (more or less the same).  As ever, the updated code is in the code repo.  I haven’t packaged it up, because I’m not clear that the code in the current release zip is causing any problems.  At any rate, it’s only the touch-screen stuff that’s the issue.

Anyway, so that’s 3) The solution.  And big news: 4) I have a workshop now!  I’ve rented a studio in Art’s Complex in Edinburgh – this should give me better separation of business and pleasure and lead to routine stuff (kitting) being done faster – or at least at a more reliable pace.   Thanks!

Driving PolargraphSD wirelessly

I’m finally on top of assembly so can pause for breath.  Thank you to the folks who are still waiting, your machines will be coming to you in the next week or two (at the most).

I wanted to let people know that there’s a couple of neat features in the Polarshield, the first of which is an XBee-shaped socket that can take a wireless transceiver.

It’s as easy as that.  There’s a weak line in the case that can be cut away if you wanted to do this.  This is a great way of simplifying installation of a polargraph machine in a particular space.  I used a wireless connection just like this in the Spectrum Arts machine so that I could do the machine setup / calibration manually and do any little pen tests I wanted to make sure ink was flowing, then draw from SD.  There I used XBees, here I’m using XRF modules (and a Bee Adapter for the PC end).

One foible I came across with my XRFs (maybe I was being dumb) is that I couldn’t get my PC to talk to the PC-side XRF any faster than 9600 baud.  Which is unfortunate because the default rate that the polargraph controller speaks at is 57600 baud, so I added a property to the controller that changes that rate.  If you need to use it, you’ll have to edit the properties file – there isn’t a visible control for it in the application itself.

But once that’s done, it just works as a serial cable replacement: Great!  It doesn’t work for reprogramming the arduino firmware yet – I tried to get that working but never did, so you still need to use a USB cable for that.

A wireless module is not supplied as part of any kit – I decided these are still too expensive, and a little too far outside my expertise to start troubleshooting, but the socket is there for those who would like it.

A weekend of fixes

Hello, please find enclosed a few fixes, an improvement, and a new feature.

Fixed:

  • 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.

An improvement:

  • 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.

Polargraph v1.2.4.  Code in the repo as usual, and compiled and bundled up in a zip.

Norwegian pixel

So this is the real star of v1.2: The norwegian pixel.

  1. Save your source image as a greyscale PBM or PGM file, and put it on the SD card. Note that GIMP saves PBM files as 2 colour dithered files, so you need to export as PGM to get it to work there.  Photoshop just saves in whatever format the image happens to be in, so make sure you convert to grayscale (not RGB or indexed) before saving.
  2. Put the SD card in the PolargraphSD and turn it on.
  3. Open the controller and drag a selection box where you want to draw your picture.  For one reason or another, you do need to have an image loaded before you’re allowed to drag a selection area.  I just noticed that.  But the image you load is nothing to do with what you’re drawing.
  4. On the roving tab, click set roving area.  This tells the machine where you want it to start.
  5. Click draw norwegian… and enter the filename of your image file.
    Click trace outline and the machine will quickly draw an outline of where the image will be.  The image will be scaled so that it is the width of the rove area, regardless of how tall that works as being.  So really the height of the rove area is irrelevant.
  6. Choose the amplitude (row width) and the wavelength, and hit submit to send the command off to the machine.
  7. Wait many hours.

I haven’t done an awful lot of testing of this, but the initial results are beautiful.  

HOWEVER, I have noticed one issue – there are regularly spaced breaks in each row, some more obvious than others.  This is because of the way the beaded cord slips on the sprockets, and it’s a problem I actually expected to see before now.  The issue is that the beaded cord is not manufactured to very close tolerances, so the sprockets are rarely a perfect size.  It means that each beads-worth of rotation, there’s a little slip while the beads pull taut into the teeth.

There isn’t really a solution as far as I can see, as long as there’s even a mismatch between the circumference of the sprocket and the length of a piece of cord with the same number of beads, there’ll always be a little period where it falls forward.

Note that I think it’s only a problem for machines with beaded cords – if you use reels of thread and smooth bobbins, you’ll be fine.

–EDIT I goofed a bit with the various firmwares, and half the stuff didn’t work. I’m a bit puzzled how I didn’t notice, but there you go. Anyway, I’ve fixed a bunch of stuff, so if you had problems with the newest stuff, give it another shot.

Polargraph v1.2: Vector sprites guide.

Two exciting new features for PolargraphSD.  Both of them rely on the new roving area facility.   This is essentially nothing more than a way of specifying a drawing “live” area, and telling the machine.  Previously the machine has had very little concept of state, and (more-or-less) just did what it’s told.  Now, by setting a rove area, we can tell it to limit its behaviour to just that area.

Both of these features are very GOOD ones.

How to rove.

Most of the roving functions are hidden away on the roving tab, but it shares buttons with input.  Define a area on-screen by dragging a selection area, or selecting the frame.  Now just press send roving area and a new command is sent off that sets this in the machine’s live memory.  This area is volatile, so if you reset, you’ll need to resend.

Vector sprites.

A vector sprite is nothing more than a small vector design, but instead of existing in the coordinates system of the machine, it has its own coordinates system.  So when I have made up a font with each letter being one sprite, each letter has 0,0 at the bottom-left point.  Capital letters are 1.0 high, and around 0.4 wide.  What unit these values are measurements of is irrelevant, because the machine can now scale them to any size, and  draw them anywhere, and rotate them to the four cardinal native polargraph directions.

Vector sprites will be able to be lots of things in the future, but the first application is writing text.

  1. Choose your rove area by selecting an area and clicking send roving area.
  2. Choose whereabouts in the rove area you want the text to start by clicking start text at point and clicking somewhere in your rove area.  The gondola will move to that point on the machine and wait.
  3. Click render writing to bring up the writing dialog:
    Type in your text or load it from a text file using the button. For now, it can only draw in a south-east direction.
  4. Notice that there’s a file prefix here.  This tells the machine to find the sprite font files on the SD card in a subdirectory called sprite, and that the files themselves will be prefixed with let (for letter).
  5. Hit generate commands and see that each character has been converted to a new command:
    The C39 commands tells the machine to draw a sprite from a file on the SD card, at the current machine position, and scaled 80x.

In this case, these are letter form files, and there’s loads of them which is why they get their own directory on the card.  And because this is being done in the context of writing, then the machine knows that if it finds itself outside the rove are, then it knows how to work out where to start the new line.

The grid size sets the text row height, and the pixel scaling controls how big the actual letter forms are scaled within those rows.

In practice, this has the ring of Jack Torrance to it, which is nervously apt.  It’s possible to read fragments, but because each line is longer than the last, and because of the curve and the distortion, it’s almost impossible to figure out how the lines follow on from one another, and very easy to lose track.  Quite disorientating to try.

For this to work you need to copy the sprites folder onto your SD card.

Get the new code, controller and things from the repo

Polargraph 1.2 Controller source code

Polargraph server for polarshield source code

Or in the binaries bundle.  I put the mac and the pc version in together – let me know if there’s any problems with doing it this way.

The other new feature is actually more significant, but a bit more simple:

Norwegian pixel FTW.  I’ll write some more about that tomorrow, because it’s bedtime now.

Norwegian pixel preview

Didn’t get around to making up a numbered release this weekend, entirely restructured the server code instead to separate the basic polargraph stuff from the advanced polargraphSD stuff.  This will make it much easier to keep multiple versions in sync, but needs a bit more testing to make sure I haven’t broken something in the mean time.

However, also added a couple of new features, one of which is the much-asked for norwegian pixel style (above).  This is named after the Norwegian Creations drawbot that I featured on this blog before, and looks quite like it, but is remarkable because it draws directly from a bitmap file on the SD card itself, rather than interpreting commands from the controller.

Vector sprites – aka WRITING

A major new feature sprang up over the weekend, and it’s actually one of the things that was immediately desirable when this project started over a year ago. 

PolargraphSD can now draw vector sprites.  These are little fragments of vector art saved into their own files, they are executed by a new command (C39) that specifies where on the machine they should be drawn and at what size.  It works as a kind of macro.  The first application is writing:

In this case I’ve made up 26 files, each with a letter form in it.  I specify the active area using the controller and a starting point where to draw the first letter, then feed in a load of text.  Lines wrap until the active area is full.

This uses the rove area as the demarcation for it’s operations.  The rove area is not entirely a new thing, but it’s never really worked before.  It’s really nothing more than a safe, cartesian area to behave in and it’s specified as simply as dragging a box in the controller and sending it to the machine. It’s going to be important for future standalone functions where the machine will be given free rein to draw or scribble or otherwise fill in this rove area.  It’s called a rove area because the machine is free to rove anywhere in it.

I’ve committed the code I’ve done already, but there’s still a little bit of work to do before putting out a full new compiled version, so that’ll happen later in the week.

Faster vector drawing

Have just committed a few firmware updates that make vector drawing much faster.  It runs at your maximum speed now, so you might want to tone it down a little – big moves can get quite violent.

I have implemented some very rudimentary braking / acceleration to make it a bit smoother.  Beforehand, small moves especially were very jerky.

That update is firmware only, and for polargraph_server_a1 as well as polargraph_server_polarshield, get the source code or the precompiled hex:

PolargraphSD users will also find that their touchscreens go blank after half an hour. Don’t worry, it’s just a screensaver, and it’ll come back on when you touch it or send a command.