## 60 in double reverse 4 bar linear linkage example

June 8, 2014

Here are some pictures of how a double reverse 4 bar using Vex 35 hole link arms. The main challenge is constructing a stable geometry. The lift has a middle link gear train to move the upper 4 bar in sync with the lower 4 bar.

Torque

Approx torque (inlb) required = 2*l_arm*(W_payload_lbs + W_lift_lbs + W_manipulator_lbs)*cos(angle)

height_delta = 2*l_arm*( sin(angle_finish) –  sin(angle_start))

where l_arm is the distance between pivots of the arms in inches, W_payload_lbs is game piece weight, W_lift_lbs  is the weight of the 3 arms used in the lift , W_manipulator_lbs  is the weight of the gripper attached to the upper arm and angle is defined relative to the horizontal.  The max torque occurs when the arms are horizontal or angle • 0 .

If you want to lift 4 1 lb Skyrise cubes with a 3lb lift weight , a 1 lb  gripper and a l_arm of 16 in you would need about 256 in lbs of torque.

As a rule of thumb I use 6 inlb of torque per motor for sizing  the number of motors.  This assumes 2  inlbs of elastic support , 1 inlb of friction and 3 inlbs from active current (about .9 amps) hold per motor used.   With these assumptions a 10:1 gearing and 4 393 motors might do the job.    The lift would take about 5 seconds to go full travel.  I’ll show a more exact torque derivation later.

Height change

With an  angle_finish = 75 deg and the angle_start= -60 deg  a 16 in arm reaches 59 in.  A 16.5 in arm reaches 61 in.   With a chain bar you could  clear an in or two more.So

## Scissor Lift Performance Excel Program (corrected 7.13.2012)

July 11, 2012

Update:Corected for dh_dl error 7/13/2012:  dh_dl was 2, should have been .67  .

I wrote this excel program to calculate the height, speed, payload capability , current draw  and lift time for a vertically linear actuated scissor lift.   The inputs are the basic dimensions, number and type of motors, lift frame weight and manipulator weight plus design torque % of max torque.

I ran a test case based upon this posted Vex BLRS college robot  in the Vex forum to see how it checked with the observed performance clarified in this post.

Excel Inputs based upon the post and picture.

The key inputs are the dh_dl which is the change in single stage height with actuactor extension.  I initially noted that the linear slide actuators are attached to the mid-point lift pivot so a lift stage raises twice as much as the actuator and I chose dh_dl = 2.     This however was incorrect .  Although it is attached to a mid_point, this mid_point is on the second stage of the lift.   Any motion of this point will only move the lower stage by 2/3 that amount.    Therefore dh_dl should be equal to .67.

I also guessed at the W_manipulator = 6 lbs since it is not in the picture but the builder stated that it was heavy.

Also Friction is ignored since it is usually compensated for with elastic bands mounted horizontally between lift sides helping to propel the lift upwards.

The lift calculated  extension time is 8.1 sec  vs 7 to 8 sec noted by the robot builder.  The total current (6. 4 amps) is reasonable… about 2 amps per power rail .   The payload capability W seems  very high  (21 lbs)  relative to just lifting 6 game objects. (3lbs).   I don’t have a reasonable explanation other than the manipulator weighed much more than 6 lbs.   If we argue that friction is not fully compensated for by rubber bands this would reduce the payload capability, however, it would also slow the lift time which is about right  .

I will post this in the Vex forum and see whether test case holds up to scrutiny.

Perhaps later I will add a drag term to simulate uncompensated friction.

Excel calculated outputs;

 Performance Summary Calculated Values h_min_stage 3.1 in starting height per stage h_max_stage 11.6 in finishing height per stage h_min 12.4 in total starting height h_max 46.4 in total finishing height delta_h_stage 8.5 in Change in lift height per stage total_delta_h 33.9 in Total change in lift height torq_motor 18.7 in_lbs Available motor torque F_act 74.8 lbs Total actuator force pushing on frame I_total 6.4 amps Total current draw at speed W 21.1 lbs Total payload capability rpm_motor 60.0 rpm motor rpm during lifting t_lift 8.1 sec Lift extension time

