Posted: May 19, 2017
A couple months ago I started saving bones from fried chicken I've been eating. My thought was since Wikipedia defines a cyborg as ".. (short for "cybernetic organism") is a being with both organic and biomechatronic body parts..." that if I hooked up a some motors and an MSP430 microcontroller to a bunch of chicken bones that I could create a cyborg chicken... and of course have a cyborg chicken fight.
I decided to design the cyborgs that fight to be wheeled based, but before I started working on that concept another idea hit me: could I connect the bones together so the chicken could stand (or something) with motors on the feet and arms. The first video on the page shows this chicken, which was eventually broken in half so the top part could become the red wheeled chicken. This chicken is MSP430 based like the wheeled chickens but the code on this one is written in Java. Why Java? Because it's fun to say "3 billion devices and a franken-chicken run Java".
Videos, pictures, parts list, explanation, and source code posted below.
The source code below can be assembled with naken_asm.
Related Projects @mikekohn.net
Here is the chicken that I was hoping could stand. I attached the bones together with hot glue and on the legs hinges I got at the hardware store. I used two servo motors to control the arms and two servo motors on the hip connected to the shin with an opened up paper clip. It's mechcanically flawed and didn't stand, but it looks pretty cool hanging from a guitar stand. As stated earlier, this chicken's firmware was written in Java (posted below) and after being compiled with javac into a .class file can be compiled into MSP430 assembly with Java Grinder. https://youtu.be/r7zSei_p1Xs
The video above shows the wheeled chickens fighting. At one point the red chicken freezes, this was due to the batteries falling out of the battery clip. Some masking tape around the battery clip fixed that. A second issue was the IR sensor was taped to the back of the chicken's head and the IR LED emitter I think has a fairly directed beam which meant if the controller board was laying flat, the chickens weren't receiving commands. I kind of fixed that by propping the remote controls so they were pointing upwards towards the head of the chicken. https://youtu.be/pA9melnU4_c
I based this project on my previous Remote Control Food project that used a Syma S-107 remote control and a simple MOSFET circuit to drive the motors which only allowed forward wheel rotation. I wanted to use the same circuit for this one but I only had 1 remote and I think to make two robots fight they also need to be able to go in reverse. Instead of trying to fit 2 H-bridges on a circuit board I decide to just use the DRV8833 Dual Motor Driver Carrier board that Pololu offers. Really simple to hook up and saved me a ton of time soldering. Still kind of feels like cheating though.
For motors I used Pololu's 100:1 Micro Metal Gear motor and attached them to some wheels they sell. These are the same motors I used before but with bigger wheels. I also got 2 pairs of mini-servos that I originally used on the standing chicken.
The chicken bones are a mix of chicken wings and chicken legs I had been buying from the local grocery store for lunch. I washed them off in the sink using dishwashing soap and the rough end of a sponge to peal off as much meat as possible. I wasn't able to get all the meat off, which kind of gives it a neat look I think. It's dry and as far as I can tell has absolutely no smell. The bones are connected with hot glue... lots of hot glue. I did this so I could pull them apart if I needed, and I did need to do that multiple times. On the standing chicken I used some small, cheap hinges from the local hardware store to make joints. The claws are real chicken feet that I bought at a local pet store (I guess dogs like to chew on them).
The IR protocol I used is pretty simple. Like the Syma joystick, the carrier frequency is still 38kHz but instead of being 32 bit commands it's only 8 bits. By using only 1 byte, each controller should be spending less time sending data which should make transmission collisions between the two controllers happen less often. Each controller also has a different delay sequence between sending commands so if they do collide, they shouldn't as easily collide on the next transmissions. Each byte is encoded as SScccCCC where SS=01b or 10b depending on if it's controller 1 or controller 2, CCC=(0 to 5.. where 0 is stop, 1 is up, 2 is down, 3 is left, 4 is right, 5 is fire), and ccc is a repeat of CCC. If a byte reaches the receiving circuit and the motor number doesn't match or ccc is not the same as CCC, the byte is ignored. A jumper on P2.6 decides if the remote / chicken is 01b or 10b.
I hope a TI expert (employee?) reads this and sends me an email helping me out with this part. I've had several circuits now that suffer from this issue, and Google'ing for it seems to show other people have it too. When connecting my battery to my circuits they sometimes don't turn on (or really they turn on in a bad state). So my typical reset circuit for MSP430 was simply using a 33k resistor from /RST to DVcc. It seems my circuits aren't resetting properly? I put a 0.1uF capacitor from /RST to ground (yeah I know it was bad leaving that out before) and the problem seemed to stop, but then the debugger won't see the chip. I dropped the capacitor to 0.001uF (1nF like the Launchpad circuit has) and the resistor to 47k. The debugger can see the chip, but the circuit still won't turn on sometimes. I ended up fixing it by using the hardware watchdog timer. I'm actually starting to wonder if it's a DCO problem. I did try adding an oscillator fault interrupt, but I don't think that ever triggered.
100:1 Micro Metal Gear motor
I also got 2 Atari Joystick clones, the 9 pin D-Sub connector, and some battery packs. Oh yeah, and lots of chicken legs and wings. I got pretty tired of eating it actually... but hey, all in the name of science.
Copyright 1997-2017 - Michael Kohn