I know everyone has done this before.  RFID and arduino that is.  But looking at the example code it looks like the antenna is always in receive mode.  I am not sure how this affects the life of the chip / reader but I thought of adding a way to detect human presence before activating the receiver.

I found some little IR heat detector (HERE: http://www.allelectronics.com/make-a-store/item/IRD-10/INFRARED-DETECTOR-MODULE/-/1.html and tossed together some analog read code and viola.  Now when the IR detector detects over a certain variable heat temp it activates the RFID reader.

So I had some free time while waiting for Alden to proof my xproto breakout board I designed for the tinyG system that we are working on.  So I took some time to try to mimic the results that Joe Grand of Grand Idea Studios did on his professional PCB mill.  I think the results were pretty good.  In fact they were even better than you see on the final version.  I say this because currently I have a very coarse wire brush on my grinder and did not take the time to switch it to a much finer wire gauge.  I was lazy.  As you can see some of the building is coming off.

Also in the middle there was some “over burn” where I left it in contact too long.

This has kind of inspired me to do some neat graphic / electronics.  Not sure what I am going to do but this would have been much cooler if the cyborg’s eye lit up and would blink faster / slower based off of the temp in the room etc…

Complete Robot Arm

One marathon hacking session later, and the robot arm is complete and functional. Thanks to a whole uninterrupted stretch of time, I was able to complete the assembly of the arm- including the most problematic part, the gripper. It is so problematic that Ril3y and I are quickly fabbing up a replacement that will be much more flexible, robust, and easier to assemble. For now, though, the robot structural framework is complete, and matches the photos that have been posted by the Oomlaut Labs guys. Of course, my arm is in the cool, racy red color, which is very nice.

Complementing the hardware, I took a few bits and pieces of software discovered on the net, and mashed it together into a manual control program for the Arduino board and the Pololu motor control board. The code is really messy, and all in Wiring, so not very elegant or compact. But it is pretty clear and easy to understand- nothing hidden, and should work on every Arduino variant. By using a readily-available Playstation PS1 controller, the interface is both familiar and cheap!

Basically, I mapped each pair of buttons to the motor axes, and hard-wired in reasonable limits, to make it harder to completely crash the machine. I also set up the “select” button to change the speed. It works great, and as you can see from the video, you can pick up and drop things with ease.

Next steps are:

1) Get the documentation completed so others can build them too, easily, if desired. Post the programs, such as they are for the same reason.

2) Add a “learning mode” using the “Start” button and L1/L2 to allow the user to program a series of way-points and then play them back. I may add a little EEPROM memory, too, for non-volatile storage of the programs. I have room on the breadboard and pins to spare.

4) Work with Ril3y to design and integrate a better gripper. As mentioned above, the one currently implemented is suboptimal.

5) Develop the framework for the kinematics programming. This will (at least at first) probably be hosted in Processing, to simplify development. There are a number of existing Open Source kinematics packages for 5DOF arms, so I am hoping to leverage (read steal) an existing one and work from that.

6) Redesign the arm to use high-torque and fine-grained stepper motors instead of the servos. This will require some position feedback. Both of these goals will nicely match what Ril3y and Alden are doing in the motion control space. Hopefully, the arm will evolve into a simple test-bed for those concepts.

Lots of fun- and a great, great weekend!

First joint of the Open Source Robot Arm

Thanks to the Hong Kong Parcel Post, I got my metal-gear servomotors last week, and then thanks to work commitments, they had to sit taunting me on my workbench the whole week. Luckily, I had a chance to do some assembly work this weekend, and got a couple of the major subassemblies put together. As you could see from the earlier post, I had the base assembled, and it was short work to put the base rotation servomotor in place.

You have to make sure that when you assemble the deck, you put the servo in so that it is at the center of its rotation when the arm is facing forward. Once that was done it was short work to get the deck put on. I went ahead and clipped the little screws that hold the servo horn on short, so they won’t rub on the acrylic frame and scratch it. I also added a trio of modified furniture casters to provide a bearing surface for the rotating platform. The oomlaut guys used M8 screws with acorn nuts, but that would also scratch up my beautiful red acrylic, so I chose to go another way. If you look at the flickr set, you can see how I did it. I had to trim them a bit to allow for the small M3 nuts on the bottom of the platform to have sufficient clearance.

