Now that the IHMC open source initiative is underway and we’ve started to receive some feedback, we feel that it’s a good time to start providing a little bit more information about our goals, roadmap, and intent. The open source initiative orbits around two key components: Simulation Construction Set (SCS) and our whole-body control algorithm for walking and manipulation. We realize that it may have been confusing for our existing alpha testers as to what we mean by “open source” since many of our components were provided to testers as binaries; this initiative is not just about providing an open source wrapper, but about open sourcing the underlying code itself. As we work towards this goal, we want to talk about our intent and ideas for where these pieces of software are going and how this will impact people who choose to use them, and how this may impact any DRC team that chooses to adopt our software.

Simulation Construction Set

SCS is, at its core, a cross-platform simulation and analysis environment developed in Java and designed from the ground up with walking in mind. Due to this, there are some aspects of SCS that cause it to differ from Gazebo; we feel that the underlying physics engine and architecture lends itself to walking with much less parameter fiddling and tuning out of the box. But unlike Gazebo, the contact and collision modelling does not readily accommodate high-fidelity simulation of grasping and manipulation. We plan to rectify this in the near term with a ground up revamp of how collisions are detected and resolved. This includes not only improved contact modeling, but support for simulating grippers (which can be computationally complex). This will be available early enough to use before the finals (since we need this functionality too), but it is not available out of the box right now. Additionally, unlike Gazebo, SCS is developed as more of a library or SDK for creating simulations than it is a stand-alone simulator in which to design environments and scenarios independently; SCS simulations are programs rather than descriptions and models. Combined with our use of Java and its lack of a static compilation step, this has served us extremely well internally in allowing for very rapid prototyping. But we realize that this is not attractive to a lot of people; some people need the physics and contact modeling that Gazebo provides, some people don’t want to switch away from Gazebo, some people don’t want to make the switch to Java as a programming environment, and for anybody with an existing Gazebo-based workflow this is a huge shift whether the desire to switch is there or not. For this reason, we are also providing a version of the Atlas robot model as distributed in the drcsim package from OSRF that replaces the ROS plugin with an IHMC plugin. Our plugin provides a bridge from our controller in to Gazebo. We plan to work with OSRF to have this model distributed as part of future drcsim releases alongside the other versions of the Atlas model.

IHMC Whole Body Controller

The chunk of the open source release perhaps of most interest to a lot of people would be the controller. We have received a great deal of questions about our controller and what we plan to offer, so in that frame let us clarify what we are and are not planning on doing at a high-level with our controller.

The first thing that we want to mention is that our intent with this open source release is not to strictly target Atlas or the DARPA Robotics Challenge; this is the easiest audience to target today, but our goal is to provide a long-term, open-source, publicly available solution for controlling walking robots to any academic, hobbyist, etc. organization that would like to use a walking robot platform but maybe have issues with a lack of time/interest/resources to tackle the challenging walking problem. This is probably our most important and driving concern: making it easier for researchers and developers who are not experts in bipedal locomotion to get humanoid robots to do real tasks. This goal will be informing a lot of our decisions in regards to what features we implement, how our API looks, and where to best allocate our resources. So while many people will have many requests for many things, at the end of the day it will be up to us whether or not implementing something that makes the DRC easier or integration with a team’s DRC stack more streamlined is also beneficial to walking robotics as a whole.

Perhaps the question we’ve received most frequently from our testers, who are Atlas teams, is “what does our controller offer that Boston Dynamics doesn’t?” This is actually a fairly difficult question to answer, because as Atlas teams none of us really know how the Boston Dynamics controller works due to its black-box nature and lack of accompanying publications describing their algorithms. That said there’s no question that for our control software to be considered useful to other Atlas teams it has to provide a value add over the existing solution that makes the opportunity cost of converting any existing software that uses the Boston Dynamics API worthwhile. Out of the box, our initial value proposition is:

  1. An open-source, documented, and published algorithm that teams are free to modify, study, and otherwise dig through to their hearts content. The open-source release will encompass not just our source code but also a public forum, public bug tracker, and publicly viewable continuous integration server to keep other teams abreast of the status of the software and should deliver a reasonable amount of confidence in regards to whether or not a new release will “break” anything.

  2. Out of the box support for whole body control. No switching of modes necessary, and no issues moving the upper body or carrying small tools while walking.

In regards to the quality of the walking algorithm, we can’t really provide any more sense of confidence than what we’ve already provided; the algorithm we will distribute to the teams will be the exact same algorithm that led us to 1st place in the Virtual Robotics Challenge and 2nd place in the DARPA Robotics Challenge trials; any improvements we make to the algorithm will make it out to the public and other teams will reap its benefits alongside of us. The algorithm that IHMC will be using at the Finals will be the same as the one that is released to the other Atlas teams. Some of the more quantifiable improvements over the Boston Dynamics software include a more robust framework for dealing with increased forces/torques at the hands/wrists (such as when providing contact with the outside world e.g. climbing a ladder or when lifting up a tool) and faster walking among other things.

We know that most teams have no intent of switching to Java. Therefore, the "high level" API will be a ROS-based API that will closely mimic our internal API. For the Atlas teams, we are actively investigating the ability to switch between our controller and the Boston Dynamics control API on the fly. We are also in the process of establishing 1KHz pass-through for the control data from the Atlas robot when running our controller. As time goes on, the API will grow to accommodate new features. As to what features this will include, we obviously don’t know yet, but at a high level we do have an idea of what teams can expect soon. We have been working with some third-party software and can start to promise a few new tricks that are absent from the existing Boston Dynamics tools that will be on the near-term roadmap. Through the help of some friends at the ETH Zurich Autonomous Systems Lab, we have added an API for externally communicating localization information to our controller and have tested it with their fantastic iterative closest point based localization and mapping software. The ETH software is also open source and we are looking for ways to provide this to the teams. You can see a video of the impact that this localization has on our walking in this video. We also plan to add API support for other high level external tools like footstep planning based on heightmap data so that teams can integrate their existing software more easily.

We will be working diligently on the algorithm in simulation with the new Atlas models in the coming weeks while the robots are being upgraded so that we can get up and running with the new robots as soon as they get back. With this in mind, please keep an eye on our BitBucket repos for the source code releases of SCS and the control algorithm, and submit any feature requests, API changes, bug reports, etc. We have also launched a simple forum at for users of our software; probably won't be much activity there right now, but we hope to see the community grow in the future.

Hopefully this clears up a lot of the lingering questions about what we intend to provide, and if you have any further inquiries feel free to reach out to us.


IHMC Robotics Open Source Software Team

AuthorDoug Stephen