…code, cg, electronics, projects…

This page is about my interests, projects, and profession (video games industry).  I mainly code in Python & Java either directly or with these implementations:  PyGame, pyglet, MEL (Maya Embedded Language), Processing, Android, with a smattering of Arduino tossed in where needed, so you’ll see topics revolving around those languages.  In addition I enjoy a bit of photography and electronic projects (LEDs, soldering, solar gizmos, etc), so they’ll slip in from time to time.  Most of my photography can be found over on Flickr.

Speaking of Processing\Android\Python, you can link to my various programs\apps via the above title bar.

I also maintain several mel\Python\Pygame\Processing wikis that I update far more often than this blog.  See info on their page.

All information on this site is copyright under the Apache Licence v2.0, unless otherwise noted.  Which means you can pretty much use the information here for whatever you like, but I always appreciate credit where applicable.

Have a look around.  Thanks for stopping by.

– Eric Pavey

You always need a good  acronym when developing a new project.  BAT = “Blind Assistance Technology”.

I came up with an idea… sometime last year while working on my “Ponar” tech, to make a device that would help one navigate blindly, by sonar.  It’s been a really slow process to get this prototype off the ground:  Work\life\learning all take their time.  But I finally got something functional.  During development, other similar items have appeared on the web (a Ping\servo glove-based solution, for example).  And they’re great!  But I’ll just start out by saying this idea came to me on its own, not that others haven’t already envisioned it\implemented it (better) elsewhere.

Conceptually, it’s a device you wear on your head that can sense the world around you via ultrasonic sensors.  Based on a certain distance, motors attached to the device will vibrate, tactually telling you you’re getting close to something.  There are a total of three sensors\motors mounted on the front, and each side.

The brains are an Arduino (Uno).  Parallax Ping))) sensors are used for the ultrasonic distance readings, and vibrating DC motors from Xbox 360 controllers are used to convey the distances to the user.  The framework I used to hook everything up was an old hat, using shapelock to form brackets for the motors, Ping))) sensors, & battery pack, and zipties to hold everything else.  Originally I had a single 9v battery powering it,… but…. it made the device was unreliable.  I switched to 6xAA batteries (still 9v total), and it’s much happier now.

Parts List:

• Arduino Uno : 1
• Parallax Ping))) sensors : 3
• Vibrating DC motors (from Xbox 360 controllers) : 3
• Mini-breadboard : 1
• 6x AA Battery-pack : 1
• Small switch : 1
• AA Alkaline Batteries : 6
• Shapelock : enough
• Zip-ties: many
• Hat : 1

Here is a Fritzing image of how the whole thing was wired together:

And here’s a link to the Arduino code.

Project Notes:

• After some research online, I figured out that the rumble motors I received from a friends Xbox 360 controllers only need 2v:  Originally I had a system setup with transistors driving them from the battery directly, but this realization simplified the process.  Furthermore, my multimeter claims they draw less than 20 mA, which makes them safe to be driven off the Arduino’s pins.
• The motors are driven off PMW Arduino pins so I can vary the voltage as distance changes.  In the current configuration, they’ll start to spin as they approach items 1.5m away, and are at full velocity at 1m.
• If I can, I’m going to pick up some pager-motors:  They shouldn’t vibrate one’s head as much as those rumble-motors
• I also have three servos:  It would be interesting to see how well one’s head could ‘detect’ their pressure.
• I had originally powered the system with a single 9v battery.  But the Ping))) sensors and motors wouldn’t behave properly.  When connecting the Arduino over USB for debugging purposes everything worked fine… which didn’t make sense to my limited electrical knowledge:  USB is only 5v, while the battery pack was 9v.  However, my guess is that the 9v battery wasn’t providing enough current for the whole system, while the USB was.  So I switched out for a 6xAA battery pack (equaling 9v total) and everything started working properly.  Presumably however, since the Arduino/Ping only needs 5v, and the motors only 2v, a 4xAA battery system (6v) should work fine.

One of the main goals I have with using the Ostrich-Egg Bot is to generate art for it via Processing.  I’ve successfully drawn and etched a variety of random svg graphics onto a variety of surfaces.  Next step was to get that art from Processing.

Turned out to be a bit more difficult than I expected:  Processing has no native API call for exporting svg’s (that I can find).  But I finally grasped the fact that it can export pdf files via its pdf library.  And these, when imported into Inkscape, have the exact paths you need to plot.  Here’s a vid of the etcher in action based on a Processing-generated image:

And here’s the source for a simple Processing sketch that makes use of this:  The sketch draws a bunch of overlapping circles, larger on the bottom, smaller on the top, and makes sure there is no seam on the edge:

// eggbot_circles01

import processing.pdf.*;

int eggWidth = 3200;
int eggHeight = 800;
int minSize = 32;
int maxSize = 256;

void setup() {
  size(eggWidth, eggHeight);
  smooth();
  background(255);
  frame.setTitle("Eggbot: Circles01");
  noFill();
  beginRecord(PDF, "processingCircles.pdf");
}

void draw() {
  float[] pos = {
    random(width), random(minSize/2, height-maxSize/2)
  };
  float eSize = map(pos[1], minSize/2, height-maxSize/2, minSize, maxSize);
  ellipse(pos[0], pos[1], eSize, eSize);

  // Tile the circles on the x axis:
  if (pos[0] < eSize/2) {
    ellipse(pos[0]+width, pos[1], eSize, eSize);
  }
  else if (pos[0] > width-eSize/2) {
    ellipse(pos[0]-width, pos[1], eSize, eSize);
  }
}

void keyPressed()
{
  if (key == 's') {
    endRecord();
    exit();
  }
}

When the sketch is going, press ‘s’ to save an image, and quit. It actually raises an exception, but the image saves… not sure what’s going on…

From there it’s a simple matter of importing the pdf into Inkscape. I discovered however that its size was bigger than what was defined in the sketch, so I had to resize it to fit the Ostrich-Egg Bot’s drawing area. Here is a close-up of the etcher in action:

And here’s a shot of the final product:

So, not the most amazing thing, but one step closer…