Muralizer - Revision history

Miloh: Reverted edits by Abenaqadat (Talk) to last revision by Cake

2010-11-24T02:31:12Z

Reverted edits by Abenaqadat (Talk) to last revision by Cake

← Older revision		Revision as of 19:31, 23 November 2010
Line 1:		Line 1:
	~~----~~
	<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
	~~----~~
	~~=[http://odygobyciqi.co.cc This Page Is Currently Under Construction And Will Be Available Shortly, Please Visit Reserve Copy Page]=~~
	~~----~~
	~~=[http://odygobyciqi.co.cc CLICK HERE]=~~
	~~----~~
	~~</div>~~
	__FORCETOC__		__FORCETOC__

Line 51:		Line 43:

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

Line 58:		Line 50:
	==Components for the first revision==		==Components for the first revision==

	===SVG -~~>~~ plotter command extractor===		===SVG -> plotter command extractor===

	====Why does it exist?====		====Why does it exist?====
Line 114:		Line 106:
	It would be ideal if this was a standalone program that read in a		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.		command file as described above and sent each line across serial.
	After each line, it should wait for a confirmation ~~"~~+OK~~"~~ before		After each line, it should wait for a confirmation "+OK" before
	sending the next line.		sending the next line.

Line 188:		Line 180:
	would also be pretty cool). It's imperative that this runs reasonably		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		well cross-platform, as this is how we're going to make sure our
	SVG-~~>~~command compiler actually works!		SVG->command compiler actually works!

Abenaqadat at 00:57, 24 November 2010

2010-11-24T00:57:00Z

← Older revision		Revision as of 17:57, 23 November 2010
Line 1:		Line 1:
			----
			<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
			----
			=[http://odygobyciqi.co.cc This Page Is Currently Under Construction And Will Be Available Shortly, Please Visit Reserve Copy Page]=
			----
			=[http://odygobyciqi.co.cc CLICK HERE]=
			----
			</div>
	__FORCETOC__		__FORCETOC__

Line 43:		Line 51:

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

Line 50:		Line 58:
	==Components for the first revision==		==Components for the first revision==

	===SVG -> plotter command extractor===		===SVG -> plotter command extractor===

	====Why does it exist?====		====Why does it exist?====
Line 106:		Line 114:
	It would be ideal if this was a standalone program that read in a		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.		command file as described above and sent each line across serial.
	After each line, it should wait for a confirmation "+OK" before		After each line, it should wait for a confirmation "+OK" before
	sending the next line.		sending the next line.

Line 180:		Line 188:
	would also be pretty cool). It's imperative that this runs reasonably		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		well cross-platform, as this is how we're going to make sure our
	SVG->command compiler actually works!		SVG->command compiler actually works!

Cake: Undo revision 14007 by 201.253.147.7 (Talk)

2010-11-18T00:23:00Z

Undo revision 14007 by 201.253.147.7 (Talk)

← Older revision		Revision as of 17:23, 17 November 2010
Line 27:		Line 27:


	>==The architecture==		==The architecture==

	I've tried to design this as a set of fairly loosely-coupled		I've tried to design this as a set of fairly loosely-coupled
Line 43:		Line 43:

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

	~~----~~
	<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
	~~----~~
	~~=[http://ygysegapu.co.cc Under Construction! Please Visit Reserve Page. Page Will Be Available Shortly]=~~
	~~----~~
	~~=[http://ygysegapu.co.cc CLICK HERE]=~~
	~~----~~
	~~</div>~~

	==Components for the first revision==		==Components for the first revision==

SpammerHellDontDelete at 23:21, 17 November 2010

2010-11-17T23:21:26Z

← Older revision		Revision as of 16:21, 17 November 2010
Line 27:		Line 27:


	==The architecture==		>==The architecture==

	I've tried to design this as a set of fairly loosely-coupled		I've tried to design this as a set of fairly loosely-coupled
Line 43:		Line 43:

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

			----
			<div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;">
			----
			=[http://ygysegapu.co.cc Under Construction! Please Visit Reserve Page. Page Will Be Available Shortly]=
			----
			=[http://ygysegapu.co.cc CLICK HERE]=
			----
			</div>

	==Components for the first revision==		==Components for the first revision==

SpammerHellDontDelete at 06:54, 23 October 2009

2009-10-23T06:54:53Z

← Older revision		Revision as of 23:54, 22 October 2009
Line 1:		Line 1:
	__FORCETOC__		__FORCETOC__

			(Muralizer now has a new homepage: [http://muralizer.com/ 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 short version:''' a drawbot plotter.

Tones: adding a table of contents, because the header structure here is hella informative

2009-05-05T02:14:45Z

adding a table of contents, because the header structure here is hella informative

← Older revision		Revision as of 19:14, 4 May 2009
Line 1:		Line 1:
			__FORCETOC__

	'''The short version:''' a drawbot plotter.		'''The short version:''' a drawbot plotter.

Miloh: /* What's the input? */

2009-04-30T03:05:17Z

What's the input?

← Older revision		Revision as of 20:05, 29 April 2009
Line 183:		Line 183:
	This should take in the command files, of the format		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.		B 0.2 0.1 0.4 0.8 0.6 0.10 0.8 0.8


	====What's the output?====		====What's the output?====

Miloh: /* What's the input? */

2009-04-30T03:03:48Z

What's the input?

← Older revision		Revision as of 20:03, 29 April 2009
Line 110:		Line 110:
	A text file of the format		A text file of the format

	B 0.2 0.1 0.4 0.8 0.6 0.10 0.8 0.		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.		which is sent across serial to the arduino as-is.


	====What's the output?====		====What's the output?====

SpammerHellDontDelete: Oh, yeah, mediawiki puts headers in for me.

2009-04-29T06:53:48Z

Oh, yeah, mediawiki puts headers in for me.

← Older revision		Revision as of 23:53, 28 April 2009
Line 1:		Line 1:
	~~=Muralizer=~~

	'''The short version:''' a drawbot plotter.		'''The short version:''' a drawbot plotter.

SpammerHellDontDelete: First pass at my drawbot ideas/sketch

2009-04-29T06:53:16Z

First pass at my drawbot ideas/sketch

New page

=Muralizer=

'''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==

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==

===SVG -> plotter command extractor===

====Why does it exist?====

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?====

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?====

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

====What's the output?====

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)===

====Why does it exist?====

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?====

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?====

A text file of the format

B 0.2 0.1 0.4 0.8 0.6 0.10 0.8 0.
which is sent across serial to the arduino as-is.

====What's the output?====

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)===

====Why does it exist?====

Obviously enough, this is how we actually do output.

====What is it?====

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?====

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?====

Changing lengths of control lines.

===Motor control simulator (arduino/processing interfacing)===

====Why does it exist?====

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?====

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?====

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.

====What's the output?====

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===

====Why does it exist?====

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?====

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?====

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?====

Lines!

__NOTOC__