# Dynamic Walking over Rough Terrains by Nonlinear Predictive Control of the Floating-base Inverted Pendulum

## Abstract

We present a real-time rough-terrain dynamic walking pattern generator. Our method automatically finds step durations, which is a critical issue over rough terrains where they depend on terrain topology. To achieve this level of generality, we introduce the Floating-base Inverted Pendulum (FIP) model where the center of mass can translate freely and the zero-tilting moment point is allowed to leave the contact surface. We show that this model is equivalent to the linear-inverted pendulum mode with variable center of mass height, aside from the fact that its equations of motion remain linear. Our design then follows three steps: (i) we characterize the FIP contact-stability condition; (ii) we compute feedforward controls by solving a nonlinear optimization over receding-horizon FIP trajectories. Despite running at 30 Hz in a model-predictive fashion, simulations show that the latter is too slow to stabilize dynamic motions. To remedy this, we (iii) linearize FIP feedback control computations into a quadratic program, resulting in a constrained linear-quadratic regulator that runs at 300 Hz. We finally demonstrate our solution in simulations with a model of the HRP-4 humanoid robot, including noise and delays over both state estimation and foot force control.

## Video

## Content

Paper with all technical details | |

Slides with a more mature discussion on forward integration | |

Source code | |

10.1109/IROS.2017.8206385 |

## BibTeX

```
@inproceedings{caron2017iros,
title = {Dynamic Walking over Rough Terrains by Nonlinear Predictive Control of the Floating-base Inverted Pendulum},
author = {Caron, St{\'e}phane and Kheddar, Abderrahmane},
booktitle = {IEEE/RSJ International Conference on Intelligent Robots and Systems},
year = {2017},
month = sep,
url = {https://hal.archives-ouvertes.fr/hal-01481052},
doi = {10.1109/HUMANOIDS.2016.7803329},
}
```

## Discussion

**What are are the values of the friction coefficient and contact dimensions
you used in the elliptic staircase? Can you share the footstep plan so that it
can be tried with other MPC algorithms?**

The friction coefficient is 0.8 while foot sole shapes are 24-cm long and 12-cm wide. Below is the footstep plan as a JSON dictionary. Positions are given in meters with respect to the origin of the world frame, while roll-pitch-yaw angles for the orientation of contact center frames are given in radians.

```
[
{ "pos": [1.6790750226171589, -0.055741083799895508, 1.3800924700714658], "rpy": [0.12239102346850544, 0.18269184403942895, 1.505511337823894]},
{ "pos": [1.3999999999999999, 0.000000000000000000, 1.3999999999999999], "rpy": [-0.2307191595592952, 0.14005023026233748, 1.3671482044619634]},
{ "pos": [1.6277728684738832, 0.41563865154759849, 1.5484423755527137], "rpy": [0.066446343242238623, -0.24305457583989062, 1.788875594837358]},
{ "pos": [1.2286155866465218, 0.67119575404588416, 1.6876553231625218], "rpy": [-0.036712809132233307, -0.12345677462093492, 1.915778979941732]},
{ "pos": [1.2292372997080192, 1.1451531168392015, 1.8089832560140005], "rpy": [-0.042587683531614295, -0.24328969513029872, 2.1450327192064917]},
{ "pos": [0.75642322821539576, 1.1780593787310549, 1.9048825908847378], "rpy": [0.18468437297451706, 0.054517851723859902, 2.7247927362357194]},
{ "pos": [0.52974156882405132, 1.5942941605173848, 1.9693907716133516], "rpy": [0.16325566520966647, -0.11415833313084929, 2.739034547242118]},
{ "pos": [0.099032082334784055, 1.3964929812456761, 1.9984969919624325], "rpy": [-0.10872932003557928, -0.18084569868500741, -3.105028843435464]},
{ "pos": [-0.2994533734911467, 1.6530963907482137, 1.990391568124362], "rpy": [-0.013731696227680218, 0.028294240436180281, 3.0135841134247174]},
{ "pos": [-0.58260557116599943, 1.2730163975559541, 1.9455784560954088], "rpy": [0.22057333002838922, -0.2094046622586018, -2.503755238261681]},
{ "pos": [-1.0553316861742015, 1.3071629707717076, 1.8668439181327527], "rpy": [-0.17153278734092464, -0.027926256721656838, -2.8563359588159409]},
{ "pos": [-1.1216010617657073, 0.83786100174553912, 1.7590832864623738], "rpy": [-0.16265342064064445, 0.0073990258466376203, -2.0159402113704354]},
{ "pos": [-1.5528279961025386, 0.64119046664791723, 1.6289965952313989], "rpy": [0.21184053369618741, 0.16798927613661602, -2.2125603339992659]},
{ "pos": [-1.3859894952406235, 0.19756801128381407, 1.4846720048359203], "rpy": [0.16048195519977812, 0.21719408029568646, -1.5649830435325576]},
{ "pos": [-1.6701378558153177, -0.18176782601058195, 1.3350829192819349], "rpy": [-0.01920744890835065, -0.073655097140418041, -1.9080927676601263]},
{ "pos": [-1.3110393622071148, -0.49109651876546767, 1.189530063386228], "rpy": [0.24238826649911999, -0.1744708637280887, -1.3231829156635888]},
{ "pos": [-1.3785397203304621, -0.9602230154871374, 1.0570632087545937], "rpy": [0.099564772223722883, 0.073851368995574443, -1.3506207082990742]},
{ "pos": [-0.91510106920905665, -1.0595234934310993, 0.94591850281524303], "rpy": [0.15092426769712289, 0.0060561552918781542, -0.92305779100058349]},
{ "pos": [-0.74942698305517197, -1.5035821218240202, 0.86300638506284988], "rpy": [-0.23292011949133065, 0.033075653590972032, -0.88755220043368799]},
{ "pos": [-0.29511411920309155, -1.3685421647311358, 0.81348192940094177], "rpy": [-0.12938348938745045, -0.23325713643335089, -0.1344267623518916]},
{ "pos": [0.063171616851800602, -1.6788118854786349, 0.80042432661477314], "rpy": [0.17721401716767826, -0.15012310357885592, -0.05886273650692278]},
{ "pos": [0.39712705964851669, -1.3424939845283939, 0.82464543520211686], "rpy": [-0.21227675597448048, 0.068017193294483413, 0.45303261574222442]},
{ "pos": [0.86030360176629239, -1.4430099489566746, 0.88463930394404477], "rpy": [-0.10423923086549804, -0.012152424300626522, 0.12462320512620527]},
{ "pos": [0.99213768400776392, -0.98775645579854854, 0.97667580465776482], "rpy": [0.22648408250504215, -0.22945202428709771, 0.96331275849737019]},
{ "pos": [1.446803260831355, -0.85390885019875407, 1.0950325535004448], "rpy": [0.16970108320577498, 0.23062004119559906, 0.58312268507903109]},
{ "pos": [1.3442384013105122, -0.39118169747849629, 1.2323507010806445], "rpy": [0.23165496787145182, -0.19394147396643366, 1.059839358262237]}
]
```

