The Making of FAB 9000

AUGUST 8, 2013. Thursday

In about 12 hours we are presenting again final projects and our web sites, and this will be the cutoff for graduation this year. This is the situation right now (1:49 AM): I have to assemble the arm again which will take me about half an hour. I do not have transmission for the elbow joint, tomorrow we'll see what I can do. Motors still do not have enough torque and I don't know why. I thought they needed more power and I just fried stepper driver number 2 using another power supply. Lucky me, before switching the power supply on, I remembered the spiral development and unplugged all the boards except this one, just in case. And finally, I still have to update two tutorials that I left unfinished. I don't know how much time I am going to sleep today, or if I am going to sleep at all. But there is one thing that I know for sure:

Pain is temporary, glory is forever.

That was Francisco, broadcasting live from Fab Academy 2013. Closing link now. Thank you all.

JULY 24, 2013. Wednesday

Today I re-worked the lasercut parts. When you lasercut a part and you notice that you forgot some shapes you have two and only two options. Option 1: Lasercut the whole part again. Option 2: lasercut only the missing shapes in the part that you already have. It is somewhat tricky and I am preparing a tutorial of it. But it can save you a lot of money in materials without spending too much time. The reason I did that is because I changed the motors, and new mount holes were required.

JULY 23, 2013. Tuesday

I've been like two weeks trying to solve the error of the weight calculation. The arm actually weights 67 grams, not 48 as I calculated. At the beginning I could not find out why. I checked the formulas and there were some errors due to radians and degrees. I fixed them, but still, calculations said 58 g instead of 67g. I double checked every line of code and everything seemed OK.

This evening I was looking at the code and when I raised a little bit my eyes I saw the word density. My density was set at 0.94 g/cm3, I found this value in the Internet. When I saw it for the first time I thought: lighter than water? But hey, it is The Internet, it knows it all. Just in case, I looked again for acrylic density and I found another value: from 1.15 to 1.20 g/cm3. I put 1.20 in the density parameter and you know what was the calculated weight, don't you? This is the second time The Internet fools me.

JULY 15, 2013. Monday

Wow, I have just received an email from the European Edition of Maker Faire in Rome!!

That is amazing, I'm going to meet all the best makers of Europe. Here we go Rome!

JUNE 19, 2013. Wednesday

Yesterday I was thinking again about integrating physics simulation inside the CAD design file. About a month ago I emailed Matt Keeter asking him the way of calculating the area of a shape in kokopelli. It looks like there is no easy solution but he found a way to do it by counting the white pixels of the shape. The resulting area is not analytical and hence the precision lays in the resolution of the image. So yesterday I thought that I could calculate analytically the area of my shapes so I started doing this. I always start with a piece of paper:

In the above image there is an error. Beta is actually 180 - alpha. Later I created a custom function for calculating the area, volume and mass of the red arm:

My next step is disassemble the arm and check that the arm weights about 48.87 g, I will do it next Tuesday, when I will try also to finish a couple of unfinished assignments.

JUNE 15, 2013. Saturday

I have successfully implemented linear acceleration motion to the motors in ArmControl.py. When I first used Easydriver with the accelstepper library I thought it was very difficult, and that it was out of my understanding. But it's just a matter of adjusting the delays between steps. The thing I like the most is that I implemented the acceleration without reprogramming the boards, it's all done in the Virtual Control side. I can think of a few advantages of this, like having the arm in a place you cannot reach, or a hostile environment.

    def shoulder(self,steps,sp):
        engine.say('Rotating shoulder')
        engine.say(steps)
        engine.say('steps at')
        engine.say(sp)
        engine.say('steps per second')
        engine.runAndWait()
        # Moving with linear acceleration
        constant_delay=1./sp
        ramp_steps=int((max_delay-constant_delay)/accel_delay)
        if 2*ramp_steps>steps: ramp_steps=int(steps/2)
        flat_steps=steps-(2*ramp_steps)
        actual_delay=max_delay # Init delay
        if steps >=0: # Moving CW
            for k in range (ramp_steps): # Ramping up
                ser.write('(')
                time.sleep(actual_delay)
                actual_delay-=accel_delay        
            for k in range (flat_steps): # Constant speed
                ser.write('(')
                time.sleep(constant_delay)
            for k in range (ramp_steps): # Ramping down
                ser.write('(')
                actual_delay+=accel_delay 
                time.sleep(actual_delay)
        else: # Moving CCW
            for k in range (ramp_steps): # Ramping up
                ser.write(')')
                time.sleep(actual_delay)
                actual_delay-=accel_delay        
            for k in range (flat_steps): # Constant speed
                ser.write(')')
                time.sleep(constant_delay)
            for k in range (ramp_steps): # Ramping down
                ser.write(')')
                actual_delay+=accel_delay 
                time.sleep(actual_delay)
        self.arm_sho+=steps
        print 'Current angular position ('+ str(self.arm_rot)+','+ str(self.arm_sho)+','+ str(self.arm_elb)+ ','+str(self.arm_wri)+')'
        return

