Tekkotsu XWalk Introduction
What is XWalk
XWalk is a motion trajectory generator in Tekkotsu. Once the configuration of a robot is set in the .kin file, XWalk will be able to generate a walking trajectory for the robot, sending position command to the servos in the robot. Currently, XWalk can successfully generate trajectory to multi-ped robots, such as Chiara and Aibo. One goal in our project is to make it work on humanoid robot.
How to run XWalk
1)Running XWalk with a Robot simulation
- A. Create a robot simulation and put related files into appropriate directories(More details: http://www.tekkotsu.org/mirage.html)
cd Tekkotsu/tools/mirage ./mirage
Afterward, a window should appear, displaying the Mirage 3D environment.
- C. connecting Tekkotsu
cd Tekkotsu/project ./tekkotsu-TARGET –c mirage.plist (for example, if we use the simulation of Gort, we type : ./tekkotsu-GORT –c mirage.plist)
- D.turning on ControllerGUI
cd Tekkotsu/tools/bin ./ControllerGUI localhost
- E.Root Control -> TekkotsuMon -> Walk Controller
- Actually, not only the Walk Controller will call XWalk, many other motions in the list, including Chase Ball call XWalk, too.
2)Running XWalk with a real Robot
- Hardware and setting preparation:
- You will need a serial-to-RS485, like USB2Dynamixel to connect the real robot to the computer.
- You will need to change the RobotInfo header file in the Tekkotsu to make the system know what to connect
- You have to give all the servos numerical IDs. But always keep in mind that, since the Dynamixel servos start at '1', and Tekkotsu offset start at 0, it is a +1 mapping.
- A.Open a terminal windown
(Usually we need to run ControllerGUI whenenver we want to use XWalk, with ControllerGUI, we will be able to control the robot easily.)
Looking Into The Code
- 1)Where is the core code of XWalk?
under this directory, there are two files: XWalkMC.cc and XWalkMC.h
- 2) Important Parameters and functions and how to use them
- A. offsetX(0): Bias the position of the body relative to the ground (in millimeters), so increasing this parameter moves the robot forward, parallel to the ground.
- B. offsetY(0): Bias the position of the body relative to the ground (in millimeters), so increasing this parameter moves the robot left, parallel to the ground.
- C. offsetA(0):Bias the orientation of the body relative to the ground (in radians), so increasing this parameter turns the robot counter-clockwise.
- D. resetOnStop(true): Causes the feet to redistribute to their central positions when motion stops.
- E. frictionCoef(0): Coefficient of friction with the ground (aka µ), limits the amount of non-normal force which can be applied.(Not finished. Cannot be used yet)
- F. strideLenX(100): The size of forward (x-axis) step (mm) to take with each leg (all legs have the same period and travel same speed, so must have the same length of stride).
- G. strideLenY(60): The size of sideways (y-axis) step (mm) to take with each leg (all legs have the same period and travel same speed, so must have the same length of stride)
- H. adaptiveLegOrder(true): If true, re-orders the leg flights based on direction of motion
- I. rotateBodyMotion(true): If true, rotate the sway and surge motions to match direction of motion
- J. transitionDuration(1500): How much time to use getting into initial position, or when parameters change (milliseconds)
- K. bounce():Movement up and down while walking
- L. sway():Movement left and right while walking, balancing the center of mass
- M. surge():Movement forward and backward while walking
- N. legParams(NumLegs,false): an array of parameters that control the leg motion
- O. nonLegJoints(): By default, there is not entry for the nonLegjoints. However, if there are some other nonlegjoints, like arms, we should add an array of parameters that control the non-leg joint motions.
- P. Two copies of XWalk parameters: XWalkMC has two copies of each parameter. The reason for this is in XWalk editor in the ControllerGUI or anything else that modifies XWalk settings, they will modify the inherited copies. When a setting is modified, it starts a transition, and gradually updates the copy in ‘p’. This allows the robot to transition from one posture to another smoothly. If you were directly editing a single parameter, it would immediately ‘snap’ to the updated position instead of transitioning smoothly over time. The two copies are just to separate the ‘current’ value in ‘p’from the ‘target’ value from the inherited class.
- Q. About the ‘updateOutputs’: Actual code can be found in the XWalkMC.cc file. This function is common to all motion commands in Tekkotsu. The motionManager will call this function at high frequency each motion command is supposed to then figure out where it wants to put the joints. And then it calls motion manager’s setOutput functions to assign these values. So, in this way it controls the parameters.
- R. Initial Position: If your robot uses Dynamixel , generally you won’t have such problems in recognizing the initial position of the servos.
- S. updateOutputInitial: if xwalk is not already standing, it will move the feet up above the belly, then over their ‘neutral’ position, and then lower to standing height. Needed to be changed because humanoid robots have different kind of initial position. (If you want to make the humanoid robot stand by itself, it will have to call another function to figure out which side the humanoid robot is sitting or lying on. If you can suspend the robot until it is initialized and put the robot manually on the floor, you can remove the call to updateOutputsInitial and only use updateOutputsWalking, or you can override the initialPlacement flag ‘false’ to skip this.)
- T. setTargetDisplacement(float xdisp, float ydisp, float adisp, float time):
This function needs the displacement in the x, y, direction and also an angular discplacement. The robot will cover the discplacement in the given time
- U. setTargetVelocity(xdisp/maxTime, ydisp/maxTime, adisp/maxTime, maxTime):
This function directly calculate the target velocity
How to Implementing XWalk on Humanoid Robots
1.Creating the configuration of a robot:
In Tekkotsu, the .kin file define the configuration of the robot: This is an XML-based format using the Property List (plist) layout. In the .kin file, you will be able to set the following features of the robot:
- 1) Baseframe
- 2) Camera
- 3) Servo configuration
- 4) Material
- 5) Collisionmodel and scale
- Understanding the format of the .kin file:
- Each joint is defined by a <dict> element with the keys listed below.
- A branch in the chain is denoted by an <array> containing the joints of the sub-chain.
- JointType: Indicates the type of motion produced by the joint(There are only two choice: revolute | prismatic)
- Modified Denavit-Hartenberg parameters: (here in order of application)
- θ: Rotation about the previous joint's z axis (theta, U+03B8)
- d: Displacement along the previous joint's z axis
- α: Rotation about the current joint's x axis (alpha, U+03B1)
- r: Displacement along the current joint's x axis
- In other words, θ and d align the previous joint's x axis with this joint's x axis, and then a displacement of r (radius of rotation) along this x defines the current joint's origin. α then defines the current joint's z axis (the axis of actuation).
- qOffset: An additional parameter which shifts the final reference frame to the physical joint's 0 position. This is a rotation about the joint's z axis for revolute joints, or transation along z for prismatic.
- Min: The minimum acceptable joint value for inverse kinematics (with Max specify the range of rotation)
- Max: The maximum acceptable joint value for inverse kinematics(with Min specify the range of rotation)
- Inverse kinematics ignores this joint if Min==Max (immobile).
- Model: for 3D graphics, the name of the OGRE mesh file to render for the link following the joint. (drop the ".mesh" suffix)
- Material: for 3D graphics, the name of the material to apply to the model, or blank to use the model's defaults
- All distances are in millimeters. Angles are radians, unless a 'unit' attribute is specified, or a 'Â°' is suffixed. You can also specify radians as multiples of Pi.
- We should also mind the order and the names of the joints should match that in other files.
- Below is some sample code from a .kin file:
<key>Name</key> <string>LArm </string> </dict> <dict> <key>JointType</key> <string>revolute</string> (There are only two choice: revolute | prismatic) <key>Î¸</key> <real>0</real> (θ: Rotation about the previous joint's z axis) <key>d</key> <real>0</real> (d: Displacement along the previous joint's z axis) <key>Î±</key> <real>0</real> (α: Rotation about the current joint's x axis (alpha, U+03B1)) <key>r</key> <real>59.75</real> (Displacement along the current joint's x axis) <key>qOffset</key> <real>0</real> <key>Min</key> <real>-90Â°</real> <key>Max</key> <real>90Â°</real> <key>Mass</key> <real>0</real> <key>CenterOfMass</key><array> <real>0</real> <real>0</real> <real>0</real> (Hasn't implemented mass here) </array> <key>Model</key> <string>KHR2/KHR2LeftForearm</string> (directory/modelname)
- Some notes for the collision model.
<key>CollisionModel</key>:It applies to the mesh, making the object interaction more like real world. <key>CollisionModelOffset</key>: x,y,z direction, telling the object where to go <key>CollisionModelScale</key> size, the number following it is the multiple of the size in x, y, z direction. (The CollisionModel’s original dimension is 1,1,1) For the graphic model, the scale is also multiple.
- I would recommend building a simulation of the robot when you try to make a .kin file for your robot. With the dhWizard, it is more direct, easy and accurate to create the configuration and visualize it.
- If you are working on humanoid robot and your robot have a similar configuration as our Mini Hubo(as shown in the picture), you can download our simulation(in GoogleSketchup format) and export the mesh.
- The .kin file is connected with the XWalk.cc file with this code:
#if defined(TGT_HAS_LEGS) && !defined(TGT_IS_AIBO)
So, if you want to change the configuration of the robot, please change the target configuration.
2. Modifying the Code
1)Changing the FlightPhase Parameters:
- FlightPhase and endFlightPhase: the percentage of the duration of one step. FlightPhase is the beginning of the phase and the endFlightPhase is the end of the phase.
- endFlightPhase – FlightPhase=flight duration
- For the humanoid robot, the right leg and the left leg should have different values of FlightPhase. Because, if they have the same value, it will do the same movement at the same time. So usually, one leg can be set to 0 and the other one can be set to 0.5, so that the duration of two legs will be even.
2)Fixing the rotation problem: Fixing the rotation problem is one of the most challenging problems when implementing XWalk on humanoid robot. With a multi-legged robot, you rotate by moving the legs about the body. The feet themselves don’t rotate (there aren’t even feet to rotate) but for a humanoid, you have more joints in the leg, in particular the hip joint, so to rotate you change the target orientation of the foot itself. Modification of the code is needed here, because the inverse kinematics is different. The other change is keeping the foot level, which is also an issue of orientation control so really this is the same issue as rotating. Theoretically, one way to solve this is to have the walk first control the position of the ankle, and then separately update the ankle joints themselves to maintain a level foot.
3)Turning off the start-up routine: When XWalk is running in Chiara, if Chiara is not already standing, it will move the feet up above the belly, then over their ‘neutral’ position, and then lower to standing height. However, this needs to be changed because humanoid robots have different kind of initial position. For example, you may want the robot stand up from sitting down, or, you may want the robot to stand up from lying down. This may require sensor which can tell you what kind of condition the robot is currently in.
If you can suspend the robot until it is initialized and put the robot manually on the floor, you can remove the call to updateOutputsInitial and only use updateOutputsWalking, or you can override the initialPlacement flag ‘false’ to skip this.
To do this, please set initialPlacement to false in XWalkMC::start() then it should go straight to walking.