Overview

What is M2?

M2: Bipedal Robot
Figure 1. M2

M2 is a roughly human-sized bipedal robot with 12 Degrees of Freedom (DoFs). Originally, M2 was designed and built at MIT’s Leg Lab under Professor Gill Pratt, but when he moved to Olin, M2 came with him. M2’s original purpose was to be a testbed for walking algorithms as well as a showcase for Professor Pratt’s Series-Elastic Actuator (SEA).

Tip
Series Elastic Actuator

SEAs are exactly what they sound like, an elastic element in series with an actuator. In M2’s case, this was a set of coil springs on the end of a linear actuator. By measuring the spring deflection, we can get the force on the actuator, assuming we know the spring constant.

This allows for an easy way of doing force control of the actuator, instead of having to use current control in the motors and dealing with the inertia and nonlinearities such as stiction in the drive train. There are some bandwidth considerations due to the added elasticity, but with careful selection of the spring constant, we can avoid most problems.

Project Goal

All of M2’s actuators are series-elastic, allowing us to use force control on all 12 DoFs. Combining the actuators in a coherent control mechanism opens up more possibilities for control algorithms, such as virtual model control and impedance control. Virtual model control is essentially the idea of representing the desired behavior of the robot with a force.

For example, to get the robot to stand, we could apply a force opposite gravity. The trick here is using the actuators to generate this virtual force. Impedance control is the idea of controlling how stiff and springy the robot is. Humans are very low-impedance systems, i.e. we conform to our environment, so it makes sense to be able to control the relative level of conformity of the robot.

Project History

One of M2's new FireWire boards
Figure 2. FireWire PCB Boards

The Leg Lab team was able to get M2 to stand, step from foot to foot, and take a few steps before stumbling. They did some of this work with a distributed computing architecture. The Leg Lab team built custom circuitry for each actuator, and attached the circuitry as close to the actuator as possible.

Unfortunately, this resulted in some issues, namely that the robot, when flailing about as robots are oft to do, tended to break its own circuitry, in addition to the standard problems that arise with distributed architectures.

To alleviate these issues, the team fabricated a new set of circuitry, based on programmable logic devices that would centrally control all aspects of the robot. There is one of these boards per leg of M2. Since the legs are essentially identical, manufacturing two boards was not a problem. Most of the processing was done off-robot on a high-end desktop PC, which communicated with the robot over FireWire.

More Information

For more information, see the old Leg Lab website on M2: http://www.ai.mit.edu/projects/leglab/robots/m2/m2.html.

Summer Research

M2's support gantry
Figure 3. M2’s gantry

The summer after my freshman year, myself, Matt Donahoe, and Matt Aasted all signed on as summer research assistants for Professor Pratt. M2 had basically been gathering dust over the past school year, and we were eager to try and get M2 to walk.

At the time when we began working on M2, the FireWire boards had already seen use, and the code to work with them had already been written. A previous team of students had done some work on M2 the previous summer, with mixed results.

Matt Donahoe dived into simulating M2, and Matt Aasted researched the various control algorithms. I was had the task of reading through all of M2’s C code and puzzling out the meaning. Unfortunately for me, the code wasn’t well documented, and was the brainchild of several different programmers, so making heads or tails of it in a short time period was difficult at best.

As the end of summer neared, I had read through the code, cleaned it up, and commented it. Matt Donahoe’s simulations gave us some initial PID values for our controllers, and Matt Aasted was ready to write some upper-level control algorithms. To ensure M2’s safety during the inevitable fall, we built a wheeled gantry to enable M2 to walk around and remain supported.

The last few weeks of summer were upon us, and after several marathon pushes, we were able to get M2 to stand on its own using PD control.

In addition to getting M2 to stand, we made some other improvements.

M2 has load cells in its feet, which measure the ground reaction forces as M2 moves around. Those load cells were originally connected to the distributed computing nodes, but no replacements were fabricated for the centralized control boards.

As a continuation of my work on the Force Plate, I designed some load cell amplifiers for M2’s feet and wired them into the control boards. Unfortunately, relying on the load cells for control was not a good idea, as there were four load cells per foot. Since three points determine a plane, each foot was overconstrained. Oftentimes, when a load cell lost contact with the floor, the simplistic control algorithms we had implemented would send the robot into spasms.

We also added a Crossbow tilt sensor to the robot, but by then the summer was over and we were only able to integrate the tilt sensor into the data collection systems and not the control algorithms.

Further Work

Over the course of the following school year and the following summer, the team expanded to include Chris Dellin and Cody Wheeland. The most significant contributions to the project that we made were redesigning M2’s feet to have only three points of contact with the floor (one heel and two toes), and re-writing the underlying FireWire and initialization routines from scratch.

The foot redesign would have helped with the algorithm stability problem, but we weren’t able to test the robot. The code re-write is not yet finished, but is at a point where the robot is communicating with its host PC over FireWire and initializing correctly.