JUNE 14, 2013. Friday

I have been talking to Guillem lately. He convinced me to go back to the original idea of Virtual Control (the computer program controls the hardware step by step). So I am not going to follow Neil's advice for the first time. I hope he doesn't mind. He told me not to send serial commands for every step but to send "move N steps". He told me that the clock is not reliable in my computer, it is more reliable in the micro-controller. I started reading how to control time in Python, it is done with the time.sleep() method, but it is only reliable down to about 10-15 ms. If you want to lower it to near 1 ms you need a RTOS (Real Time Operating System). I also read that Ubuntu has a kernel that can do RTOS. But I am on a Mac now.

So let's be in the safe area. Assume my lower delay (maximum speed) will be 20 ms. That means that the maximum speed I can reach with the arm will be 1/20/1000=50 steps per second. Since my motors have 200 steps per revolution that means it will take 2 seconds for moving 180 degrees (which is the usual span for an arm) or 4 seconds in half stepping mode. I don't need it to be faster that this. 

So that is what I did. I reprogrammed original Neil's code (I am so happy that I returned back to C and leaved the Arduino IDE). The code is constantly listening to the serial port. When it receives a certain character it moves one step clockwise. When it reads another certain character it moves one step counterclockwise. That simple! Here is the loop for one of the boards:

   while (1) {
   
    get_char(&serial_pins, serial_pin_in, &chr);
    if (chr == 40) {  // This is the '(' Character
		step_cw();}
	if (chr == 41) {  // This is the ')' Character
		step_ccw();} 
	
	}

In the computer side, this is the code to move a certain number of steps at a certain speed:

    def rotate(self,steps,sp):
        engine.say('Rotating Arm')
        engine.say(steps)
        engine.say('steps at')
        engine.say(sp)
        engine.say('steps per second')
        engine.runAndWait()
        # Moving step by step
        constant_delay=1./sp
        if steps >= 0:
            for k in range (steps):
                ser.write('(')
                time.sleep(constant_delay)
        else:
            for k in range (steps):
                ser.write(')')
                time.sleep(constant_delay)
        self.arm_rot+=steps
        print 'Current angular position ('+ str(self.arm_rot)+','+ str(self.arm_sho)+','+ str(self.arm_elb)+ ','+str(self.arm_wri)+')'
        return

I like this solution because it's simple, and simple is better that complex (The Zen of Python). It has some drawbacks though. I will sweat when I try to code the movement of all 4 motors at the same time

JUNE 4, 2013. Tuesday

While having breakfast today I got an idea. Since the serial communication seems to be interfering with the stepper delays I should create a function for moving n steps so that the micro-controller executes this function before listening again to the serial port. The only drawback is that once initiated a movement, there will be no way to stop the arm. I will try to code this today.

(Evening) So I coded two functions. The first one is move n steps and the second one is move n steps with linear acceleration. The first one has two parameters: number of steps and speed (in steps per second). What I do is compute the delay in ms between each step (1000/speed) and then I enter a loop for moving a step followed by a delay. It should work but it doesn't because the compiler complains that _delay_ms expects a constant integer. So no floats and even no integer variables are accepted. So far I haven't found a way to solve it.

                //

                // move number steps at speed steps per second

                //

                void steps_speed(int number, int speed) {

                 static uint8_t k;

                 int  constant_delay = 1000/speed;

                 if (number >= 0) {

                  for (k = 0; k < number; ++k){

                    step_cw();

                      _delay_ms(constant_delay);}

                  }

                 else if (number < 0) {

                  for (k = 0; k < number; ++k){

                    step_ccw();

                        
              _delay_ms(constant_delay);}

                  }

                }

