In general, the speed of a joint should be kept well below its physical maximum to avoid burning it out. Another speed consideration is that the arm has inertia, and if it moves too fast it will overshoot, causing it to oscillate backwards and forwards as it settles down to the final destination.

The Lynx6Arm service provided with this chapter limits the speed that joints are allowed to move because the L6 arm is a little fragile. The service does this by calculating the difference between the current joint angle and the desired joint angle, calculating the time required based on a maximum angular speed, and then instructing the SSC-32 controller to make a timed move. If a time parameter is not supplied in a command to the SSC-32, the joint jumps to its destination as fast as possible.

The following code in the Lynx6Arm service handles the SetJointTargetPose request that sets the value for a single joint. You don't need to know how it works in order to use the request, but it is interesting to understand how the service works under the hood.

The function starts by looking up the joint details and converting the joint orientation to an angle in degrees. As with many MRDS operations, there is a lot of converting to and from quaternions and axis angles when you are working with joints. You need to become familiar with these—for example, to make a SetJointTargetPose request!

private IEnumerator<ITask> SetJointPoseHandler(armproxy.SetJointTargetPose update)
{
    // Find out which joint it is from the name
    string name = update.Body.JointName;
    int index = _channelLookup[name];

    // Get the joint
    Joint j = _jointLookup[name];

    // Figure out the desired angle in degrees
    AxisAngle orientation = update.Body.TargetOrientation;
    float orientationAngle = orientation.Angle * Math.Sign(orientation.Axis.X);
    float jointAngle = Conversions.RadiansToDegrees(orientationAngle);

The time parameter is calculated based on the change in the joint angle and the MaxAngularSpeed, which is a value set in the service state. If you want to make the arm move faster, you can change the value of MaxAngularSpeed and recompile the service. (It is not exposed through a configuration file.) However, be aware that making the arm move too fast can make it wobble!

float angleDiff;
    int moveTime;

    // Calculate the difference between the current angle and the
    // requested angle and then figure out the time to take
    angleDiff = Math.Abs(jointAngle—_state.Angles[index]);
    // Calculate the elapsed time for the move
    moveTime = (int)((angleDiff / _state.MaxAngularSpeed) * 1000.0f);
    // If the time is very small, ignore it
    if (moveTime < 20)
        moveTime = −1;

The jointAngle is saved in a cache in the state for use the next time. It must be converted to a servo angle and then to a pulse width to send to the SSC-32. The conversion function called JointAngleToServoAngle allows remapping of the joint angles and is used to make the real arm match the conventions used in the simulated arm. Following the conversion, the information is put into a SSC32ServoMove request and sent to the SSC-32 controller. Note that the joint properties also contain a speed parameter that can act to limit the speed of movement.

// Update the joint angle in the state now
    // NOTE: This will also be updated during a Get request
    // with info from the arm itself
    _state.Angles[index] = jointAngle;

    int servoAngle = JointAngleToServoAngle(index,

(int)(orientationAngle * 180 / Math.PI));

int pulseWidth = AngleToPulseWidth(servoAngle);

    ssc32.SSC32ServoMove moveCommand = new ssc32.SSC32ServoMove();
    moveCommand.Channels = new int[1] { index };
    moveCommand.PulseWidths = new int[1] { pulseWidth };
    moveCommand.Speeds = new int[1] {(int) physicalmodel.Vector3.Length(
            ProxyConversion.FromProxy(j.State.Angular.DriveTargetVelocity))};
    // Always apply some sort of reasonable time so that the arm does
    // not move suddenly
    moveCommand.Time = moveTime;

    ssc32.SendSSC32Command command = new ssc32.SendSSC32Command(moveCommand);
    _ssc32Port.Post(command);
    yield return Arbiter.Choice(command.ResponsePort,
        delegate(ssc32.SSC32ResponseType response)
        {
            update.ResponsePort.Post(DefaultUpdateResponseType.Instance);
        },
        delegate(Fault fault)
        {
            update.ResponsePort.Post(fault);
        }
    );
}

