Tag Archives: firmware

A flurry of activity

Posted on by
10

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.

live-trace-example

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.

Grace Kelly in spirals
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.

Get the bundle at https://code.google.com/p/polargraph/downloads/list

 

A weekend of fixes

Posted on by
Reply

Hello, please find enclosed a few fixes, an improvement, and a new feature.

Fixed:

  • Controller – Pulling a selection area that overhangs the bottom of an image would cause an unhandled exception.  Fixed by mending the Rectangle.surrounds(..) method.  Off by one, tsk.
  • Controller – Changing to another serial port would always set the baud rate to 57600, regardless of what was set in the properties file.
  • polargraph_server_mega – Rolled mbcook’s pbm format fixes into the mega branch.  I’d forgotten that I had to do that.  Also rejigged it a little, but cosmetic.

An improvement:

  • polargraph_server_* – All firmwares have had their straight line (C17) commands improved.  The last version was ok, but seemed to work much better on polarshields than on the adafruit shield, because of a poorly scaling acceleration algorithm.  It was pretty pausey.  I have pinched the acceleration algorithm from Mike McCauley’s Accelstepper library, and that works much, much better.  I even half understand it.

And a feature in a pear tree:

Vector art that has been created from an automatic bitmap tracing process tends to be made up of loads of tiny lines.   When processed through the controller and quantised to the grid of the machine, they often end up on top of each other, and duplicate points are just slow.

So I’ve added this new slider, which is essentially a lowhigh-pass filter that filters out lines below a certain length.  It re-samples longer lines, and discards entirely lines that are shorter than the threshold.  See these two vector previews:

The left-hand figure has only duplicate points filtered out, this brings it down from around 15,000 commands to 11,700.  Quite a few of those are still just single points – just dots.

The right-hand figure has the shortest vector filter bumped way up, and only has 300 commands.

The drawing wasn’t very good because my pen was running out and it was a bit fast, but you get the point.  Smaller filter values will result in more fidelity, while bigger values will have a more dramatic effect.

Polargraph v1.2.4.  Code in the repo as usual, and compiled and bundled up in a zip.

More updating firmware without using Arduino

Posted on by
6

I realised that the Arduino Uploader (featured here earlier) doesn’t work for Mega2560s.  Easy enough to fix, but I wanted something that’d work out the box so I’m recommending XLoader instead.  Works much the same way.  In fact, I’m just going to leave you with this screenshot and a couple of links.

Download XLoader from the XLoader site.

And download the precompiled firmware you want to update to (do right-click-> save target as…):

Start XLoader, load the hex file you downloaded into it, select your device (Mega(ATMEGA2560) for PolargraphSD machines, Duemilanove/Nano (ATMEGA328) for older Polargraph machines), select your COM port and press UPLOAD.
UPDATE- [minor] WARNING WILL ROBINSON.
Kongorilla points out to me that XLoader is a little unforthcoming in the event of a problem – If you load a file that isn’t a hex file, then it still goes through the charade of loading it, but then quietly announces at the end “0 bytes uploaded“.  So keep an eye on the status line to make sure it actually does what you think it’s doing.

Some interesting stuff that you probably aren’t interested in:

Note that I’m going to start uploading the compiled hex files to the SVN repository so I don’t have to faff on with updating zips and things.  The problem with this is that the hex file will not automatically be the compiled version of the code that is next to it in the repo.  I’ve still got to do that bit manually so it’ll probably be out-of-sync much of the time.

The way to check to see if the source code has been updated since the hex file has been compiled is to look at the revision numbers:

In this case, the source code (the .ino file) has been updated in the same revision as the compiled file (the .hex file).  This means that there hasn’t been any updates to the source code since the hex file was compiled.

If the source code has a higher revision number than the hex file, then the hex file is an older version and won’t reflect the changes in the source code.  You should compile it yourself (the regular way, through Arduino IDE).

Uploading firmware without Arduino

Posted on by
1

EDIT! – Use XLoader instead of this – it’s just as good and works on more boards.

Hello, a few people have had problems getting their programs uploaded to their arduinos.  I haven’t.  Not rubbing your faces in it, but if I can’t replicate it, I can’t fix it.  I think it might be something to do with bootloaders, but who knows.

EDIT! Looks like it is to do with bootloaders – Matt’s adventures confirm that.  I think it’s restricted to UNOs of a certain age.  The only UNO I ever owned I blew up literally hours after getting it, so can’t test.  And I don’t think this way of uploading will get around the issue – you might just have to reprogram your bootloader.

A second problem is that you need a couple of libraries installed, and not everybody want’s to harass themselves with that.  So I’ve made a precompiled hex file that you can load onto your arduino to save you that hassle.  You don’t even need to have arduino installed anymore.

What you need:

  1. The hex file is here.
  2. ARP-Uploader.  This is the thing that uploads the hex.  Get it from here.

And that’s it.  Unzip and startup ARP-Uploader, load up your hex file that you downloaded.

Choose the COM port that your arduino is on, and m328p as the microcontroller.

Change the baud rate from 19200 to 57600 where I’ve highlighted in the pic.

Press upload!

I’d be interested in knowing if this helps anybody who is having sketch size issues too.

OK, this hex file is good for Arduino UNO, Duemilanove, or any ATMEGA328-based arduinos.