Libbarrett Programming Library

Quick Start Guide

Updated July 29, 2012

Libbarrett Quick Start Guide Modified July 29, 2012 Page 2

Table of Contents
Section 1 The Physical Stuff
1.1 - Understanding your WAM Arm 1.2 Understanding your WAMs Safety System 1.3 Joint Torques, Positions, and Velocities, and Cartesian Values

Section 2 Introduction to WAM Code

2.1 Theory of Operation 2.2 General Terminology 2.3 What is a WAM Object?

Section 3 Programming the WAM

3.1 3.2 3.3 3.4 3.5 Implementation Basic Demo Program Principles of Design A More Complicated Program A Program with Systems

Section 4 Additional Procedures

4.1 4.2 4.3 4.4 How to Build and Run Your Programs WAMDiscover, SSH, and PuTTY Managing WAM Settings Additional Documentation

Libbarrett Quick Start Guide Modified July 29, 2012 Page 3

Section 1 The Physical Stuff

1.1 - Understanding your WAM Arm
Welcome to the world of the WAM Robotic Arm! The WAM is made mainly of aircraftgrade aluminum with a self-contained PC and Safety System in its base. It is a cabledriven arm that eliminates the need for conventional gears. With these cables, each joint moves with significantly less friction than their gear-driven counterparts, making the WAM highly back-drivable, or easy to manipulate. The WAM comes in 4 and 7 Degree-of-Freedom (DOF) models. Pictured below is the 7DOF WAM, with a BarrettHand attached. While both models are nearly identical, the 7DOF includes a 3-DOF wrist module while the 4-DOF arm only has a hollow wrist for connecting purposes. This guide refers to the 4 DOF WAM Model.

The WAM Arm (7-DOF Configuration)

Joint Four (Rotates outer link about its end)

Joint Three (Rotates inner link about its center)

Inner Link Outer Link

Joint Five (Rotates wrist about its center)

Joint Six Joint Two (Rotates inner link about its end) Joint One (Rotates entire arm about the base) (Rotates wrist about its end) Joint Seven (Rotates tool-plate (or hand) about its center)

Libbarrett Quick Start Guide Modified July 29, 2012 Page 4

The WAMs motors are driven by Pucks, Barretts patented motor controllers. Pucks are exceptionally small and they are placed throughout the WAM Arm, rather than stored in a motor controller box outside of the robot. Pucks communicate with the control PC through the CAN Bus (Controller Area Network), and all communication is monitored by the Safety Board. The Safety Board is a large PCB in the base of the WAM that monitors the velocity of the arm, the magnitude of the torque commands being sent to the motors, the communication rate between the control PC and the Pucks, and the status of the buttons on the Pendants (see the next page). The CAN bus is a 2-wire differential serial bus that provides digital communication at 1 Mbps with high noise immunity. The protocol used is proprietary for the WAM (not CANopen). For more information on CAN, visit http://en.wikipedia.org/wiki/CAN_bus. Pucks are the lowest level of control that the programmer needs to understand. They send motor positions to the WAM PC and receive motor torques back from the control PC in a single control loop. The control loop may run at any rate up to 1 kHz, but the default rate is 500 Hz. When you send a command, it is translated into CAN signals and addressed to the appropriate Pucks. The image below shows a Puck and its leads.

The Puck Motor Controller

DC Power Motor Phase Leads

Temperature Sensor & Auto-Tensioning System

CAN Bus

Libbarrett Quick Start Guide Modified July 29, 2012 Page 5

1.2 - Understanding your WAMs Safety System

Although the WAM arm is inherently safer than most robots due to its backdrivable nature, the Safety Board prevents most possible errors that the backdrivability does not prevent. The WAMs safety features include a dedicated Safety Board and two safety Pendants. The WAM has three possible states when power is applied: active, idle, and faulted. The power status and ability to read data from or send commands to the WAM in those states is shown below. State Active Idle Faulte d Power Status On On Off Communication Enabled Yes Yes No Motion Control Enabled Yes No No

