Octopod First Test

After much soldering and programming I finally have the code base and electronics mostly setup for the Octopod.  As previously stated I’m using two Adafruit 16-channel servo controllers for handling the 24 leg servos.  I’m currently using an Arduino Pro Micro to handle the controlling of the breakouts.  I have a rudimentary Arduino library up on my Github.

I’m basically handling the control as a hierarchical set of libraries.  On the top level I have the Octopod class which will handle very abstract motion such as stepping, turning, rotating, and tilting.  The Octopod class has eight Leg objects.  The Leg class is responsible for, you guessed it, a leg!  It handles things such as forward and inverse kinematics, which is a topic for another post,  and some trajectory generation (e.g. arcs, lines, etc.).  Each leg consists of three Joints.  The Joint class handles the servos’ default positions and offsets and contains a Servo which is just the barebones implementation to control a hobbyist servo using the PCA9685.  I’ve done some basic testing on the Servo and Joint classes and am fairly confident that they work but I’ve been avoiding the Leg class since I don’t yet want to go through the nightmare of debugging my trigonometry.

Instead, I decided to create a walking program just to get a chance to see the robot in action.  However, this didn’t go nearly as well as I’d hoped and the Octopod collapsed in a jittery mess.  In my haste I decided to not include the decoupling capacitors on the Adafruit boards which turned out to be a mistake since I have 24 servos which can each draw several hundred milliamps.  Once added, the operation was a little better, though not by much.  Below is a video of the robot attempting to walk.

From the looks of things, either the capacitors were not enough or my code is incredibly messed up.  In the next couple of days I’m hoping to take a closer look at the problem.

The Deconstruction

***Developing***
Last weekend I had the great opportunity to participate in a 48hr hackathon.  Called The Deconstruction, it involved a 48hr marathon where teams people from any age or background got together and built a project of our choice.  Aside from some of the creepy messages we got from trolls on our stream, it was awesome!  I think setting aside everything and taking a weekend to concentrate on making something is great and really spurs creativity.  I’m just lucky school is still slow and I didn’t have much work.

So on to the project.  Ever since last summer, I’ve wanted to build an automatic drink mixing machine.  I even spent a fair bit of time planning it out and ordered some of the parts.  When I presented the idea to my teammates they all jumped on board and we decided to do that this weekend.  Our team was The Dangerous Dijkstras.  A lot of details about the construction of the project are at the team site.

Here are some videos of the final project.

Jurassic Singularity

So in my first post one of my interests that I neglected to mention was hardware hacking.  In fact, as much as I love high level programming and computer science, I’d have to say my true passion is the low level stuff.  Learning about computer architecture, designing logic circuits, and programming microcontrollers provides a lot of challenges and a great sense of accomplishment.  The best part is being able to turn lines of code into something tangible by interfacing microcontrollers with real world appliances, sensors, and actuators.  This is one of the main reasons why I find robotics so appealing.

And as a result of this passion, I’ve accumulated a fair amount of old toys with the intention of taking them apart, seeing how they work, and possibly hacking their electronics to make a cool autonomous robot.  I have a bunch of RC toys from my childhood such as cars, an RC robot (Rad 2.0: very cool!), and a small hovercraft.  In addition I’ve also managed to snag some cheap used toys off of eBay or from thrift stores.  That’s how I acquired my most recent project which will be the main focus of this post.  More specifically, one day I was frequenting one of the geekier (awesomer) parts of the internet, when I thought to myself, robots are cool, and dinosaurs are cool, I wonder if someone has combined the two before (FYI most of my interests may make me seem like an eight year old, but I’m a legal adult I swear!).  So I searched  a bit around the linked website as well as the internet but could only find one or two examples of a robotic dinosaur.  But then I stumbled upon this beauty.

