Abstract¶
In this talk, we discuss some hardware and software practices to foster cross-lab developments in robotics. On the hardware side, we highlight the alternative made possible by recent innovations in actuators: building lighter robots of the kind that can (1) be made at home/with minimal equipment, and (2) bump, fall on, or be lifted by us with no harm. We'll discuss the example of Upkie as one instance of this template.
On the motion control side, we look at how the physics of a task dictate how fast a controller should run to perform it. Balancing, in particular, is a rather low-frequency task: it was demonstrated (in theory and on real hardware) that a DCM-based controller can balance an adult-size humanoid while running at only 10 Hz. Jumping on this, we discuss how this property allows us to write more control-critical code in a high-level language like Python. We illustrate our points with practical sub-modules from two controllers: the LIPM walking controller for HRP humanoids, implemented with mc_rtc, and the Pink controller for the Upkie wheeled-biped, implemented with Vulp (🦊).
Recording¶
Content¶
Slides | |
Recording of the presentation | |
Python code from the slides | |
Motion control software for the Upkie wheeled biped |
Discussion ¶
You can subscribe to this Discussion's atom feed to stay tuned.
-
Daniel Felipe Ordoñez Apraez
Posted on
Going forward, do you have plans to bridge or standardize conventions between simulators and motion control libraries?
-
Stéphane
Posted on
I have faced what you are pointing to, which is that simulators and e.g. kinematics or dynamics libraries sometimes use different conventions, and that creates friction in our work. What Vulp provides currently is just a simulator-real robot switch, so it does not try to address this question. It is a worthy question though and standardization (e.g. via a better description format) could help.
-
-
Silvio Traversaro
Posted on
You mentioned how packaging and software distribution is important in general, with which I agree, as opposed e.g. to the opinion that a list of command-line instructions (with no versioning) is sufficient to distribute research software. You also pointed out how this feature is lacking in C++. Any hint on how this can be improved?
-
Stéphane
Posted on
First, I'm also looking for a satisfactory answer to this question, and I haven't found it yet 😉 As a user I feel CMake over the last ten years hasn't been delivering to a level that will eventually take us out of this valley. That's what drove me to try out Bazel, and I found some great improvements there. For instance I'm happy about the fact that it can fetch and build the whole locomotion stack for Upkie in one go without installing anything:
git clone https://github.com/upkie/upkie.git cd upkie ./start_test_balancer.sh
As of 5.3 Bazel doesn't solve everything, e.g. diamond dependencies are still work in progress, but there is a roadmap and I'm following it. For this particular example, the Bazel Central Registry tackles diamond dependencies, and it looks a lot like conda-forge's stages-recipes.
-
-
Stefano Dafarra
Posted on
I'm curious about the result you showed about the sampling period (this slide about this work). I wonder how this result would hold under external disturbances: don't we loose something with a larger sampling period?
-
Stéphane
Posted on
The answer depends on the spec for external disturbances. Whether it's explicit or not, there is always such a spec (for instance we don't expect a balancing biped to sustain a 1,000 N push for 1 s without falling). External disturbances are modeled in this work as a bounded ZMP uncertainty , which is fed into the closed-loop discrete-time dynamics as:
My understanding is, starting from a given spec for external disturbances that the robot should be able to sustain while balancing, we should be able to define a corresponding set and unroll the model.
I haven't checked this, but if the set is too large, one assumption of the work (that the ZMP stays inside its support area) would not hold and the maximum sampling frequency would be lower than the bound we mentioned. See the discussion around this related question.
-
-
Daniele Pucci
Posted on
What is your take on how much of a robot's design should happen in simulation versus how much should happen iterating on/with hardware, possibly in relation to the sim2real gap?
-
Stéphane
Posted on
My answer will be mostly opinions without facts to back them up, I hope that's OK.
For some design questions, it is better to iterate in simulation rather than on hardware. I saw one example of this with the Low-Friction 12-DOF Tendon-Driven Robot Hand that was developed at the Nakamura Lab during my PhD, where one question was: where should we position the various pullies to optimize (for some metric) tendon routing in the hand? In that situation, I think it made sense to go for models and optimization in the design process.
For locomotion and manipulation controllers, I'm a supporter of iterating more with hardware and less with simulation than what we currently do. With adult-size humanoids, one driver of the runtime cost being so high is that we tend to be afraid to break the robots, and insidiously this situation incents us to spend more time in sim (possibly lamenting about sim2real) and do last-mile adaptions (possibly lamenting about the number of hacks needed) to make controllers work on real robots. To alleviate this, I'm a strong supporter of making smaller, more specialized, brittle-is-ok robots that we are not afraid to break (because they are easier to fix), not afraid to use (because they can fall on us or move abruptly with no harm), and more comfortable to iterate with (because they don't need safety cranes).
A follow-up point, which we didn't go into in this presentation, is that with more runtime we also get a chance to collect more data and organize it into some "data store", e.g. to use it later on as replay buffer for offline reinforcement learning. Even if the data thus generated results from simple "teacher" controllers, even work-in-progress buggy ones, there are ways to leverage it and possibly share it more widely than just the immediate team circle (open robot data!).
-
Feel free to post a comment by e-mail using the form below. Your e-mail address will not be disclosed.