The WAM must be activated manually before any commands can be executed. If there is a problem, it will idle or fault automatically. In addition, it can be manually idled or faulted by hitting the emergency stop button. The emergency stop will stop the robot instantly, and must be reset by turning the button a quarter turn clockwise before reactivating the WAM. When power is not being applied to the Pucks, the WAM resistively brakes, meaning that it does not actively exert any force, but instead lightly resists any forces applied to it. This results in the WAM slowly falling until its hits a physical impediment. It also allows the WAM to be easily moved into a resting position by the operator. There are two Pendants that attach to the WAM. The Control and Display pendants both show the state of the WAM and have an emergency stop button, but only the Control pendant can idle or activate the WAM. The diagram below shows the control pendant and describes its functions.

Pushing the idle or activate button at the same time as the shift button changes the WAM to that state, as long as the safety system determines it is safe to do so. The WAM must be idled before it can be activated. These lights show the status of different factors that impact the state of the WAM. If they are all green, the WAM is either active or able to be activated. If one or more are red, the WAM is faulted and will stop. If there is a warning while the WAM is active, it will not stop; however, it should Libbarrett Quick Start Guide Modified be noted that the program may be July 29, 2012 Page 6 approaching the limits of safe operation if that is the case.

The Control Pendant

Libbarrett Quick Start Guide Modified July 29, 2012 Page 7

1.3 Joint Torques, Positions, and Cartesian Positions

When beginning WAM programming, there are three types of input that are good to learn: joint positions, joint torques, and Cartesian positions. All three are translated by software into joint torques, which are fed to the Pucks in the arm. Fundamentally, the arm takes joint torques as an input and outputs joint positions. The Cartesian positions are calculated from the torque and position as opposed to direct feedback. The easiest input to understand is the Cartesian Position. The WAM understands Cartesian positions with the origin located at the intersection of the axis of joints 1, 2, and 3. This method of control allows the user to control exactly where the end of the arm ends up (Point X, Y, Z), but does not guarantee the exact position that the arm will hold. The WAM PC receives a Cartesian position and then calculates the virtual path (spline) needed to be taken in order to get the end of the arm to the destination point. However, while the end of the arm will reach the destination point, the WAM does not have collision detection and Cartesian control should be used carefully, or else WAM damage and torque faults may occur. The diagram below outlines the Cartesian grid. Joint positions and torques tend to give more control over the orientation of the WAM. The WAM gives feedback in the form of positions, and as such, there no perfect conversion between the Cartesian and Joint methods of control. While a Cartesian position is only three dimensional, the WAM has four (or seven) joint dimensions and Cartesian positions do not contain enough information to uniquely describe every possible position of the WAM. In situations where you need such control, it is usually better to avoid Cartesian positions, and opt for a joint-space unit.

Coordinate Axis of the WAM

Z

X Y

Libbarrett Quick Start Guide Modified July 29, 2012 Page 8

Section 2 Introduction to WAM Code

2.1 Theory of Operation
The WAM uses a type of computing called realtime in order to execute commands properly. Realtime computing guarantees that operations occur at a given frequency, which allows for precisely timed code without the operating system delaying the clock and skewing time readings. The WAM operates at a frequency of 500 Hz by default. Each cycle consists of the PC asking for the pucks motor positions, the pucks sending their positions to the PC, the PC calculating a new set of motor torques based on a PID module (explained later) and sending new motor torques to the pucks. It is extremely important that any code does not get in the way of timing or else the robot will read heartbeat fault and notice a lag in communications and shut down. Blocking functions and input/output functions often change the timing of the program and then delay the code (thus erasing the effectiveness of the code) and should be avoided in realtime code. In order to avoid these problems, the WAM control system is written to separate realtime and non-realtime code. Essentially, there are little virtual machines in a computer running a WAM, which are linked together so that they can pass information between one another and to and from the WAM. These machines, called Systems, (explained in section 2.3) contain the majority of the realtime code in a WAM. The systems are called into action by a main() method, directly or indirectly, which handles blocking and most I/O functions, thus leaving the realtime code free to run uninterrupted. For example, to control the WAM, values are put into a separate machine and then sent as packets via Ethernet to the WAM PC to minimize potential timing issues. This PC then receives those packets in a non-realtime process, converts the packets into a spline for the WAM to follow, and drops those commands into the realtime code to be sent to the Pucks over the CAN bus. The only part of that code that happens in realtime is the actual passing of commands to the Pucks from the WAM PC, as all the blocking functions involved with sending and receiving packets cannot be guaranteed to happen in perfect time. Once the spline has been calculated, the WAM PC has a queue of torques to send to the pucks and does not need to wait for a separate torque every cycle. The following flowchart shows the path of information from the user to Realtime the WAM PC and WAM Motors. code is isolated here