Program inputs:

 Scissor lift calculations Written by Vamfun 6/1/2012  Vamfun@yahoo.com    Mentor 599 and 1508 Vertical Linear slide actuating lift… 12 tooth gearing inputs percent_torq_stall 40 % Design torque in % of torq_stall W_manipulator 6 lbs Weight of  manipulator W_f 1.5 lbs Weight of single stage of lift frame phi_min 15 deg Minimum angle between arm and horizontal phi_max 75 deg Maximum angle between arm and horizontal L_stage 12 in Total leg length per stage N 4 Number of lift stages r_gear 0.25 in gear radius used to convert motor motion to linear motion dh_dl 0.67 Change in single stage lift height per change in actuator extension torq_393 14.76 in_lbs Spec motor I_stall_393 4.8 amps Spec motor I_free_393 0.37 amps Spec motor n_393 2 User set number of motors torq_269 8.6 in_lbs Spec motor I_stall_269 2.6 amps Spec motor I_free_269 0.18 Spec motor n_269 2 User set number of motors

## Sack Attack Scissor Lift Torque Requirements (theory)

June 27, 2012

Assume that we have a scissor lift that we use to lift W_lb of sacks to a height of 36 inches.

Also assume that the lift is actuated by a center pin torque with gearing ratio GR that is the output torque/motor torque.

A  N stage scissor lift requires a center torque = N*(W_lb + W_lift/2)*L*cos(phi) where phi is the interior angle between the arm and the base (see post).

The max torque occurs when phi = 0  or when the lift is at its lowest point.     At this point the total torque = M* m_torq where M is the number of motors and m_torq = max motor torque set by the PTC limits.

m_torq*M = N*(W+W_lift/2)*L/GR  or

W = GR*m_torq*M/L/N – W_lift/2

Lets put in some typical numbers:  L = 6 in,  W_lift = 1 lb, N = 4 , GR = 7:1, m_torq = 6 in lbs    (the 6 in lbs is set by alloting 3.5 amps per  two 393’s driven by half a cortex or power expander.)

W = 1.75*M – .5 lbs

M motors => lbs (sacks)

1  => 1.25 lbs (2.5 sacks)

2 => 3 lbs ( 6 sacks)

3 => 4.75 (9.5 sacks)

4 => 6.5 lbs ( 13 sacks)

Focusing on the 4 motor case, lets see what happens when elastic is added that pulls with an upward force on the center pivot.  In this case, when the robot is picking up sacks, the motors would be holding the lift down against the elastic.   When the lift goes up the elastic and motor are working together.   If we add just enough elastic that the motor can still hold the lift down then this is equivalent to doubling the motor torque when the lift is down.   So

Elastic +4 => 13.5lbs (27 sacks)

Or we could also up the gearing ratio by x3 factor…. the lift would be 3 times slower but here you would be making one large dump and speed is not required.

3x gear + 4 => 20.5 lbs(41 sacks)

Ok now we are talking…. 41 sacks !! But in Mythbusters style…. more is better  so how about 6 motors.

3x gear + 6 => 31 lbs (62 sacks)

Ok… enough for me.  Not sure how you would stack 62 sacks on the upper goal.    These numbers are of course rough cuts and ignore friction etc but elastic can be use to make the theory come true.

So in summary, looks like we should be able to lift 13 sacks to a 36 in height with 4 393’s  working through a 7:1 gearing ratio.    Adding elastic can increase this to 27 sacks or using a 21:1 gearing we can get to 41 sacks or with a 21:1 gearing and 6 motors we can lift 61 sacks.

Related Posts:

https://vamfun.wordpress.com/2012/07/11/scissor-lift-performance-excel-program/

