The March 2024 issue of IEEE Spectrum is here!

Close bar

How a One-Man Team From California Won NASA's Space Robotics Challenge

By mastering a Mars robot simulator, an engineer and stay-at-home dad took home the $125,000 top prize

7 min read
In NASA's Space Robotics Challenge, participants had to command a virtual Valkyrie robot to perform a series of repair tasks in a simulated Mars base hit by a dust storm.
In NASA's Space Robotics Challenge, participants had to command a virtual Valkyrie robot to perform a series of repair tasks in a simulated Mars base hit by a dust storm.

NASA’s Space Robotics Challenge (SRC) took place last month, full of virtual Valkyries wandering around a virtual Mars base trying to fix virtual stuff. Anyone was allowed to participate, and since the virtual nature of the competition means there was no need for big expensive robots that mostly didn’t fall over, anyone actually could (and did) participate. Of the 93 teams initially signed up to compete, NASA selected 20 finalist teams based on their performance completing some tasks in the Gazebo 3D robot simulator, and each of those finalists had to program a Valkyrie humanoid to complete a repair mission on a simulated Mars base.

The winner of the SRC was team Coordinated Robotics, which also was the only team to manage a perfect run with 100 percent task completion, taking home the US $125,000 top prize plus a $50,000 “perfect run” bonus. “Team” may be a little bit of a misnomer, though, since Coordinated Robotics consists entirely of one dude: Kevin Knoedler. We spoke with Kevin about his epic win, and also checked in with Nate Koenig from Open Robotics, which leads the development of Gazebo and helped organize the SRC, to get more info on the competition, along with footage of all the best outtakes.

The SRC was very similar to the VRC (the qualifier for the DARPA Robotics Challenge), in that all of the teams competed by running their code in a Gazebo virtual environment. “The tasks themselves were somewhat inspired by The Martian,” Open Robotics CTO Nate Koenig told us. “Valkyrie is on Mars, preparing the way for human settlement, and a dust storm comes.” Post dust storm, Val has to align a communications dish, repair a solar array, and locate and fix a leak in the habitat. Here are some highlights from the competition:

“The competition overall went pretty smoothly,” says Koenig. “A unique aspect of the SRC, as opposed to the VRC, is that we were emphasizing sequential completion of tasks. You get more points for completing more tasks in order without having Valkyrie fall or require a reset, so the more reliable you are in terms of walking and manipulating, the better you’ll do.” 

As with the DRC, the time limits on the tasks were set such that teams were heavily encouraged to use as much autonomy as possible. And it sounds like most of them did; only a few timed out. Making things even more challenging were severe restrictions on bandwidth coupled with latency designed to emulate (to some extent) what it would be like trying to teleoperate a robot somewhere out in space, as Koenig explains:

“Network latency and bandwidth limitations were more severe than the VRC. We wanted to simulate something closer to what you might experience with a round trip delay to Mars, but that would have been too extreme, so we toned it down to a maximum of 20 seconds delay. Some of the tasks had bandwidth limits of 380 bits/second, and if you look at those numbers, that essentially kills TCP. 

People had to get creative, and we did see some unique things: one person ran an IRC server and client to pass information, and some other people used just straight text-based console messages, getting no visualized data, which was pretty awesome: It was like reading The Matrix. One team [Team Xion] ran completely autonomously: They just deployed their code and hit go, and they were able to complete a lot of the tasks, which was impressive.

Koenig said he and his colleagues weren’t expecting any of the teams to complete all of the tasks in sequence. “But Kevin proved us wrong,” he added. “And he was the only team that was able to perform that feat.”

Kevin is, of course, Kevin Knoedler, who is the entirety of Team Coordinated Robotics. As Nate pointed out, Kevin managed to complete all of the Space Robotics Challenge flawlessly in a row, which is pretty amazing. We spoke with Kevin over email to learn more about how he pulled it off.

IEEE Spectrum: What’s your background, and what made you decide to enter the SRC by yourself?

Kevin Knoedler:After graduating from MIT I worked as an engineer and engineering manager at Teradyne. I left in 2007 to be a stay-at-home dad. Both during my time at Teradyne and in my current role as a stay-at-home dad, I have continued to be involved in various contests—Robot Wars, Battlebots, the three DARPA autonomous vehicle grand challenges, and the DRC. The SRC looked challenging and fun, so I signed up to compete in it.