Information Flow from User to WAM

Libbarrett Quick Start Guide Modified July 29, 2012 Page 9

The user inputs a position into his or her computer. The computer translates this position into a packet and sends it to the WAM PC.

The WAM PC receives the packet in a blocking function that is not part of the realtime code, calculates the WAMs path, and sends ONLY the spline to the realtime functions. These functions send commands to the WAM to move it to the desired position.

Libbarrett Quick Start Guide Modified July 29, 2012 Page 10

2.2 General Terminology

PID Controllers A PID controller controls the output of a fluid process by gathering error feedback and attempting to minimize that error by controlling the output of the moving object, in the WAMs case, motor torque. Specifically, they operate proportionally to the error, the integral of the error, and derivative of the error. These proportions must be tuned for whatever system a controller is present in. For more information, visit http://en.wikipedia.org/wiki/PID_Controller.

P
Setpoin t
Error e(t)

I D
Feedback

Proce ss Outpu t

First Order Filter This is a filter that attenuates the high-frequency components of a signal going through it, such that it is smoothed out, which prevents sudden changes. The following graphs demonstrate the difference between a filtered signal and unfiltered signal.

Signa l

Tim Unfiltered signal e

Si g n al

Tim Filtered signal e

Trapezoidal Velocity Profile This is a function of velocity over time, where there is a period of constant acceleration, a period of constant velocity, then a period of constant deceleration, forming a trapezoid. This is commonly used by the WAM to smoothly move its joints to a given position. An example of such a relationship, in graph form, is below.

Max Velocity

Velocit y

Acc eler atio n

Time Libbarrett Quick Start Guide Modified July 29, 2012 Page 11

2.3 What is Libbarrett and a WAM Object?

Libbarrett is a library of C++ code designed for the WAM arm that allows users to control and operate the WAM. It contains several classes, including the WAM Object, that can help you write your own applications. See the chart below and the flow chart on the next page for key function definitions and the librarys structure. System Libbarrett is composed mostly of these. Systems are like small virtual machines which process information from their inputs, and pass it through to their outputs. If their outputs are not connected to anything, the information is simply lost. Outputs can be hooked up to multiple inputs, but an input may only accept information from one output. This is how information moves within the WAM code through virtual hoses which are managed with the connect() and disconnect() functions. Systems are designed to work in RealTime, and fulfill a set of parameters which allow them to be called by an ExecutionManager. ExecutionManager This is the object which supervises all realtime operations. It has a list of all the Systems in the program, and at a set rate (usually 500 Hz) tells them to process their inputs and put information in their outputs. Data is passed from one System to the next every time an execution cycle occurs. jp_type, jv_type, jt_type, cp_type These are type definitions (typedefs) of joint positions, velocities, torques, and Cartesian positions from the units.h header file. They are arrays which have been formatted to prevent confusion, and are, in many cases, the actual data that is being passed between systems when a WAM is run. The table below summarizes these types and their units: Type Cartesian Position Joint Position Joint Velocity Joint Torque Short Name cp_type jp_type jv_type jt_type Units Meters Radians Radians per Second Newton-Meters

Libbarrett Quick Start Guide Modified July 29, 2012 Page 12

