New pixel preview styles

Polargraph Controller v1.8 adds a more representative pixel density preview style to the controller app:

native-pixel-size-preview

Edit your properties.txt file and set controller.density.preview.style=5

native-pixel-density-preview

 

or set controller.density.preview.style=2

These new modes are designed to give a better idea of whether pixels are going to fall off the page. That’s really annoying when it happens.

I’ve also taken out a couple of buttons that didn’t really do anything sensible any more.

It’s available here on the github page.

Also included in that bundle is v1.9 of the polargraph_server_polarshield firmware. This is really only intended for the new v2 polarshield, but should do no harm if you want to play with it. Well, I hope it doesn’t do any harm anyway.

The only new feature is that the pen-lift height (at up or down points) can be adjusted through the touch UI now, rather than just through the controller app.

 

Polargraph Server for Adafruit Motorshield v2

There’s been a bit of ongoing investigation about getting the polargraph firmware running with the new Adafruit Motorshield (v2). I have just got one of these shields recently, so have only just had a chance to work on it tonight.

https://github.com/euphy/polargraph_server_a1

The new Adafruit library is slightly bigger than the old one, and the polargraph_server_a1 firmware was super tight on space already, so I’ve split up the code into a set of features that can be easily enabled or disabled at compile time to save space:

  • PIXEL_DRAWING – This is pixel shading.
  • PENLIFT – Controlling a servo to lift the pen.
  • VECTOR_LINES – Drawing straight lines, aka vector plotting.

So to get this to fit on, you need to disable either PIXEL_DRAWING or VECTOR_LINES – can’t have both anymore, not with Motorshield v2.

For convenience, I’ve pre-compiled two binaries, one for Motorshield v1 (using AFMotor), and the other for Motorshield v2 (using Adafruit_MotorShield). The firmware for Motorshield v2 has pixel drawing disabled.

This is a bit of a pain, but I don’t see an acceptable alternative.

I haven’t tried this for actual drawing yet, because I haven’t got a machine made up that uses this system, but at least the motors move! Please let me know if there is any success – or otherwise.

Happy scribbling!

See also http://www.polargraph.co.uk/forum/polargraphs-group2/troubleshooting-forum5/motors-not-working-when-i-compile-but-hex-works-thread324/

This knowledge transferred to: https://github.com/euphy/polargraph/wiki/Polargraph-Server-for-Adafruit-Motorshield-v2

Polargraph Pro Preview

Hello, I’m getting excited about the new Polargraph installation that’s been eating up all my time recently. IMG_20140327_160058025_HDR This is part an exhibition called Making It, itself a feature of the Edinburgh International Science Festival, and it’ll be running in the Grand Hall of the National Museum of Scotland, here in Edinburgh, for most of next month (April 2014).

IMG_20140330_112312329_HDR

I’m just putting some finishing touches to the machine and the control software.

There’ll be more of an update when it’s up and running.

Mystery of the Gappy Drawings- new controller version

I have uploaded v1.7.1 of the controller here on github. I know it’s in the wrong place, but I couldn’t figure out restructuring the projects quite yet.

So, polargraph innovator Kongorilla pointed out that he was getting gaps in his pixel shaded drawings, some 8 months ago. I was baffled, but agreed that , forsooth, they were gaps. Like him, I’d seem them, but never seemed to be able to replicate them. Like a ninja, they seemed to melt into the night, leaving me with a haunted feeling.

a40k5-IMG_20140309_19193207622

Well, thanks to his work, including the sample drawing patch above, and encouraged by code sleuthing from Nosetinker (and literally no contribution from me), a solution has been found!

While the value for grid size is displayed as integers, internally it is handled as a float. In the example above, the grid size was displayed as 41, but was actually 41.5, internally. When the positions of each pixel were calculated, and rounded to the nearest integer, 41.5 became 41. The next pixel along was put at 41.5+41.5: that is 83, and there’s no rounding there, but that means that there is 42 steps between them instead of 41.

So one pixel is 0.5 steps too high, and the next pixel is 0.5 steps too low. Simple! I had thought it would be something more tricky than that – thanks to Nosetinker and Kongorilla for shining a light on this – sorry it took me the better part of a year to get around to doing anything about it.

Note – I don’t have a machine right here to test it with, so it still might be something afoot. There are no updates to the firmware, but it is included in the zip.

(Note the first version of this, 1.7 wasn’t right, hence the extra .1)

PolargraphSD firmware update for SD card problems

SD cards are tricky beasts. I have spent the last few days trying to get better reliability out of my polargraph machines. I found a bunch of new SD cards that just wouldn’t initialise. Then I tidied up the software init routines, and some sprang into life! Hurray!

There is a new PolargraphSD firmware available in the github repo, and I’ve also rebundled it into a zip using the new releases feature in Github:

Polargraph v1.7.25

The design of the Polarshield, and the interaction between it, the arduino underneath and the SD card reader on top, the USB port and the power supply is clearly dysfunctional. Some combinations are trickier than others, it isn’t at all clear to me why.

The takeaway is hopefully that a couple of SD cards that previously did not work, now do. Please have a go with this, and let me know.

So that about wraps it up for v1.3

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.

I ran out of numbers.

Ha, so I thought that a Polargraph could be as big as your piece of string, well, that’s true, but there’s a significant caveat.  Because the string lengths are represented by variables of type long, it can never be longer than 2,147,483,647 steps.  One more step, and it rolls over to -2,147,483,648.

Now that’s pretty long.  With a PolargraphSD machine, that’s 63,761,390 mm, or a 63 metres diagonal distance.   Plenty room for expansion there.

Well, not quite, because to deal with strings that long, and machines that size, we need to have some headroom.  One of the core calculations that happens in Polargraph is working out the cartesian coordinates given the native coordinates:

float getCartesianXFP(float aPos, float bPos)  {
      float calcX = (sq(pageWidth) - sq(bPos) + sq(aPos)) 
        / (pageWidth*2);
      return calcX; 
}
float getCartesianYFP(float cX, float aPos) {
      float calcY = sqrt(sq(aPos)-sq(cX));
      return calcY;
}

So squaring (with the sq(…) function) produces a much larger number than is input, and it produces a number that is larger than can actually be expressed with a long (32 bit) number. Disconcertingly, sq(2147483647L) evaluates to 1.  1! That’s not helpful.

This calculation (sq(pageWidth)) is used a lot during any vector moves, and will be wrong if pageWidth or the target move positions are any larger than the square root of 2,147,483,647.  It’s 46,340 btw, which in steps is actually about 1.3m, or very very much less than 63 metres.  I’m slightly amazed that nobody (myself included) has not come across this problem already.  I have chased this issue down after helping a customer debug their envelope-pushing setup, and I’m a bit embarrassed to be honest, all my bold chat about “it’s as big as a piece of string”, well.

So, the good news is there’s a simple solution: cast to floats during the calculation.  In principle I may lose accuracy, but in practice I don’t believe it’s in a place where it is likely to be significant.  If it comes down to it, I could cast to use a long long, which is a 64 bit int type I only just discovered existed, but in a method that takes floats as parameters, and returns floats, I think it makes sense to treat the other numbers as floats too.

The fixed method looks like this:

float getCartesianXFP(float aPos, float bPos)  {
      float calcX = (sq((float)pageWidth) - sq(bPos) + sq(aPos)) 
        / ((float)pageWidth*2.0);
      return calcX; 
}

Note the casting to floats when referring to the variables that are actually longs.

The fixes (firmware 1.66) are in the usual places:

Though be aware that you only need bother update, if your machine is wider than 1.3m – there aren’t any other fixes in there.

– EDIT I introduced a new issue with 1.65.  1.66 (just now) should fix it.

Webcam removed from controller

The webcam view was too unreliable, and crippled the controller app for those people who didn’t have compatible machines / cameras.  I’ve taken it out.  It will be back in future, in a safer form, but in the meantime, it caused too much havoc.

So I’ve just uploaded a new package, containing unchanged firmwares (1.63 for _a1, and 1.62 for _polarshield and _mega versions), and an updated controller (1.6) that uses the loaded image instead of the live webcam view:

Thanks for being patient!

New updates come to UNO

Well, the 1.6x code compiles fine on an UNO after all.  I just didn’t have one to test on before today, only Duemilanoves.  SO, it doesn’t fit on a Duemilanove, but it does fit on an UNO ok.

Updates in this version:

  • v1.62 Firmwares: Fix significant problem that caused vector move to lose steps, and the image to chase itself up the page.  That wasn’t cool.  Anyway, I could only replicate the issue with the _mega firmware, but have rolled the “fix” (such as it was) into the _polarshield and _a1 branch too.
  • v1.5 Controller: Can rotate webcam image, also show live feed, and flip.

There’s a bit of beta stuff in the _mega firmware (1.7a) and the controller about a new rove-render drawing style.  It works like the norwegian pixel in that it reads a bitmap off the SD card and will “behave” all over it.  It uses the penlift, and it probably the most annoying thing I’ve ever witnessed.  Do not try it if you value your sanity.

— EDIT – I’d forgotten to put the actual precompiled controller app in the zip, duh, it’s there now, sorry about that folks.

— EDIT – I’d forgotten to MAKE IT WORK, so there’s a 1.63 out now.  This is an update for polargraph_server_a1 ONLY.

A flurry of activity

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.

live-trace-example

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.

Grace Kelly in spirals
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.

Speedy chat!

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!

Github

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