With about 3’500 folder, we would have been quickly mad.

And of course, moving all files in one folder isn’t possible, because they already are sorted.
There is probably many other (programmatic and smarter) solutions, but the punk-ier still is the funn-ier, no ?

So my solution is to recycle an old project, writing this post and going for a nice diner, while the mechanism goes by it-self…

PS: I guess it’s a good way to test keyboards…

#include 

Servo servo;

int servo_pin = 9;

void setup ()
{
  servo.attach(servo_pin);
  Serial.begin(57600);
  Serial.println ("Finished setup\n");
}

void loop ()
{
  servo.write(115);
  delay(250);
  servo.write(80);
  delay (1000);
}

When I ordered the printer, I was expecting a tool and not a toy. I strongly hoped that I would be able to print my own parts for bots, prototype and so on. I believe I will now be able to use it as a tool, but it took some work and tinkering to get there.

When the package arrived, I had to wait 2 more days before starting to build the machine. But then, I forgot all my duties and dove deep in the assembly for what turned out to be a long evening of happiness. I can easily relate this moment with my child memories: spending days and night with legos, mekanos and computers, where the conscience is a perfect mix of dreams and reality.

Building the printer was easy. It’s pretty well explained on wiki.makerbot.com. The parts are precise and well designed.
Except for some details with the plastruder and the inversion of two motor axis, everything worked out of the box.
However, I experienced pain with the software. Skeinforge is a complicated software, because 3D printing by extrusion is something complicated. But Skeinforge is also a bit immature and performances are not that good.

Anyways, finally I was able to print little pieces. However, when I tried larger pieces or more complicated forms, the plastruder jammed. It took me a while to understand the multiple origins of this problem:

1. the plastruder

Assembling the extruder isn’t that difficult as long as you understand what really matters !
It is well documented on the internet, but I think it’s worth telling again.
Two mechanism are fundamental :
1. the ABS filament propulsion
The force which causes the extrusion has to be powerful and constant. Makerbot industries produced a new pulley gear which improves this aspect.
It turns out after a short while that the idler bearing brike because of the excessive forces bearing on it.
To make it push ‘like a charm’ I had to check the following points twice :
- the idler pulley is stable and well aligned with the motor pulley (which is not so easy, I used spare washers)
- the motor pulley used should be the MK5 model, the new one
- washers around the idler bearing should be oriented to produce as little friction as possible
- the gad between both pulleys is tight and correct (use the calibration tool to check)
- everything is well tightened

It should be very difficult (and not recommended) to keep the filament from going forward through the pinch system.

2. the linearity of the filament’s path through the insulator to the heater barrel
When the heat is on, it happens that the PTFE insulator expands with the effect to let ABS matter leak between the insulator and the heating barrel. The more material leaks, the wider the gap grows.
When the insulator inflates it becomes impossible to extrude.
Digging the web I found two solutions :
- Using PEEK insulator instead of PTFE seams to improve durability (I haven’t tried this yet, my parts have just arrived)
- Tighten the insulator with a hose clamp (which I did on my old defunct PTFE insulator)

3. the heating platform

A heating platform is a good choice. Mine is made of 3 8ohm resistors setup in serial.

With theses two adaptations, I’ve been able to print almost everything.

ReplicatorG

Working with skeinforge’s configuration was a bad adventure. Fighting with parameters and struggling with weak performances isn’t easy at all.
Hopefully the new ReplicatorG can hide all those details for beginners and grumpy guys like me.

Tonight is the first time I could print in peace and reliably, without worries, which explains my motivation in writing this post. I’m happy and looking forward to finding lots of real use for my printer. Thanks to makerbot industries and thanks to all the makerbot owners who helped me find a solution.

links

STL-> gcode improvement witch CUDA : http://pleasantsoftware.com/developer/3d/
Interesting experiments : http://hydraraptor.blogspot.com/
hose clamp solution on makerbot blog : http://blog.makerbot.com/2010/07/14/barriers-barrels-ptfe-oh-my/
hose clamp solution on makerbot forums : http://wiki.makerbot.com/forum/t-250421

To allow for better control, I updated the communication protocol between the desktop program and the robot. The previous version supported a minimal set of commands (stop, forwards, spin left, spin right). This set has been replaced by a tuple of values directly controlling the speed of the left and right motors. This allows us to write a more “ambitious” target following algorithm.

The new heuristic is in two steps, speed and direction. We first determine the distance between the tracked robot and the target, and set the speed component as a proportion to distance (close = slow, far = fast). The direction is calculated in a similar fashion: we turn in the direction of the target, the bigger the angle difference between the current heading of the 3pi and the target, the stronger the turn. This remains a simple algorithm, but I a kind of like the behavior. There is more life to it. The following video illustrates (the white dot represents the position of target, the orange dot represents the position of the tracked 3pi robot).

