my lift keeps falling down when I let go of the stick

To prevent a lift from falling, a motor can be programmed to run to and hold a specific position using RUN_TO_POSITION mode . This mode tells the motor to move to a target position, specified in ticks, and uses a PID loop to control the motor's position .

To implement this:

Set the desired target position as an integer using motor.setTargetPosition(desiredPosition) .
Then, set the motor's run mode to DcMotor.RunMode.RUN_TO_POSITION .
The maximum power the motor can use to reach or hold this position can be set with motor.setPower(0.5) (using 0.5 as an example) .

Was this right?

Sources6

Gamepad Usage > Boolean Inputs > Falling Edge Detector

Game Manual 0·CC BY-NC 4.0

A very similar technique is a falling edge detector. It allows code to be run only once when the button is released, as opposed to every loop while it is held down. It works by checking that the button is currently not pressed, but was pressed in the previous loop. For example, inside of a TeleOp loop:

if (!currentGamepad1.b && previousGamepad1.b) {
    servo.setPosition(servo.getPosition() - 0.1);
}

This will decrease the servo position by 0.1 exactly once per release of b.

Note: One button can run different code on the rising and falling edge. This is mainly useful for fairly complex interactions and so is not demonstrated here.

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

Dead Wheels > Design > Spring Tensioning

Game Manual 0·CC BY-NC 4.0

It is highly recommended that your dead wheel design includes some form of spring tensioning that pushes the wheel into the ground. This ensures that the wheel is always in contact with ground and has adequate traction. Sufficient force is required to ensure constant traction to prevent the wheels from slipping. Keep in mind that too much force may lift a light drive train off the ground and disrupt driving.

The most popular method of spring tensioning is to pivot your pod around a point and provide a rotational force via a spring or rubber band.

(Figure: FTC 14320's spring tensioning)

A much more niche option is to vertically spring odometry pods. The idea is that springing around a pivot will cause the dead wheels to move in the axis parallel to the ground if the height of the dead wheels relative to the ground changes. Vertically sprung odometry pods will not experience such an issue. However, this is not really an issue that most teams will experience. Vertically springing is much harder to design well and is not recommended for the relatively minor improvement in accuracy it yields.

(Figure: FTC 18172's vertical springing)

Open Game Manual 0

Mecanum TeleOp > Deriving Mecanum Control Equations

Game Manual 0·CC BY-NC 4.0

Before thinking about mecanum, envision a scenario where you have a 2 motor tank drivetrain which you want to control using the left stick Y axis for forward/backward movement, and the right stick X axis for pivot turning. The motors are configured so that positive is clockwise for the right motor when the body is facing away from you, and the left motor is the opposite. To control only forward/backward movement, you simply need to set the motor powers to the Y stick value (flip the sign since Y is reversed):

Java

double y = -gamepad1.left_stick_y; // Remember, Y stick is reversed!

leftMotor.setPower(y);
rightMotor.setPower(y);

Although at first adding rotation might seem like a difficult task, it's actually super simple. All you need to do is subtract the right X stick value from the right wheels, and add it to the left:

Java

double y = -gamepad1.left_stick_y; // Remember, Y stick is reversed!
double rx = gamepad1.right_stick_x;

leftMotor.setPower(y + rx);
rightMotor.setPower(y - rx);

Here, if the left stick is pressed upwards, both of the motors will be fed a positive value, causing the robot to move forward. If it is pressed downwards, both of the motors will be fed a negative value, causing the robot to move backwards. A similar principle applies for rotation: if the right stick is pushed rightward, the left wheels will spin forward while the right spin backward, causing rotation. The opposite applies for pushing the stick left. If both sticks are pushed at the same time, say the left Y stick is at 1 and the right X stick is also at 1, the value of the left wheels will be 1+1=2 (which gets clipped to 1 in the SDK) and the right wheels will be 1-1=0, which causes a rightward curve.

Applying omnidirectional movement with mecanum wheels operates under the same principle as adding turning into the tank example. The left stick X values will be added or subtracted to each wheel depending on how that wheel needs to rotate to get the desired movement. The only difference from turning is that rather than wheels on the same side being the same sign, wheels diagonal to each other will be the same sign.

Open Game Manual 0

Shaft Retention

Game Manual 0·CC BY-NC 4.0

If you are powering any mechanism with a live axle system, you will need a way to retain the shaft so that it does not move axially (along its length). It is necessary to constrain movement in both directions, and two methods can be mixed and matched on one shaft. Generally, this is done by having something contact the bearing's inner race that is constrained axially on the shaft. It is important to make sure the bearings themselves are also constrained.

Note: Make sure to use an appropriately sized shim/washer between the thing retaining the shaft and the bearing, such that it only touches the bearings inner race. Otherwise, the rubbing will lead to inefficiency.

Outlined below are some common methods FTC teams use for shaft retention.

Open Game Manual 0

Encoders > Programming Encoders > Running Motors With Encoders

Game Manual 0·CC BY-NC 4.0

We've learned how to read encoder values, but how do you set where you want to go and tell the motor to go there?

Earlier, we learned about the RUN_WITHOUT_ENCODER mode for the motor. We can use another motor mode, RUN_TO_POSITION, to tell the motor to run to a specific position in ticks, like so:

Java

DcMotor motor = hardwareMap.dcmotor.get("Arm Motor");
motor.setMode(DcMotor.RunMode.RUN_TO_POSITION); // Tells the motor to run to the specific position

Tip: You can find out more about run modes at the official REV Robotics Documentation page (https://docs.revrobotics.com/duo-control/programming/using-encoder-feedback)

However, before we tell the motor to go to a position, we have to tell the motor what position to run to. Note that this value must be an integer. Let's amend the above code to do that.

Warning: Setting the motor to RUN_TO_POSITION mode before setting a target position will throw an error. Be careful not to do that!

Java

DcMotor motor = hardwareMap.dcmotor.get("Arm Motor");
int desiredPosition = 1000; // The position (in ticks) that you want the motor to move to
motor.setTargetPosition(desiredPosition); // Tells the motor that the position it should go to is desiredPosition
motor.setMode(DcMotor.RunMode.RUN_TO_POSITION);

This code tells the motor to move to 1000 ticks, using a PID loop to control the motor's position. You can read more about PID loops here. (https://gm0.org/en/latest/docs/software/concepts/control-loops.html#pid)

We can cap the speed that the motor runs at using the following code:

Java

DcMotor motor = hardwareMap.dcmotor.get("Arm Motor");
int desiredPosition = 1000; // The position (in ticks) that you want the motor to move to
motor.setTargetPosition(desiredPosition); // Tells the motor that the position it should go to is desiredPosition
motor.setMode(DcMotor.RunMode.RUN_TO_POSITION);
motor.setPower(0.5); // Sets the maximum power that the motor can go at

Now, let's use this information to control an arm in an OpMode.

Java

Open Game Manual 0