Uncategorized

Makelangelo Update: Higher Resolution Images

2013-04-03 Dan

v0.9.4 is now available from the official page and is, of course, checked into Github. There are two changes.

First, when dithering the image it now uses the average tone of the image as the cutoff value instead of just 50% grey. On the whole I find this means more of the important details are preserved.

Second, Settings > Preferences now includes an “Image Resolution” slider that goes from 50 to 500. The default value is 100. If you increase the value you’ll get more dots in your pictures that are closer together. Here’s a sample at different resolutions.

at 50
50

at 100 (as normal)
100

at 150
150

at 250
250

That last one is estimated to take almost three hours to draw!

On a side note, I love my personal wiki. I wrote down all the steps to update Makelangelo software the last time I did it and followed the steps today. I had forgotten at least three important things and found two ways to improve the method. Process control FTW!

Uncategorized

More Why I Love MediaWiki and Process Control

2013-04-04 Dan

I hate making mistakes.  I know they happen and are sometimes inevitable.  That doesn’t mean I’m going to make the same one twice if I can help it.  Instead of kicking myself I look at the mistake as a lesson I’m being taught – provided I’m smart enough to recognize what the lesson is.  That’s why I set up my Wiki – to document how things should be done so that it never happens again.

My Private Wiki grows daily. It’s a clone of MediaWiki, the same system that runs Wikipedia.  My top level menu now contains:

  • Business Plan (eye on the prize)
  • Roles (who does what)
  • Tools (equipment and how to use it)
  • Materials (consumables like wood & ABS)
  • Processes (how to do things)
  • Event triggers (things that happen and how to deal with them)
  • Holidays & Major Events (to set up sales and such)
  • Blue Sky (future projects)

Today I added “Event Triggers” to that menu.  Event Triggers are “when a thing happens deal with it like this.”  When a bill arrives, this is the right way to pay it.  When a package arrives, this is how you file the contents and update the shop.

Already my brain is boiling with ideas: I’m thinking I might add event triggers to specific sub-pages, like “events that only matter to 3D printing”. As a programmer I can’t help wondering if processes will eventually be consumed by event triggers and everything will be a “if this then that” clause. Maybe soon I’ll have a “main loop” for daily activities.  How much of this can I document, and then how much can I automate?  I’ve already got event triggers that trigger other events.  Will there be a recursive loop?  Do I need try/catch blocks?  Can a company SEGFAULT!?

I’m reminded very much of a book I read not so long ago about a guy who created companies that ran on computers and their only job was to serve as legal structures to screw with music companies.  Doctorow?  Stross?  Tip of my tongue.

William, on of my new favorite-est VHS members, once said to me “an accident is always three mistakes”.  Three lessons in one and all it costs is a risk of serious injury or death.  Woo hoo?

Uncategorized

Spray Paint Makelangelo?

2013-04-08 Dan

Chad writes,

“I have been playing around with draw bots this winter, and I really like your interface. I wanted to get your input on how difficult would it be to scale up the hardware and convert the pen to a paint can? I am a volunteer working with a city revitalizing effort. I would attempt to make a large scale Makelangelo Mural Bot to cover up gang related tagging on downtown buildings.

My thoughts are replacing the spindles with a chain sprocket, the thread would be #25 chain. allowing for long lengths and chain will reduce vertical sway.

Where I am confused how hard would it be to change out the adafruit board to a stepper driver board? Can your interface handle a much larger image? With a can of paint the speed of movement is an issue.

Any input would be greatly appreciated.”

Hi, Chad!

I’d stick with fishing line and increase the bobbin size, maybe get a local hackspace to print some gearing to handle the extra torque on the steppers. The bigger challenge will be the can holder/paint dispenser. The logic changes completely – instead of continuous lines and pen up/down it’s short taps on the nozzle to make dots, kind of like a giant pointilism piece. At the moment that logic doesn’t exist in the software.

It might also be easier to co-opt the tagging kids – pay them (in paint) to make actual murals with approved designs. They’re just trying to express themselves, right? If you give them ownership of the art they’ll defend it and feel pride in their community.

So far the only spraypaint polargraph I know of is Hektor. It only draws indoors. I guess the wind would be a problem for their model.

Anyone else want to convert their Makelangelo to use spray paint? Let’s talk in the forums.

Uncategorized

How cranes build themselves

