how do I stop my lift from falling when I let go

To stop your lift from falling when you let go of the controls, you should program the lift motor to use the RUN_TO_POSITION mode to actively hold its target height, or apply a constant feedforward power (kF) to counteract gravity.

The most straightforward software solution is to configure your lift motor to use RUN_TO_POSITION mode. As demonstrated in the Game Manual 0 finite state machine implementation, you can set the motor's mode to DcMotor.RunMode.RUN_TO_POSITION, set the target position to the desired height, and apply a constant power (such as 1.0). When the driver lets go of the controls, the motor controller will automatically apply the necessary power to maintain that encoder position .

Alternatively, you can implement a feedforward control loop to counteract gravity. Game Manual 0 explains that you can use a feedforward constant (kF) to approximate the power needed to hold a mechanism against gravity. While rotating arms require a cosine-based calculation because the effect of gravity changes with the angle, a linear lift experiences a constant gravitational force, meaning a constant kF can be added to your motor output. You can find this constant empirically by setting your PID gains to zero and slowly increasing kF until the lift holds itself up at any position , .

Additionally, adding a static friction feedforward term in the direction of intended movement can help overcome the system's initial resistance. Game Manual 0 notes that every system has static friction, which can be modeled by adding a constant feedforward term in the direction you want to move .

The condition that would change this recommendation is if your lift is rigged with elastic retraction, which continuously pulls the slides downward and increases the force required to hold them up. According to Game Manual 0, elastic retraction applies a continuous force on the slide that opposes the motor during extension, which would require a much higher holding power or feedforward constant to keep the lift from falling , .

Was this right?

Sources16

Control Loops > Feedforward Control > Gravity Compensated Feedforward

Game Manual 0·CC BY-NC 4.0

In gravity-compensation we derive the effect of gravity upon an arm as Fg = gcos{theta}. Here we can use that with the following logic.

while True:
    error = desire_position - current_position; # no effect on gravity compensation
    current_angle = (TICKS_AT_ZERO - current_tick) * DEGREE_PER_TICK
    output = PID(error) + cos(radians(current_angle)) * kF