## Error in Scissor Lift Equations at Engineers Edge??(Finally fixed)

November 12, 2011

Error in Scissors Lift Equations??

7.12.2012 Update:

Ok…. finally Engineers Edge has corrected their equations.  So I have modified this post to take out the obsolete references.

I was looking for some lift equations for our Vex students to use.  I derived some myself but decided to check them against a popular  reference site.

The equations stated in this engineersedge scissor-lift link were incorrect prior to their last update but are now correct except the new authors have not included the weight of the frame in their answer.

For the bottom actuator the force  is given as

F = W /tan(phi)

at engineersedge .  With frame weight Wa  added this becomes:

F =( W + Wa/2)/tan(phi)

and

for the center pin actuator  the force with frame weight  is

F = 2*(W+Wa/2)/tan(phi)

Where W is the load weight, Wa = the total arm frame weight  and phi is the interior angle between the horizontal and the arm.

The  solution is obtained by using the moment equation written about the center pin of the lift.  This gives:

F*L*sin(phi) = (W + Wa/2)*L*cos(phi)

or F =( W + Wa/2)/tan(phi)

where L is the half length of a scissor leg.

This is easily checked by an energy approach.   If the load W is lifted by dh  then the center of mass of the frame (with weight Wa)  is lifted by dh/2.

We know that if the actuator moves a distance of dx the work input is F*dx which must equal the potential energy increase of the lift masses moving against gravity.

So F*dx =(W + Wa/2)*dh
or
F = (W+ Wa/2)*dh/dx

From geometry, dh/dx = 1/tan(phi)

Hence F =( W + Wa/2)/tan(phi);

When the force F is applied to the center pin of the lift the same dh is achieved with dx/2 movement so the force F must be twice as large to raise the masses.

So F_center_pin = 2*F_bottom = 2*( W + Wa/2)/tan(phi);

When multiple stages are added the force is simply multiplied by the number of stages.  This follows from the energy formulation since each stage adds another dh but the dx displacement of the actuactor remains the same.

An excellent reference for a more detailed proof is from a paper “Mathematical Analysis of Scissor Lifts” by H. M. Spackman .  He also wrote a paper

“Mathematical Analysis of Actuator Forces in a Scissor Lift”

12/18 Update: Pivot torque required to extend a scissor lift

If one wanted to apply a torque τ to the center pivot pin to extend the lift rather than use a base force F (similar to the “Chinese Vex scissor lift”) the equation is

τ  = (W + Wa/2)*L*cos(theta)  where L is the half length of a scissor leg.

Proof:

Let

theta = interior angle between the scissor legs.

d_theta = a small change in this angle.

τ = torque applied to the scissor joint
The torque must do the same work that was done by the force F derived above.
τ*d_theta = F*dx =  work done to move the lift a height of dh  against gravity.
So    τ = F*dx/d_theta.
Using half of the base triangle  we know that the base x is  x = 2* L*sin(theta/2)  .So  we can differentiate with respect to theta
dx /d_theta = L*cos(theta/2)
We want this in terms of    phi = 90- theta/2      so
dx/d_theta = L*cos(90 – phi) = L*sin(phi)
Now plugging in for F and dx/d_theta
τ = (W + Wa/2)/tan(phi) * L*sin(phi)  or
τ = (W + Wa/2)*L*cos(phi)
Again, if there are N stages then the total torque = N*τ

## More pictures of 599 2010 Vex RoundUp Robots

January 4, 2011

599C :

At CAMS final before side claws added.  Shows good view of lift and collector in action. Its on  Blue alliance paired with 599B claw robot.

Our 599C robot was able to extend 18 inches in about 2 seconds by driving both nested slides at once.  The front two nested slides were synchronized  by a common drive shaft.  Same for the back two slides.   The two sets of nested slides were mounted back to back and driven separately and simultaneously.  The slide pairs were also offset to make the mounting easier.     An encoder was attached to each slide and we positioned the lift height automatically based upon the sum of the two slides encoders. Although the slides were not synchronized it really didn’t matter since it was the total movement that concerned us. Each slide did have its own electrical position limit. We used a 36 tooth drive gear.  In this configuration, the two motor pinions always had the same separation and could have been synchronized by a connecting chain however, this was unnecessary.