**What is the difference between the ZMP in this paper and the extended
Centroidal Moment Pivot (eCMP)?**

The eCMP is a characteristic point used to define the

centroidal axisof the contact wrench,i.e.the non-central axis where points \(P\) have the same moment as the center of mass (CoM) \(G\): \(\bftau^{c}_P = \bftau^c_G\). This axis always goes through the CoM. By contrast, the ZMP is used to define another non-central axis of the same wrench, namely, the set of points where the horizontal coordinates of the moment are zero: \(\bftau^c_P \times \bfn = \bfzero\). This axis does not always go through the CoM.In general, the angular momentum at the center of mass can vary, so that the two axes will not coincide and the eCMP and ZMP will be two different points. However, in this work, we are assuming conservation of the angular momentum at the CoM, meaning its rate of change is zero, so that by Euler's equation we have \(\bftau^{c}_G = \bfzero\). Then, the CoM is both on the ZMP axis (horizontal coordinates of \(\bftau^c_G\) are zero) and on the centroidal axis (by definition) of the contact wrench. The two axes coincide and the eCMP and ZMP define the same point (provided we use the same constant \(\omega\) in their respective formulas).

**Then what is the difference between the CMP and eCMP?**

Thecentroidal moment pivotwas originally defined by Popovic, Goswami and Herr (2005) at the intersection between the central axis of the contact wrench and the ground contact surface. This made sense at the time, since at this stage of the research the ZMP was also considered as a point on the ground (rather than a non-central axis of the contact wrench) and most works focused on walking over horizontal surfaces (2D point-mass dynamics). When considering the full 3D point-mass dynamics, it turned out to be easier to characterize the centroidal axis by a point \(\bfp_Z = \bfp_G - \bff^c / \omega^2\) with a constant value for \(\omega\), rather than computing the intersection of this axis with the ground (which would yield a time-varying value \(\omega(t)\)). This is the rationale behind the eCMP introduced by Englsberger et al. (2013), which matches the ZMP we use in this work.

**Why are we interested so much in the centroidal axis of the contact wrench?**

We are fond of this axis because of the Newton-Euler equations that govern the overall physics of our system. In short: to go somewhere we accelerate the center of mass, this acceleration corresponds to a ZMP, this ZMP is decomposed into individual wrenches at each contact bywrench distribution, individual contact wrenches are converted to joint torques and accelerations bywhole-body control, and we finally convert these into voltage/current for all motors. You can dig this page and pointers therein for details. See also this open source walking controller and its documentation.