You can see that the first joint of the arm is supported by two servos- note that in order to make the parts fit without undue stress on the lasercut plastic, I put one servo inside and one outside the mounts. I also had to make sure that the motors were both turned to the same degree of rotation before mounting them. The way I mounted them, the first joint can swing from fully to the back of the platform all the way to fully front. This should be perfect, and maximize the reach of the arm.

Assembling the second joint turned out to be much more problematic, and necessitated several tear-downs and re-assemblies. As far as I can tell from the (albeit sparse) pictures on the oomlaut website, it appears that the motors are mounted on the outside of the arm assembly, but as far as I can tell, this will not fit without really bending the lasercut frame. I don’t want to do this as I do not want to break the plastic, but I am at a loss about what to do. I am planning on sleeping on it, and ordering a couple of the motors that the oomlaut guys suggest and see if they fit better. According to the specs posted on the motor source website, they are exactly the same size as the ones that I have now, so I am kind of puzzled.

Next up- second arms joint, gripper (which is its own puzzle, to be sure) and the control mechanism. (Yes, I am still hacking around with my old Playstation2 controller!)

So I ordered a 1-Wire RTC (real time clock) from the maxim corporation.  To be exact its a ds1904.  What is really cool about the 1-Wire protocol is it only needs 1 wire to send data on.  It is a bit misleading however since it does need a ground as well.  You really need to read the data sheet on these guys to understand fully how they work.  But in the mean time basically one button gets to talk at a time.  Every button has a unique serial number which is kind of a cool feature in it self.  Since its in a steel “can” its really rugged so you could place it on say a card, keychain etc?  It would be cool to use as a key FOB to get into my workshop.  However no time for a new project at the moment.  The reason I am messing with this stuff is I had to take a break from the project I have been working on for work.  Call it a mind break.

I created a DIY (with a laser cutter that is) OneWire button mount as you can see it just holds 2 wires against the top and bottom of the steel can.  Pretty simple.  Not really useful as an end solution but good for testing.

Anyhow there is a nice Arduino lib for the 1-wire stuff here.  Just extract this to your arduinoxxx/hardware/lib/OneWire folder.

This is the source code that I used and edited to get the RTC DS1904 working.  Note that you need to uncomment the //write Section upload it to the board let it run then re-comment it and upload it again.  Otherwise the oscillators will not turn on and it does not “count seconds” or more to the point at as a normal clock.

#include 
 
// DS1904 Real Time Clock iButton I/O
OneWire ds(10);  // on pin 10
 
void setup(void) {
  Serial.begin(9600);
}
 
void loop(void) {
  byte i;
  byte present = 0;
  byte data[8];
  byte addr[8];
 
  if ( !ds.search(addr)) {
      Serial.print("No more addresses found.\n");
      ds.reset_search();
      delay(500);  // for readability
      return;
  }
 
  Serial.print("ROM: ");
  for( i = 0; i < 8; i++) {
    Serial.print(addr[i], HEX);
    Serial.print(" ");
  }
 
  if ( OneWire::crc8( addr, 7) != addr[7]) {
      Serial.print("CRC is not valid!\n");
      return;
  }
 
  if ( addr[0] != 0x24) {
      Serial.print("\t\tDevice is not a DS1904 family device.\n");
      return;
  }
 
/*
  // write!
  Serial.println("writing to RTC...");
  present = ds.reset();
  ds.select(addr);
  ds.write(0x99,1);   // write RTC - this is the write code
  ds.write(0xAC);  //This is the control byte.  AC in hex = 10101100
                   //read the datasheet and you will see that this is important
                   //to start the internal osc's... Or to make the clock start
                   //counting seconds.  --ril3y
  ds.write(0x02);  //0x02 is a random time set it with your own
  ds.write(0x03);  //same with this
  ds.write(0x05);  //this
  ds.write(0x08);  //and this
  present = ds.reset();
  delay(1500);     // unknown if wait needed
*/
 
  // read!
  present = ds.reset();
  ds.select(addr);
  ds.write(0x66,1);   // read RTC
 
  Serial.print("PR: ");
  Serial.print(present, HEX);
  for ( i = 0; i < 5; i++) {
    data[i] = ds.read();
  }
  Serial.print(" CTRL BYTE:  ");
  Serial.print(data[0], BIN);
  Serial.print("\n\ttime:  ");
  for ( i = 1; i < 5; i++) {
    Serial.print(data[i], HEX);
    Serial.print(" ");
  }
 
  Serial.println();
 
}