3pi pololu robot controlled via ir tracking: second test from david hodgetts on Vimeo.

The 3pi pololu robots are fairly simple, so I figured it would be easier to consider the robots as brainless and blind particles under the control of an all-seeing “smart” desktop computer.

The first problem was remote communication with the 3pi. Thankfully, Theo was kind enough to mount an xbee module on one of the bots. This allows remote communication via a serial port abstraction.

The second problem was vision, the desktop controller needs to know the position of the 3pi. As I wanted to create a test environment quickly I fired up CCV instead of written custom tracking code. This is an open source tracker usually used for multitouch surfaces.

I thought it would be interesting to track the 3pi with Infrared light, this would allow for a overhead projection to be added later without influencing the tracking. I used an IR sensitive ps3 eye webcam and Theo added an infrared led to the 3pi to make it visible to the camera (it’s the led on top of the mast on the 3pi picture). The setup was ready to track and send the position of the 3pi to the main desktop program. Now that I knew the position of the 3pi, it was time to make it find and move to a new arbitrary position (target).

For a first test, I opted for a very naive strategy. The situation is the following:
1. we know the position of the 3pi via tracking but not its orientation (visually tracking the orientation is too big of a problem for this first test).
2. we can control the motors of the 3pi, make it move forwards and turn, but we can’t tell it to move or turn a known distance (for instance you can’t tell it to turn 30 degrees).

However, if we tell the bot to move forwards, and we track the movement, we get a new position, which we can compare to the starting position and transpose as a vector, and now we have a direction.

The next step was to decide for a simple vocabulary of movements for the 3pi. I decided that it could either be moving forwards, or spinning to the right, or spinning to the left or, finally, it could be immobile. The heuristic is then quite simple:

1. move forwards

2. are we close enough to the target to be considered the final position?
if yes
stop all done.
else
are we getting closer to the target?
if yes
continue forwards
else
decide if target is to the left or to the right of 3pi and spin in the corresponding direction, then goto 1

Granted this is very naive, but fine for a proof of concept stage.
I used openframeworks to read the tracking information and to communicate serially (xbee) with the 3pi.

You can see the first result in the following video. On the screen, the white dot represents the target and the blue dot is the tracked position of the 3pi.

As you can see the basic system is in place, but there is still a lot of work to get a more fluid experience : )

open /Applications/Blender/blender.app --args -W

I tried to put it directly in Info.plist which wasn’t possible.

Using automator I have been able to build another user application (kind of script) that runs Blender with the fullscreen parameter.
All through the Finder so it’s easy, even for newbs and lazy creatures.

Finally you can shortcut it to your dock or anywhere else.

blender_fullscreen.app

ERRATA
I had some strange issues using the -W switch. Use the command below instead :

open /Applications/Blender/blender.app --args -p 0 900 1440 900

Where 1440 and 900 are X & Y of your resolution.

Open the package using open package content of your Automator script and edit Info.plist. Add:

<key>LSUIPresentationMode</key>
<real>4</real>

/ERRATA

/* RS 485 V1 Master, using a SN75176BP

                              -------
                          RO -|     |- VCC [connect to 5v]
                              |     |
                          RE -|     |- B-------------->   [connect to Slave's B]
                              |     |        | 120R (parallel resistor)
          connect to 5V   DE -|     |- A-------------->   [connect to Slave's A]
                              |     |
   connect to pin 1 (TX)  DI -|     |- GND [connect to GND]
                              -------

*/
const int ledPin = 13;      // the pin that the LED is attached to

void setup() {
  Serial.begin(9600);
  pinMode(ledPin, OUTPUT);
}

void loop() {

  byte b = 0;

  Serial.write(b);
  analogWrite(ledPin, b);
  delay(1000);

  b=255;

  Serial.write(b);
  analogWrite(ledPin, b);
  delay(1000);
}

And now for the slave:

/* RS 485 V1 SLAVE, using a SN75176BP

                              -------
   connect to pin 0 (RX)  RO -|     |- VCC [connect to 5v]
                              |     |
          connect toGND   RE -|     |- B-------------->   [connect to Master's B]
                              |     |        | 120R (parallel resistor)
                          DE -|     |- A-------------->   [connect to Master's A]
                              |     |
                          DI -|     |- GND [connect to GND]
                              -------

YOU'LL HAVE TO DISCONNECT RO DURING UPLOAD TO I/O BOARD!!!!!!!!!                          

*/
const int ledPin = 13;      // the pin that the LED is attached to

void setup() {
  Serial.begin(9600);
  pinMode(ledPin, OUTPUT);
}