I was busy coaching two soccer teams when the qualification round started (fall 2016), and I knew I would be busy coaching track and Odyssey of the Mind when the finals started (early 2017). It is usually key to contribute and coordinate with teams early in the project cycle. Since I would be busy with other things during those key times, I decided to do it alone to avoid frustration for myself and any team I worked with. Working with teams is generally a better choice as more people have more creative ideas. I have worked with teams on all of the previous contests.

During my time at Teradyne and in my current role as a stay-at-home dad, I have continued to be involved in various contests . . . It is usually key to contribute and coordinate with teams early in the project cycle. Since I would be busy with other things, I decided to do it alone.

How much autonomy did your strategy rely on?

I approached the design for the contest assuming I would always have the maximum time delay, so the robot needed to do shorter tasks on its own. Even without the design work, the up to 20-second delay was not a major problem given that the allowed time was in the hours. My perception code was not as reliable and accurate as I would like, so I focused on the robot doing the planning and execution. It was mostly supervised autonomy with human perception help.

You sent us a video of one of your runs [below]. Can you take us through it?

The video is a short third-person view of the robot completing the three tasks. The first is turning handles to align the antenna. The second task shows the robot removing a solar panel from the trailer, placing it on a table, and plugging in a cable. The final task is climbing the stairs, opening the habitat door, using a tool to locate the leak, and then another tool to fix the leak. One of the fun parts for me was when the robot would find the leak. There was a lot of area to be covered, some of which was partially obstructed, which made it exciting to actually find the leak each run.

The leak was found by the robot doing sweeps up and down and using torso rotation to minimize the amount of walking necessary. As the robot looked for the leak it kept track of the search area as either un-searched, clear, or leaky. That information was displayed to the operator via an interactive marker in Rviz [a 3D visualition tool for ROS] to make it easy to see what had been searched, and when the leak was found, easy to visualize.

What was the trickiest part for you?

I would say the most challenging part was the manipulation and use of tools. Getting a good grasp on the tool and then having the robot use the tools as an extension of the robot were hard to do consistently. I created a scenario in Gazebo where the robot started right at the tools with nothing else around. That allowed testing of picking up the tools from various starting positions and putting them down over and over. 

An interesting story from the contest: Sometimes real hardware gets stuck and has to be pushed to get it moving again, and the simulated [Valkyrie robot] in Gazebo also had this behavior. [Open Robotics called that an "interesting emergent behavior" that wasn't programmed in deliberately.] It was possible for the robot’s thumb to get stuck and no longer respond to commands. That happened to me during the contest on my third run. But, much like in real life, I was able to push the thumb against the table to get it unstuck and moving again to be able to complete the tasks. 

What kinds of things are easier in simulation than they are in real life?

The main thing that makes simulation easier is the hardware reliability—the simulation hardware doesn't break like real hardware frequently does. You can also try riskier experiments.

Everything is easier in simulation. It is not dramatically easier, but you can solve 90 percent of the problems in simulation. … The main thing that makes simulation easier is the hardware reliability—the simulation hardware doesn’t break like real hardware frequently does. You can also try riskier experiments. A falling humanoid robot in Gazebo does not cost $100,000 to repair and cause a multi-week delay. The other big advantage to simulation is that one person can run one or multiple tests simultaneously. With a real robot it generally takes multiple people to run a single test.

If NASA put a real Valkyrie inside of a physical mock-up of a Mars base and asked you to complete the same set of tasks, how do you think you’d do?

The robot should be able to complete the tasks after some initial testing to identify and fix differences between simulation and hardware. I had a layered approach where I could fall back to lower level control if the primary method did not succeed. There always seem to be enough differences between simulation and real hardware that some adaptations are needed for success. But, given some testing and adaptations, I do think it would be a success!

After participating in the DRC and now the SRC, how do you feel about the potential for humanoid robots to be realistically useful in disaster areas or planetary exploration?

After the DRC and SRC we are getting closer to be able to use humanoid robots in disaster areas on earth and for planetary exploration. The main challenges I see on earth are making the hardware robust, handling falls, and being able to do manipulation in difficult situations (crawling, obstructed or constricted working environments, situations requiring an arm for support, etc.). In space there are the same challenges plus the distances require giving the robot more perception and autonomy.

Kevin made sure to remind us to thank NASA, Space Center Houston, Nine Sigma, Open Robotics, and IHMC on his behalf, which we’re more than happy to do, because we’re also constantly wanting to thank them for what they’ve all done for robotics.

Oh, and before we forget: outtakes!

[ SRC ] via [ Gazebo ]

The Conversation (0)