I really liked this design when combined with a perimeter tube collector. It could score and de-score with vertical motion.   It also had and additional set of side claw grippers that could be used to de-score a stack of 4 tubes while simultaneously holding 4  of its own tubes.   In one single move it could remove 4 tubes and drop 4 for a 26 point score turn around.    The side claws were only one tube tall and pivoted on axles mounted on the side of the basic gripper.

It did have a few friction problems … and for some reason, we actually had two 393 motors fail during the same competition. One had a broken steel gear tooth and the other had excessive friction. You can get a glimpse of the 599C robot defending against the 599D collector robot in this video. (I think in this match, its upper lift was inoperable so it doesn’t seem to be doing much but defending.) The robot can self align nicely with a low goal by pushing it and subsequently was able to do well in programming competitions.

My summer Mentor dual Bobcat that was designed to hang had the slides all mounted facing the same direction. Here, because of power requirements, only two of the slide pairs were driven at a time. It needed two 393’s per lift stage to hoist the robot. It didn’t use a power expander, so we needed to limit the current. This design also used a 36 tooth drive and subsequently it took around 5 sec to move 18 in.

599D:

Fat robot after all tubes collected:

## Peaucellier Linear Linkage for Vex Round Up

December 29, 2010

I am trying to revive the Grant HS Vex robotics team.   I helped start this team several years ago but they lost their mentor this year and got off to a late start.   I worked with them during the first four days of their winter break.   We are going to try a Peaucellier linear linkage to make the lift go vertical.

http://web.mat.bham.ac.uk/C.J.Sangwin/howroundcom/straightline/exact.html
Should be fun if it works and doesn’t weigh too much.
The actual design marries a 7 bar desk lamp (Two  4 bars in series  with a common middle link) and Peaucelliers linkage.   The top two linkages of Peaucelliers are in common with the bottom two linkages of the 7 bar.   The 7 bar provides the strength structures and torque while the Peaucellier provides the guide to maintain the vertical movement.  In total there are  7 plus 5 or 12 linkage bars.    All linkages are dual with about 3 inches separation to provide lateral stability.
We have the preliminary design prototyped and it gives an 18 in delta vertical movement.

Preliminary Torque Requirements:

The plan is to drive it as one would a standard 4 bar.  This has the advantage that if it doesn’t pan out, it can easily be converted to a 4 bar design without major structural changes.    I haven’t done a force analysis, but I am guessing that this design requires more torque than an equivalent 4 bar with the same length as the distance between the rear pivot and the back of the claw when the claw is at mid position.

One can estimate the average torque by using a virtual work analysis.   Work done by the arm is equal to the work of lifting the load.

τ*Δθ = W*Δh  where

Δθ is the angle the torqued bar changes (rad) ,

Δh is the corresponding change in the claw height (in)

τ is the torque (in_lbs)

W is the equivalent weight lifted (lbs)…. we add a little extra here for the lift structure and assume it is lifted the whole  height.

Δh = 18 in,

Δθ = ∏/2 = 1.57 (90 degrees)

W = 3 lbs   (1 lb for claw, 1 lb for tubes and 1 lb for the linkage)

τ = 3*18/1.57 = 34.4 in_lbs  ….  With a 50% safety margin, we should design for around 50 in_lbs.

If we operate with a 5:1 gearing, then we need 10 in_lbs from the motors and any elastic bands used to help neutralize the lift load.

Lets look at using  big 393 motors … each can supply a max torque of 13.5 in_lbs and a static friction hold of 1 in_lb.  With 2 motors we get 27 inlb of max torque and 2 in_lbs of friction torque.