Notice that the code posts a response back to the caller as soon as the command is sent to the SSC-32. At this stage, the motion will not have completed. There are various options here. In the case of the sample applications in this chapter, the code simply waits for a period of time before issuing a new motion request. Alternatively, the arm service could interrogate the SSC-32 to determine when the motion has completed and only send the response after the command has finished executing. The simulation takes this approach.

There is another architectural issue here. The Lynx6Arm service implements a hard constraint on the speed of arm movements. In the case of the simulation, the limit is applied by the caller specifying the amount of time allowed for the motion to complete. It is up to you whether you want to impose an internal limit and treat the arm as a "black box" or take complete control and suffer the consequences of getting it wrong. However, the Lynx6Arm service tries to protect novice users from themselves.

Ideally, to minimize the stress on the motors and the jerkiness of the motion, each joint should gradually accelerate to some maximum speed, travel at this speed for a while, and then decelerate so that it arrives at its destination. The KUKA documentation defines three different approaches for point-to-point (PTP) motion:

As shown in the preceding code, the Lynx6Arm service does not do any accelerating or decelerating. It does apply a maximum speed, however, and most of the time this works fine. The extra sophistication and overhead of a motion planner are not essential.

Although it might be obvious, it is important to realize that an arm cannot move to every possible position within a hemisphere around its base. There are combinations of joint angles that will violate constraints either on the way that the joints and linkages are interconnected or on the servo motors themselves. In addition, of course, there are combinations of angles that will result in the arm crashing into the ground. In fact, an arm has a fairly limited range over which is it safe to operate.

Another problem is that an arm is a cantilever and there can be large stresses on the joints when the arm picks up a heavy object. The L6 arm has a load limit of only about 85g. It can successfully pick up an AA battery, but it is not a good idea to have it pick up anything much heavier than this.

Lastly, if you have never used an arm before, it might not be apparent to you that moving the EOA in a straight line is a nontrivial task. Joints rotate, so changing the angle of a joint invariably means that you have to change the angle of another joint to compensate and keep the EOA moving in a straight line.

This is referred to as linear motion, and most industrial applications require linear movements. If you have an industrial robotic arm, the controller itself might be able to do the necessary calculations on-the-fly. In that case, you are off the hook, but if you have a hobby robot arm like the L6, then you need to interpolate a series of points along the motion path and execute them in sequence.

Luckily, if you are only moving a small distance, such as approaching an object to pick it up, the motion of the arm is approximately linear provided that all of the joints move simultaneously in a synchronous PTP fashion. The Lynx6Arm service does not implement linear motions, but as you will see from the sample applications this is not a significant problem.

The KUKA tutorials discuss at length the various approaches to motion planning and control for moving robotic arms. The calculations are quite complex, and are not implemented in the Lynx6Arm service.

Forward kinematics can be done using simple geometry if you know the configuration and measurements of the arm linkages. Using the L6 arm as an example, the forward kinematics calculations can be done as explained here.

The physical dimensions of the arm are provided in the following table. All measurements are between joints' centers, except for the last one, which is measured to the tip of the gripper. The values in the table are in inches because these are the units that the manufacturer uses. However, MRDS works in meters so the values need to be converted. (The conversion factor of 1 inch equals 2.54cm is exact because the two systems were aligned a long time ago to allow precise conversions.)

Forget about the wrist rotation (which happens between L4 and L5). It is not really relevant, as most of the time the wrist will be horizontal. The "tip" of the gripper is always taken to be the point midway between the tips of the two fingers, regardless of how far open the gripper is.

First, note that the shoulder, elbow, and wrist joints all rotate in the same plane. This is an important point because it allows simple geometry to be used, rather than 3D matrix algebra.

