Archive for November, 2010

Color wiring diagrams

Whenever I look at a car wiring diagram, I tend to get cross-eyed. The entire thing is usually black-and-white with labels to indicate wire color. When I see a loose wire in the engine bay, it often takes as much as twenty minutes to figure out where in the diagram that wire is located.

But what if the diagrams were in color? Would that not make it easier to locate the wire?

My first stab at this was to sit down with some colored pencils and start coloring away. This actually turns out to be quite relaxing (as one friend pointed out, it’s like kindergarten for adults). It’s not a good way to share the diagrams with others, though, and it’s time-consuming to recolor them if they get lost or damaged. (in my case, I left my binder of 1989 plymouth voyager turbo wiring diagrams on the top my my minivan while driving down a rural highway at 80mph).

This is why we invented computers. Some people may tell you it had to do with codebreaking or physical simulations or the internet, but the real reason they were invented was so we could have our wiring diagrams in color.

Step 1: Download wiring diagrams from here: http://www.oldschoolhotrodder.com/modules.php?name=Downloads&cid=2

Step 2: Load the pdf into acrobat and print it to a ps file

Step 3: Convert the entire ps file to a series of pgm (greyscale) images. The greyscale takes a little more processing time, but the text labels turn out a bit nicer this way.


gs -sDEVICE=pgm -r300x300 -dNOPAUSE -sOutputFile=page%03d.pgm wiring.ps

this will convert every page of the ps file to a file called pageXXX.pgm at a resolution of 300dpi. It should be possible to instead use a bitmap (black and white) at a higher resolution, but I got better results with less processing time using greyscale.

I also tried using greyscale at a higher resolution (600dpi), but this yielded worse quality. Presumably this is because the resolution of the image exceeded the resolution of my input file.

Step 4: I considered writing a script for this step, but it turns out someone’s already done all the hard work of vectorizing the pgm input file. Enter potrace. It takes a bitmap as input and produces a vectorized output in xfig, svg, or a variety of other formats. Beautiful!

I’ll start with one page for now:


potrace -b xfig -o page001.xfig page001.pgm

Coloring it is as easy as loading it up into skencil:

Screenshot-page001.xfig - Skencil

First I select the objects and then ungroup (in the Arrange menu). To color an object, click on it, and select the color. The image above highlights one small problem: potrace decided that the wires that connect in a single dot are a single object. That makes colorizing them a bit trickier.

Two options from here: 1. find a better drawing tool that will let me manually split the polygon, or 2. figure out what options to pass to potrace or autotrace to generate separate objects in the first place.

Tags: ,

A new project

A difficult and unfortunate truth for any hobbyist is that there is only so much time in a single human lifespan. I have wanted to continue to play with JIT compilation, not only because it is useful and an interesting mental challenge, but because it’s a great way to disconnect from the world. Sadly, time does not permit this to happen.

I hope to one day again come back to the hobbyist programming world. It was a difficult decision this year to not attend RubyConf for the first time ever (until this year, I was one of four remaining nine-time attendees). But all good things must come to an end, and ends make way for new beginnings. In my case, new beginning include racing in the 24 Hours of Lemons, building a minivan drag car, and the possibility of entering medical school.

As for the minivan, I would like to make it ruby-powered. K-cars (including the caravan/voyager) are really simple machines, and for a few hundred dollars, every sensor in the vehicle can be datalogged. This is a must for building reliable power: if the engine is not running efficiently, then it’s not producing as much power as it potentially could; worse yet, at high boost it could damage the motor. (yes, you read that right — this minivan has a turbo).

Datalogging a drag-run should be straightforward. I’ve never done anything like this, so what sounds simple when I read about it may turn out to be a PITA. But once I get the datalogger hooked up, how much fun would it be to write a ruby library to intercept the data in real-time? And how much more fun would it be on top of that to visualize this data in real-time using an opengl frontend? Lastly, how slick would it be to take this opengl display and project it onto the windshield ala a heads-up-display?

I’ve wanted to get back into graphics programming for quite a while; now I have an excuse. All I need now is some spare time.

Tags: , , , , , ,