So to hold the lift in position we need a net of 10 – 2 = 8 in_lbs of torque, which without elastic represents about 30% of max torque.  This will overheat the motors in the course of a match.  So   we need  to cut this down to about 15% (4 in_lbs) of max torque if the motors are going to continuously hold the torque during a match.

One way would be to add two extra legacy motors to provide extra friction and max torque capability and the other might be to add elastic tension to the inner pivot bar used in the Peaucellier linkage set.   We could tie rubber tubing  to the point where the pivot bar attaches to the Peaucellier cage and stretch it to the upper back of the robot creating enough force to hold the lift in the center position without motor input.      Anyway, some experimentation is in order.

More later.

1/5/11 Update: To simplify the motor selection the following rules of thumb could be applied if motors are to hold continuous torque to counter gravity.

393 motors: 1 in_lb static, 2 in_lbs dynamic(15% max torque) … total 3 in_lbs

legacy 3 wire: .6 in lbs static, 1 in_lbs dynamic (15% max torque) .. total 1.6 in_lbs

So… we need 10 in_lbs total.   2 393’s and 2 legacy gives  3+3+1.6+1.6= 9.2 in_lbs.

That leaves a requirement for 1 in_lb of elastic torque and a steady state drain of current = 15%*total max current = .15*(3.6+3.6+1.6 +1.6) = 1.6 amps

This creates a battery drain equivalent to one legacy motor running stalled.

To have minimum current draw, we would need  10 – 3.4 = 6.6 in lbs of elastic torque to augment just the static friction of the motors.

If we are willing to trade speed for less torque… say using 7:1 gearing then 2 393 motors might suffice .

Update 7/1/2012 More recent blog links:

Team 1508a Lancers Compete Peaucellier Design at 2011 Vex Round Up World Championships

Team 1508a Vex Peaucellier Lift Roundup Youtube Video

## Sample Auto_lift RobotC program

October 2, 2010

Since I have been working with the kids on auto_lift control I thought I would put in writing a sample program that uses potentiometer feedback to stop the lift at discrete goals.  The friction of the lift is relied upon to hold the lift in place since closed loop feedback is removed once the lift has reached the goal.   This program doesn’t require scripting logic , however,  the int =auto_lift(int goal,int rate,int TOL) function is tailored to fit easily within a script if required.

Here is the RobotC  Sample_Auto_lift.c Program :

Edit: 1/6/2011  Simplified EasyC version here:

Tuning for minimum overshoot.

A note on how to tune the program. The lift is commanded at a fixed rate. This rate will cause an overshoot after the lift_goal is reached. The size of the overshoot depends on the lift inertia, the magnitude of the fixed rate and the motor drag torque. The LIFT_TOL is used to bias the target goal in a direction that anticipates the overshoot and shuts the lift rate off early.
You can get an idea of the overshoot by setting LIFT_TOL = 0 , pushing the select goal button and then looking at the difference between where the lift stopped relative to the lift goal position. Repeat this for both above and below goal starting conditions. You will find that the overshoot is a lot more for the down position due to the assistance of gravity.

Now you can set the LIFT_TOL equal to the overshoot in the up direction. To compensate for the extra overshoot in the down direction, you can increase LIFT_TOL to LIFT_TOL_DOWN =LIFT_TOL*factor. Use LIFT_TOL_DOWN in place of LIFT_TOL in the down direction error test. I.e. if(error <-LIFT_TOL_DOWN)) lift_cmd = -LIFT_RATE.

You can also keep the LIFT_TOL small and just adjust the goal heights. Probably would need separate heights for up and down directions.

If your overshoots are just too large , then you can lower your average rate or make the lift_rate = K*error and limit the rate to [ -127, 127]. This is essentially a PID loop without the I and D. K is just a gain constant. Sometimes, I also use a little timed speed reversal to assist in the braking of the arm.

RobotC Code Starts  Here (copy and paste in RobotC non competition program file template)****************************************************

