Walking

The current walk is inspired by the rUNSWift walk¹. It is based on three ideas:

• As in all walks, the body swings from left to right and back during walking to shift away the weight from the swing foot, allowing it to be lifted above the ground. In contrast to many other walks, this is achieved without any roll movements in the leg’s joints (unless walking sideways), i. e. the swing foot is just lifted from the ground and set back down again, which is enough to keep the torso in a pendulum-like swinging motion
• As a result, there is a clearly measurable event, when the weight of the robot is transferred from the support foot to the swing foot, which then becomes the new support foot. This event is detected by the pressure sensors under the feet of the robot. At the moment this weight shift is detected, the previous step is finished and the new step begins. This means that a transition between a step and its successor is not based on a model, but on a measurement, which makes the walk quite robust to external disturbances.
• During each step, the body is balanced in the forward direction by the support foot. The approach is very simple but effective: the lowpass-filtered measurements of the pitch gyroscope are scaled by a factor and directly added to the pitch ankle joint of the support foot. As a result, the faster the torso turns forward, the more the support foot presses against this motion.

Smaller other ideas are added by us to further improve the robustness against disturbances. Those are listed in List of Design Decisions

The module corresponding for the walk is located in Modules/MotionControl/WalkingEngine/WalkingEngine.h. It contains lots of parameters, which are used either directly for generating the joint requests, or to generate the desired step size of a walking step. Note that not all parameters are explained, but only those that might need adjustments, depending on the robots hardware state. The parameters can be found in Config/Robots/Default/walkingEngine.cfg, respectively Config/Robots/Default/walkingEngineCommon.cfg. Parameters in walkingEngine.cfg are those, that need adjustments for different robots more often and are therefore separated into an own configuration file for more readability. Those different needs are more location and scenario depended, e.g. we use different parameters for testing and demos than for competitions. Therefore currently all our robots use the same parameters. Also for competitions we use higher walking speeds. The parameters for those are explained below. We highly recommend to only use higher walking speeds for competitions, to reduce the wear and tear of the robots.

Calculation Cycle

For the walking there consists two modes. A normal WalkPhase or a WalkDelayPhase. The WalkDelayPhase first does a short delay and holds the current position, while it stretches out the coming up swing foot. Afterwards the normal WalkPhase starts.

The WalkPhase itself consist of four parts. The original walk generating from the rUNSWift walk¹ , the Walk Step Adjustment², the JointSpeedControl (JointSpeedRegulation) and JointPositionCompensation (JointPlayOffsetRegulation)³.

The original walk generating part calculates the original target feet poses. The yaw rotation is modified by the JointSpeedControl. As this has an influence on the correct positioning for the feet in the translation space, those targets are adjusted. The Walk Step Adjustment corrects the feet poses in the pitch direction, to prevent walking in the opposite direction of a possible fall. The JointSpeedControl ensures that the support foot does not bring the robot in an even more unstable state, resulting from stuck joint positions, by reducing the maximum speed with which the joint positions can change. The JointPositionCompensation does a similar adjustment, but has the goal to actually compensate the errors in the joint positions and prevent those moving into the already existing joint play.

Parameters

The most important parameters in walkingEngineCommon.cfg are as follows:

• stepSizeParameters.noTranslationYFromRotationFastInner and stepSizeParameters.noTranslationYFromRotationFastOuter: The reduction factor for the sideways translation based on the requested rotation. For worn out robots both might need to be reduced if they fall often when walking around the ball. Currently other parameters help us to prevent the need of adjustment for these parameters.
• stepSizeParameters.minXForwardTranslationFast: When walking near the ball, the minimal allowed forward step size is equal to this value.
• stepSizeParameters.minXBackwardTranslationFast: When walking near the ball, the minimal allowed backward step size is equal to this value.
• stepSizeParameters.minXBackwardTranslationFastRange: When walking near the ball, allow bigger backwards steps (without needed acceleration). The size is scaled down for worn out robots. Otherwise they will fall more often when walking around the ball.
• useFootSupportSwitchPrediction: The representation FootSupport can predict a support foot switch. With this flag you can decide if you want to use it. The prediction is not used, if the robot is walking backwards, because we noticed that worn out robots will then fall less often.
• blockStoppingWithStepAdjustment: If set true, the Walk Step Adjustment will try to not walk into the ball as a balancing step.
• walkStepAdjustmentParams.desiredFootArea: The thresholds for the step adjustment. Defines the percent area in the feet in which the COM should be.
• walkStepAdjustmentParams.maxVelX: Defines the max allowed translation speed for the step adjustment.
• balanceParameters: The gyro balancing parameters.
• soleRotationParameter: The parameters for the swing foot leveling and back catch steps.
• speedRegulatorParams: The parameters for the joint speed control.
• walkDelayParameters: The parameters for the walk delay phase.
• walkSpeedParamsWalkStep: The very maximum a walk step is allowed to do. This is not for regular walk, but to clip the Walk Step Adjustment.
• sideStabilizeParameters: The parameters for the side hip shift to stabilize side walking.