If you look at the arm side-on, the linkages for a typical pose of the robot might look like the simplified diagram in Figure 15-3. The wrist is rotated in the diagram so you can see the two fingers. The hand consists of the wrist rotation mechanism and the gripper, but for the purposes of the example it is only necessary to know the total length of the hand (L3).

Figure 15.3. Figure 15-3

The height and depth specify the location of the tip of the gripper relative to the center of the base, which is the origin. A right-hand coordinate system is shown in Figure 15-3. It is intended to show the respective axis directions, although the origin should be located at the center of the base. Ignore the coordinate system for now and assume that the robot is in the X-Y plane. Note that rotations are measured counterclockwise around a joint.

As you traverse the arm from the base to the tip, the angles of the joints add up to determine the angle of each link measured with respect to the horizontal. In Figure 15-3, the shoulder is about 110 degrees with respect to the base, the elbow is at −95 degrees with respect to the upper arm, and the wrist is at −30 degrees with respect to the lower arm. (The diagram is not drawn to scale.)

Consider each link as a simple straight line that is the hypotenuse of a right-angled triangle. The contribution of each link to the total depth and height are the horizontal and vertical edges of this triangle and can be calculated based on the angle of the link, α, and its length, L. Figure 15-4 shows the side-on view of a single link, which might be the upper arm, lower arm, or hand.

Figure 15.4. Figure 15-4

For the L6 arm in the position in Figure 15-3, the calculations are shown in the following table:

To determine the angles for each of the links, you need to take into account the way that the servo is fixed to the respective links and translate the servo angles to link angles. For example, when the shoulder servo has a setting of zero degrees, it is standing upright, i.e., the upper arm (L1) is at 90 degrees. A summary of the servo orientations and directions of travel is given in the following table:

The depth and height show the position of the tip relative to the base. The height immediately translates to the Y coordinate in 3D space. However, the base can also rotate, so to obtain the X and Z coordinates you use the depth and the angle of base rotation. The depth corresponds to the radius of rotation measured on the ground (looking down at the arm from above).

To complicate matters, the base servo starts with the arm facing away from the SSC-32 controller board and it moves clockwise for increasing servo angles. If you are sitting beside the robot with the SSC-32 on your right, which is the view that first appears in the simulation, the X coordinate is always negative. Unlike the simulation, the real L6 cannot rotate by 180 degrees in either direction.

Combining all of these calculations results in the (X, Y, Z) position of the tip, given all of the servo angles. The code to do this is in a routine called ForwardKinematics, which is in Lynx6Arm.cs in the folder ProMRDSChapter15LynxmotionLynx6Arm. There is no point in reproducing the code here. If you are interested you can read through it.

For basic operations, these requests are sufficient. In fact, you can control the arm using only SetJointTargetPose if you know all of the relevant joint positions for the trajectory of the arm. If the arm will be performing some repetitive task, you can just record the joint positions using the Motion Recorder service developed for this chapter and then replay them.

The Lynx6Arm service treats the gripper as the last joint in the set, but limits the angle to ±35 degrees because the gripper servo is a very lightweight servo, and it could become overloaded if the gripper mechanism were driven too far. In addition, be very careful when closing the gripper on an object so that you do not try to drive it too far.

There are no timing parameters for SetJointTargetPose so you are restricted to using whatever value is implemented in the service itself. SetJointTargetVelocity can be used to specify the maximum speed for joint motions. Its name might suggest that it starts a joint moving at a specified speed, but this is not the case.

The firmware on the SSC-32 has been designed so that a sequence of joint motion commands can be sent in quick succession and it will execute all of them. However, this is not an ideal approach. Unless the Time parameter is the same for all of the joints in a sequence, they will move to their destinations at different speeds. This is equivalent to Asynchronous PTP in KUKA terminology.

You can use GetEndEffectorPose to obtain the 3D coordinates of the EOA and the tilt angle of the wrist. Note that the wrist tilt angle is not the same as the angle of the wrist servo angle. The wrist tilt is the accumulation of all of the angles for all the joints and specifies how the wrist is tilted with respect to a horizontal line.