2013-04-08 Dan

This is too good not to share. I never thought to ask the question until someone showed me the answer.

Miscellaneous

Debugging a DIY Segway at the Vancouver Hack Space

2013-04-10 Dan

Al's Segway device

Al first contacted me by email.  Apparently someone has been telling him that I’m the go-to guy for anything Arduino.  He is not wrong. Sit right here and I’ll tell you about how we went to work on this machine and how far we got in an evening.

A Segway PT drives by sensing the way you tilt your body.  The brain of the robot can sense which way is up and which way you lean.  It does this with a gyroscope.  This model also has an Dead Man’s Switch for safety: you have to hold the button down to make it go, meaning it can’t make any escape attempts.  In order to test the parts early on there’s also a knob to make the robot turn and a knob to make the robot go forward and back.  In theory you could drive this model without the robot brain, but that’s not as cool.

Al did what anyone would do.  He carefully assembled the entire machine by following the steps in the manual, copied the code into the Arduino line by line, and when it was ready flipped the switch.  One wheel started to turn right away and the other did nothing – and nobody was holding down the Dead Man’s switch!

To attack this problem efficiently we made a plan: if we know the fundamentals work then we can test higher-up stuff.  First we have to check the mechanical and electrical connections match the diagram.  Second, we have to check that the inputs work and the Arduino can “hear” them.   Third, test that the brain can make the motors go the right way.  Fourth, we know we have an input > brain > motors connection.  The last step then is teaching the brain how to balance.

We disconnected the motors and then Al got out a sharpie and some masking tape.  I gently pulled on a wire at the top of the steering controls and when the other end at the Arduino moved, he put a piece of tape on and labelled it.  We did that through all the wires, which took about 20 minutes.  You can see a ‘T’ (for turn) on a piece of tape next to Al’s index finger.

Al, being very clever, had drawn a schematic of how the wiring should be done.  We took out all the wires from the red breadboard shield, effectively disconnecting all the controls.  The breadboard has the gyroscope chip mounted in the center for easy connecting to the Arduino.  The breadboard and the Arduino click together like a LEGO sandwich.  Then we used the traced Dead Man’s wire and reconnected it to the pin in the schematic and went poking in the code.  About 40 minutes later we had the light on the top of the breadboard turning on when the Dead Man’s Switch was pushed, and turning off when it was released.  This was an excellent sign!  We didn’t stop for high fives, there was a long way to go.

The next step was to get the knobs and the button all working at once.  To do this I wanted to display on a screen the position of the knobs and the on/off of the button all at once.  The best way I know to debug an Arduino is the Serial interface.  In the code we have a value called steeringPot and another called gainPot.  I wanted to be sure that when the steering knob is turned that only analogRead(steeringPot); would return a changing number between 0 and 1023.  I also wanted analogRead(gainPot) to do work the same when the forward/back knob was turned.  I told the Arduino,

Serial.print(analogRead(steeringPot));  Serial.print('\t');
Serial.print(analogRead(gainPot));  Serial.print('\t');
Serial.print(deadManSwitchState);  Serial.print('\n');

…This is where we hit the biggest bug of the night.  We had the code reporting

1023   1023   1

over and over, no matter what we did to the knobs.  We retested everything.  The always resourceful Simon joined in with a multimeter and tested that the electrical signal from the knob potentiometers was rising and falling as the knob was turned.  It’s his hand in the left of the photo when we tried removing the breadboard to see if it was somehow the problem.  Everything seemed to be working, and yet the Arduino was deaf.  For nearly and hours various people took a crack at it.  In the end, it was a function I’d never used before called analogReference(INTERNAL); that was the culprit.  Nobody caught that the AREF wire in the schematic was missing; the one in the board was removed because it wasn’t in the schematic; and the Arduino was waiting for voltages it would never get.  We removed the line and suddenly we were getting numbers that made sense.

By then it was 11pm and time to go home.  Al promised to work on connecting the 6DOF sensor over the week.  If he does we’ll take another crack at it Tuesday night and you can read all about it here Wednesday afternoon.

I should probably mention along the way John cleaned a 1000 watt amplifier and started putting together the Solidworks computer; Miriam got her Makerbot Cupcake 3D printer moving; Jack was laser cutting; and there were at least 9 other people with as many projects going on that I didn’t even get to talk to.  Come on down and check it out sometime, it’s really something.