Note that I did not write most of this code. You can see the original thread here:  This should be enough to get you starting using a 1Wire RTC.  Enjoy!

Pololu Micro Serial Servo Controller, from SparkFun Electronics

Since I am still waiting for my servomotors to arrive from across the ocean, I went ahead and assembled the servo controller. I decided to use the Pololu Micro Serial Servo Controller, which I ordered on Free Day from SparkFun electronics. I did not end up getting it for free, however, as I am too slow on the “reload” key. Nevertheless, I ordered it anyway, which is exactly what several Internet curmudgeons would rather I didn’t do- “don’t encourage them!” they claim. I like SFU, though, and I have to support my Colorado brethren. Maybe I will move back to Colorado one day and become a combined snowboard bum / electronics guru!

The Micro SSC, despite being the size of a postage stamp, is not the latest technology, and is being threatened with extinction itself by a slightly more expensive USB-connecting version. In fact, it implements the serial protocol from an even older controller, the SSC from Scott Edwards Electronics, which had it’s debut way back when “Nuts and Volts” magazine was in that weird large tabloid format. I used it successfully on several projects, mostly interfaced to an HC11 Miniboard (thank you Fred Martin and MIT Media Lab!) or a Basic Stamp BS1. It had a remarkably easy command structure, and you could string several of the boards together to get even more servos online. Neat!

The Pololu unit implements the old SSC interface, but also a much-improved interface of its own that has lots of nice features like travel limits and travel rates, etc., all of which make for a much nicer robot arm. I will probably start off using the old SSC language that I am familiar with, and then move to the new framework as I need the additional features (or as I break servos doing the usual stupid stuff…)

Next step is to set up the pendant for programming the robot. Ultimately, I am planning on integrating one of the several open source inverse kinematics frameworks available or path planning, but for now I am going to integrate a simple “do as I do” training system, using an old Playstation 2 joypad that I have sitting around. While I am waiting for the servos to come in, I will set that up- watch for a post on that topic in the next couple of days.

The oomlaut open source robot arm base assembled easily and looks slick and professional.

Thanks to Riley, I am the proud owner of a pile of lasercut parts for the uber-cool oomlaut open source robot arm. The details can be had from both the original blog post and a thingiverse.com post that has the necessary design files (nicely laid out for the lasercutter, although Riley was able to get the layout down to a single 12×24in sheet, which was great. He said he will upload it as a derivative on thingiverse ASAP, so others can benefit, too.) My daughter and I both thought watching it cut was the coolest thing ever. She has taken all the scrap and has it proudly displayed in her room, too. It helps that the color we chose was bright red- gives it a gem-like (and somewhat sinister!) appearance. Can’t beat that!

I have most of the electronics already- I will be using a barebones Arduino as the controller, and a Pololu servo interface board to maximize the precision. I did have to order some good metal-gear servos, which I got for a steal at dealextreme.com The total cost of the project will be about 70$US, and if I had to buy everything fresh, closer to 100$US. Pretty good for a flexible robot arm and experimental hacking platform. My intent is to incorporate it into some work that colleagues and I have been doing around automated lab testing. I intend to borrow an existing reverse kinetics framework and use that for path planning. I am also going to rework the gripper, as I think it is the weakest part of the design.

Next up will be an illustrated build diary, here on the Synthetos blog, and a compete set of instructions, ordering guide, etc., over at Instructables. The goal is to get the arm built and tested, and to validate the design, as well as get others interested in building their own. Who knows- if it works out well, I may even take a crack at a derivative design that can be built using only RepRap-ed parts!

Well I was the only one there….  BUT! I did have a few different ATMEGA’s guests.  I had purchased about 10x  ATMEGA168V’s and 5x ATMEGA168P’s both in the SMD packages for some upcoming projects.  My goal was to get a TQFP (which is just the name of the chip foot print or size if you will) socket hook it up to the SPI programming ports that ATMEL uses to flash their chips and then burn the Arduino Boot loader on to them.  Well this turned out to be harder than I though.