Even though I did not solve the above problem I started coding the linear acceleration subroutine. This is my strategy. I set the acceleration parameters at the beginning, that is, what would be the delay to start and what is the rate of acceleration. Then I compute how many steps will have the three different parts of the movement: acceleration, the constant speed and the deceleration. And for each one I apply a routine similar to the above routine. It doesn't work because of the same _delay_ms constant integer issue. I am heading to the Iaac. If I find Guillem I'll ask him.

               //

               // stepper movement with linear acceleration

               //

               

               int max_delay = 500;

               int accel_delay = 50;   // Adjust these for
              acceleration

               

               void steps_accel(int number, int speed) {

                static uint8_t k;

                int constant_delay = 1000/speed;

                int ramp_steps =(max_delay-constant_delay)/accel_delay;

                if (2*ramp_steps > number) {

                    ramp_steps = number/2;

                }

                int flat_steps = number - (2*ramp_steps);

                int actual_delay = max_delay; // Init delay

                if (number >= 0) {  // Moving CW

                 for (k = 0; k < ramp_steps; ++k){ // ramping up

                   step_cw();

                  _delay_ms(actual_delay);

                  actual_delay = actual_delay - accel_delay;

                 }

                 for (k = 0; k < flat_steps; ++k){ // Constant
              speed

                     step_cw();

                     _delay_ms(constant_delay);

                 }

                 for (k = 0; k < ramp_steps; ++k){ // ramping down

                     step_cw();

                     actual_delay=actual_delay +
              accel_delay;

                     _delay_ms(actual_delay);

                 }

                }

                  

                else { // Moving CCW

                    for (k = 0; k < ramp_steps;
              ++k){ // ramping up

                      step_ccw();

                     _delay_ms(actual_delay);

                     actual_delay = actual_delay -
              accel_delay;

                    }

                    for (k = 0; k < flat_steps;
              ++k){ // Constant speed

                        step_ccw();

                       
              _delay_ms(constant_delay);

                    }

                    for (k = 0; k < ramp_steps;
              ++k){ // ramping down

                        step_ccw();

                       
              actual_delay=actual_delay + accel_delay;

                       
              _delay_ms(actual_delay);

                    }

              

                 }

                }

Hola

MAY 30, 2013. Thursday

Today I slept for 8 hours in a row at last. Yesterday I finally presented FAB 9000 to the world! Some things like the stepper motors, were not working properly but I am happy that I could progress that much. Guillem Camprodon told me that it could be caused because the serial bus is implemented in software and the delays may interfere with the clock cycles. Since Guillem is an expert I will follow his advice, so this is my next milestone. It was important to be forced by a deadline because this is the only way if you want to finish things. No deadline = unfinished work. I will keep working in the project until it works.

After the worldwide presentation we had a cool party over the new Polycom MCU. In our Lab we had beers and chips. It's sort of funny using so expensive equipment for an online party. Fablab Leon were the best dancers! Cesar Garcia was so funny!

MAY 28, 2013. Tuesday Evening

This is probably going to be the last post in the final project section before the presentation. I will dedicate the remaining hours to improve the code and the mechanics of the arm.

Today I tried a Nema 17 motor that was in a tray. The motor kept stepping forward and backwards no matter what combination or wire coils I used. One of the times I removed the motor connector to change the combination of wires I heard what sounded like a spark and my computer suddenly shutted down and rebooted. This is not a good signal, definitely not. I suddenly remembered that in the instructions of the Easydriver there is a big warning like this:

Looks like the same warning applies to Neil's stepper board. Since the board was not working I checked with a multimeter and found that one of the Alegro's A4953 wasn't delivering power to the motor. I didn't have more Allegro chips but I remembered that Ramin, one of my buddys did the Stepper assignment in the output devices week. So I kindly asked him if he would donate it to science and he did. Thanks man, you saved my final project. I owe you a big one. I quickly unsoldered the chip and resoldered it to my board to find that everything was working again.

Later I tried to clean the marks that the laser makes to the acrylic. The laser beam leaves some marks around the cutting edges that seem water, but you cannot clean them. I found a can of acetone so I put on a pair of gloves (please be safe) and used a cloth to clean them. While I was cleaning I noticed that my gloves were dissolving so I thought this was not good at all and stopped cleaning. I used then some alcohol and the marks removed quite well. You have to press a little bit hard sometimes but the alcohol removes the "watermarks". When I was cleaning one of the green fluor arms I pressed too hard and it broke a bit in the side. I fixed it with a nut and a bolt. I spent all the afternoon in the arm assembly. It's 90% done. The rest is for tomorrow right after I bring my kid to the kindergarden I will head to the Iaac.