When you call GetEndEffectorPose, the Lynx6Arm service calls the SSC-32 service to query the arm. This means that the values returned should be current. This operation is done synchronously. In other words, the SSC-32 service sends a request to the SSC-32 and then waits for a reply. However, it does not guarantee that the arm is physically located at the corresponding location. If the arm's motion is restricted for any reason, the servo settings might not be reached. The SSC-32 is only telling you how it is pulsing the servos, not whether the servos are at the desired positions, which it has no way to know.

The EOA is at the tip of the gripper, but to pick up an object you need to position the gripper so that the object is at the TCP. There is a difference of about an inch (a couple of centimeters). It is a simple matter to change the kinematics code to calculate the TCP rather than the EOA. Open Lynx6Arm.cs, locate the following code, and reduce the value of L3:

// Physical attributes of the arm
float L1 = Conversions.InchesToMeters(4.75f);   // Length of upper arm
float L2 = Conversions.InchesToMeters(4.75f);   // Length of lower arm

// Not required
//float Grip = Conversions.InchesToMeters(3.5f);  // Length of gripper

// NOTE: The gripper is basically in two parts because it contains
// the wrist rotate joint which is NOT at the same place as the
// wrist joint.
// Measurements are:
// Wrist joint to rotate plate = 2.25"
// Rotate place to tip of fingers = 3.5"
// The actual length of the "hand" varies slightly depending on
// whether the gripper is open or closed.
// L3 measures the distance to the tip of the fingers or End Of Arm (EOA).
// A Tool Center Point (TCP) would be shorter than this.
// The rubber fingers are just over 1" long, so to keep the grip action
// happening on the fingers, then L3 needs to be shorter by about 0.5".
float L3 = Conversions.InchesToMeters(5.75f);   // Length of whole hand

float H = Conversions.InchesToMeters(2.5f);     // Height of the base

If you have an older Lynx 6 arm, you will have a yellow base instead of a black one. This base is a different height so you also need to modify the value of H. Note that the base height is measured up to the center of the shoulder servo.

The SetEndEffectorPose request performs the inverse kinematics calculations. You specify both the position and orientation (wrist tilt) of the end effector.

The SSC-32 has a command that sets multiple joints in motion at the same time but with an overall Time parameter, and SetEndEffectorPose uses this command. (Speeds can still be specified individually, and the motion will take the longer of the times specified or the time based on the speed.) This is basically the equivalent of the KUKA Synchronous PTP mode of operation.

One consequence of this is that motions specified using SetEndEffectorPose are usually much smoother than setting all of the joint angles (via multiple calls to SetJointTargetPose).

By now you should be familiar with the Dashboard. It includes a panel for controlling an arm and it will work with the Lynx6Arm service.

To try using the Dashboard, run the following command from a MRDS Command Prompt window (remembering that it has to be on one line):

dsshost -port:50000 -tcpport:50001

-manifest:"ProMRDS/Config/Lynxmotion.Lynx6Arm.manifest.xml"

-manifest:"ProMRDS/Config/Dashboard.manifest.xml"

For your convenience, a batch command file called LynxL6Arm.cmd is also provided.

When the Dashboard starts up, connect to localhost. You should see the lynx6arm in the services list. Make sure that you have enabled the articulated arm display under Tools

Figure 15.6. Figure 15-6

You can select a joint by clicking it. Enter a value for the angle and then click the Set Angle button. The joint will move to the specified angle. When you are first experimenting, use fairly small angles until you know how the arm will behave. You can use both positive and negative angles. If you click the Get Pose button, the current X, Y, Z coordinates of the EOA will display.

