K'nexabeast - A Theo Jansen Style Octopod Robot

K'nexabeast is an octopod robot built with K'nex. The electronics are built around a PICAXE microcontroller. It uses a leg structure and walking mechanism inspired by Theo Jansen's innovative Strandbeests. In addition to the aesthetic, lifelike gait of the Jansen Linkage, the eight-leg configuration allows for a smooth flowing, relatively agile robot powered by only two motors. K'nexabeast can go forward or backward with equal traction, and can rotate to the left or right.

Like any good hobby robot, the Beast is currently in a state of development with no clear end in sight. This space is being used as a home-base for the project with background information, details on the current state of the build, relevant notes from along the way, future goals, and general ramblings. Of course since this is Hobbizine, it is also the intent to provide you with insight and information you can use in developing your own projects.

The current hardware:

PICAXE 20X2
GWS S35 continuous rotation servos(x2)
Tower Pro SG90 servos (x2)
Sharp GP2Y0A21YK Infrared Proximity Sensor
Lots of K'nex

The below video from our YouTube channel shows the Beast in action.

This longer video is from one of the earliest successful test runs and shows an earlier configuration.

The Jansen Mechanism

Theo Jansen is a Dutch artist who has spent a good bit of the last 20 years developing a series of walking, lifelike kinetic sculptures. He calls his creations Strandbeests and he refers to them as animals. Although he does not to my knowledge consider himself a roboticist, it would be fair enough to think of Strandbeests as BEAM robots. (Although since there are no electronics and BEAM is an acronym for Biology, Electronics, Aesthetics, and Mechanics, perhaps they are BAM robots.) The sculptures are powered by wind and have mechanical sensors and control. They are designed to operate autonomously on beaches with a basic behavioral reflex of sensing and avoiding water. It's very cool stuff and has attracted quite a bit of interest among people from many walks of life - including robot hobbyists.

Strandbeest legs are based on a four-bar mechanical linkage design that people have taken to informally calling the Jansen Linkage or Jansen Mechanism. The distinctive motion of the legs derives from the unique proportions of the various rods. Jansen found the proportions by running a genetic algorithm to select for lengths which moved the foot of the leg in a pattern he had determined in advance. He calls the pattern the ideal walking curve and it is shown nearby. In the ideal walking curve the leg arcs gently during the swing phase of the gait when the foot is lifted, and a virtually horizontal line is traced during the stance phase when the foot is on the ground.

K'nex with its various rods and connectors makes a very appealing platform for experimenting with Jansen legs. However it does present some serious issues. K'nex pieces come in fixed lengths and a limited number of angles are achievable when attaching rods to connectors. The lengths and angles in Jansen's linkage are very precise and cannot be easily duplicated in K'nex - at least not at the scale I'm working with in K'nexabeast. A significant amount of work to-date has been invested in trying to get as close an approximation of Jansen's proportions as possible. Shown below side-by-side are three images - an early K'nexabeast leg to the left, a Jansen leg in the center, and a current K'nexabeast leg to the right.

The early effort on the left reflects an intuitive approach to looking at Jansen's designs and putting together something that appears pretty close. Although the design worked, it was in the barely acceptable range. The ideal walking curve had been essentially flattened with the foot lifting only a few millimeters at the top of its stride and actually dragging for part of the swing. In addition to creating terrible inefficiencies, the lack of a true stepping motion was dissatisfying and meant the Beast could only operate in very restricted environments.

The quest for improvement was interesting. With so many variables in play it was difficult to say when one design was "closer" to Jansen's than the last. In experimenting with different configurations that were achievable with K'nex, I found that it was very easy to over-correct and arrive at mechanisms which either performed much worse or failed altogether. Real improvement finally came when I experimented with raising the crankshaft relative to the legs allowing for connecting rods of different lengths. This change resulted in a walking curve that is significantly improved as you can see in the video below which compares the old and new.

It's worth noting that this improvement did come at a cost. I was not able to use a standard length K'nex rod for the longer connecting rod in the new design, but instead had to use a pair of rods coupled with connector. I have been trying to avoid such couplings as much as possible assuming they add weakness. Also, I struggled a bit to work out a good mounting strategy for the servos which are now higher up on the chassis.

Throughout all of this I've been working to tighten things up - eliminating slop in the mechanism wherever I could. Since tightening up frequently required adding bracings and other reinforcement, the Beast has been getting steadily heavier. I've been worried about all this weight but so far the efficiencies gained through the improved leg design and the elimination of slop have more than offset the weight with the net result being a robot walking stronger than ever.

Navigation and the Sharp IR

The current navigation algorithm is extremely basic - even crude - but nonetheless effective. The Sharp sensor has a stated range of about 10cm to 80cm, although in practice it is only reasonably accurate to about 50cm. The sensor is mounted on a pair of servos setup to pan and tilt. It makes one sweep at an approximately horizontal view and makes seven readings. It then sweeps back angled slightly downward and takes seven more readings. When it detects an object at about 30cm in any direction it registers an obstacle and takes appropriate avoidance action. Although it is crude as noted, the strategy is sufficient to escape corners and avoid table legs (usually!).