My code is ready, all the basic movements have been programmed and also angular coordinates. Tonight I will add more and more movements until I fall sleep. We'll see how long I can keep my eyes open. 17 hours remaining for the deadline.

MAY 28, 2013. Tuesday

It is curious how different you see things at late evening and early morning. Yesterday at 03:00 AM the last thing I thought before falling sleep was "I am not going to make it". Today I woke up, washed my face, and thought: "I am going to make it".

Yesterday I could send and receive serial commands with more than one character using Neil's code if I send them as strings in Python like this: ser.write('50'). The only bug is that it it only reads numbers and symbols (like "." and "!" and "*"). Letters are not recognised. I will use the characters that are working and after the presentation and I will debug the code again for the error. For the RGB y will use Neil's based raw C code. But for the motors, I will use the Arduino IDE code. Although the raw C code works, I could not manage to properly set the delays of the coils and the PWM cycle count. The salvaged motors I am using either block or stall or make random movements and jitters. Today I will try with a Nema 17 standard motor and will have a last look at how the Stepper.h manages this task. The following are the current set of functions that I have defined in the class arm in Python. The commands make some calculations and then send commands over the serial connection to the motors and the LED nodes.

              Welcome to ArmControl.py version 0.5

              Created by Francisco Sanchez Arroyo. Fab Academy 2013

              Type help() for help

              System Ready!

              >>> help()

              #####################################

              # ArmControl.py currently supports: #

              #####################################

              

                help() # This help

                clearscreen() # Clears the console

              

                Arm movements:

                --------------

                arm.goto(theta,r,z,time) # Goto theta,r,Z cylindrical
              coordinates

                arm.rotate(angle,time) # Rotate arm angle

                arm.shoulder(angle,time) # Rotate shoulder angle

                arm.elbow(angle,time) # Rotate elbow angle

                arm.wrist(angle,time) # Rotate wrist angle

              

                Colors:

                -------

                arm.red() # Change color to red

                arm.green() # Change color to green

                arm.blue() # Change color to blue

                arm.yellow() # Change color to yellow

                arm.cyan() # Change color to cyan

                arm.magenta() # Change color to magenta

                arm.white() # Change color to white

                arm.dark() # Turn off the LED

              

                Other:

                ------

                arm.quit() # Try to shut down a 9000 series

                arm.whoami() # Find for yourself

              

                exit() # Quit to shell

                ######################

I will deal with coding in the morning because I can adjust the mechanical issues of the arm even 5 minutes before the presentation. But definitely I cannot code under a pressure of 90 Giga Pascal. My brain will just freeze. I feel so tired now. 28 hours for the deadline.

MAY 27, 2013. Monday

Yesterday I implemented the Arduino IDE code with one of my motors. Footage will appear below soon. I could stop here and finish the coding of my project now. But there are a couple of things that I don't like. The first one is that the libraries Stepper.h and SoftwareSerial.h are consuming most of the memory space of the ATtiny44 uC. Actually you have less remaining bytes than a twitter message to express your creativity. The second problem is that I don't want to be a hostage of the Arduino IDE implementation. It's working now, but what will happen tomorrow? I think I decoded part of Maurice's code. I thought that void get_char was reading characters. But I think that get_char actually reads an array string. So if you send 'hello' it will read that. So I will design a set of strings to control my arm and will give it a try. I feel I'm so close to the end of the tunnel now. I hope I can solve this today, cut the gears and mounting the arm. That is the goal so that tomorrow I can assemble it all and play with scipy in Python for some stunning movements in the presentation. I still have 52 hours left. Let's see what we can give under some pressure Francisco.

MAY 26, 2013. Sunday

In the university, my Calculus professor used to say: "Time x Effort remains Constant. So given an initial large time, the effort you put will be small. As remaining time approaches to zero, the effort you put will raise to infinite. Conclusion: If it wasn't because of the last minute, nothing would be done." 75 hours left for the final project presentations.

Yesterday we had a crazy day in the Iaac. There were a lot of people sewing and ironing in the lab because there was a textiles workshop. I can feel how the maker movement is rising, don't you? Suddenly Sara Ezz came and showed me the Barduino she had redesigned. She did a great work because she adapted the Barduino in order to accept standard Arduino shields, which is great. She was sad because she had just soldered the micro-controller in the wrong place for the second time in a row. Her morale was very low because she was doing everything wrong and she was stuck with her final project as well. I know her feeling very well. I have felt the same so many times in my life. I convinced her to leave aside the Barduino and tried to help her to get on track with her final project. I think her final project is the best one this year in Fab Lab Barcelona. Her original idea was to make a clock with a custom hypnotic pattern code so that you know what time is it by knowing the code. I'll keep an eye on her.