Wam<DOF> - This is a class that contains all the Systems and other objects necessary to operate the real-life WAM with the given DOF. This object is not a System, but it is comprised mainly of various systems. The following are classes contained in every WAM object: LowLevelWam This is the core of a WAM Object, it is representative of the actual hardware WAM, and handles the communications between the software and the arm. It is a System which takes joint torques as an input, converts them to motor torques which are sent out to the Pucks, and receives motor torques back from the Pucks, which it converts to joint positions and joint velocities and places in its output. jtSummer An object that adds all of its inputs together and feeds the result to its output. In this case, in the virtual WAM object, it is adding together joint torques. jpOutput and jvOutput These are virtual spigots for joint positions and velocities, respectively, to which you can attach the input/output hoses that connect WAM systems. toolOrientation and toolPosition These are Systems which compute the position and orientation of the end point of the WAM. supervisoryController This object accepts any input which the PID Controllers in the WAM object can accept. It is not a System, however. It decides which controller should deal with the input, and passes it to that controller. It then handles the output of that controller and passes it to the jtSummer. It is told which signal to follow with the wam.trackReferenceSignal() call, and can be reset with the wam.idle() call. gravityCompensator This object, when connected to the jtSummer, calculates the force of gravity on the WAM and compensates for it by sending the appropriate joint torques to the arm.

Libbarrett Quick Start Guide Modified July 29, 2012 Page 13

To write a program for the WAM, create a virtual WAM object. A WAM Object is a collection of Systems that makes it easier to write the rest of the code. LowLevelWam is the object which deals directly with the real WAM arm at the core of the system. While it is possible to write code that deals directly with the LowLevelWam, it is generally easier to work with the tools built around it, because they will yield values that are easier to understand than joint torques. The tools built around the LowLevelWam are mostly Systems, which are created and connected together when you create a new WAM object in your code. The diagram below shows this framework, and the flow of information between the Systems, in a brand new WAM object. Notice the clear control loop, where a series of controllers are already receiving feedback from the WAM, and that they are all contained within the supervisoryController. The supervisoryController attaches the controller systems to the Summer based on the reference signal it receives (none are connected by default), and the Summer adds all the control torques together before passing them to the LowLevelWam. This loop is what all WAM programs interact with or modify.

WAM Systems Structure and Information Flow

Libbarrett Quick Start Guide Modified July 29, 2012 Page 14

Section 3 Programming the WAM

3.1 Implementation
After reviewing the conceptual structure behind libbarrett code, it is important to understand some implementation and its practical uses. Most implementations have a number of #includes and typedefs at the start of every piece of code. For simplification purposes, typedefs have been consolidated into stddhr.h (not all of these are necessary for every WAM program):
stdhdr.h #ifndef STDHDR_H_ #define STDHDR_H_ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include <stdlib.h> <stdio.h> <iostream> <string> <boost/ref.hpp> <boost/bind.hpp> <boost/tuple/tuple.hpp> <boost/thread.hpp> <libconfig.h++> <barrett/thread/abstract/mutex.h> <barrett/math.h> <barrett/units.h> <barrett/log.h> <barrett/systems.h> <barrett/wam.h>

namespace math = barrett::math; namespace systems = barrett::systems; namespace units = barrett::units; using using using using barrett::Wam; systems::connect; systems::reconnect; systems::disconnect;

const int DOF = 4; const double T_s = 0.002; typedef typedef typedef typedef units::JointTorques<DOF>::type jt_type; units::JointPositions<DOF>::type jp_type; units::JointVelocities<DOF>::type jv_type; units::CartesianPosition::type cp_type;

inline void waitForEnter() { static std::string line; std::getline(std::cin, line); } #endif /* STDHDR_H_ */

This code includes all the necessary libbarrett components and then renames several namespaces for convenience. Following that, it creates two constants that govern the coding environment DOF indicates the type of WAM (typically 4 or 7) and T_s is the Libbarrett Quick Start Guide Modified July 29, 2012 Page 15

period of the realtime code operations, meaning that the systems all operate every 0.002 seconds. The typedefs and waitForEnter() method at the bottom have been included for convenience.

3.2 Basic Demo Program

This program turns on and off the gravity compensator. Before running this program (or most programs), the WAM must be both idled and placed in a known home position (The default position is folded on itself as shown on the left). The code is shown below:
first_program.cpp #include stdhdr.h int main(int argc, char** argv) { libconfig::Config config; config.readFile("/etc/barrett/wam4.conf"); systems::RealTimeExecutionManager rtem(T_s, false); systems::System::defaultExecutionManager = &rtem; Wam<DOF> wam(config.lookup("wam")); rtem.start(); std::cout << "Press [Enter] to compensate for gravity.\n"; waitForEnter(); wam.gravityCompensate(); std::cout << "Play as long as you want, then idle the WAM and press [Enter] to exit.\n"; waitForEnter(); rtem.stop(); }