Parameters of interest located in the file walkingEngine.cfg are as follows:

• maxSpeed and minSpeed: The maximum and minimum walking speed allowed. Based on the value from the Representation JointPlay the walking will walk slower for worn out robots.
• maxSpeedBackwards and minSpeedBackwards: The maximum and minimum backwards walking speed. Based on the value from the Representation JointPlay the walking will walk slower for worn out robots.
• jointPlayOffsetParameters: The parameters for the joint play regulation.
• walkSpeedParams: The very maximum a walk step is allowed to do. This is not for regular walking, but for e.g. in walk kicks and intercepting balls.

It must be noted, that currently changes to maxSpeed must be done in the configuration file and not in SimRobot over a view or the console. This parameter is loaded and converted when the B-Human process is started, so changes afterward will make no difference. A forced reload can be done with the following command:

dr module:WalkingEngine:init:parameters

Normally, we use the given maxSpeed and minSpeed values. Only at competitions like the GORE or RoboCup we set the following values:

maxSpeed = { rotation = 120deg; translation = { x = 270; y = 230; }; }
minSpeed = { rotation = 100deg; translation = { x = 250; y = 230; }; }

Otherwise the following values are used:

maxSpeed = { rotation = 120deg; translation = { x = 250; y = 200; }; }
minSpeed = { rotation = 100deg; translation = { x = 220; y = 180; }; }

Higher walking speeds are possible too, like 300 sideways ( y = 300 ) or 300 forwards ( x = 300 ). We plan on using those large side walking steps for intercepting balls but not for the regular walk. The walking steps are stable but do not look healthy for the robot. For the forward walking the higher walking speeds result in the robots being tilted more backwards, which in turn unintentionally rotate the robot around the yaw-axis on the field. As a result the robots need to correct their walking path and are walking slower on average. This is most likely a cause of the joint speed control, which balances too extreme at those higher walking speeds.

Note

We highly recommend to only use the higher walking speeds at competitions. Under those conditions, the robots will always first walk slower for the kick off and can actually measure their joint play. Under lab conditions the robots will always start and walk directly to the ball, which increases the risk of falling for worn out robots. Also we are currently analyzing if the higher walking speeds wear the gears faster. At least in edges cases, when the robots postpone a fall for a few walking steps, which happens at higher walking speeds more often, we currently assume a faster wear.

If you are further interested how we calculate the current step, you can find the calculation in the file WalkingEngine.cpp in the implementation of the method getTranslationPolygon. Further calculations like the walk direction are located in the generator modules WalkToPoseEngine, WalkToBallEngine, WalkToballAndKickEngine and DribbleEngine.

You can also use the following command, to see some plot views. They show the requested and measured translations for the feet, balancing values and the adjustment value of the walk step adjustment. Also the 3D drawing from the walk step adjustment are activated. Additionally some requests for the MotionRequest are shown in the console to easily let the robot walk in one direction.

call Calibrators/Walk

List of Design Decisions

For the walking lots of design decisions where made. Each improves the walking a tiny bit, but together result in a very stable and robust walk. A demonstration is uploaded on our youtube channel ⁴.

Foot Support

At the start of each control cycle while walking, e.g. whenever new sensor data is received, the FSR sensor data is processed in our module FsrDataProvider. Here we calibrate the 8 pressure sensors based on their individual highest and lowest measured pressure, updated once every 10 seconds while walking. The module FootSupportProvider takes those values, weights them similar to rUNSWift, e.g. giving the outer sensors more weight than the inner ones. Additionally we only accept support foot switches if the new support foot has a minimal measured pressure. This helps on edge cases like when robots walk on their heels to prevent rapidly changing the swing and support foot.

Wrong Support Foot Handling

After about 20-40 % of the walk step (depending on the corresponding code line) the Walk Step Adjustment will only hold the current swing foot position in the x-translation (and apply half of the correction on the support foot), if the swing sole measures pressure. Also all interpolations (expcept for the height) are frozen if the swing foot measured pressure.

This results in an extremly robust walk under external disturbances, like bumping into other robots.

Also, if the swing foot is detected as the support foot for a longer period of time, an ealier support foot switch will be executed than normaly allowed.

Walk Height Duration Increase

The original rUNSWift walk increases the step duration for larger side steps, e.g. from 250 ms to something like 320 ms. As we do not want longer step durations, we keep the 250 ms when side walking. Instead we interpolate the swing foot height slower back to 0, e.g. the side translation is done with the 250 ms, but the height interpolation with the 320 ms. This prevents the swing foot to collide prematurely with the ground.

