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.
The 2.2 inch screen that I use for the Polarshield is now unavailable, so I’m switching to the 2.4 inch screen instead. Not much difference, but it does mean the PCB needs to be revisited so that it fits in the same footprint. I only have a couple of the 2.2 inch panels left.
The 2.4 inch screen has a higher resolution, so in principle it can fit more stuff on. But in practice, I will keep the two designs aligned for as long as possible.
So I am planning to remove the XBee socket, and the hardware that goes with it. I don’t think anybody uses it, and I’ll leave some pins open so that I can wire it up again in the future.
I would quite like to have space for a third stepper driver, for doing some like this lissograph drawing machine which I covet deeply. If that happened it would be a mostly unpopulated blank, cos it’s a pretty niche idea. It’s also true that a machine like that could easily fit into an arduino uno sized board, and there’s already plenty of multi-stepper shields out there to choose from.
Apart from that, I’m blank. Does anybody have any feelings about the direction of the cables, locations of the sockets, or the types of connectors, things like that? Drop me an email (sandy dot noble at gmail), or go on the forum.
Cheers!
Sandy
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.
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!
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:
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.
So you wait months for an update and then three come along at once:
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.
…
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.
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.
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.
The serial comms handling on the arduino end is now significantly quicker. Very good!
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!
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
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.
Well, I am stupid.
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.
So forgive me. This was prompted by Makerblock’s lucid response to my childish chest-beating on his blog. I don’t know why it took me so long to actually figure this out.
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!
So I’m going to have a couple of machines running at the Edinburgh Mini Maker Faire, which is on on the 7th of April, 2013 at Summerhall in Edinburgh. I hope to have one or two big slow machines that will be drawing all day, and a little, webcam-driven machine that will be drawing quick (ish) portraits for anybody who wants them.
If you’re in Edinburgh, please come along, and get a scribble that looks somewhat like you! Needless to say, there’s lots of other exciting things afoot at the Faire too, even if drawing machines don’t float your boat (what’s wrong with you?!).
I’m not exhibiting at the main Maker Faire in Newcastle at the end of April, but I will probably be attending, and am hoping to meet up with a few folks then. If anyone is planning on being around, drop me a line.
I’m not sure how many more of these polarshields I’ll be making, I’ve got nine left that I’ve just soldered up, and need a couple for my stand at the Edinburgh Mini Maker Faire at the beginning of April.
Amazingly, that means I’ve made up and sent out 70 (SEVENTY!!!) Polarshields! Almost exactly half polarshield vitamin kits, and half PolargraphSD full machines. It’s so weird!
In case I never order up another batch of PCBs, I’ve made a couple of videos that show the technical build process, soldering etc. They are long, and very very boring.
Soldering:
Testing:
Making cables:
What about that?!