C17 is rocking the house.

So I decided how many slices to cut the line into (to keep it on track), and iterated through the lines, and in each iteration I was recalculating the cartesian position, and then recalculating the delta (the change required).  But that wasn’t working (see previous posts).  I took advice from Andy Kinsman who is much smarter than me, and took out the recalculation, and now it workings brilliantly.

I don’t understand why recalculating it sent it off so wildly.  Very possibly an off-by-one issue with my getCartesian() methods.  But it’s fixed now, so I’m not going to worry about it unless I have to.

Repository updated, in the arduino 1.0 style (ouch, sorry).

I’ve been using Arduino 1.0 this last couple of days.  It’s a bit of a pain because it breaks all existing libraries.  Now, they aren’t that hard to fix, and adafruit have already released an updated version of AFMotor that works in all versions of arduino.

AccelStepper 1.9 doesn’t compile in Arduino 1.0, so I’ve done it myself and that’ll do until the author releases his own updates.

The AccelStepper mods are to the two files AccelStepper.h and AccelStepper.cpp, and you can get them from this branch.  They are actually dead simple, which is why even I was able to do it, ha.  Replace your existing files with the ones here, or check out the whole branch into your /arduino-1.0/libraries/AccelStepper folder.

So there are a couple of changes within the arduino language when it comes to 1.0, so I have implemented them, and the new version is committed to the trunk of the repository right now.  It has a new name and a new file extension – polargraph_server_a1.ino. Be aware that I won’t be updating the old project any more.  Any changes will happen to the new project only, and the old project file is no longer in the project.  If you still want it, then it’s available through version control though, update 129 is the last one.

The new file is here.  It is unfortunate that changing to the new version of Arduino is such a pain, but I’m told it’s for the greater good.

The good news is that there aren’t many terrible problems in the old version, so there’s nothing you _have_ to upgrade for.  The stuff about straight lines (below) is still getting fixed, so you’ll probably agree that there’s no hurry to get it yet.

More straight line work.

Made a minor improvement to C17 (the straight line command), but there’s still something wrong with it.  Here’s some sample plots based on:

C01,3137,3600,END
C13,END
C17,4069,3596,4,END
C17,3638,3101,4,END
C17,3137,3600,4,END
C17,3628,4035,4,END
C17,3638,3101,4,END
C14,END

The red line is drawn by the machine.  I drew the blue lines with a ruler to indicate deviation.  The numbers underneath each test pattern are the “max length” values.  This essentially controls how long the largest line segment is allowed to be.  So for the first one, each line is split up into lots of smaller lines, each one 4 steps long.  For the last one, the long lines are split into a few lines 150 steps long.

You can see that while the larger values do actually keep to the line accurately, the line ends up too wavy to represent good fidelity.

With the smaller values though, something’s going very wrong, and I’m not sure what it is.  I don’t think it’s a cumulative effect because the line drawing algorithm recalculates the current pen position, and the new direction/distance afresh for each sub-line, so there isn’t anything that can accumulate as far as I can see.

My best guess at the moment is that it’s a rounding issue – where the distance to move is consistently being rounded up when it should only be being rounded up half the time.  Or down.  And that’s why there tends to be a corner in the inaccurate lines, where suddenly the movement jumps from being rounded up to being rounded down, something like that.

I don’t think it’s to do with the position working-out algorithms (getMachineA(), getMachineB(), getCartesianX(), getCartesianY()) because that would show up as positioning errors in all of the tests.  Though my feeling is that the difference seems to be that the longer segments have more space to correct their deviations, whereas the smaller segment can only go one or two steps either way, so can’t do it.  But that doesn’t explain why it’s so consistently wayward.

–EDIT

Just for amusement value, this is what it draws with max segment length of 1 (the finest resolution):

So that’s no good.  I’ve just been and converted all the positioning maths to use all floating point numbers instead of integers, and that’s actually made the lines a lot more regular.   But they still aren’t straight from end to end at all.

In terms of point-to-point accuracy, this machine is still surprisingly brilliant, with the pen tip size providing the likely level of precision available.  But straight lines are not there yet.

Oh, one more thing: Sorry about going with arduino 1.0, I know it’s a pain.

I’ve just committed a couple of little updates to the controller software that will make things easier for you all.

1. IMAGE LOADER!!  Finally, don’t know why I didn’t do it ages ago.  It was easy.
2. Import / export command queue.  This is so that you can edit your command queue by hand if you want do do something funky.  Combine portions of a drawing, that kind of thing
3. Picture frame is now useful.  Those four coloured circles you see are the picture frame.  I use them as a guide to where to click when I want to be able to select the same area lots of time.  Well, now there’s two buttons, one that sets the picture frame to be the same as the current selected box (save selection), and the other that just draws a selection box, based on the picture frame (select frame).  Useful.
4. The information overlay can be toggled on or off with the “I” key.
5. The pixels are now automatically recalculated after moving the image.  Don’t have to re-select the box to prompt it.
6. mmPerRev and stepsPerRev are now stored in the properties file rather than hardcoded.  They are NOT uploaded to the machine though.

Now many of you have received your machines, and are bolding setting about destroying decorating your walls with them, I’ve made a couple of updates to the software guide, namely mentioning the extremely key point of how to get your machine size settings from the UI into the arduino itself. I’m positive I have written this somewhere already, but I can’t find it, so maybe I just imagined it:

Save machine size into hardware (IMPORTANT!)

The hardware (arduino) needs to know the size of the machine too, so once you’ve got your proper machine size into your properties file, and your processing controller running, go to F3-Details page and click both change machine buttons. This puts the machine values into EEPROM on the board, and it’ll be saved until next time.

from Polargraph Software Guide v2

I’ve chatted with a fair few of you on email and things, but I’d also like to remind anybody that there’s a forum on this site too, and it might be useful for other polargraphers to share the questions there.  That could be a good resource of information, particularly for new users.

Machine size is too big for your screen issue

Those bold fellows amongst us striving for very large machines (or those with very small screens) will have noticed that the UI doesn’t play nice with them.  The problem is that the machine size and image size is coupled directly to the pixel size on-screen.  So a 1800mm wide machine will be 1800 pixels wide onscreen, and that doesn’t leave a lot of room for much else.

I am working to decouple these things, and that should also make it a lot easier to zoom, and to resize the image to fit the page, that kind of thing.

Thanks for your feedback everyone, this is fun!

The first couple of polargraph machines are on their way!  I have had a little factory set up, and am testing each machine with a drawing.

So each will ship with its first drawing.  I AM PLEASED.  Also slightly updated the instructions.