Yesterday my goal was to deal with the C code of the boards trying to make the steppers and the RGB respond to serial commands. I managed to mix the code of the stepper and the RGB LED with the bus node code, and after compiling 250 times the code and debugging the errors the program finally uploaded. And it worked!!! Here's footage:

The problem is that Neil's example code was only sending one character over serial and I had no idea how to send more characters in order to achieve a more complex behavior. So I broadcasted help to the class and the class responded to me. Maurice gave the hint to follow: arrays, pointers, atoi's and itoa's. With this I found a guy who managed to program an ATtiny85 with the Arduino IDE using the libraries stepper.h and SoftwareSerial.h. With those libraries the code is very easy so I was happy. Then Chris shared with me his code to send more characters using Neil's code. If I can make it work, I will use Chris and Neil's code because you can control the motor at the coil level and hence you can adapt the code to fit non standard motors like the ones you can salvage from printers and scanners. With the libraries and the Arduino IDE you can only control the motor at the step level and has been coded with standard stepper motors in mind.

At the end of the day I had yet another problem. I didn't find my RGB board and while I was looking for it I heard a crack in my foot. Don't ask me why, but I knew it was my board. All the connectors broke removing a lot of pads and traces. So the first thing today is advanced surgery to fix it since I don't want to mill another one. Well, my train is arriving to Barcelona, and I have and exciting and busy day ahead!

MAY 25, 2013. Saturday

Yesterday I made big advances. I fixed the bridge board, it was not working because the ATtiny45 was broken. This is the second time that happens me in the Academy so maybe we got a bad batch. Also I could test that all the boards were working.

Later I was dealing with the Python interpreter and the library of commands ArmControl.py. I readed all the pyserial documentation and started creating the commands that will control the arm. I will command the arm using cylindrical coordinates (theta, radius and z) which are the natural coordinates given the geometry of the arm . At night, hyper-jumping in google I found a cool Python module named pyttsx which is a multiplatform text to speech module. Is pretty cool to listen the computer saying the commands aloud. I implemented the module and that gave me the idea to add an easter egg that you will have to find for yourself.

Now I'm in the train, heading again to the Iaac. I wish I could work on this at home but I can't, my older son (4) keeps asking me all the time: "Daddy is that your homework?, Daddy, why do you go to school? What is your teacher's name? Do you have friends Daddy?". I love you son, but daddy must finish this. It is important for us.

MAY 19, 2013. Sunday

Dealing with forward and inverse kinematics. From now on, you may not understand a single word of what I'm about to say. A nice source of information about robot kinematics is the course Introduction to Robotics, from Stanford University taught by Oussama Khatib. I really recommend you to take lessons four and five.

Forward kinematics is obtaining x,y,z coordinates and orientation of the end effector of the robot arm by knowing the angles of the joints. On the other hand, inverse kinematics is obtaining the angles of the joints needed to place the end effector in given x,y,z coordinates and orientation. Both forward and inverse kinematics are needed.

The most used are inverse kinematics, because if you want the arm to draw a line, you will describe that line using cartesian coordinates. You need to obtain the joint angles so that you can tell the microcontroller to move the stepper motors a certain number of steps in order to reach that angle. Those are also the most difficult set of equations to solve and includes solving the inverse of the Jacobian of the 4x4 forward kinematics matrix. Forward kinematics is used in a closed loop. The encoder will give you the angles of the joints, and you will obtain the coordinates of the end effector using forward kinematics. Comparing these coordinates with the target coordinates will help you to program a Proportional-Integrative-Derivative (PID) algorythim for accelerating/slowing down smoothly.

I told you that you would not understand anything.

MAY 16, 2013. Thursday

I have made the basic wireframe interface of the Virtual Control Machine in light painting mode. There is a top right button to load the image, which previews in a window.  There are three settings that the user must enter: speed (this is related to camera aperture in bulb mode). Number of columns (see MIT example image) and physical width of the image. There is also a big button for sending the job to the arm. Python, here we go!

MAY 15, 2013. Wednesday

I am very happy because I managed to fit most of the electronics of this project using only half of a 6x4" single side copper board. Which will reduce the cost of the arm and also make it easier to fabricate.