This is also done for our InWalkKicks. Here the swing foot is often requested to move so fast forward that is would otherwise collide with the ground before touching the ball.

Side Walking Hip Shift

As our walk is allowed to do large diagonal walking steps, we have a big balancing problem: the leftover momentum when closing the feet together after a larger side step pushes the robot in the original side walking direction, even if it just walking straight afterwards. As a result the robot will often fall sidewards or diagonally.

To counteract the problem, we do a sidewards hip shift. After a side step when the feet move close together again, we shift the hip sideways by up to 2 cm, based on the size of the previous and current side step. This trick improves the side walk by a large margin and allows us to walk diagonal with large walking steps like 270 mm/s forward and 230 mm/s sideways within one step, which results in a diagonal walking speed of up to 350 mm/s. Larger side steps like 300 mm/s are possible too. Those are stable but look unhealthy for the robot, whereby we only used it in the dynamic ball handling challenge 2023.

Slow Down Based On Torso Tilt

Similar to HTWK Robots we reduce the interpolation speed of the forward and rotational components when the robot is tilted backwards. This improves the walk at higher walking speeds and gives the robot (and the balancing approaches) more time to react to disturbances.

Special Knee And Hip Gyro Balancing

If the robot was tilted too much backward or forward and our Walk Step Adjustment went active, the gyro values will be used for the knee and hip pitch afterwards to reduce the follow up swinging of the torso. To prevent overbalancing, the resulting balancing value is clipped to 2 degrees and is only conditionally active. If the robot was tilted too much backward, the CoM must first be a specific amount forward again, before this special balancing starts. The same applies for forward tilts.

For new robots, this special balancing is not needed for those situations, but also does no harm. But when walking it can sometimes occure, especially after side or diagonal steps, that the robot has some leftover momentum and will have a significant longer step duration than planned. In those situations the joints of the support foot will at some point overreact and tilt the robot more forward or backward, based on the swinging motion of the torso. We also use this special balancing when the current step takes more time than the planned step duration to reduce this effect.

Walk Delay Phase

When colliding with other robots, a huge problem is that after a support foot switch the new swing foot will contract in its height. As the robot is still pushed by the other robot, the now swing foot is actually still the support foot. By reducing the height the robot has no support and will just fall in the direction of the swing foot. After the swing foot reaches its max contraction the robot will stop falling, but the damage is already done. The build up momentum is enough to let the robot fall sideways and no balancing technique can prevent that from happening.

Therefore, to prevent this effect from occuring in the first place, we start a so called WalkDelayPhase, if the center of mass (CoM) is to much sideways in the coming up swing foot. For example if the left foot will be the swing foot and the CoM position is more left than normal, the special motion phase will start.

The WalkDelayPhase will expand the new swing foot in its height to push it away from the ground. This is done only for a very short moment, like 36 ms. Afterwards the normal WalkPhase can start. This small push is enough to prevent the robot from falling from the push of the other robot, as the swing foot can finish its walk step and reach its default height again before it touches the ground again.

Joint Position Resets

A huge problem with the NAO robots is that all the motion control is done by sending requests of joint positions. On all robots, no matter whether new or worn-out (but worse for worn-out ones), the requested positions and measured positions will differ. While a walking step is executed this is not a huge problem and only costs some precision. But once a support foot switch occures these differences, when too big, can destabilize the robot by a lot. To work with this problem, we do several position resets at the moment a support foot switch occures.

• We use either the pitch torso rotation or the leftover error of the Walk Step Adjustment to interpolate the hip pitches. For example if the robot is tilted too much forward, most often the hip pitch of the previous support foot (and now swing foot) will have a large position error. Without a reset the swing foot would automatically move backward and then forward, as our request first needs to interpolate to the target position and as the error is large, the swing sole would not move forward (as expected in such case). We reset the hip pitch request position by interpolating between the last request and the measured position, determined by either the torso rotation or the Walk Step Adjustment leftover error. Afterwards we use our forward kinematics to determine the correct starting variables for the WalkingEngine, which result in this modified joint request.
• We do the same for the hip rolls under specific conditions. If the feet shall move together (e.g. after a side step), both hip rolls are resetted by interpolating between the last request and the measured positions. But this is clipped in a way, that the feet can not move further out. Same applies when the feet shall move outwards (e.g. a planned side step starts), but this time clipped in a away, that the feet can not move further in by the reset. This results in less lag at a support foot switch and lets the swing and support foot move faster in the side direction. The effect of this reset is shown in the video below on a very worn-out robot. The walk quality improves by a large margin.

Walk Start

For the very first walk step after standing, the maximum height for the swing foot is halved. Until 2019 we noticed that if the robots use the full height interpolation for the first step, the durations of the following steps will be much longer and the robots are walking less stable. With the reduced height this effect does not occure.

