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:
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 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.
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:
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 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:
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.
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.
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.
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.
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.
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.
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:
There’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!:
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:
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!
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.
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.
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!
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!
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.
