Muralizer

From Noisebridge
Jump to navigation Jump to search


(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.


The architecture[edit]

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.


Components for the first revision[edit]

SVG -> plotter command extractor[edit]

Why does it exist?[edit]

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.

What is it?[edit]

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

 ./mural_compile foo.svg foo.plot

would be great!


What's the input?[edit]

SVG. That's a big can of worms, so let's focus on just extracting bezier curves directly for now.


What's the output?[edit]

The control points for bezier curves, one per line, with a B at the beginning of the line:

 B 0.2 0.1 0.4 0.8 0.6 0.10 0.8 0.8

For now, let's assume the space is square and of dimension 1.0x1.0.


Plotter interface (computer and arduino protocol parser)[edit]

Why does it exist?[edit]

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.


What is it?[edit]

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.


What's the input?[edit]

A text file of the format

 B 0.2 0.1 0.4 0.8 0.6 0.10 0.8 0.8

which is sent across serial to the arduino as-is.

What's the output?[edit]

The arduino side should parse these B-lines, then echo back over serial:

 # Bezier (0.2,0.1), (0.4,0.8), (0.6,0.1), (0.8, 0.8)
 +OK



Motor control (pick motors, arduino software)[edit]

Why does it exist?[edit]

Obviously enough, this is how we actually do output.


What is it?[edit]

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.


What's the input?[edit]

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.


What's the output?[edit]

Changing lengths of control lines.



Motor control simulator (arduino/processing interfacing)[edit]

Why does it exist?[edit]

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.


What is it?[edit]

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!


What's the input?[edit]

This should take in the command files, of the format

 B 0.2 0.1 0.4 0.8 0.6 0.10 0.8 0.8

What's the output?[edit]

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.


Pen caddy and overall physical assembly[edit]

Why does it exist?[edit]

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.

What is it?[edit]

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.


What's the input?[edit]

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.

What's the output?[edit]

Lines!