As an exception to this are side steps. Based on the executed side step size, for the first walk step the maximum height is interpolated to the normal height, the bigger the side step is.

Automatic Calibration Of The Height Interpolation Duration

For very worn-out robots a huge problem is that the step durations will be often too short. This is because the swing foot has so much joint play, that it can not execute the height correctly and also has some rotational error, which lets the tip of the toe collide prematurely with the ground. An easy trick to work with this problem is to measure and filter the duration of the previous walking steps. In case they were too short the interpolation duration of the swing height is increased, so it reduces the height slower back to 0.

As a side effect the robot will now also walk more unstable in general, as the feet can now move further apart, because they will no longer collide with the ground prematurely. Without a good balancing technique other problems occure. Our Joint Speed Control (TODO ref) does the much needed balancing to keep the robot upright.

Note

We do not recommend to use this trick, unless good working balancing approaches are used too (like the Walk Step Adjustment with the Joint Speed Control). Otherwise the robot will fall over more often at higher walking speeds. Without the robot will automatically walk slower and fall less often. This was at least the state for our 2021 and 2022 walk.

Back catch steps

Under specific conditions the robots will execute a back catching step. Once activated the correction values, which are normally for the swing sole leveling, are used to rotate the swing sole requested 3D pose around the knee joint. This causes the swing sole to rapidly move backwards with a large height above the ground to reduce the risk of a fall. This version was tested as a prototyp back in 2022 and is now active in the current version of the walk. For the original prototyp see the video below:

For the prototyp the catch steps went active the moment the Walk Step Adjustment interfered. This was good for the video but not applicable for actually playing soccer. Therefore we use some conditions to ensure that there are as few false positives (e.g. situations in which it was not necessary) as possible. Also from testing we noticed that the robots would often fall sideways afterwards. To counteract this effect the robot is forced to do a small side step too to spread out the feet to better handle the disruption in the swinging of the torso.

• Y-Gyro: The gyro must be negative and measure a minimal value. It is also used as a scaling for the other thresholds
• Walk Step Adjustment delta: The center of mass must be a minimal value outside of the defined safe supporting area
• Torso pitch rotation: The torso must have a minimal rotation

We currently have no physics model of the robot about how it will behave. We assume a modelling of the velocity of the robot would already be enough to change those conditions into a smooth interpolation between the current motion behavior and the final back catch step. But for now it already prevented a handful of falls at the RoboCup 2023 competition.

An example from testing at the RoboCup 2023 is shown below:

Safe usage with humans

To reduce the risk by human intervention, the robot behaves different when picked up or losing ground contact. The stiffness is reduced from 100 to 30 percent, the gyro balancing is reduced to 0 and the Walk Step Adjustment can only hold the feet positions but not move them anymore. Also a new step will only start after a few seconds and force the robot to return to the 0 step, which means 0 rotation and 0 translation.

Note

Once the robot loses the ground contact the fall protection is no longer active. Only the stiffness of the robot is reduced to prevent most harm.

Currently Known Problems

This is a list of currently known problems with the walking:

• The camera shakes a lots
• When walking to the ball, the robots tend to walk closer than commanded.
  • This effect occures mostly on worn-out robots (which B-Human has plenty of).
  • When stopping the robot tilts forward from the previous forward momentum. The joint play takes this opportunity and the Walk Step Adjustment forces the robot to walk a bit more forward.
  • This effect can be reduced by using slower walking speeds near the ball.
  • Video of this problem is shown below.
• Walking with a forward speed of over 300 mm/s is possible even on worn out robots, but the joint speed control regulates too extreme
  • As a result the robots are tilted too much backwards most of the time, which causes the robots to rotate more unintentionally. The walking path needs to be corrected and an overall slower walk results.
• In walk kicks have three precision types. Type justHitTheBall result in most falls when kicking the ball.
  • After a side walk step those kicks can hit the ball as intended because of our side hip shift. This side shift of the hip needs to be remained to improve those falls.

---

1. Bernhard Hengst. - rUNSWift Walk2014 report. Technical report, School of Computer Science & Engineering University of New South Wales, Sydney 2052, Australia, 2014. ↩↩

2. Philip Reichenberg, Thomas Röfer - Step Adjustment for a Robust Humanoid Walk. In RoboCup 2021: Robot World Cup XXIV, volume 13132 of Lecture Notes in Artificial Intelligence, pages 28-39, Springer, 2022 Best Paper Award Finalist. ↩

3. Philip Reichenberg, Thomas Röfer - Dynamic Joint Control For A Humanoid Walk. RoboCup 2023: Robot World Cup XXVI, Lecture Notes in Artificial Intelligence, Springer, 2024, to appear. ↩

4. Robust Walk Demonstration: https://www.youtube.com/watch?v=NKo7-wrIHlU ↩

---

Last update: October 29, 2023