Posted by Wade
If you are looking for ideas on how to create highly functional mechanical walkers, Professor Joseph Shigley's 1960 feasibility study for the army is a great resource. It combines engineering rigor and sound reasoning to illuminate many of the challenges, and potential capabilities of mechanical walkers.
To meet the requirements of walking tanks, Shigley sought a mechanism that could:
To meet the rugged terrain and speed requirements of tanks, much of Shigley's study focused on the foot-paths of mechanisms. Below is Shigley's diagram of foot-path types, with type E representing his ideal type for rugged terrain and fast speeds.
When Creating New Mechanisms, Start By Investigating 4-Bar Linkages
In general, the fewer bars in a linkage, the better (lower costs and build-times, less mechanical complication and friction, etc.). So, searching for a mechanical solution based on a 4-bar linkage is usually a wise first step. Shigley advised searching thru Hrones-Nelson's atlas of hundreds of 4-bar linkage coupler curves as a "good first approach to such a problem", which must have been a vital resource for mechanical engineers in the days before personal computers. Below is one of the better 4-bar linkage configurations Dr. Shigley found in Hrones-Nelson's atlas, but it doesn't step high enough for rugged terrain.
Shigley described how the step-height could be increased by allowing a joint to slide along a cam groove, but we wanted a mechanism that could be prototyped in LEGO. So, instead we experimented with pairing two 4-bar linkages into a combined 10-bar linkage with front and back legs, such that the rear leg lifted the front foot and vice versa. This allowed us to increase the step-height significantly.
We found that the boat-shape of Strider's foot-path mitigates this problem, since the foot's horizontal speed during the lift and lower phases is similar to the foot-speed of the drive phase. This can be seen in the above GIF of Strider walking across the screen. Notice how the bottom halves of its lift and lower phases are nearly vertical, which means that when a foot steps on an obstacle halfway down its lower phase it will be less likely to skid or cause the robot's forward motion to stop while stepping up onto the obstacle.
The impact of the boat-shape can be exaggerated by reducing the number of legs from 12 to 8, causing the feet to contact the ground well above the bottom drive phase of a 12 leg Strider:
You can see this in action in the below video of an 8-legged Strider walking on rocky terrain, where Strider's feet often contact the rocks well above the bottom drive phase, yet the robot's speed remains fairly consistent as it walks across the rocks:
How robot speed varies as ground height changes can also be gauged by simulating the front legs while keeping the mechanism horizontal, which results in fairly consistent speed for mechanisms with rounded foot-paths like Striders:
In contrast, the feet of robots with triangular foot-paths will be going the wrong way when stepping on/off obstacles, or when the terrain's slope changes abruptly. If the feet can't skid, then the change in the terrain's elevation can push the robot backward, as happens to Klann's Mechanical Spider below. If the rear legs aren't stepping on a similar obstacle at the same moment, then they'll be pushing the robot forward as usual, fighting the front legs and potentially jamming the mechanism.
Here's a test of how Strider and Klann linkage robots handle elevation changes, using a slope change to make the test scale-independent:
The front-to-back symmetry of Strider's foot-path results in fairly consistent horizontal speed when the terrain's elevation changes on either side of its foot-path - e.g. when either ascending or descending the stilts in these simulations. In contrast, TrotBot's foot-path is somewhat teardrop-shaped. This causes TrotBot's horizontal speed to drop when encountering large elevation changes on the shorter, inner side of its foot-path, which can be seen in the below simulation when TrotBot steps down to a lower stilt:.
Tank-Scale Functionality on Rugged Terrain?
Strider's high-stepping, boat-shaped foot-path allows it to meet Shigley's rugged terrain requirements fairly well at LEGO-scale. However, tank-scale functionality on rugged terrain is another matter, which would require the robot to be strengthened dramatically due to the lower strength-to-weight-ratios of larger scales. Furthermore, increasing strength typically involves adding structure and motor power, which further increases weight, which requires even more structure, which adds even more weight and costs, etc.
The legs in particular would need to be strengthened, since walking along the side of a hill, or turning the walker tank-style while on rugged terrain would put a tremendous amount of sideways forces on the long legs - if it were even feasible at such large scales. However, adding too much structure and weight to fast-moving legs would create other problems. Instead, perhaps the lower half of the legs could be supported laterally by rails connected to the frame? Rails that created channels that the leg's path should follow? Positioned below the legs' knee and "hamstring" joints to reduce sideways forces on these weak points? Eh......for rugged terrain I think I'll stick to smaller-scale walkers, which also benefit from Shigley's insights.
High Speed Walking
As Shigley described, an ideal walking mechanism for a tank should have the constant horizontal speed of a wheel, while also being able to step over obstacles that block wheels. Strider has relatively constant foot-speed, as indicated by how little the feet skid in the following video. Since the feet aren't constantly accelerating/de-accelerating the robot this improves the gait's efficiency, and Strider is the only mechanism that we've tested which can walk with a 1:1 gear ratio without the LEGO motors stalling:
High Speed Vibration
Shigley also described how the vertical and horizontal inertia forces of the mechanism should be balanced for a tank to walk fast without vibrating itself to death. Such vibration isn't much of a problem at LEGO-scales, but it gets dramatically worse as scale increases. If you've ever driven a vehicle where the steering wheel shakes due to its wheels being out of balance, and seen how it's corrected by attaching small metal weights to the wheels, then you can probably imagine how much worse the vibration problems could be for a vehicle with large mechanical legs running at high RPMs.
Strider's mechanism would need to be modified in order for a large-scale version to walk at high RPMs with limited vibration. If curious, Shigley's study below shows how to mathematically analyze inertia forces by calculating the horizontal and vertical accelerations of the legs' masses, and gives some suggestions for balancing them.
Load Bearing and the Linkage's Bar Count
The more bars a linkage has, the more joints it needs. Each joint adds friction. Furthermore, the joints will always have some play, which can cause long legs with many joints to bend sideways under loads, especially when turning them tank-style. Like Klann's 6-bar linkage, Strider's linkage has relatively few bars per leg with 10 bars per leg pair, versus TrotBot's and Strandbeest's 8 bars per leg. If implemented well, this implies that Strider's linkage has the potential to be relatively energy efficient and should be able to handle loads relatively well.
Below tests linkage variation #6 with a 25 pound load. The plastic parts bend and shift somewhat under the load, increasing the difficulty of carrying the load, but the LEGO motors didn't stall. Also, we were planning on uploading a video with Strider self-destructing at the end by attempting to turn it while carrying 25 pounds. Some of our other walkers self-destructed while carrying much less weight, so we were a bit surprised that Strider survived with its legs intact. Strider's low bar count per leg does appear to result in a stronger linkage.
Notice how adding the weight causes Strider v6 to have a stammering gait, which is due to Variation 6 having less consistent foot-speed than does Variation 7 featured in the slow motion video above.
Before performing this test the plastic LEGO axles were replaced with steel axles to handle the torque. Other than that, and the 2 steel support rods, all of the parts are plastic LEGO parts connected by LEGO pins (no glue).
Strider's linkage dimensions can be found here, and other configurations of Strider can be found here where you can also create your own customized Strider linkage with an interactive simulator.
Below is Prof Shigley's feasibility study, a 1960 Popular Science article discussing it, and the Hrones Nelson Atlas of four bar linkage coupler curves.
TrotBot's lower leg pins tend to come out when the legs experience sideways forces, as can happen when turning TrotBot on terrain with a lot of friction (like on thick carpeting).
If the legs aren't snapped back in place, then friction on the pin's lips will wear them down, and the pins will no longer join with a sharp "snap", causing them to pull out more easily. Ideally, joints should be 3 beams wide and symmetrical like the red chain of beams below, which prevents pins from pulling out or bending sideways when bearing weight:
However, using LEGO's parts to sandwich TrotBot's leg joints inline like the red beams above would add a lot of width to the robot. Instead, I sandwiched the leg joints by attaching an additional 3x5 L-shaped beam to the outside of the legs, which is a bit off center but still works well with LEGO's high strength-to-weight ratios. I tested these new attachments by turning TrotBot on some thick carpeting, which would usually cause a few of the leg's pins to pull out. Below the video are some pictures of how I added the parts, and I used these attachments in my TrotBot version 3 builds.
I've got a few other ideas to test over the next few weeks, and then I'll post some new TrotBot instructions with the improvements. UPDATE: Here are the new instructions with a part list.
I rushed my Klann Ver 2 build and didn't build the outer frames in an optimal way:
The only thing keeping this frame's corners at right angles are the two 3x5 L-shaped LEGO parts. If this frame were put under a lot of force, like would happen at a larger scale, the corners would be subjected to torque that could easily cause the rectangle to collapse. To avoid this diagonals need to be added, which will convert the rectangles into triangles and lock the corner's angles.
The challenge with walkers in LEGO is we often need diagonals for rectangles that define the linkage's parameters. In other words, these diagonals often need to be the hypotenuses of right triangles. As you can see below, my Klann's upper support rods are 7 holes above the motor's axle, and the lower support rods are 2 holes below the motor's axle. Neither of these lengths work with a 3-4-5 or 6-8-10 right triangle with LEGO parts for hypotenuses. What can we do using the integer lengths of LEGO's beams?
NOTE: When determining the length of LEGO beams the first hole is always counted as 0! If you don't measure LEGO beam lengths in this way you won't be able to use the Pythagorean theorem to calculate which beams to use as hypotenuses.
Fortunately, with LEGO we don't have to be at precise integer numbers, and we can use hypotenuses that are close enough.
1. Hypotenuses for rectangles of height 7.
Plugging in a 90 degree angle with a side length of 7, plus a few other whole number sides into the Pythagorean theorem yields this near integer number triangle:
I used this triangle for Klann's inner frame where two 9 hole beams create hypotenuses of length 8:
I also used this triangle for TrotBot's frame:
2. Hypotenuses for rectangles of height 9.
We can also connect the top and bottom beams of Klann's frame with a hypotenuse:
Plugging a 90 degree angle with a side length of 9, plus a few other whole number sides into the Pythagorean theorem yields another near integer number triangle:
So, 13 hole LEGO beams can be used to lock Klann's outer frames into triangles, like this:
Here are a few other useful triangles for LEGO frames:
Also, the below 5-3 bent beam can be used as a hypotenuse.
You can create more triangles by lengthening a side of the above parts by attaching a LEGO beam to it.
When two linked bars are nearly parallel their connecting joint can easily flip orientations and cause the linkage to lock. This phenomena is known as a "Dead Point", "Toggle Point", or "Singularity". Here's an example of what Klann Ver 1 experienced, since it used a configuration of the linkage where the "knee" joint came close to being straight :
The below right picture is near the Dead Point, where two bars highlighted in red are nearly parallel:
Due to the force on the foot, the joint can hyper-extend and "flip" as shown below, which causes the linkage to lock::
Like how animal joint hyper-extension is prevented by structures like ligaments and elbow bones, linkage joint hyper-extension can be prevented by adding structure.
Side Comment: did you notice how the knees of mammalian quadrupeds' rear legs don't actually bend backward? As can be seen by the green foot bones and blue shin bones, the backward bending "knee" joints of horses and cats are actually their ankle joints, and their lower legs aren't their shins but are instead long feet, and so they walk on the "balls" of their rear feet with their heels far off the ground. No wonder us humans are more agile when we aren't "caught flat footed" and are instead on our toes ready for action.
Below are some examples of joint "hyper-extension blockers" in LEGO.
The following solution for Klann Ver 1 blocked the joint from flipping with the addition of a 2-hole red LEGO beam:
Dead-Points are also know as "change points", which all Parallelogram linkages have:
As shown below, Strandbeest has (nearly) a parallelogram linkage in the center of the mechanism, and its knee joint can also flip:
Strider's knee joint also has a dead point that needs to be managed. As you can see in the following simulation, Strider's knee joint hyper-extends inward during the weight-bearing phase of the crank's rotation:
Adding weight to Strider robots can cause the knee joint to hyper-extend further, which can either reduce the height of the leg, resulting in a bumpier gait, or cause the joint to flip.
As shown in the image below, Strider Ver 3 uses blue LEGO pins to limit knee hyper-extension, which work well at LEGO-scale weights, but when heavy loads are added to Strider, these blue pins bend and the gait gets bumpier.
In the following experiment we added stronger "hyper-extension blockers" to a Strider robot using Linkage Variation #6, which we tested with a 25 pound load. The blue pins were still used, but an additional part was added to the front of the knee that presses against the shin if the knee hyper-extends too far.
Below is a video of the test. Notice when the weight is initially placed onto Strider, the inner knee on the right side hyper-extends slightly, but not enough to prevent Strider from lumbering away under the 25 pound load:
Note: before performing this test, the plastic LEGO axles were replaced with steel axles to handle the torque. Other than that, and the 2 steel support rods, all of the parts are plastic LEGO parts connected by LEGO pins (no glue).
Below shows how we managed Strider Ver 2's dead point:
Dead Points can also be "directional" in nature. For example, adding a motor, crank and 6th bar to the below puncher converts the motor's circular motion to oscillation of the punching arm. However, reversing the mechanism by manually moving the arm back and forth won't necessarily cause the motor to rotate 360 degrees. When the puncher's "elbow" joint is either fully bent or straight, the crank and 6th bar will be parallel, and applying force to the arm at these points will no longer cause the motor to rotate. This is why the crank is rotated less than 180 degrees at the beginning of the video. How this impacts walkers is explored in Dead Points Part 2.