Yesterday Monica Pedro gave me a a very good advice on programming the PC Virtual Control. She told me to program based on Use Case, that is to think as an user, thinking what the users of the arm will need and how are they going to interact with it, how is it going the interface to look like. And then, when you have it, you start programming to achieve this. That sounds a pretty good idea, and might seem obvious to you, but I didn't even think about it. Thank you Monica! I have just find a webapp to make simple wireframe interfaces which I highly recommend due to its simplicity.

MAY 14, 2013. Tuesday

I have finished modifying Neil's bipolar stepper driver to become a node of a network. Given that my goal is to manage it from Python in a personal computer, no Arduinos or microcontrollers should be needed. Tomorrow morning I will mill and stuff it and hopefully I will be able to make some smoke tests. I need four of these. Time is running out.

Later in the afternoon I also modified Neil's hello.rgb.45 to become a node of the network. This is my light painting module.

And the unmodified bridge board to interface with the computer:

I will add input devices once I've dealed with all of this mess.

MAY 13, 2013. Monday

Last weekend we all received an email from Luciano saying that Monday (for today) was the deadline for ordering parts for our final projects. I have a dilemma, which makes me remember The Matrix Reloaded dialogue. The Architect:

"Which brings us at last to the moment of truth, wherein the fundamental flaw is ultimately expressed, and the Anomaly revealed as both beginning and end. There are two doors, Francisco. The door to your right leads to the Easydriver and the salvation of your project. The door to your left leads back to Neil's boards, to the source code, and to the complete failure of your robotic arm. As you adequately put, the problem is choice. But we already know what you are going to do, don't we? Hope. It is the quintessential human delusion, simultaneously the source of your greatest strength, and your greatest weakness."

I came here to learn, not to success.

MAY 6, 2013. Monday

Today I felt like starting the project and lasercutted some parts of the arm. It is curious how fast you can develop under some pressure. I was bored and even modified the shoulder to become a blue Pac-man ghost. I have been all this time refining the design in kokopelli, but someday you have to take a step forward and start cutting and doing something if you really want to face problems that do not arise in the paper (computer, I mean).

MAY 2, 2013. Thursday

I am getting more and more confident to kokopelli. I can now represent 3D shapes, and even simulate the robot arm movements with sliders. My next goal is to integrate physical properties like weight and inertia in order to display torques on each joint for any given angle.

Now the problem is other. I m stuck in making big key decisions. Every time I listen to Neil I change my mind about the way I should control the arm. Yesterday he talked about Virtual Machine control. My initial idea was to have a micro-controller "brain" that receives data from sensors and send data to actuators. But there is a tendency in moving the processing power to a personal computer so that all the boards in the machine are semi-idiot sensor boxes just for communication between the computer and the sensors/actuators. This way the system becomes modular and adding or removing modules from the design does not affect the rest of the boards. I wonder if the personal computer could even be a Raspberry PI. I like modularity so I should proceed this way. But I have almost no experience with Python programming. So I am taking a Python course in codeacademy and looking at the examples that Jose Pablo showed me. Thanks buddy for pointing me all these resources. I wonder if I will be able to achieve this.

My modules are clear now: A piezo module for sound and tones. A RGB led module for light painting. A stepper module for motor control. An encoder module for closed loop control. A camera trigger module. And a bridge module for interfacing with the computer. And I think nothing else is needed. Now in the computer side I will program what to do with the arm , say draw a circle (no idea of how it is made) and the arm must go to an initial known position and from there, start the movement with a PID scheme. So I must receive feedback from the encoders to make that calculations and refresh the commands.

APRIL 19, 2013. Friday

Today I started designing a system to join the acrylic parts together. I started with a clip system like the one below.

I lasercut the piece in 3 mm acrylic using the Epilog 36 EXT. The design ultimately proved to result a miserable failure since acrylic has a very poor elastic performance and the prototype broke at the first trial with very little force. So I abandoned that idea.

Then I designed a tab system. The most important feature of a tab system is making it tight enough so that you don't need any glue. What happens is that if you cut a hole to the exact dimensions it feels too loose. The hole is too big. This is because of the kerf. When you cut the material, part of it disappears. So you have to play with the kerf in order to make it fit tight. This is where kokopelli starts to show its potential. I made a lot of testings in just a few minutes by assigning a variable the value of the kerf.

I tried several values. With values of kerf above 0.2 mm it was not possible to make it fit, if you try to force it too much, the material breaks. A value of 0.1 mm is quite tight, maybe a bit too much. A value of 0.0 mm is too loose, it won't resist any dynamic forces, it even falls to the ground if you flip it. Finally I will adopt a value of 0.05 or maybe 0.07 mm depending upon the force that the part has to resist. For a very strong fit I might use a kerf of 0.09 mm.

