WalkGenerators¶
In the current motion framework we provide different representations which implement the generation of walk speed requests for the walk policy for specific situations. In this documentation those generators are described.
WalkToBallAndKickGenerator¶
The WalkToBallAndKickGenerator implementes the interface for the behavior to walk to the ball to kick it.
It is implemented by the module WalkToBallAndKickEngine.
Note, that is only determines a reference kick pose to walk to, used by the other path planing generator WalkToBallGenerator and WalkToPoseGenerator.
The kick itself as well as the step planing close to the ball is done by the RL kick policy.
WalkToBallGenerator¶
The WalkToBallGenerator implements the behavior to walk around a ball and is implemented by the module WalkToBallEngine.
This module checks beforehand whether this special handling is needed.
Therefore if the kick pose is not on the other side of the ball and a walking around the ball is not required,
the WalkToPoseGenerator is automatically called to generate the next walk speed request.
When a walking around the ball is necessary the calculate both tangents to the ball, which is modeled as a circle. In case we are already inside the circle some special handling is applied to prevent walking further into the ball. Afterwards the tangent with the shorter distance is used as a walking path.
Afterwards the WalkUtilities are used to optimize between forward, diagonal and side walking to waste as little time as possible.
The resulting speed request is then clipped based on the translation polygon of the WalkingEngine.
Note, that once the robot is close enough to the ball, this request is ignored and the RL kick policy takes over.
WalkToPoseGenerator¶
The WalkToPoseGenerator is our general go-to representation to walk from point A to B.
It is implemented by the module WalkToPoseEngine. Here the obstacle avoidance from the behavior is used to determine the path to avoid a collision.
Note that the orientation to walk past an obstacle is independent of such obstacle.
Otherwise the robot would rotate to follow the path and afterwards rotate once again to align to the original walk target.
This can cost precious time and slow down the robot significantly.
Afterwards the WalkUtilities are used to optimize between forward, diagonal and side walking to waste as little time as possible.
The resulting step target is then clipped based on the translation polygon of the WalkingEngine.
WalkAtSpeedGenerator¶
The WalkAtSpeedGenerator either takes in percentages of speeds for the rotational and translational components or direct speed values.
In both cases a corresponding walk step is calculated based on the limits of the WalkingEngine. It is implemented by the module WalkAtSpeedEngine.
DribbleGenerator¶
The DribbleGenerator is implemented by the module DribbleEngine. It is a depricated module and could be fully replaced by the WalkToBallAndKickGenerator.
This is due to the RL kick policy, which plans walking to and around the ball all by itself.
InterceptBallGenerator¶
The InterceptBallGenerator is implemented by the module InterceptBallProvider.
If the behavior set the flag shouldInterceptBall in the MotionRequest, this module is called to calculate a walking step to intercept a rolling ball.
The walk speed request is optimized to execute large side steps in the direction of the interception point with the path the ball is rolling. As rotational walking steps are sometimes necessary too, the side translation and rotational size are both optimize to prefer large side steps over rotational steps. This is due the constraint, that the walk policy can no execute both perfectly. Therefore the walking reduces the translation sizes if high rotational steps are requested. For the intercepting we swaped this constraint, therefore the rotational step size is reduced for large translational steps.
As a result the robots will always do the largest possible side step in the direction of the interception point with close to no rotational component.
WalkUtilities¶
The WalkUtilities are functions found in Tools/Motion/WalkUtilities.h.
They are currently used by the WalkToBallEngine and the WalkToPoseEngine to optimize the rotation and translation when walking from point A to point B.
Both modules use the same functions to prevent behavior oscillation and to enforce that those different situations, walking to a ball and walking to a pose on the field, are treated the same.
The general idea is that when walking from point A to B the current orientation of the robot should not matter that much. It is important that when the target pose is reached the orientation is so too, but while walking to it, it is allowed to differ. Therefore it should not matter if the robot is walking perfectly straight or slightly diagonal or even sideways,as long as no additional time is wasted. Otherwise, which was the approach in previous years, the robot is forced to perfectly align itself with the walking path. This caused the robot to execute small rotational steps in every walking step, because the walk is not smooth and rotates the robot with every walking step.
For this reason it is faster to just accept that the robot will slowly turn its orientation over time when walking to a position than to force a correction in every step. This of course is at some point only possible if the walking is capable of doing so too.
On the other hand the functions are implemented in such a way that a target of interest, like the ball or the target pose, can be visible with both cameras and are not concealed by the shoulders or lost because of errors in the localization of the odometry.
calcSideWalk¶
Give a target of interest (ToI) the goal of this function is to find a walk orientation, which is later used as the rotation part for the walk step, which lets the robot walk sideways while also keeping the ToI in sight.
This is achieved by defining a static view range maxTargetFocusAngle, which is applied to the current angle to the ToI. For example if the ToI is at coordinate (100,100) then the current angle to the ToI is 45 degrees. With maxTargetFocusAngle = { -50_deg, 50_deg} the final view range would be { -5_deg, 95_deg }.
Afterwards a second angle range is determined, which represents the view range based on the max side step range (e.g. max side step size plus min and max forward translation). It is based on the optimal side walk direction, e.g. the 90 degree direction relative to the walk target direction which is closer to the ToI angle, and the max step size to the side.
Those two ranges are then used to clip the walk direction (rotated to force exact side steps of 90 degrees) to get the largest side steps which also still allow the ToI be inside the view range.
The implementation itself is slightly more complicated to correctly handle angles outside the \(-\pi\) and \(+\pi\) range.
calcDiagonal¶
Similar to calcSideWalk the same approaches are applied. We use the same view range maxTargetFocusAngle. But instead of optimized side walking, we use the translation polygon of the WalkingEngine to get the maximum size of diagonal walking steps. Those allow for the maximum possible forward speed with some additional side speed. The walk direction angle is then clipped into this diagonal angle range and view range.
The implementation itself is once again slightly more complicated to correctly handle angles outside the \(-\pi\) and \(+\pi\) range.