This gorgeous thing is a semi-autonomous, remote controlled, robotic toy raptor.  Normally retailing for $200, I managed to snag one of these suckers off eBay for a mere $15.  The only catch was there was no remote!  So I figured this would at the very least look pretty awesome tearing around in autonomous mode but optimistically, I hoped I could build a remote using an Arduino or possibly piggyback the electronics directly and have an Arduino controlling the built in microcontroller.  Well let me tell you, it works!
In an attempt to save myself effort and money I started off by looking online to see if anyone else had had a similar idea.  Turns out Wowwee robots are notoriously simple to hack and there was a whole online community that focused on hacking the RoboSapien, which is a humanoid robot.  After some more research I found that these ‘bots use IR wireless communication.  This essential makes the robots way more hackable for a number of reasons.  First off, most RC toys use radio frequencies between the remote and the toys.  These radio frequencies are usually low power, relatively easy to make, and provide very little interference with the outside world.  The only problem is there are several commonly used frequencies which all require special chips that are not commonly available in order to transmit data.  Wowwee robots, on the other hand, use IR, or infrared, light to transmit data.  IR is relatively high power compared to radio frequencies, but usually has a lower range.  It is also a lot more susceptible to interference because there many things that produce IR radiation, such as the sun for example.  IR controllers also tend to be more directional in nature, meaning you have to be pointing the remote at or around the thing you’re trying to control.  However IR does tend to be a more popular wireless control method because it’s very cheap and readily available.  In fact Radioshack sells IR LEDs that can be used to make custom remotes.
But anyways, while I certainly wouldn’t have used IR to control a $200 toy, it does mean that the average hacker can easily recreate a remote control.  The only caveat is that in order to one to control a commercial device, you need to know what protocol to use or how the controller sends data.  So first off I needed to find out what modulation frequency the controller used.  For those who don’t know what that means, let me explain.  As a said before, IR is notoriously susceptible to interference.  Infrared is everywhere!  Essentially anything that is producing heat is producing infrared light.  TV remotes produce it, the sun produces it, we do as well.  It’s a pretty busy section of the spectrum so it’d be easy to lose signals if you’re just blinking an IR LED.  A good analogy would be if you’re swimming way out in the ocean.  You’re probably not going to notice if the water level gradually changes by ten feet.  You will notice, however, if all of the sudden the water gets really rough and there’s a lot of waves constantly lifting and dropping you.  This is what frequency modulation is.  Rather than an IR LED being simply on or off, the LED is switched on and off thousands of times a second for a specified amount of time.  The ones and zeros of a binary message can then be whether the receiver sees a modulated IR burst, how long one lasts, or how long a pause between bursts is seen.
This brings me to the Wowwee protocol.  Despite the fact that not many people have hacked the raptor, I still managed to find enough info to understand the protocol since the same command structure is used by all the Wowwee robots.  This makes my job of building a controller a breeze because, if the protocol had not already been documented I would have had to buy a controller and built an IR receiver to record the IR bursts that the controller sent.  So with this difficulty aside, I could go straight to making the remote.
Using the this website, I found that the IR signal is modulated at 39.2KHz (I rounded to 40KHz which was good enough) with a 1200Hz transmission frequency which means a 833 microsecond bit width (the time taken to send a bit).  The transmission starts with an eight bit width IR pulse, a logic high is a pause of four bit widths followed by a one bit width pulse, and a logic low is a one bit width pause followed by a one bit width pulse.  There are a total of twelve bits in each message.  Here’s the command table taken from the above website which is now out of commission.  The numbers are in hexadecimal format (base 16).

Normal Operation

Function

Mode

Default

Mode 1

Forward
$186
Backward
$187
Left
$180
Right
$188
Stop
$18E
Demo
$1D0
$1B1
Head Right
$194
$1B4
Head Left
$191
Tail Left
$192
$1B2
Tail Right
$193
$1B3
Bite
$1D1
$1B0

As you can see from the above table there are multiple signals for each command.  On the RoboRaptor controller there is a shift button which can trigger alternate functions of the Demo, Head Right, Tail Left, Tail Right, and Bite commands.

I then proceeded to create an Arduino program to control an IR LED.  Using the AVR built in PWM I managed to modulate the frequency to 40KHz.  I then set up two NPN transistors in an AND gate format with the two inputs being the 40KHz signal and the bit logic signal which is manually timed using the delayMicroseconds function and some bit logic.  I’ve uploaded the code to Github where it’s free to use and distribute.  I’ll most likely be updating it over the next few weeks as I work more on the RoboRaptor.  I’d like to convert the entire sketch into a RoboRaptor class with built in functions for walking, trotting, and running, as well as many of the other commands.  That way in the future it’ll be easy for other people to simply import the library and use it.

As for my other future plans with the raptor (I haven’t come up with a name for him/her yet), I’ve noticed that the front speaker seems a little quiet which I’d like to try and fix.  My dream is also to have a team of three of these, with one command Raptor and two soldiers, and get them to move around and hunt like the Velociraptors in Jurassic Park.  The only problem with this is that there is no way to control two of the toys separately since they use the same command protocol (Guess the inventors never thought someone would have more than one of their $200 toys), so I might try and take apart the electronics, probe it to see how the internal microcontroller controls the RoboRaptor’s movements, and try to imitate that with my own microcontroller that I can put in instead.  That way I can have more control over how the Raptor moves, the noises it makes, how it communicates, etc.  So while that’s an ambitious endeavor, it’s my ultimate goal!