void loop() {
  byte brightness;

  if (Serial.available()) {// check if data has been sent from the computer:

    brightness = Serial.read(); // read the most recent byte (which will be from 0 to 255):

    analogWrite(ledPin, brightness); // set the brightness of the LED:
  }
}

If all goes according to the plan, you should see something like this:

However, before starting I should warn you that my knowledge of Blender is virtually non-existent. The blender specific code used here to generate faces is probably not ideal and you’re very welcome to improve that part.

So, what do we want to do? Make triangles, lots of them. We probably need a function to generate triangles. Let’s stay simple and assume that a triangle is composed of 3 points. We are in a 3d space so each point will have 3 components. We shall refer to these points as Vertices. There are many ways to represent this type of data in Python. For something different, let’s try namedtuples. They provide an elegant extension to the base tuple type. They work as follows:

from collections import namedtuple

Vertex = namedtuple('Vertex', 'x, y, z')  # define vertex 'type'

v1 = Vertex(0.0, 0.0, 0.0) # define a Vertex tuple, with positional arguments

v2 = Vertex(x=0.0, y=0.0, z=0.0) #define a Vertex with named arguments

x, y, z = v2    # unpack as regular tupple

x = v.x   # accessible with named parameter

We can now define our triangle function

#import blender bindings
import Blender
from Blender import NMesh
from Blender.BGL import *
from Blender.Draw import *

def triangle(a, b, c):
    """generate triangle geometry
       we expect a b c to be namedtuples of type Vertex"""

    ######### Creates a new mesh
    poly = NMesh.GetRaw()

    ### fill vertices
    v = NMesh.Vert(a.x, a.y, a.z)
    poly.verts.append(v)

    v = NMesh.Vert(b.x, b.y, b.z)
    poly.verts.append(v)

    v = NMesh.Vert(c.x, c.y, c.z)
    poly.verts.append(v)

    ## create a face
    f = NMesh.Face()
    f.v.append(poly.verts[0])
    f.v.append(poly.verts[1])
    f.v.append(poly.verts[2])
    poly.faces.append(f)

     ######### Creates a new Object with the new Mesh
    polyObj = NMesh.PutRaw(poly)

    Blender.Redraw()

My poor knowledge of blender doesn’t allow me to say much about this code. We basically use the api to generate a three point polygon. As said, please improve or correct this part.
Time for a first test!

#define the three vertices of a triangle
a = Vertex(0.0, 0.0, 0.0)
b = Vertex(25.0, 50.0, 0.0)
c = Vertex(50.0, 0.0, 0.0)

triangle(a, b, c)

We define three vertices for our test triangle and call the triangle function. The next step is to load the code in Blender’s text editor and to press Alt-p to run the code.

(sorry for the crappy window in the middle)

Ok, so let’s get to the meat of the problem, i.e. the recursive subdivision. I use the basic algorithm from here, and adapted it to python:

def divideTriangle(a, b, c, step):
    """ recursive divide until step == 0"""

    if step > 0:
        #compute midpoints of sides

        midpointof = lambda v1, v2: Vertex(x = (v1.x + v2.x) * 0.5,
                                           y = (v1.y + v2.y) * 0.5,
                                           z = (v1.z + v2.z) * 0.5)

        ab = midpointof(a, b)
        ac = midpointof(a, c)
        bc = midpointof(b, c)

        # divide all but center triangle

        divideTriangle(a, ab, ac, step - 1)
        divideTriangle(c, ac, bc, step - 1)
        divideTriangle(b, bc, ab, step - 1)
    else:
        #stop recursion and generate geometry
        triangle(a, b, c)

I tried to be as expressive as possible, but I have the feeling that there is something fishy in the midpoint lambda. I guess it could be simplified. But it will do for now. Let’s put it all together, and see what we get in blender.

from collections import namedtuple

import Blender
from Blender import NMesh
from Blender.BGL import *
from Blender.Draw import *

Vertex = namedtuple('Vertex', 'x, y, z')  

def triangle(a, b, c):
    """a b c are of type Vertex"""

    ######### Creates a new mesh
    poly = NMesh.GetRaw()

    ### fill vertices

    v = NMesh.Vert(a.x, a.y, a.z)
    poly.verts.append(v)

    v = NMesh.Vert(b.x, b.y, b.z)
    poly.verts.append(v)

    v = NMesh.Vert(c.x, c.y, c.z)
    poly.verts.append(v)

    ## create a face
    f = NMesh.Face()
    f.v.append(poly.verts[0])
    f.v.append(poly.verts[1])
    f.v.append(poly.verts[2])
    poly.faces.append(f)

     ######### Creates a new Object with the new Mesh
    polyObj = NMesh.PutRaw(poly)

    Blender.Redraw()

