Straight lines are straight

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

 

More Arduino 1.0 – the time has come

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.

Christmas updates

Ho ho ho!

Well, thank you all for your support this year, hope you’re not regretting it!

Software updates:

  • New straight lines.  I have improved C17, the “draw straight line” command.  This now works!  More or less.  There’s still a subtle curve to some lines, with some orientations being more pronounced than others.  This works by splitting the line into lots of little bits, and so although close up they’ll look a little wiggly, overall they should be straight.  And certainly a lot straighter than the old “fastest move” method.  The button for this is “move direct”.  The number of sub-lines it gets chopped into is controlled with “<” and “>” (max segment length).
  • Speedometer.  The motor speed and acceleration speed are both now specified as absolute values rather than relative ones.  The current speed and acceleration is shown in the info overlay, and the keyboard controls are the same, that is “*” and “/” to change the acceleration, and “+” and “-” to change the max speed.
  • Values of motor speed, acceleration and pen tip width are preloaded into the queue on start up.  This should keep things in sync better.
  • Command queue line drawing preview.  This is a little thing, but hints at the next big thing for polargraph machines – vector graphics.  Andy Kinsman has done some brilliant work on writing a little PostScript interpreter that will convert PostScript vector graphics output into line commands for the Polargraph.  This is the best thing that’s happened to polargraphs since ever.  He has a wiki page on the code site and I haven’t had a chance to play with it properly, but hope to get into it over the holidays. It’s very exciting.  So if you load a queue full of C17 commands into the controller, you’ll have a little display of what it might look like drawn.  It’s primitive so far, but this is just the beginnings.
To get the straight lines working, I found a problem with my mmPerRev settings.  Which means all you probably have that problem too, you should fix it.
Set machine.motors.mmPerRev=95.0 to get better fidelity.  It shouldn’t make much difference, but the old setting of 84 is one bead too short, and will lead to your images being compressed vertically, and maybe distorted with narrow bottoms.  Give it a shot please, sorry about the mistake.
There are also a couple of new properties that get saved in the config file, so do a “save” to rebuild your file.
Let me know how you get on, and have a merry christmas and a happy new year!

No more polargraph machines!

Thank you to everybody who bought kits and vitamin packs from me – the last few of you will have your machines heading out to you during next week and will probably get yours in the new year.

But that’s them all gone!  It’s kind of fun running a little factory, but those of you who are still waiting will agree that I haven’t managed it terrifically well, and my wife deserves to get her living room back, so I will not be offering kits again in the foreseeable future.

That said, I’ve got 20 machines worth of cord and sprockets leftover, so if anybody wants those bits I can still sell you some of them.

 

Controller update for countries that use commas as decimal points.

I’ve just committed a couple of very minor code changes to the controller in response to a query on the forum. Turns out I misunderstood how Java’s DecimalFormat class worked, and allowing the locale of the user to change how decimal numbers were formatted for transmission to the board. So the number (for instance) 0.25 was being formatted as 0,25 with a comma. And since I’m using commas to separate parameters, this made it look like 0 and 25 are two separate parameters.

And that made things behave oddly, and anything that has a decimal point in the parameters didn’t work properly.

So, updated code here: http://code.google.com/p/polargraph/source/browse/controller/trunk/polargraphcontroller.pde?spec=svn116&r=116.

Not urgent unless you’re having a problem, but anyone in much of Europe who might have been having problems with certain commands, should get this.

Changed pixel drawing direction algorithm again

Hello, when testing these most recent machines, I decided I really didn’t like the new drawing direction algorithm.  Because when you’re drawing left to right, and then get to the end of the row, and jump to the next one, it tends to draw the first pixel in the new row in the same direction as the previous row.  And I don’t like that. 

So I’ve reinstated the C08 command, that is “change draw direction”, except now it has two parameters, the first is direction mode, which can be 1 (AUTO – where it will choose the direction itself, based on the pen’s current location), 2 (PRESET – where it’ll just draw in the direction you’ve set in the second parameter until you tell it otherwise) or 3 (RANDOM – guess).

The second parameter only really makes sense for the PRESET mode, and it’s the actual direction to draw in, values are 1 to 4, NE, SE, SW, NW.

This looks like a bit of a retrograde step, but in fact it’s only partly that.  It’s an acceptance that unless I load a whole row at a time, or otherwise implement a pixel look-ahead, the machine can’t properly figure out the best direction to draw in, at least not if it takes into account the pixels that are already drawn.  It needs a memory for that, and it’s not getting one til next year.

The good part of this is that the machine’s ability to draw in all four directions is preserved.  It’s up to the controller to tell it what to do.

Controller source code

Embedded source code

Waiting for sprockets, but still moving

Hi everyone, just wanted to apologise for this pause in shipping machines – I had a bit of a miscalculation about how many sprockets I had in stock, so I’m currently waiting for a big batch of new ones.  Orders that were placed on or later than the 2nd of November will be delayed until at least the extra sprockets arrive (hopefully next week).  Outstanding orders for before then will go out this weekend.

I’ve been unexpectedly busy recently too, so that’s my other excuse for my general slowness.  Sorry about that everyone.  You will have your machines for Christmas though.