Today I also have very good news. For the first time in the academy I was able to laser-cut all those pieces directly from kokopelli with my Macbook using fab modules. You might think: So what? But this is really important because it saves me a lot of time since the workflow has been reduced a lot. I will make a tutorial in order for you to do the same. The are a couple of things that I still have to solve but I found workarounds for the meantime.

Hopefully by Monday I will start laser-cutting iteration 1! Stay tuned!

APRIL 10, 2013. Wednesday

I have been experimenting with settings for cutting and engraving with the Epilog Laser. Iteration 1 is going to be made with acrylic leftovers from other students. The most unusable the leftover seems, the best it is for me. All the acrylic leftovers I found are 3 mm thick. I had a look at the Fablab BCN Wiki section and I experimented with the recommended settings:

• CUTTING 3 mm acrylic: Power 60%, Speed 15%
• ENGRAVING 3 mm acrylic: Power 10%, Speed 65%

I found the recommended settings perfect to me. Please find below some quick tests I made.

My next step is going to be designing a tab and clipping system. Because this method of construction may be used from people all over the world and they will probably have different leftovers sizes and thickness, it is important to design parametric parts so that by changing a few numbers everybody can obtain a suitable fit. I will do this in kokopelli.

APRIL 4, 2013. Thursday

It's raining cats and dogs outside, a perfect weather to sit back in the sofa and think about my final project. I am just remembering Joe Justice now, he is the guy from Wikispeed. I remember when he came to the Iaac and explained how he made his car in three months. A process that takes years to the established industry. He uses extreme manufacturing techniques borrowed from software development: Making it short he makes iterations of the design and obtains a working version every 7 days. The second week he improves the design and maybe adds new features and so on. I will try this now.

Robot Arm Iteration 1

This week I will make a working version of the robot arm. Small in size, made out of acrylic leftovers. Since I don't know the size of the leftovers that I will find, I will design the arm in Kokopelli. That way I will quickly adjust the robot arm to the available acrylic pieces. I will use servo motors without a transmission system. In electronics I will make a servo controller and an Arduino. That's should be enough to have a working version. Will see how it looks like in a few days. Follow this week Kanban in my Scrumy page.

MARCH 26, 2013. Tuesday

It has been a long time with no updates. I have been very busy both at the Academy and at work. Last Friday we had a local session in Fab Lab Barcelona where we talked again about our final projects. Our instructors do not want us to leave the final project aside and encouraged us to build a working prototype in the following two weeks. This is a good advice. If you don't know how to make it work in the following couple of weeks, probably you won't make it. At the beginning of the Fab Academy I did some research about what past students thought they would make and what they really did for their final projects. I found a significant percentage of people who changed their mind.

When choosing your final project take into account that you are going to be given a set of tools and how to use them. You should be able to make your final project in combination with your background. Do not forget that. Fab Academy won't transform you into a NASA engineer. I would like to make an electric vehicle for my final project if you ask me. I am sure it can be done with the Fab Lab tools but I don't have the background to make it. Well I don't have the background to make the robot arm either, but I like it so much that I am acquiring it on my own.

In our talk I explained how I changed my mind about the Final Project. At the beginning I imagined a high-tech robot arm made out of carbon fiber and stainless steel. I don't see it like this in my mind now. I would like to create the very same project but from other point of view. The main questions that I want to answer are: Is it possible to create something high tech using common low tech things that people trash? Is it possible to convert trashed items into something nice and pleasant to the eye? To achieve this goal I created my own project boundaries, which I have named The Ten Commandments.

FEBRUARY 4, 2013. Monday

Kokopelli

I've been all the weekend playing with Kokopelli. The more I use it, the more I like it. I have made 2 items. The first one is a gear for a timing belt. Look, it took me all the weekend to do this, but now, I can make hundreds of variants in seconds just by typing 3 numbers: Pitch, number of teeth and shaft diameter. Isn't that incredible?