First, the wayyyy too cheap TQFP Socket Breakout Board $25 actually when most are around $150 – $200 was too good to be true.  I assumed and did not RTFM (google if it you dont know that one) that it had a standard male breadboard socket headers on the bottom to “breakout” the pins.  It actually had this:

So after realizing that my whole “good idea” of removing the 6 pin headers needed to flash and arduino bootloader off of any future design and just use the “breakout board” to quickly flash these guys was starting to seem like it was not going to work.  After about 4 hours of searching for the counterpart of this connector I gave up and got crazy.  I went ahead and desoldered the whole enclosure popped it off solder 6 wires to the right corresponding pins needed to flash the AVR’s.  I needed this to be done quickly as I had a project that’s deadline is approaching so I had to breadboard

this design rather than make a nice custom eagle footprint for this part and do a DIY PCB via the Laser.

This is where the real trouble started.  I thought I had bought all ATMEGAxx8P’s when in reality I had bought ATMEGA168V’s.  So my trouble was through the arduino IDE I had selected to flash these chips with the Arduino mini pro as the board selected.  All this means is through the IDE the mini pro has the smd atmega168p chip which is what you would have wanted if you had the right chip.

Issuing the avrdude -c tinyisp -p m168 told me that everything was good.  So then I proceeded to select Burn Boot Loader through the Arduino IDE.  This failed and now I was no longer able to talk to these chips.  After reading more I realized they were ATMEGA168V’s which is the same chip the lillypad uses.  I selected that board on a new chip burned the bootloader and now its all working.  However I did “screw up” about 6 other chips.

I posted a question on chiphackers to see if anyone could help me out.  It turns out that the Arduino IDE seems to have changed the fuses on the chip to need an external oscillator.  This is ok if the hex file that the arduino was trying to burn was the right one.  Which it was not as I described above.  So I am in the process now of trying to fix these “screwed up chips”  by adding an oscillator to the xtal pins and then trying to burn them again with the right bootloader.  I will update with more info when I know its fixed.  Here is some more pics of the process.

So its a new year.  This blog should attempt to paint a picture as to the road map of Synthetos projects.

1. Get the store.synthetos.com up and running.
2. Finish a work hardware project.  (hush hush until its released)
3. Finish up contraptor mini-cnc
4. Finish new stepper driver board. (Including the linear encoders)
5. Finish Atenna Bot.
6. Start the DIY pick and place.
7. Convert the mill to a cnc metal mill.

If we were to finish all of this by June that would rock!  So if anyone is interested in contributing to any of the above projects please let me know.

Ril3y

I’m currently laying out a DSP/FPGA board to interface to the MUSAMP board below for real-time signal processing. I’m laying out the schematics and PCB layout using gEDA (GPL Electronic Design Automation) tools. I originally started working on gEDA through a SuSE VirtualBox virtual machine on a Mac OSX host.

The Mac OSX host is on a Macbook Pro, which is naturally somewhat limited in resources compared to desktops. In addition, I tend to have my spec sheets open through spaces. Zooming in and out in gschem and flipping between spec sheets wasn’t as responsive as I hoped.

After some trouble migrating the VirtualBox ‘Appliance’ to my Windows 7 desktop (required an NTFS partition), I started using ‘Headless’ mode in VirtualBox. ‘Headless’ starts the virtual machine in the background, which can then be accessed using Windows’ RDP protocol (the standard windows remote desktop software).

A few things of note, Windows 7 uses port 3389 for remote desktop, which is the same as the default port in VirtualBox. Change the port, and make sure your firewall lets the chosen port (in TCP) through.

Execute in command prompt

%VirtualBox Installation%/VBoxHeadless –startvm “VirtualMachineNameHere” –vrdp=config

Choose a remote desktop client for your remote computer (TSclientX is the only Mac OSX client that worked with VirtualBox, CoRD worked only for getting to Windows 7).

If it works, make a shortcut to the above command with cmd.exe as a prefix.

EDIT #1: make sure to install VBoxGuestAdditions. You can then change the resolution from your RDP client by

$ sudo /opt/VBoxGuestAdditions-3.x.x/bin/VBoxControl guestproperty set /VirtualBox/GuestAdd/Vbgl/Video/SavedMode 848×480x32