The first part reads an interchangeable config file. This file contains calibration settings for gravity compensation and other internal WAM components. However, the config file is only good for gravity calibration (Section 4). The second part of the code calls upon the Execution Manager. The manager is necessary for the program to run correctly, as it tracks all of the connected Systems and tells them to update every 0.002 seconds. Without it, no realtime code executes. The WAM must be then idled and moved to the home position before the WAM virtual object is created, because the code must be able to communicate with the physical WAM. If the WAM is not ready to communicate, faulting or errors will occur.

Libbarrett Quick Start Guide Modified July 29, 2012 Page 16

When gravityCompensate() is called, one of the virtual hoses that connects systems together is connected or disconnected. The following is the gravityCompensate() code found in libbarrett:
gravityCompensate from wam-inl.h void Wam<DOF>::gravityCompensate(bool compensate = true) { if (compensate) { systems::forceConnect(gravity.output, jtSum.getInput(GRAVITY_INPUT)); } else { systems::disconnect(jtSum.getInput(GRAVITY_INPUT)); } }

This is the code that connects the gravity compensator to the summer. Compare this code back to the block diagram of the WAM object for a better perspective. We achieve the desired effect of the systems; they connect, disconnect, and mix at will, making the code both flexible and stable and link using short code like above.

Libbarrett Quick Start Guide Modified July 29, 2012 Page 17

3.3 Principles of Design

A good WAM program is both modular and reliable. The code should be modular, so it can be easily applied into any coding sequence without much configuration. Think of it like each class is a brick comprising a chimney. The code must be reliable in that it can be counted upon to not break the hardware. For instance, if a WAM were being controlled remotely, and the connection were severed between the controlling PC and the WAM PC, code would need to be written in a secure manner so that collisions and torque faults would be avoided. Following these guidelines to make programs more robust: Do not use a 4 or 7 where you could use the variable DOF. Many programs, if written well, will work with either type of arm by changing the value of DOF.

Use loops to recurse through arrays instead of referencing them through hard numbers. This makes the code easier to extend.

Give your new code AS LITTLE information as possible; the library is written to isolate data and thereby prevent accidental modifications.

Rely on libbarrett as much as possible. The code you are hoping to write (at least at first) is probably a lot simpler than you think it is if you use the built-in functionality of the library.

Isolate thinking from realtime code. Realtime is for passing information around and performing concise calculations. It is NOT for waiting for input, writing output, or crunching large amounts of data. If you try to do too much within realtime, your code will take too long to execute, and interfere with controlling the WAM.

Libbarrett Quick Start Guide Modified July 29, 2012 Page 18

3.4 A More Complicated Program

After grasping the basics of libbarrett, it is good to try and make a more complex code to utilize all of the features of libbarrett. An example is shown below:
complex_program.cpp #include stdhdr.h int main(int argc, char** argv) { barrett::installExceptionHandler(); libconfig::Config config; config.readFile("/etc/barrett/wam4.conf"); systems::RealTimeExecutionManager rtem(T_s, false); systems::System::defaultExecutionManager = &rtem; Wam<DOF> wam(config.lookup("wam")); system::ExposedOutput<jp_type> holder; rtem.start(); std::cout << "Press [Enter] to compensate for gravity.\n"; waitForEnter(); wam.gravityCompensate(true);

Notice how the code up until this point is the same as the code in the previous program. A WAM object was created and was told to compensate for gravity, leaving it in a stable, equilibrium state. This is a perfect springboard into the code that follows, which gives the user several modes to place the WAM in. Notice how the code that follows is supervisory it does not do anything, it just passes on actions for Execution Manager to do. This is an example of separating realtime and nonrealtime code.

bool going = true; std::string line; jp_type setPoint; cp_type cartSetPoint; std::cout std::cout std::cout std::cout std::cout << << << << << Please enter a command below:\n; i = Idle (Gravity Compensation ONLY)\n; h = Hold Position\n; p = Go to Position\n; x = Exit\n\n;

