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.