Welcome!

My name is Stéphane Caron and I'm a locomotion engineer. I have worked on the locomotion of Kawada HRP-4 humanoids and ANYbotics ANYmal quadrupeds. You can find out about the algorithms in the published papers or grab the code on GitHub. I write posts to my blog, or for robotics questions to the teaching notes on this site, whenever I run into cool questions, helpful tricks, or just spend too much time on something I want to remember later ;-)

I love feedback so don't hesite to write me if you are on a similar path and have questions on things I haven't detailed here :-) You can reach me by e-mail. Answer guaranteed if you use GPG.

Legged Locomotion

Locomotion grows robots from “do this, do that” 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 walking 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 an open-source walking controller to make the HRP-4 humanoid climb stairs, it turned out it's not the more general walking patterns that 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. I'm sure 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 source, we make sure knowledge gaps can be crossed by anyone who takes the time to work it 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 who want to cross knowledge gaps.

© Stéphane Caron — Pages of this website are under the Creative Commons CC BY 4.0 license.