Chris Dugan's Course Project
The robot that I built is not necessarily modeled after a specific animal. It evolved from the simple goal of getting a robot to walk on four legs. Having very little robotics experience and even less engineering experience, this was no trivial task. Below, you will find the design ideas, the actual robot, and the CAD modeling of the robot.
My robot was built using Legos from the Lego Mindstorm kit. This kit is basically Legos with a bunch of motors and similar gadgets. Handyboards are also provided that are "fully" programmable. The only necessary programming involves turning the motors on. This is arguably unnecessary due to the ability to use a 9V battery, but I digress.
I began by attempting to build something usable out of the Legos. I decided to use two motors facing opposite directions. One motor would power the front two legs and one motor would power the back two legs. In order to balance the creature, the diagonal legs would be in step. The feet were block shaped and rigid. While this idea worked conceptually, it was not so great when fielded. The balancing of the robot depended on the timing of starting the motors. Since I was using the Handyboard, which seems to run its program line-by-line, the motors would never start at exactly the same time. Perfecting the alignment was frustrating and I looked for another solution.
I began searching the Internet for leg ideas and balancing ideas. I found  to be quite helpful. The next few pictures were taken from that website. They had built a walking robot very similar to mine, except the two motors operated in unison as gears ran all around the robot. The legs had also been built using a crank-shaft. My original feet did not do so well on low friction surfaces and a crankshaft allowed the robot to walk on the corners of the Lego pieces.
At left is a schematic for the motors. Note that the motors spin in opposite directions, but operate in unison because of the gears. There is the possibility of a fifth and sixth leg on the small gears in the middle; however, it is currently unimplemented. This design was much, much more efficient than the original ideas mentioend above.
At right is a general abstraction of the legs that were used. A crank-shaft ensures the legs remain rigid. The actual legs deviate from this figure slightly as I wanted the legs to bend at a far greater angle. They also extend towards the front and back, respectively, of the robot--again, similar to a spider. Four legs present a unique challenge for stability and movement. The diagonal legs are always in step, thereby achieving balance.
The robot is mostly as described in the Design section. Using the two motors that operate together, the robot remains balanced and can carry a heavy load. In fact, I am able to put the Handyboard on top of the body and it still walks at about the same rate as without.
At left is a top-down view of the robot. Gears line the side of the robot and we can see how they are all interconnected with the motors via the axles. At right, we can see a side view and compare it with the design above. The crank-shaft is modified due to the lack of similar parts. I am curious as to whether it is more efficient to have the front legs bending outward as they are now, or if the robot will move more efficiently if they bent inward; that is, they would bend the same direction as the back legs. This view also gives us the best idea of the gear structure used on the side of the robot.
This design has seemed to work very well thus far. The robot walks in a straight line and can carry a decent load. It has an interesting and predictable wobble motion that will be interesting to simulate. The best part of implementing the modified design is that the legs stay in synch because it is impossible to get out of synch! When the motors are switched on, there is still the slight delay mentioned above. The delay is short enough to cause little problem. I speculate a longer delay between motors starting would cause severe strain on the robot and possibly cause it to break or at least the motors to burn out.
Finally, a .avi is available to view the walking behavior of the robot. It is about 9M, so is only somewhat large. The quality is horrible and the sound is not in synch with the picture--mainly because I know nothing about mpeg/avi and I converted a mpeg from my camera to an avi. The quality is also horrendous. Lastly, the codec used is probably some weird one that nobody has so you probably won't be able to view it anyway. It worked on my WMP. Anyway, click here for the video.
This week I spent playing with the Legos and attempting to figure out how gears actually work. I also downloaded and installed Microstation. This proved to be non-trivial because the license supplied with the package is out of date. Another one exists in the Bentley directory on software.drexel.edu though, for the astute web surfer. Read the file and follow the simple directions for installation.
That being said, I've also been trying to figure out Microstation. It is a very complex program with little documentation. I found a tutorial online that is only average and only works for 2-D drawings. Check  for information. Additionally, it is worth noting that the default file type (.dgn) is 2-D when you create a new project within Microstation. Be sure to change the file type to .dwg when creating a new document.
Perhaps we can start up a Microstation FAQ, for instance. Maybe I will add a link to a skeleton to the main page. Help for even the smallest task would be fantastic. I cannot even make a cube!!!
The motors work! The handyboard turned out to be a huge pain. Not having an engineering background didn't seem to help. I followed the links provided by Joe Kopena in his emails and downloaded the Windows version of Interactive C. The QuickStart was straightforward to follow. Problems arose when I discovered a faulty telephone cord (which made it impossible to connect the serial converter chip with the handyboard). This was not trivial to discover, unfortunately. Then, I discovered a faulty motor port. That is, all of the other motor ports eventually worked with the same code.
After all this initial setup was complete, I finally have a working handyboard and some motors. If anyone has similar problems, I would be glad to assist.
In other news, I have narrowed my project down to two different ideas. I am interested in getting the tw-legged creature to work, but do not know how feasible it is. I hope to narrow this down by Tuesday. My idea for balancing the two-legged creature is to use the handyboard to shift the center of gravity on the being. I plan on attempting to build a mechanism that shifts the handyboard left and right depending on which leg is on the ground. This may be idiotic, but my non-engineering self can see it working. If that doesn't work, I am going to default to a four-legged beast since balancing such should be easy and setup should be as well.
The two legged animal proved to be a failure and I have began working on a four legged animal. It has no type yet. My initial design, implemented in Legos, uses two motors. One motor powers the front legs and one motor powers the back. I will likely run into a problem because the motors do not stay in synch, but will deal with that later. My major problems are making actual legs. I think I'm going to have to get more of the shorter axles from other kits because I don't have enough and am having problems with the feet hitting the axle and each other.
Spent a lot of time on the Wiki and plan on becoming a Microstation expert. The robot works and I'm happy with the design and implementation. I will not likely make any further modifications.