#pragma config(Sensor, in5,    lift_pot,            sensorNone)
#pragma config(Motor,  port10,           lift_motor,    tmotorNormal, openLoop)
//*!!Code automatically generated by ‘ROBOTC’ configuration wizard               !!*//
//599 Robodox Vex Team
//Author:Chris S. Engineering Mentor
//Sample auto lift control program that uses a potentiometer to sense lift position.
//Simply hook up a motor to a potentiometer , set the config to match your ports and run.
//Lift states are commanded by either the joystick Ch3 or joystick buttons 5Down,5Up,6Down,6Up.
//At anytime the auto_lift is operating, a Ch3 input will automatically disconnect the auto_lift and allow manual takeover.

//Potentiometer – Returns an analog value between 0 and 4095
//(although mechanical stops my limit the values to between 5 and 4092)

//When Ch3 input is less than DEADZONE then auto_lift commands are enabled.
//If a lift_goal is chosen by a button, auto_lift causes the lift to move toward the goal at LIFT_RATE.
//When the (goal-lift_pos) is within LIFT_TOL, lift_goal is set to NO_GOAL and auto_lift is exited.

//lift_state variable is set equal to a lift goal when the lift_pos is within LIFT_TOL of the goal.  This
//allows other functions to poll the discrete lift_states.  I.E. if(lift_state == LIFT_DOWN) do something.
//lift_state = LIFT_OTHER when not within +_LIFT_TOL of a goal.
//Routine also contains max/min lift limiting.
#define  LIFT_RATE 20 //speed of auto lift

//lift goals and/or states
#define  NO_GOAL     -99 //if lift_goal = NO_GOAL, auto_lift is bypassed.
#define  LIFT_OTHER  -88 //use when lift is in between discrete states
#define  LIFT_MIN     50 //lift goals
#define  LIFT_DOWN    200
#define  LIFT_PICKUP 1000
#define  LIFT_DROP   2000
#define  LIFT_HANG   3000
#define  LIFT_MAX    4000

#define  LIFT_TOL     50 // lift position control tolerance

//function prototypes
void Joystick();
int auto_lift(int goal, int rate, int tol); //sets lift pwm and moves until withing tol of goal
void lift_function();

//Global Variables
//Define variables for complete joystick although we only need 5 inputs
// Joystick Axes – Joystick 1
int RT_Ch1 = 0;
int RT_Ch2 = 0;
int RT_Ch3 = 0;//only need this chan really
int RT_Ch4 = 0;

// Shoulder Buttons – Joystick 1
int RT_5Down = 0;//need these four
int RT_5Up = 0;
int RT_6Down = 0;
int RT_6Up = 0;

// Front Buttons – Joystick 1
int RT_7Up = 0;
int RT_7Right = 0;
int RT_7Down = 0;
int RT_7Left = 0;
int RT_8Up = 0;
int RT_8Right = 0;
int RT_8Down = 0;
int RT_8Left = 0;

//lift variables
int pwm_lift_cmd = 0 ;
int lift_goal = NO_GOAL ;
int lift_pos= 0;  //lift pot
int lift_state = LIFT_OTHER;//this is the discrete state of the lift

