Muralizer

(Muralizer now has a new homepage: muralizer.com. I (jbm) am trying to make the project into a proper kit in the next month or two.

The short version: a drawbot plotter.

The Details: a program on a computer that reads in SVG files,
compiling them into plotter command files. Another program sends
these over serial to an arduino, which then turns them into motor
control events. And, for good measure, there should be a simulator of
the whole thing, so people can see how their works will look before
committing them to whiteboard or wall.

The Motivation: painting the door at 83c, maybe doing some murals
inside the space, and having it around as a demo for people. We could
also consider loaning it out to people doing murals, etc, which would
be pretty neat. It's also a great performance piece.

It sounds ambitious, but Muralizer is intended to take SVG files and
turn them into complete outlines! There's a bit of work involved in
getting there, but I believe that I could do it myself in two weeks of
evenings and weekends, so we, as a group, should be able to knock it
out pretty quickly. The trick is going to be division of labor and
staying focused, with regular sync-ups to keep folks apprised.

I've tried to design this as a set of fairly loosely-coupled
components. Each component is supposed to be an evening's work for
someone who already knows how to solve the problem, or a couple
evenings/weekend for someone who's learning as they go.

There's a gradual stack: one program turns an SVG file into plotter
instructions, and saves those to a file. Then, another program takes
those instructions and coordinates executing them with an arduino
program via the serial port. That arduino program has two parts: one
to decode the input from serial, and another to control the motors.
All of this needs a physical assembly, of course, which is the last
component of the actual bot.

There's one other piece: a simulator. Having a pure-software version
of Muralizer will let us play with the SVG->command extractor, as well
as serving as a sanity check on the motor control logic.

This frees up our artistic friends to focus on using Illustrator or
Inkscape, instead of fiddling with control points. This is key to
making the drawbot a tool anyone can use, and is probably the coolest
user feature.

A script that turns an SVG input file into a set of plotter commands.
However that's accomplished is great, but it would be helpful if it
were reasonably cross-platform. A simple command-line program that
runs as

We want to draw things that are likely too big to fit into arduino
memory (unless we do some annoying things). We're better off to just
treat the muralizer as a computer peripheral, and do most of the heavy
graphical lifting on the computer side. Why not just put this driver
into the compiler program? Well, that would keep us from doing neat
generative art things, etc. If we separate the format from the
driver, we can use something besides the image compiler to draw, which
is helpful. Also, it keeps these two components really simple and
straightforward.

It would be ideal if this was a standalone program that read in a
command file as described above and sent each line across serial.
After each line, it should wait for a confirmation "+OK" before
sending the next line.

It takes in the bezier control points and runs the motor control
operations required to actually draw those points. That is: it plans
how long to take for the stroke, then figures out how fast to spin the
motors (and in which direction) at each instant within that time
period.

A set of bezier control points as above. I have worked out the math
for how to move the motors over time to plot a bezier curve, so you
just need to to run through that, controlling motor speed as appropriate.

I don't know which motors to choose here, but it seems like variable
speed DC motors are perfect for the job.

This is how we're going to test the whole image compilation/protocol
stack without having to build the hardware up front. This is critical
for allowing us to get our control systems roughed-in early, and to
give us something to sanity check against. There's a lot of other
moving (software) parts, so having a reference implementation is really helpful.

This is a pretty/ugly little program with a graphical display. I've
knocked out something kind of crappy in Processing, and it would be
great if the next version was using that framework as well. (Flash
would also be pretty cool). It's imperative that this runs reasonably
well cross-platform, as this is how we're going to make sure our
SVG->command compiler actually works!

A little graphical window that shows the wires moving around (or
circles representing them), and draws as appropriate. It's nice to
make it take a little time to draw, but doing it nearly-instant is
also good. Not everyone delights in watching process unfold, after
all.

There's a lot of physical stuff in a project like this one. Having
everyone worry about it seems inefficient, so let's put it under the
guise of the person who cares the most: the person who's responsible
for the pen itself.

This is the sum total of the physical device. Basically, it's
everything but the motors and the software: the pulleys, gears, pen
caddy, and mounting hardware. There's a lot of important details in
here, and they're going to get neglected if we don't put someone sharp
on them.

The pen caddy needs to take in a logic +5V and be able to push itself
off the wall, so we can move the pen from the end of one line to the
beginning of another without drawing a line between the two points.
When it does so, it might travel over existing lines, and we don't
want to smudge them, so it needs some way to travel. I'd suggest
Wartenberg Wheels or something similar.