def divideTriangle(a, b, c, step):
    """ recursive divide until step == 0"""

    if step > 0:
        #compute midpoints of sides

        midpointof = lambda v1, v2: Vertex(x = (v1.x + v2.x) * 0.5,
                                           y = (v1.y + v2.y) * 0.5,
                                           z = (v1.z + v2.z) * 0.5)

        ab = midpointof(a, b)
        ac = midpointof(a, c)
        bc = midpointof(b, c)

        # divide all but center triangle

        divideTriangle(a, ab, ac, step - 1)
        divideTriangle(c, ac, bc, step - 1)
        divideTriangle(b, bc, ab, step - 1)
    else:
        triangle(a, b, c)

#main

a = Vertex(0.0, 0.0, 0.0)
b = Vertex(25.0, 50.0, 0.0)
c = Vertex(50.0, 0.0, 0.0)

divideTriangle(a, b, c, 5)

and in blender:

Sierpinsky triangle with 5 levels of subdivision

All done : )
I leave the extruded version as an exercise for the reader.

In attachment, code, schematics and video for reuse and improvement.

thanks to fritzing

/* Theo Reichel, Reichel Complex AI, 02/2010 */

int sensorPin = 2; // interrupt 0
int sensorAlimPin = 4;
int ledArrayPin = 9; // PWM
int buttonPin = 3; // interrupt 1
int ledPin = 11; // PWM

volatile bool sensor_status = LOW;
volatile bool button_pressed = LOW;

volatile unsigned int light_power;

unsigned long sensor_millis_diff = 0;
unsigned long sensor_status_age = 0;

volatile int menu;
int i;

void setup()   {
  Serial.begin(19200);
  Serial.println("Labo desk light with detector started");

  pinMode(ledArrayPin, OUTPUT);
  pinMode(sensorAlimPin, OUTPUT);
  pinMode(ledPin, OUTPUT);
  pinMode(buttonPin, INPUT);

  digitalWrite(sensorAlimPin, HIGH);

  attachInterrupt(0, sensor_trigger, CHANGE);
  attachInterrupt(1, user_button, FALLING);
}

void loop()
{
// menu
  while (menu == 0)
    detector();

  while (menu == 1)
    always_on();

  while (menu == 2)
    always_off();
}

void fadein()
{
  for (light_power; light_power<255; light_power++)
  {
    analogWrite(ledArrayPin, light_power);

    if (button_pressed) // button can interrupt fade
    {
      button_pressed = LOW;
      break;
    }

    delay(5);
  }
  if (light_power == 255) // electrical workaround
    digitalWrite(ledArrayPin, HIGH);
}

void fadeout()
{
  for (light_power; light_power > 0; light_power--)
  {
    analogWrite(ledArrayPin, light_power);

    if (sensor_status) // sensor can interrupt during fadeout.
      break;

    if (button_pressed) // button can interrupt fade
    {
      button_pressed = LOW;
      break;
    }

    delay(10);
  }
  if (light_power == 0) // electrical workaround
    digitalWrite(ledArrayPin, LOW);
}

/////////// programs /////////////

void detector()
{
  digitalWrite(ledPin, 50);

  if ( sensor_status )
  {
    Serial.print("update sensor_status_age: ");
    Serial.println(sensor_status_age);
    sensor_status_age = millis();  

    if (light_power < 255)
    {
      Serial.print("fadein from light power: ");
      Serial.println(light_power);

      fadein();
    }
  }
  else
  {
    sensor_millis_diff = millis() - sensor_status_age;

    if ( light_power > 0 && sensor_millis_diff > 60000 )
    {
      Serial.print("fadout from light power:");
      Serial.print(light_power);
      Serial.print(", duration without motion");
      Serial.println(sensor_millis_diff);

      fadeout();
    }
  }
}

void always_on()
{
  digitalWrite(ledPin, HIGH);

  if (light_power < 255)
    fadein();
}

void always_off()
{
  analogWrite(ledPin, LOW);

  if (light_power > 0)
    fadeout();
}

/////////// interrupts /////////////

void sensor_trigger()
{
  sensor_status = !digitalRead(sensorPin);
}

void user_button()
{
  button_pressed = HIGH;

  if (menu == 2)
    menu = 0;
  else
    menu++;
}

The next project in the same wave is to make a nice PCB, arduino compatible with FET and detector on board.
Adding some nice little things like RTC, light sensor and a little led display, I plan to build a better light management.
For instance, if the room is bright enough the leds stays off.
If the time is far in the night, meaning that I’m not supposed to be awake, the light is faded to keep it soft for my eyes.
And of course a single push button to iterate different modes.

There is probably a lot more to do to make “clever” lights.
Feel free to share your ideas, I’m very interested.
But please, don’t mention clapping in the hand like in SF movie. I believe the light is improved if it adapts to our presence without our explicit will or interaction.