{
while(true)
{
Joystick();
lift_pos = SensorValue(lift_pot);//get the potentiometer postion
// Operator function code

{
//inside deadzone so set command to zero and allow auto commands
pwm_lift_cmd =0;
if(RT_5Down) lift_goal = LIFT_DOWN;
if(RT_5Up) lift_goal = LIFT_PICKUP;
if(RT_6Down) lift_goal = LIFT_DROP;
if(RT_6Up) lift_goal = LIFT_HANG;

}
else
{
pwm_lift_cmd = RT_Ch3/2 ;//half gain for demo
lift_goal = NO_GOAL;//joystick input so reset lift_goal = NO_GOAL
}
//End Operator Function code

//Core functions
auto_lift(lift_goal, LIFT_RATE,LIFT_TOL) ; // modifies pwm_lift_cmd if lift_goal != NO_GOAL
lift_function();

}//end while
void lift_function()
{

//Compute discrete lift states for other functions to test on.
if(lift_pos – LIFT_DOWN < LIFT_TOL && lift_pos-LIFT_DOWN >-LIFT_TOL) lift_state = LIFT_DOWN;
else
if(lift_pos – LIFT_PICKUP < LIFT_TOL && lift_pos-LIFT_PICKUP >-LIFT_TOL) lift_state = LIFT_PICKUP;
else
if(lift_pos – LIFT_DROP < LIFT_TOL && lift_pos-LIFT_DROP >-LIFT_TOL) lift_state = LIFT_DROP;
else
if(lift_pos – LIFT_HANG < LIFT_TOL && lift_pos-LIFT_HANG >-LIFT_TOL) lift_state = LIFT_HANG;
else
if(lift_pos – LIFT_OTHER < LIFT_TOL && lift_pos-LIFT_OTHER >-LIFT_TOL) lift_state = LIFT_OTHER;

//limit lift travel with potentiometer
if(pwm_lift_cmd > 0 && lift_pos >= LIFT_MAX || pwm_lift_cmd <0 && lift_pos <=LIFT_MIN)
{
motor[lift_motor] = 0;
}
else
{
motor[lift_motor] = pwm_lift_cmd;
}
//sometimes it is good to also have hard limit switches in case the potentiometer slips.
//if(pwm_lift_cmd > 0 && upper_limit_sw || pwm_lift_cmd <0 && lower_limit_sw)
//{
//  motor[lift_motor] = 0;
//}
// else
//{
//  motor[lift_motor] = pwm_lift_cmd;
//}
}

int auto_lift(int goal, int rate, int tol)
{
//goal is the position you want to move to… in pot units
//rate is the pwm that you want the lift motor to move at
//tol is how close you want to be within the goal when you are done moving
//tol should be set large than the noise band of the position sensor

if(lift_goal == NO_GOAL)
{
return 0 ; // no goal so get out
}

int error = lift_pos – goal;

if( error > tol )
{
pwm_lift_cmd = -rate;
}
else

if(error < -tol)
{
pwm_lift_cmd = rate;
return 0;
}
else //we are within the tol so we have met the goal
{
pwm_lift_cmd = 0; //stop moving
lift_goal = NO_GOAL;
return 1;
}

}
void Joystick()
{
//Read Joystick inputs ****************************************************************************
// Joystick Axes – Joystick 1
RT_Ch1 =    vexRT[Ch1];  // Returns -127 to +127
RT_Ch2 =    vexRT[Ch2] ; // Returns -127 to +127
RT_Ch3 =    vexRT[Ch3];  // Returns -127 to +127
RT_Ch4 =    vexRT[Ch4] ; // Returns -127 to +127

// Top Buttons – Joystick 1
RT_5Down =  vexRT[Btn5D]; // Returns 1 or 0
RT_5Up =    vexRT[Btn5U]; // Returns 1 or 0
RT_6Down =  vexRT[Btn6D]; // Returns 1 or 0
RT_6Up =    vexRT[Btn6U]; // Returns 1 or 0

// Front Buttons – Joystick 1
RT_7Up =    vexRT[Btn7U]; // Returns 1 or 0
RT_7Right = vexRT[Btn7R]; // Returns 1 or 0
RT_7Down =  vexRT[Btn7D]; // Returns 1 or 0
RT_7Left =  vexRT[Btn7L]; // Returns 1 or 0
RT_8Up =    vexRT[Btn8U]; // Returns 1 or 0
RT_8Right = vexRT[Btn8R]; // Returns 1 or 0
RT_8Down =  vexRT[Btn8D]; // Returns 1 or 0
RT_8Left =  vexRT[Btn8L]; // Returns 1 or 0
}

End Code******************************************************