while (going) {

Libbarrett Quick Start Guide Modified July 29, 2012 Page 19

std::cout << >>> ; std::getline(std::cin, line); switch(line[0]) { case x: going = false; break; case i: wam.idle(); break; case h: holder.setOutput(wam.getJointPositions()); wam.trackReferenceSignal(holder.output); break; case p: std::cout << x = ; std::cin >> cartSetPoint[0]; std::cout << y = ; std::cin >> cartSetPoint[1]; std::cout >> z = ; std::cin >> cartSetPoint[2]; wam.moveTo(cartSetPoint); break; } } rtem.stop(); }

This code gives the user four options: hit i, h, or p. The first, i, idling, leaves gravity compensation on, but cancels all other commands the WAM might be following by disconnecting the PID controllers with the wam.idle() method. The second, h causes the WAM to try to hold its position, by taking a snapshot of the WAMs joint positions and telling it to maintain them. TrackReferenceSignal() is very useful, because it can accept joint positions, torques, velocities, and Cartesian positions and effectively deal with them (it is a feature of the supervisory controller). While it can accept all these types, they must come from an output of another system in order for the controller to accept them. The third, p takes a Cartesian position as an input and commands the WAM to move the endpoint of the arm to that position. This uses the moveTo() call, one of several included WAM methods. moveTo can handle any types that supervisoryController can. Finally, x is the exit choice; it will cause the loop to break and the program to exit. Libbarrett Quick Start Guide Modified July 29, 2012 Page 20

3.5 A Program with Systems

Now you can try to do something simple with your first system. There are four joints in the WAM detailed in this manual. Try matching joints, such as joint 1 with 3 and joint 2 with 4. When tied, if you raise joint 1, joint 3 will rise as well. To do this, you first need to get an input of the joint positions then link the two. Finally, set the result as an output to send to the WAM. In order to tie together joints, the joint positions of the joints that we want to tie must be switched. This forces one to move where the other moves. Below is the system where all the manipulation occurs (LOCK_JOINTS):
lock_joints.h #ifndef LOCK_JOINTS_H_ #define LOCK_JOINTS_H_ #include <algorithm> #include <barrett/units.h> #include <barrett/systems/abstract/single_io.h> class LockJoints : public public: static const int DOF = 4; typedef barrett::units::JointPositions<DOF>::type jp_type; protected: virtual void operate() { jp = input.getValue(); std::swap(jp[0], jp[2]); std::swap(jp[1], jp[3]); outputValue->setValue(jp); } private: jp_type jp; }; #endif /* LOCK_JOINTS_H_ */ barrett::systems::SingleIO<jp_type, jp_type> {

The key piece of this class is the operate() function. This is the function called by the ExecutionManager every .002 seconds, along with all the other operate() functions in all the other systems. This system receives values from the systems::SingleIO template, which gives it a single input and a single output. operate() gets the input, does its manipulation, then sends it out via the output. This is the basis upon which all systems operate this system will be connected to others through its inputs and

Libbarrett Quick Start Guide Modified July 29, 2012 Page 21

outputs, and data will move through the network of systems through those connections.

Libbarrett Quick Start Guide Modified July 29, 2012 Page 22

After understanding realtime code, it is also important to understand the role of the supervisory code that compliments the realtime. Below is the code for this program:
lock_joints.cpp #include stdhdr.h #include lock_joints.h int main(int argc, char** argv) { std::cout << "Idle the WAM then press [Enter].\n"; waitForEnter(); libconfig::Config config; config.readFile("/etc/barrett/wam4.conf"); systems::RealTimeExecutionManager rtem(T_s, false); systems::System::defaultExecutionManager = &rtem; Wam<DOF> wam(config.lookup("wam")); systems::LockJoints lockingSystem; connect(wam.jpOutput, lockingSystem.input); rtem.start(); std::cout << "Activate the WAM now.\n"; std::cout << "Press [Enter] to compensate for gravity.\n"; waitForEnter(); wam.gravityCompensate(); bool locked = false; bool going = true; std::string line; while (going) { std::cout << ">>> "; std::getline(std::cin, line); switch (line[0]) { case 'x': going = false; break; case 'l': locked = !locked; if (locked){ wam.moveTo(jp_type(0.0)); wam.trackReferenceSignal(lockingSystem.output); } else { wam.idle(); } break; } } rtem.stop(); }