This code uses a kF constant to approximate how much power the arm needs to counteract gravity. In theory, this is something related to gravity multiplied by the rotational moment of inertia of your arm. Calculating this is impractical and kF is instead found empirically. This can be done by setting the gains on the PID to 0, and increasing kF until the arm can hold itself up at any position. If your arm is still falling, increase kF, and if your arm is moving upwards, decrease kF. FTC team 16379 Kookybotz has an excellent video on Arm programming (https://youtu.be/E6H6Nqe6qJo?si=AztzVtAqShFEA4EP&t=440), where they demonstrate how to increase kF.

Open Game Manual 0

Rigging > Retraction Options > Elastic Retraction

Game Manual 0·CC BY-NC 4.0

Instead of retracting using a retraction spool, one common way to retract is to attach a piece of elastic (commonly surgical tubing) to the last stage. The elastic applies a force on the last stage that is counteracted by the motor when extending. However, when retracting, the motor reels the last slide back in. While this is the retraction method recommended by many kit slide manuals, this method is not recommended.

Advantages:

There is only one string to tension, instead of multiple, so tensioning is simpler.
The elastic automatically tensions the extension string.

Disadvantages:

Since the elastic applies a force to the slide at all times, this force opposes the force applied by the motor when extending the slides. Thus, elastic retraction decreases extension speed considerably.
The elastic does not apply a constant force at all times. It applies force proportional to the amount that the slide is extended, so retraction may not be smooth and controlled, like other rigging methods.
It is very easy to unwind your extension spool when using elastic retraction.

Open Game Manual 0

Extrusion Slides > Actobotics X-rail Slide Kit > Advantages

Game Manual 0·CC BY-NC 4.0

Easily interfaces with Actobotics building system
Elastic retraction is a simple way to retract
Should be used for light/medium loads only

Will flex under load, needs additional support
Elastic retraction slows down extension speed and retraction will be slower than string retraction

(Figure: 12599 Overcharged, Relic Recovery, Actobotics X-Rail slides)

Open Game Manual 0

Three Stage Cascading Lift | REV DUO Build System

This source does not publish a licence, so its text is not reproduced here. Open the source to read it.

Open REV Robotics Docs

Rigging > Retraction Options

Game Manual 0·CC BY-NC 4.0

As the name suggests, continuous retraction utilizes inverted continuous rigging to retract the slides. There are two main methods of doing this, free floating retraction where a string is run from the last stage directly back to the spool, and with slide retraction where the string is run in an inverse continuous pattern. Generally, with slide retraction should be used with extensions going outside the robot frame to prevent entanglement, and free floating retraction should only be used with purely vertical slides.

Note: If continuous retraction is being used with cascade extension, the two spools cannot be the same diameter. If the variable N is the number of stages in the system, the diameter of the cascade extension spool must be N times smaller than the continuous retraction spool.

(Figure: Continuous Retraction)

Warning: If free floating retraction is used, make sure your retract string is always parallel to the slides. If the string is misaligned, it can pull on your slide and cause excess bending forces on the stages.

Advantages:

Simplest retraction rigging

Disadvantages:

Can become tangled if free floating
Requires different sized spools if used with cascade retraction

Open Game Manual 0

Extrusion Slides > OpenBuilds Mini V Gantry Kit > Advantages

Game Manual 0·CC BY-NC 4.0

Sturdy, doesn't flex even under a lot of load
Interfaces with most other build systems thanks to sliding T nuts

Not designed for multi-stage lifts right out of the box
Heavy, overkill for lifting lighter objects unless precision is important
OpenBuilds only offers M3 and M5 T nuts, although other compatible sizes might be found on Amazon or McMaster-Carr

(Figure: 4997 Masquerade, Cascade Effect, OpenBuilds slides)

Open Game Manual 0

Chief Delphi > FTC > 3d printed linear lift reliable? FTC

Chief Delphi·Community forum posts — not openly licensed

This source does not publish a licence, so its text is not reproduced here. Open the source to read it.

Open Chief Delphi

Control Loops > Feedforward Control > Kv Ka Feedforward Pseudocode

Game Manual 0·CC BY-NC 4.0

while True:
     targetVelocity = getTargetVelocity(time)
     targetAcceleration = getTargetAcceleration(time)
     output = targetVelocity * Kv + targetAcceleration * Ka;

In every system there is bound to be some amount of static Friction. This means that the robot mechanism will not move until a certain amount of power is applied. This can be modeled by adding a constant feedforward term in the direction you want to move.

while True:
     error = desire_position - current_position;
     sign = signum(error) # sign of error, will be -1, 0, or 1
     output = sign * staticFriction + PID(error); # PID Controller + Friction Feedforward

Open Game Manual 0

Rigging > Tensioners

Game Manual 0·CC BY-NC 4.0

Tensioning string is one of the most painstaking tasks for a builder in FTC. Ensuring that both sets of slides are tensioned evenly can be an arduous and annoying job. However, adding tensioners to your strings can help solve the uneven tension and ensure that both sides of slides run together. The most common type of tensioner is a spring that can be purchased at a hardware store. It generally will be placed at the end of the string run, near the part that extends farthest out from the robot's center. By doing so, the string will stretch out when the spool extends the arm, keeping tension so that the string does not detach from the pulleys in the linear slide extension.

Another form of tensioner can be a spring-loaded pulley. Since the pulley is spring-loaded, it will take up the slack in the string. Alternatively, it is possible to mount a pulley on a piece of extrusion, and slide it so the string is taut.

There are two main reasons that tensioners are highly recommended in string based linear slides, the first and oftentimes more important one is that at its core, a run of string is a series of polygons, and as the slide extends the effective size of that polygon changes. Meaning that when fully extended, your slide may require more or less string compared to when halfway extended. Or partially extended. The closer each set of bearings are, the less this impacts string tension.

Another (but less impactful) thing to keep in mind that spool size changes as string is added/removed from the spool. If the spool radius increases, the speed of the extension will also increase, and torque, which opposes speed, will decrease. Consequently, tension will change as well. Therefore, a bit of slack is inherent in all linear extension designs using string.

Attention: It is highly encouraged that teams have at least one spring tensioner per linear slide set.

(Figure: 13075 Coram Deo Robotics, Rover Ruckus, string tensioner)

Open Game Manual 0

Finite State Machines > Implementation > Useful Implementation

Game Manual 0·CC BY-NC 4.0

/*
 * Some declarations that are boilerplate are
 * skipped for the sake of brevity.
 * Since there are no real values to use, named constants will be used.
 */

@TeleOp(name="FSM Example")
public class FSMExample extends OpMode {
    // An Enum is used to represent lift states.
    // (This is one thing enums are designed to do)
    public enum LiftState {
        LIFT_START,
        LIFT_EXTEND,
        LIFT_DUMP,
        LIFT_RETRACT
    };

    // The liftState variable is declared out here
    // so its value persists between loop() calls
    LiftState liftState = LiftState.LIFT_START;

    // Some hardware access boilerplate; these would be initialized in init()
    // the lift motor, it's in RUN_TO_POSITION mode
    public DcMotorEx liftMotor;

    // the dump servo
    public Servo liftDump;
    // used with the dump servo, this will get covered in a bit
    ElapsedTime liftTimer = new ElapsedTime();

    final double DUMP_IDLE; // the idle position for the dump servo
    final double DUMP_DEPOSIT; // the dumping position for the dump servo

    // the amount of time the dump servo takes to activate in seconds
    final double DUMP_TIME;

    final int LIFT_LOW; // the low encoder position for the lift
    final int LIFT_HIGH; // the high encoder position for the lift

    public void init() {
        liftTimer.reset();

        // hardware initialization code goes here
        // this needs to correspond with the configuration used
        liftMotor = hardwareMap.get(DcMotorEx.class, "liftMotor");
        liftDump = hardwareMap.get(Servo.class, "liftDump");

        liftMotor.setTargetPosition(LIFT_LOW);
        liftMotor.setMode(DcMotor.RunMode.RUN_TO_POSITION);
    }

    public void loop() {
        liftMotor.setPower(1.0);

        switch (liftState) {
            case LIFT_START:
                // Waiting for some input
                if (gamepad1.x) {
                    // x is pressed, start extending
                    liftMotor.setTargetPosition(LIFT_HIGH);
                    liftState = LiftState.LIFT_EXTEND;
                }
                break;
            case LIFT_EXTEND:
                 // check if the lift has finished extending,
                 // otherwise do nothing.
                if (Math.abs(liftMotor.getCurrentPosition() - LIFT_HIGH) < 10) {
                    // our threshold is within
                    // 10 encoder ticks of our target.
                    // this is pretty arbitrary, and would have to be
                    // tweaked for each robot.

                    // set the lift dump to dump
                    liftDump.setTargetPosition(DUMP_DEPOSIT);

                    liftTimer.reset();
                    liftState = LiftState.LIFT_DUMP;
                }
                break;
            case LIFT_DUMP:
                if (liftTimer.seconds() >= DUMP_TIME) {
                    // The robot waited long enough, time to start
                    // retracting the lift
                    liftDump.setTargetPosition(DUMP_IDLE);
                    liftMotor.setTargetPosition(LIFT_LOW);
                    liftState = LiftState.LIFT_RETRACT;
                }
                break;
            case LIFT_RETRACT:
                if (Math.abs(liftMotor.getCurrentPosition() - LIFT_LOW) < 10) {
                    liftState = LiftState.LIFT_START;
                }
                break;
            default:
                 // should never be reached, as liftState should never be null
                 liftState = LiftState.LIFT_START;
        }

        // small optimization, instead of repeating ourselves in each
        // lift state case besides LIFT_START for the cancel action,
        // it's just handled here
        if (gamepad1.y && liftState != LiftState.LIFT_START) {
            liftState = LiftState.LIFT_START;
        }

        // mecanum drive code goes here
        // But since none of the stuff in the switch case stops
        // the robot, this will always run!
        updateDrive(gamepad1, gamepad2);
   }
}

Open Game Manual 0

Finite State Machines > Implementation > Useful Implementation

Game Manual 0·CC BY-NC 4.0

FSMs are the right tool to use when a robot needs to complete multiple tasks at once; a common example of this is when a robot should have automation in teleop, but still have control over the drivetrain.

Often times, teams have issues because their teleop executes in a loop and their servo logic has sleeps in it. But, we can avoid this if we write code in an asynchronous fashion - where instead of waiting for a task to complete before doing the next one, tasks are performed at the same time, and each task's state is checked without stopping the other tasks from executing.

An example of this would be that if one had a robot similar to Gluten Free's Rover Ruckus Robot (https://www.youtube.com/watch?v=NQvhvYJXVMA), and one wanted to automate the scoring lift so that the drivers don't have to think while the bot deposits the minerals. There are two parts of the bot that are relevant to us in this exercise: the angled scoring lift, and the servo that tips the dumper so the minerals fall out. The goal is to be able to push a button, and then the bot will:

extend the lift,
at full lift extension, angle the mineral bucket servo to deposit the minerals,
wait for the minerals to fall out,
reset the servo to the original position
retract the lift

If the drivers press a specific other button, we will stop executing the actions above as a failsafe - in case the robot is breaking somehow and the drivers need to take manual control. All the while, the drivers should still be able to control our drivetrain so we can make adjustments. Now, of course, this is a bit simplified (and probably not entirely what GF did), but it will do for now.

Before anything is programmed, it may be useful draw out the state diagram for this to get a better understanding of what we the robot should actually be doing. This can also add to a Control Award submission.

Notice how resetting the dump servo and retracting the lift share a state. That's because the robot doesn't need to wait for the servo to reset before moving the lift down; they can both happen at once.

Open Game Manual 0

Lifts | FTC Kickoff Concepts

This source does not publish a licence, so its text is not reproduced here. Open the source to read it.

Open REV Robotics Docs

Rigging > Retraction Options > Cascade Retraction

Game Manual 0·CC BY-NC 4.0

Cascade retraction entails simply rigging another set of cascade string that can retract the system when engaged (see the image below).

Note: If cascade retraction is being used with continuous extension, the two spools cannot be the same diameter. If the variable N is the number of stages in the system, the diameter of the continuous extension spool must be N times bigger than the cascade retraction spool.

Advantages:

Very space-efficient
All stages retract at the same speed at the same time

Disadvantages:

Requires more string (less strings to tension, less strings that can become loose)
Requires different sized spools if used with cascade extension

(Figure: Cascade retraction)

Additional Considerations:

If the system has only one stage, cascade rigging is identical to continuous rigging
Unlike continuous rigging, each time a new stage is added to a cascaded system, the gear ratio required to maintain the same extension speed increases. For instance, if 2 stages are added to a 1 stage cascaded lift that is geared at a ratio of 3:1, the ratio must increase by a factor of frac{2+1}{1} to maintain the same speed, changing the ratio to 9:1.
One disadvantage of cascade rigging is that each string must be kept tensioned. This is still the case with continuous rigging, but you have many more strings to keep track of, as tension must be maintained on all of them.

You need to make sure, as with any time you work with strings and pulleys, that you are pulling the string straight. Any amount of misalignment can lead to the string coming off of your pulley.

Open Game Manual 0

Kinematics > Manipulators

Game Manual 0·CC BY-NC 4.0

Often in FTC, teams have arms that swing out around an axis. Controlling these arms requires a bit of thought as depending on the angle they're at, the effect of gravity drastically changes.

Our first step is defining a reference frame. Our recommendation is to define zero as straight to the side, as this is when gravity has the greatest effect on your arm. Other reference frames will still work, but the exact trigonometry will change.

(Figure: 11329 I.C.E. Robotics)

In a reference frame like this, the relative force of gravity will be equal to the cos of the angle. This makes sense as when the cos function is evaluated at zero degrees, it returns 1, while at 90 degrees where there is no effect of gravity, it returns 0.

Fg = gcosθ

Assuming you have an encoder on your arm, you can find theta (the angle of the arm relative to the vertical) using something similar to the following pseudocode.

Note: DEGREE_PER_TICK can be found by taking 360 divided by your encoder resolution all multiplied by your gear ratio. For example, for a 19.2:1 goBILDA Yellow Jacket (https://www.gobilda.com/5203-series-yellow-jacket-planetary-gear-motor-19-2-1-ratio-24mm-length-8mm-rex-shaft-312-rpm-3-3-5v-encoder/), there are 537.7 ticks per revolution, and so frac{360}{537.7} degrees per tick at the gearbox output shaft. If there was a 2:1 gear ratio after that, then the ticks per revolution would instead be frac{360}{2 times 537.7}

current_angle = (TICKS_AT_ZERO - current_tick) * DEGREE_PER_TICK

The typical way to utilize the effect of gravity you just found, is to pass it in as a feedforward parameter to a PID controller. We cover this in gravity-compensated-feedforward.

Open Game Manual 0

Rigging > Belt-driven slides

Game Manual 0·CC BY-NC 4.0

One increasingly popular alternative to traditional string-based rigging is belt-driven slides. This can be done continuously or using cascade rigging.

Unlike string, belts used on slides never need to be tensioned. As discussed in the linear motion section, in order for string-driven slides to remain efficient, string tension must be maintained. Naturally, string loosens over time, so you either need a mechanism that can provide extra tension (a spring) or manually tighten string, which can get a bit tedious (especially for cascade rigging).

However, belts do not have this issue. They tend not to stretch over time, meaning complex external tensioners are rarely needed. Belts are also on an automatic one to one loop, meaning that for every inch you pull in on the extension side, you always feed back out that inch on the retraction side, and vice versa. While this might not seem like a big deal, if a string winds itself up on a spool and overlaps at any point, the diameter of the spool changes, making the two spools out of sync.

Open Game Manual 0

Chief Delphi > FTC > Multistage lift(ftc) project update

Chief Delphi·Community forum posts — not openly licensed

This source does not publish a licence, so its text is not reproduced here. Open the source to read it.

Open Chief Delphi