The second item that I made is the castellated beam. When I say I made it, read Evan Jones made it. Today he was about to leave the lab when he had a last look at my screen and said: Is that Python? I said.. yes, sort of... it is the Kokopelli tool... I'm just trying to figure out how to make the holes smaller as they move to the end of the beam. He opened his laptop and started coding. I don't know what he was doing, but he didn't even finish typing the commands and variables, they auto completed. In two minutes he showed me my beam with he holes getting smaller as they move to the end. Then I asked... umm now you are here, can you evenly divide the distance between the holes? He paused 5 seconds (this should be like thousands of billions of operations in his brain). Then he typed a couple more lines and the holes where evenly distributed. Evan Jones did in two and a half minutes what I could not even figure out in a whole weekend. There are some people that do not think, they code directly, Evan Jones is one of them.

Well, now I have 2 problems: the first problem is that I spent all of this time in Kokopelli and when I had a look at my mates work today they all were rendering real 3D models of their projects in Rhino. And all that I have is a hand drawed sketch, a Kokopelli script for a gear and a castellated beam, and the same castellated beam, done in Rhino. And I still want model and render it in Rhino and I also would like to test the castellated beam with finite element analysis (FEA/FEM) in COMSOL to see the differences between acrylic and carbon fiber. The second problem is that it is Monday 21:19 in my watch and the deadline is tomorrow at 24:00 Barcelona time. Someone is not going to sleep today.

FEBRUARY 1, 2013. Friday

Rhino tutorial

Arian is a great guy. He is architect and Rhino and Grasshopper expert. I am proud of being in such a multidisciplinar, multicultural and talented class. I have had one lecture of rhino a couple of years ago and I found it very powerful and with a quick learning curve. But I did not have time to practice with it. Now I feel it even more powerful. One of the tools that made an impression on me was PROJECT, I don't think I will use it in this project but since I like truss structures it can help me a lot. Arian also pointed me to a great plugin: KARAMBA for structural design (I don't know who decides those names for rhino plugins). I practised a little bit and I made my robot arms in no time. Rhino is a must!

Look, in no time!

After class hangout

When we finished the master class (actually when we were fed up of trims, offsets and rebuilds) we walked downtown to El Borne district because people from the Iaac and others were performing a Live Jam session. We had a great time listening to the music, drinking beers, talking to each other and getting us to know ourselves better. I am happy I went there, I left with the feeling that coming to the Academy has been one of the best things that have happened to me. We'll repeat guys!

JANUARY 31, 2013. Thursday

Designing

From now on, I will publish here my progress in the project. Neil told us yesterday in the lecture that the goal of the Archive is not to show the final result, but the process and progress, including all of our miserable failures -actually he did't say that last thing, I just completed the sentence-. I also need to start this project as early as possible. This is not a tweeting cauliflower, you know, that sends help when someone boils it, this is serious, I have a lot of coding, mechanics, electronics, all of them with many uncertainies that I haven't even come across. And I want to finish it, for me it is important.

Yesterday in the train trip to the Iaac I started drawing the arms of the robot, and trying to fit them inside the carbon fiber board. It is important to try not to waste material, not only because carbon fiber is expensive, but also because it is stupid to waste material if you can save it.

As you can see in the image below, my initial design is based on a Castellated Beam. These kind of beams have been used since the early 1900's in order to increase beam depth and strength without increasing material. They cut the beam in a particular shape so that when they welded it again, the beam became taller (increased bending resistance). In my case I cut the holes to decrease even more weight and also because I like Castellated Beams. They are so nice, don't they? The members sizes are initially derived from the equations that determine the maximum arm that could be fitted in the board. It is like some sort of functional and parametrical design actually.

Fitting the arm inside the plate Table with results (max. size)

I'm going to try now draw a piece of the arm the the Fab Modules.

Surfing the web

In a desperate try to find someone who has dealed with inverse kinematics I found this guy:

http://www.circuitsathome.com/mcu/controlling-robotic-arm-with-arduino-and-usb-mouse

He managed to control a Lynxmotion (servo motors) with Arduino and some sort of inverse kinematics. It's not exactly what I want to do but I will print the code and try to decipher it. With servos is easier to move a motor because you just tell the servo go to that angle. In my case, with steppers and a transmission system you have to tell it move n steps forward or backward, and you have to calculate how many steps you need to achieve that angle. It depends upon many factors, like pulley diameters, microstepping, etc. Anyway it is a good start, at least I know Arduino has enough processing power to deal with it. He also managed to manually move the arm with a mouse. I will also need a method to manually move the arm to learn some 'keyframes' for the time-lapse scene. But a mouse is not something I could use in the forest. I prefer something more analog, like just grabbing the arm and moving it to its position.

JANUARY 29, 2013. Tuesday

I created this video trying to explain in one minute what is Fab Academy.