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 enable the robot to walk over a certain displacement at a certain speed.
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, lie 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
- B.cd /usr/local/Tekkotsu/tools/mon
- C. enter ./ControllerGUI ip-address
(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
What to do when 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.