Hi, I was there! I was on the field team WPI-CMU's robot Warner. (I am one of 4 undergraduate students on the team, I have worked with the team for 1.5 years.

Hi, I was there! I was on the field team WPI-CMU's robot Warner. (I am one of 4 undergraduate students on the team, I have worked with the team for 1.5 years. I worked on UI's for operator control, robot testing and many other side projects). Just thought I would mention that our Atlas Robot never fell down or needed a reset. We completed 7/8 tasks, we unfortunately failed the drill task twice. The first time because of software error, and the second time a hardware error. There will be some papers coming out in the future from my team, and I am sure there will be plenty from the other teams. I am using in flight wifi, so I will not be providing youtube links to my comments, but I encourage you to check out the youtube pages for WPI-CMU Warner, MIT, and IHMC To respond to some of your other comments: WPI-CMU, MIT, and IHMC all had their own balance controllers and specialized walking for atlas. I do not know as much about the other atlas teams. The atlas robot is ~400 lbs and ~7 feet tall. My team looked into fall recovery, but we found that the arms we not capable of doing a "push-up" to get the robot off the ground. At that point we decided the best strategy was to do everything in our power to avoid a fall. My understanding is that both MIT and IHMC damaged their robot during their falls. Any attempt to recover would have likely failed anyway. If a fall occurred the safest option was to e-stop the robot to turn off the hydraulic pump. Picking objects up off the floor is tricky. Our team has done it successfully on occasion during tests, but it was very risky and also often caused the robot to fall. In many cases the software reaches the limit of the mechanical capabilities of the Atlas robot. Even though the Atlas is the cutting edge in robotics getting out of a car is a challenge because it's range of motion is incredibly limited compared to that of a human. It takes Warner ~3.5 minutes to get out of the car and onto a platform we added on. This the result of 2 years of work by a brilliant researcher who exclusively worked on egress. It might be true that most manipulation was pure teleoperation for some teams, but that is not the case for WPI-CMU. I also think MIT and IHMC were highly automated. The pauses in operation were often the robot running planning algorithms. For example we click a point on the operator screen to select an object - such as the drill. Then the robot autonomously determines the location, and finds the most efficient way to grasp it using a technique called trajopt. (If I'm not mistaken) Tartan Rescue used another technique called RRT's - it's rapidly-exploring random tree. These types of algorithms take time. Regardless, after some practice operation with full communication and with com dropouts had similar run times. Manipulation and locomotion are difficult because manipulation changes the location of the center of mass on the robot. WPI-CMU uses a static stepping technique the always shifts the center of mass above a stationary leg, it then lifted and moved it's other leg, then placed it down. The robot would shift it's weight after the foot is on the ground. Moving the arms while one foot is in the air is not easy. IHMC has a karate kid video where they balance on one foot and do a few kicks and move their arm. It is very very impressive, but not easy. Originally teams were given 30 minutes to complete each task. Now teams had 1 hour to do all tasks. Things were going to have to change. Hopefully everything I wrote made sense, and helped clarify things.