While our LEGO-scale TrotBot solved the problem of feet getting stuck on obstacles, we weren't sure how our mechanism would work at large scale. So, in the ethos of our LEGO Engineering class, we decided to "put our ideas to the test" by scaling it up.

Team members brought three key areas of experience to the scale-up:

1. Experience with

2. Experience with

3.

During the scale-up the team also developed skills with basic tool use (which most no longer learn in shop classes), and showcased their computer programming skills by writing their own improved versions of our simulation software, which employs basic algebraic and coordinate geometry algorithms within their grasp.

During the first month of the project we met a couple times a week to explore the problems involved in scaling up with either experiments where possible, or as homework assignments where I would withhold my thoughts on solutions to let the boys discover their own, which we would then debate as a group. We even explored solving the problem of "how to solve problems", which from my perspective was one of the primary goals of this project. Debating root causes of problems and noodling out solutions seemed to be the most fun aspect of this project for the team.

The major design decision we had to make was whether to go with 2 or 3 "horses" per side of the robot (8 or 12 legs). While we knew from both LEGO prototyping and computer modeling that 12 legs would significantly improve TrotBot's gait due to having more foot-contact with the ground at each corner, and would increase our odds of producing a machine with a smooth gait, this also seemed like an overly wide solution. Instead, we chose the more risky design path of 8 legs, thinking that if we could make that configuration functional we would have a better solution for our goal of creating a walking machine that could traverse rough terrain. A comparison of the gaits of 2 versus 3 horses per side in LEGO prototypes can be seen in this video:

**Team Preparation**Team members brought three key areas of experience to the scale-up:

1. Experience with

**Straight-Line Linkages**that convert the rotational motion of an axle to the linear motion of a foot. The team explored various linkages, their trade-offs, and how they can be implemented on motorized frames to create functional walking machines in this advanced LEGO Engineering class.2. Experience with

**Statics**, or the building of strong structures with minimal material and weight. The primary problem with scaling up is reduced strength-to-weight ratios, and if we did not employ basic Statics principles in the scale-up the resulting TrotBot would not even be able to stand under its' own weight, let alone walk. For the previous two years the team had solved numerous Statics problems in our LEGO Engineering challenges, such as bridges and cranes which were tested for failure weight, and they had become quite skilled at using triangles to transform bending forces to tension and compression in creative ways.

3.

**Problem Solving**. While all students develop problem solving skills to a degree, this project required those skills at a very high level. Problems had to be broken down into sub-problems, testing procedures for each sub-problem had to be developed, and the trade offs of potential solutions had to be thought about critically. The team had honed their problem solving skills in our various LEGO Engineering challenges where no solutions were provided for them, only parts, some sort of testing method like this bridge tester, and a motivating goal.During the scale-up the team also developed skills with basic tool use (which most no longer learn in shop classes), and showcased their computer programming skills by writing their own improved versions of our simulation software, which employs basic algebraic and coordinate geometry algorithms within their grasp.

**To Find Better Solutions, Focus on Defining the Problem**During the first month of the project we met a couple times a week to explore the problems involved in scaling up with either experiments where possible, or as homework assignments where I would withhold my thoughts on solutions to let the boys discover their own, which we would then debate as a group. We even explored solving the problem of "how to solve problems", which from my perspective was one of the primary goals of this project. Debating root causes of problems and noodling out solutions seemed to be the most fun aspect of this project for the team.

**Design Choice: Lean or Fat?**The major design decision we had to make was whether to go with 2 or 3 "horses" per side of the robot (8 or 12 legs). While we knew from both LEGO prototyping and computer modeling that 12 legs would significantly improve TrotBot's gait due to having more foot-contact with the ground at each corner, and would increase our odds of producing a machine with a smooth gait, this also seemed like an overly wide solution. Instead, we chose the more risky design path of 8 legs, thinking that if we could make that configuration functional we would have a better solution for our goal of creating a walking machine that could traverse rough terrain. A comparison of the gaits of 2 versus 3 horses per side in LEGO prototypes can be seen in this video:

**Construction**

We then went into the garage to start building. While construction wasn't always a straight path, in general our ethos to systematically anticipate and explore solutions to problems paid off, and we had the first version of TrotBot ready to test within about 2 months of weekend work.

**Walking Test 1: Breaking a Shoulder**

While our frame, legs, transmission, etc. largely functioned as planned, our 2 horse per side design choice proved inadequate. Rather than having a foot on the ground of each corner like a stable 4 wheeled vehicle, this configuration oscillated from having a foot on the ground at each corner to a tripod state which was also a low point from which the machine resisted rising. Furthermore, descending into these low points put large stresses on the legs, breaking a shoulder.

Walking Test 1: Breaking a Shoulder

**The Problem isn't the Shoulders, it's the Feet**

While the obvious, brute-force solution for our broken shoulder was to build stronger versions, which we did, we first paused to explore why it broke to better define the problem. Slow-motion videos of the walking test showed the shoulder broke not just from the force of hitting the low point of the tripod state, but from the leg bending sideways upon impact. We debated solutions to prevent such bending, and finally got consensus when we ran an experiment on our LEGO Engineering bridge tester that showed a leg with wide feet would resist bending sideways, since such bending would cause the robot to rise. We then built and installed the stronger shoulders and wide feet and did our second walking test. While TrotBot still suffered from the tripod low points, the wider feet helped to keep the legs vertical and the shoulders did not break.

After this test we disassembled TrotBot and we went back to prototyping in LEGO and computer simulators to find a solution for the tripod low points of our 2 horse per side configuration. This yielded the additional linkage that acts like an expanding heel for each foot, which obviates some of the need of a third horse per side. We also explored adding toes to the feet, and chose the rigid toe shown in the image below. We referred to this heel/toe combination as our "articulated foot", or "Feet 2.0" in our versioning.

**Walking Test 3**

The following summer we installed Feet 2.0. This was much more involved than Feet 1.0 since the additional linkage attached to the mid-point of a leg section, which required trussing to handle the stresses. As with the other leg sections we made jigs, or drill templates, to create identical parts on my drill press. Here's how they looked while rotating the crank on the stand:

And here's the resulting walking test:

**Next Steps?**

While feet 2.0 improved TrotBot's gait, it still suffered from a low point where the "toes" of our feet fail to push down for another 5% or so of the axle's rotation. We have a feet 3.0 simulated which mitigates this and should result in a smoother gait, but the best option to ensure a smooth gait would be to switch to 3 horses per side, or 12 legs. I think we'll delay deciding until Boston Dynamics sponsors us! ;)

Considering how difficult it is to design and build such a complicated machine that actually walks using nothing but our wits and home-made computer simulators, and with tools no more sophisticated than a drill press, I'm pretty amazed by how far we got. Just a heads up - any of my team members would be excellent candidates for a technical internship - they are smart, hard working, and are a blast to work with!