My name is Stéphane Caron and I'm a robot locomotion engineer. I have developed locomotion software for HRP-4 humanoids and ANYmal quadrupeds. You can find out about the algorithms in the published papers or grab the code on GitHub. I post to my blog or to the robotics section of this site whenever I run into a noteworthy question. I hope these notes can help others :-)

Don't hesite to write me if you have any question or suggestion. You can reach me by e-mail, answer guaranteed if you use my GPG key.

Legged locomotion

Locomotion grows robots from “do this” machines to “go there, do that” machines, expanding significantly what they can do. I've been wondering why we don't have more of these abler mobile machines around us already. One reason, I thought at first, is that their control algorithms only track a narrow trajectory called a “walking pattern”. I've studied that question, and we can indeed make walking patterns more general. But when I developed a walking controller to make the HRP-4 humanoid climb stairs, general walking patterns were not what helped the most in solving the more general task.

What helped the most was the simplification and tuning of the robot's stabilizer, which is the reflexive part that decides how to react to disturbances (roll the ankle? shift the pelvis? maybe tilt the torso as well?). On HRP-4 all these reflexes were implemented by hand-tuned control systems such as linear feedback and model predictive controllers, but hand tuning doesn't scale up to the full scope of things that “go there, do that” machines can achieve. We can do better.

Open access

As academics, we want our works to be reproduced not only by experts, who are already advanced in their various paths of knowledge, but also by newcomers eager to climb up their own paths. For them, published papers ripe with field idiosyncrasies (which come naturally from compression to a fixed number of pages) are not an efficient tool. That's why we should distribute compilable source code of our works. Note the emphasis on "compilable": non-compilable source code is weaker and somehow less likely to be used, for good reasons. By giving access to the usable source, we help ensure knowledge gaps can be crossed by newcomers who take the time to work them out. Papers cannot be fully detailed on every point, but compilable source code has to.

On a publishing variant of this stance, I support the model of overlay journals, also known as “reviewing entities” or “Peer Community in”, where peer reviewing happens on pre-print repositories like arXiv or HAL. We should put out pre-prints first, then iterate on them in the open, taking into account feedback from colleagues and reviewers. The record of these iterations is also valuable information for newcomers eager to cross knowledge gaps.

© Stéphane Caron — All content on this website is licensed under the CC BY 4.0 license.