Tekkotsu XWalk Introduction

From IPRE Wiki
Revision as of 14:31, 16 December 2010 by Ypan01 (Talk | contribs)

Jump to: navigation, search

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

ControllerGUI: Motion Control

1)Running XWalk with a Robot simulation

    cd Tekkotsu/tools/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

  • 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?
     cd Tekkotsu/Motion/

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 a 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
  • 2. Understanding the format:
  • 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 canalso 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>
               <key>JointType</key> <string>revolute</string>
               <key>θ</key>         <real>0</real>
               <key>d</key>         <real>0</real>
               <key>α</key>         <real>0</real>
               <key>r</key>         <real>59.75</real>
               <key>qOffset</key>   <real>0</real>
               <key>Min</key>       <real>-90°</real>
               <key>Max</key>       <real>90°</real>
               <key>Mass</key>      <real>0</real>
                       <real>0</real>  <real>0</real>  <real>0</real>
               <key>Model</key>     <string>KHR2/KHR2LeftForearm</string>
  • 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.