At this point I have something of a love-hate relationship with the GP2Y0A21YK. The possibility of a $14 optical sensor capable of range finding is too attractive to easily give up, but these guys are tricky to work with. First of all, the sensor pulses its IR signal about 1,000 times a second creating some pretty severe noise and voltage swings. You can get the situation under control with capacitors but it takes some fiddling. Other challenges involve the nature of the sensor output which is a variable voltage. The output is non-linear, changing very little when measuring distances at the far end of its range and changing quite a lot between readings at the near end of the range. Therefore to use it effectively for range finding the sensor needs to be calibrated and some type of linearizing function worked out. The biggest challenge with the Sharp IR sensors is that when they get inside the near end of the range, the output, which has been rising steadily as objects get closer, abruptly reverses and begins to drop rapidly to zero. This reversal creates a very real possibility that when an object is closer than the near end of the range, it could be registered in software as being further away. Pictured nearby is the chart from the datasheet which illustrates the nature of the output.

As an additional problem I've found that despite smoothing the power lines, the output of the sensor is still fairly erratic so I'm working in software to clean the readings up further. The approach I'm using is to take three readings at each scan position, throw away the high and the low readings, and keep the middle. The strategy of throwing out high and low readings can be somewhat more reliable than averaging. If you're averaging a small data set (in this case three) then one off-the-wall reading will skew the result too far to be usable. There would be a few ways to handle the coding in PICAXE BASIC. Below is a code snippet for my approach:


 #picaxe 20x2

 ;---------------------------
 ; Variables
 ;---------------------------

 
  symbol ir_reading = w5
  symbol ir_low = w6
  symbol ir_high = w7


 ;----------------------------
 ;
 ;     ...various code
 ;
 ;----------------------------


 
 ;-----------------------------
 ;read the sharp ir subroutine
 ;----------------------------- 

  read_ir:

   pause 250
   readadc10 7, ir_reading
   ir_high = ir_reading
   ir_low  = ir_reading
 
   pause 250
   readadc10 7, ir_reading
   if ir_reading > ir_high then        
      ir_high = ir_reading
   elseif ir_reading < ir_low then
     ir_low  = ir_reading
   endif 
  
   pause 250
   readadc10 7, ir_reading
   if ir_reading > ir_high then        
      ir_reading = ir_high
   elseif ir_reading < ir_low then
      ir_reading = ir_low
   endif 
 
  return

One of my goals for the Beast is to find ways to use its relatively large stature and wide stance as an advantage in developing navigation and other situational awareness strategies. I plan to use a fair number of redundant proximity, ranging, and other sensors including color and heat. The width should provide a good platform for experimenting with triangulation and for motion detection. Also, by using sensors that overlap in their purpose I hope to be able to dramatically improve the overall reliability of the sensing. For example, if I were to add sonar range finding to the current infrared system the ir might find soft objects invisible to sonar while the sonar would function in bright sunlight conditions which might overwhelm the ir sensors.

The Servos

In the world of hobby robotics, using a continuous rotation servo in the place of a standard geared motor is like having your cake and eating it too. You get a nice geared motor with all of the ease-of-use of a servo. The GWS S35s are wired straight to the PICAXE with only a current limiting resistor - no H-bridge or other motor driver solution is necessary. The servos are controlled by using the PICAXE servo commands SERVO and SERVOPOS. A number below 150 will cause the motor to run counterclockwise. The lower the number the faster the motor will turn. A number above 150 will cause the motor to run clockwise. The higher the number the faster the motor will turn.

I was worried that they wouldn't have enough torque, but so far GWS S35 servos have been working just fine. Buying servos that are already setup for continuous rotation has some obvious advantages over modifying them yourself, not the least of which is that you eliminate the risk of doing damage during the modification. The downside of buying continuous rotation servos is that your choices are fairly limited. But again, so far I'm pretty happy with them.

The Search for Purpose

Perhaps the greatest challenge for a robot at this level is the search for purpose. Once the sensors are setup and basic situational awareness established, the robot really needs to have something to do. My basic ideas are along the lines of having the Beast navigate between way points.

In researching this area I came across a very interesting approach to using sound beacons at a personal robotics site Pitronics. In the method described, a robot issues a chirp and then after a brief interval a beacon responds with a chirp of its own. By calculating the time it takes to receive the return chirp and factoring in the delay interval a fairly accurate estimation of the distance to the beacon can be determined. With two or more microphones on the robot it should be possible to make further determinations about the location of the beacon based on the difference in how long it takes for the chirp to reach one microphone compared to the other.

Another potential beacon scheme that I'm researching is inspired by bar coding. This idea involves using a basic visible light sensor to search for beacons indicated by a pattern of black and white checks or stripes. The big appeal of this system is that it is passive. It doesn't involve any flashing or pinging but instead uses visible light much like a biological eye. Another appeal is that mechanically and electronically it might be very simple. Processing the data generated will likely be more complicated, but should be manageable nonetheless.

About the Author: Ralph Heymsfeld is the founder and principal of Sully Station Solutions. His interests include artificial intelligence, machine learning, robotics and embedded systems. His writings on these on other diverse topics appear regularly here and across the Internet.

Hobbizine

for all the things you do...