The switch/case statement waits for input; x will exit and l will toggle between normal gravity compensation and the joints being tied together. Notice how the WAM is moved to its zero position before the joints lock. This prevents the WAM from moving suddenly and somewhat unpredictably while trying to make its joints match up Libbarrett Quick Start Guide Modified July 29, 2012 Page 23

when they are bound. It does this by assuring that they are already in a safe position to begin with.

Libbarrett Quick Start Guide Modified July 29, 2012 Page 24

Section 4 Additional Procedures

4.1 How to Build and Run Your Programs
Libbarrett was written using Eclipse, a free, open-source development platform available at eclipse.org. Some configuration may be necessary depending on your system and version of software. Dan Cody (Barrett Technology, [email protected]) can answer questions regarding configuration.

4.2 WAMDiscover, SSHing and PuTTY

For basics on how to SSH, http://en.wikipedia.org/wiki/Secure_Shell gives a good intro. There are several things to know about connecting via SSH into the WAM PC. First, Barrett has a program, WAM Discover, which locates WAMs connected to a local network. WAM Discover runs on both Windows and Linux machines and allows connecting to the WAM directly from its interface when configured properly. Under Linux, configured properly means that you simply choose which WAM you want from the provided list, and hit connect. Under Windows, WAM Discover must be in the same folder as PuTTY, a free, open-source SSH client. If so, the Connect button will establish a Secure Shell between the WAM PC and the Users PC. The default username for the WAM is robot, and the default password is WAM. Connecting via SSH into the WAM is the same as connecting into any other Ubuntu computer. The commands for a Linux terminal window are the commands you use in the SSH session with the WAM PC. To change the name of your WAM, change the default password, or add users, refer to Section 4.3. Below are pictures of the GUIs of WAM Discover and PuTTY under Windows. In PuTTY, once you know the IP of the WAM you want to connect to, you need only enter it in the Host Name field and hit Open. In WAM Discover, Refresh List makes the program look for WAMs, and Connect opens a connection through PuTTY.

Libbarrett Quick Start Guide Modified July 29, 2012 Page 25

4.3 Managing WAM Settings

This Section describes how to modify your WAMs name and User settings. To change the default password for the robot account: 1. SSH into the WAM PC under the robot account. 2. Type passwd into the terminal. 3. Enter your current password. 4. Enter your new password twice as prompted. 5. You are done! To add a new WAM user (<username> should be replaced with the desired account name): 1. SSH into the WAM PC. 2. Type adduser <username>. 3. Enter a password for the user as prompted. 4. Enter usermod -G adm,cdrom,audio,video,plugdev,admin,xenomai <username> into the terminal. 5. You are done! To change the name of the WAM that shows up in WAMDiscover: 1. SSH into the WAM PC. 2. Use the cd command to get to /etc/barrett. 3. Edit the serial file using VI or another editor. Whatever you put in this file is what will show up in WAMDiscover. 4. You are done!

Libbarrett Quick Start Guide Modified July 29, 2012 Page 26

4.4 Additional Documentation

In addition to the printed material which came with your WAM, there are instructional videos, more documentation, bug fixes, and example code available on Barrett Technologys web site. The following internet addresses will direct you to these repositories. The Barrett Technology Support Wiki - wiki.barrett.com/support This site contains tutorials, setup instructions, and fixes for Barrett hardware and software. You can find videos that describe how to calibrate your WAM and where to download new software from here. Barrett Technology Forum web.barrett.com/forum The forum is a great place to ask a question and get responses from Engineers and other customers alike. If your question is not answered in the Wiki, as it here next. Libbarrett Doxygen Documentation - web.barrett.com/libbarrett/ This site contains documentation for the Libbarrett library, which was created using doxygen. Browsing this resource will give you greater insight into how the library is structured and how to use it. Barrett Technology Mailing List - web.barrett.com/mailman/listinfo/wam You may sign up for the WAM listserv here, which allows you to communicate with other WAM users easily through email. Barrett Support Email Address [email protected] If you have additional questions about your Barrett products, you may ask them here.

Libbarrett Quick Start Guide Modified July 29, 2012 Page 27