Clearly, moving the arm around in this fashion is tedious. The example is simply included here to illustrate that the generic arm contract works. An alternative way to control the arm is using one of the VPL programs in Chapter 12 and an Xbox game controller. The two VPL programs for robotic arms in Chapter 12 use the thumbsticks and buttons in different ways. This is deliberate, and highlights the difference between adjusting servo angles and specifying the position of the end effector. Some people will find one way more intuitive than the other, but in some situations both approaches are useful. Playing with an Xbox controller is a very good way to get a practical understanding of the different approaches to moving an arm.

You will notice some similarities between the Motion Recorder and the GUI for the Lynx arm simulation in Chapter 8. In fact, it can be used with the simulator if you want. To use the simulator, edit the manifest in the ProMRDSConfig directory called MotionRecorder.manifest.xml. At the bottom of the manifest you will see that the simulated arm is commented out (this is highlighted in the following code). Remove the commenting and instead comment out the real arm service, which is just above the simulated one.

<?xml version="1.0" ?>
<Manifest
  xmlns="http://schemas.microsoft.com/xw/2004/10/manifest.html"
  xmlns:dssp="http://schemas.microsoft.com/xw/2004/10/dssp.html"
  >
  <CreateServiceList>
    <ServiceRecordType>
        <dssp:Contract>http://schemas.tempuri.org/2007/11/

motionrecorder.html</dssp:Contract>
    </ServiceRecordType>
<!-- Use the real arm -->
    <ServiceRecordType>
        <dssp:Contract>http://schemas.coroware.com/2007/11/

lynx6arm.html</dssp:Contract>
    </ServiceRecordType>

<!-- Use the simulated arm
    <ServiceRecordType>
        <dssp:Contract>http://schemas.tempuri.org/2007/10/

SimulatedLynxL6Arm.html</dssp:Contract>
    </ServiceRecordType>
-- >
  </CreateServiceList>
</Manifest>

Now when you run the Motion Recorder, the simulator will start. You can play around as much as you like without potentially damaging your Lynx 6 arm.

The following is a brief description of how the Motion Recorder works. The user interface should be fairly intuitive. Three main files make up the application:

The MotionRecorderTypes.cs file should not require any explanation, as it is quite short.

MotionRecorder.cs does all the work of controlling the arm and is explained further in this section. It specifies the Lynx6Arm service as a partner. Notice that it uses the generic arm contract and creates a port called _lynxPort:

[Partner("Lynx6Arm", Contract = arm.Contract.Identifier,
    CreationPolicy = PartnerCreationPolicy.UseExisting, Optional = false)]
private arm.ArticulatedArmOperations _lynxPort =
    new arm.ArticulatedArmOperations();

A lot of the code in MotionRecorderUI.cs is for validating input data, reading and writing files, and so on. This has nothing to do with MRDS, but unfortunately it has to be included.

MotionRecorderUI.cs uses the standard process for a WinForm to communicate with the main service. (If you are unsure about how this works, refer back to Chapter 4. Only a very brief explanation is provided here.) It uses a set of classes that are defined in a similar way to operations for a service, except that it is not a full-service interface. Instead, it posts all of its requests using a single operation class and passes across an object that represents the function to be performed. This helps to reduce the number of operations in the main service's port set so that the limit of 20 operations is not exceeded.

For example, when the Form is first created it sends back a handle to itself to the main service. This lets the main service know that the Form is running so that it can enumerate the joints in the arm. In the Form, the code is as follows:

// Send a message to say that the init is now complete
// This also passes back a handle to the Form
_fromWinformPort.Post(new FromWinformMsg(FromWinformMsg.MsgEnum.Loaded, null,
this));

Back in the main service, the FromWinformMsg handler processes the request and executes the appropriate code based on the command type, which in this case is Loaded:

// Process messages from the UI Form
IEnumerator<ITask> OnWinformMessageHandler(FromWinformMsg msg)
{
    switch (msg.Command)
    {
        case FromWinformMsg.MsgEnum.Loaded:
            // Windows Form is ready to go
            _motionRecorderUI = (MotionRecorderUI)msg.Object;
            SpawnIterator(EnumerateJoints);
            break;

EnumerateJoints issues a Get request to the Lynx6Arm service to get its state. Notice that it does this in a loop because the arm service might not be up and running properly, in which case there will be a Fault. To ensure that it does not loop forever, there is a counter:

IEnumerator<ITask> EnumerateJoints()
{
    int counter = 0;
    arm.ArticulatedArmState armState = null;

    // Get the arm state because it contains the list of joints

// Wait until we get a response from the arm service
    // If it is not ready, then null will be returned
    // However, we don't want to do this forever!
    while (armState == null)
    {
        // Get the arm state which contains a list of all the joints
        yield return Arbiter.Choice(
            _lynxPort.Get(new GetRequestType()),
            delegate(arm.ArticulatedArmState state) { armState = state; },
            delegate(Fault f) { LogError(f); }
        );
        // This is not good error handling!!!
        if (armState == null)
        {
            counter++;
            if (counter > 20)
            {
                Console.WriteLine("***** Could not get arm state. Is the arm

 turned on? *****");
                //throw (new Exception("Could not get arm state!"));
                yield break;
            }

            // Wait a little while before trying again .
            yield return Arbiter.Receive(false, TimeoutPort(500),

delegate(DateTime now) { });

        }
    }

The armState contains a list of the joints. A list of the joint names is created and then the Form is updated using FormInvoke, which executes a delegate in the context of the Form. The Form contains the function ReplaceArticulatedArmJointList, which updates the list of joint names inside the Form so that it can also refer to them by name:

// Create the new list of names
    _jointNames = new string[armState.Joints.Count];
    for (int i = 0; i < armState.Joints.Count; i++)
    {
        _jointNames[i] = armState.Joints[i].State.Name;
    }

    // Now update the names in the Form so that it can do
    // whatever it needs to with them as well
    WinFormsServicePort.FormInvoke(delegate()
    {
        _motionRecorderUI.ReplaceArticulatedArmJointList(_jointNames);
    });

In addition to setting the joint names, the initial joint angles are also set, but the code is not shown here. That completes the startup process.

The Motion Recorder does not automatically record anything. You must click the Record button (near the bottom of the window) to record the current command. You can play around using the slider controls, and as you move them the arm will follow (and the angle values in the textboxes will update). When you are happy with the position of the arm, you can record it. By doing this repeatedly, you can build up a complete sequence of motions to perform a particular task.

The UI contains four basic areas. At the top is the Control Panel, which enables you to execute motion commands. Next are the Arm Pose and Joint Positions panels, which provide values for motions. Finally, there is an area for recording, saving, and replaying commands.

The most important button is the Execute button, which calls the main service to perform either a SetEndEffectorPose if the Use Pose radio button is selected, or a sequence of separate SetJointTargetPose operations (one for each joint) if the Use Joints radio button is selected. These two operations are the crux of the application, so the code for them is discussed here.

As you move the sliders around, the trackbar controls continually fire off requests to the main service to move the corresponding joints. Once the main service has decoded the FromWinformMsg it executes the MoveJoint function using the values passed from the Form:

void MoveJoint(string name, float angle)
{
    arm.SetJointTargetPoseRequest req = new arm.SetJointTargetPoseRequest();
    req.JointName = name;
    AxisAngle aa = new AxisAngle(
        new Vector3(1, 0, 0),
        (float)(Math.PI * ((double)angle / 180)));

    req.TargetOrientation = aa;

    _lynxPort.SetJointTargetPose(req);
}

Notice that the SetJointTargetPoseRequest requires the name of the joint and the target angle, expressed as an AxisAngle. By convention, the axis angles are all with respect to the X axis. In addition, the angle from the Form is in degrees, so it has to be converted to radians.

When Use Joints is selected, the Execute button invokes a different method in the main service called MoveMultipleJoints, but this simply calls MoveJoint for each of the joints because the generic arm contract does not have a request to set multiple joints at the same time. The disadvantage of this approach is that the different joint movements are not coordinated.

Conversely, if Use Pose is selected when the Execute button is pressed, it sends a request to run the MoveToPosition function in the main service. This function sends a SetEndEffectorPose request to the Lynx6Arm service, but first it has to create a quaternion for the pose. This is a somewhat painful process that is not helped by the fact that the proxy versions of the classes don't have the necessary static methods. After several lines of code, the request is finally sent. Then the wrist rotate angle and the gripper are set independently because SetEndEffectorPose does not do these:

public SuccessFailurePort MoveToPosition(
    float mx, // x position
    float my, // y position
    float mz, // z position
    float p, // angle of the grip
    float w, // rotation of the grip
    float grip, // distance the grip is open
    float time) // time to complete the movement
{
    // Create a request
    arm.SetEndEffectorPoseRequest req = new arm.SetEndEffectorPoseRequest();
    Pose rp = new Pose();
    Vector3 v = new Vector3(mx, my, mz);
    rp.Position = v;
    physicalmodel.Quaternion q = new physicalmodel.Quaternion();
    q = physicalmodel.Quaternion.FromAxisAngle(1, 0, 0,

Conversions.DegreesToRadians(p));
    Quaternion qp = new Quaternion(q.X, q.Y, q.Z, q.W);
    rp.Orientation = qp;
    req.EndEffectorPose = rp;
    _lynxPort.SetEndEffectorPose(req);

    // Set the positions of the wrist rotate and the gripper as well
    MoveJoint(_jointNames[(int)lynx.JointNumbers.WristRotate], w);
    MoveJoint(_jointNames[(int)lynx.JointNumbers.Gripper], grip);

    // Now return success
    SuccessFailurePort responsePort = new SuccessFailurePort();
    responsePort.Post(new SuccessResult());
    return responsePort;

}

Note a couple of advantages in using SetEndEffectorPose. You can set precisely where the arm will go by entering values into the Arm Pose panel. You can also specify the tilt angle of the gripper, which is important if you want the robot to pick something up. More importantly, the motion is better coordinated because, as explained earlier, it sends a single command to the SSC-32 to move all the joints.

The disadvantage of using the Arm Pose panel is that it isn't always easy to pick valid values. Moreover, sometimes the results might be a little surprising. If the arm doesn't move, look in the MRDS DOS command window for an error message. It is possible that you selected an invalid pose, which causes the arm service to generate a Fault.

When you click the Get Pose button, the code sends a FromWinformMsg request to the main service containing the command GetPose. In the main service, the FromWinformMsg handler decodes the command and calls GetArmHandler. This handler makes a GetEndEffectorPose request to the Lynx6Arm service and then uses FormInvoke to return the results to the Form, where they appear in the textboxes across the top. The slider controls are also updated to match the current positions of the joints. A Copy button beside the pose values enables you to transfer the pose information to the Arm Pose textboxes.

Alternatively, you can enter values into the textboxes beside the joint sliders. Then when you click Execute (with Use Joints selected), the joint angles will be set.

The Save button provides a quick way to save all the values in the Arm Pose and Joint Position textboxes. You can get them back later using Restore.

The Reset button sets all of the angles to zero, which should be the initial setting when the arm starts up. Park sends the arm to a "parked" position, but it is quite arbitrary. You can change the joint angles for each of these at the top of the main service:

// Joint angles for the Reset and Park commands
float[] _resetAngles = { 0, 0, 0, 0, 0, 0 };
float[] _parkAngles = { 0, 20, −50, 30, 0, 0 };

The remaining buttons across the bottom of the window perform the following functions:

Saved command history files are comma-separated value files. These are plain text and can be edited with Notepad, or loaded into Excel. An example is given in the next section. You might find it quicker to edit a file rather than use the Motion Recorder once you have saved a few key commands. Just be careful not to mess up the format.