Sensors: Touch vs Gyro

VEX IQ General Discussion IQ Technical Discussion
1

Our team has been working on a redesign (yes, Worlds is less than 16 days away)…they kept their existing robot which qualified them for Worlds.

Anyway…they want to use a sensor to make sure the arm/scoop stops at the correct angle. If you were going to guide a team at this would you use the touch or the gyro sensor?

We have basically zero sensor experience.

2

Erica,

There are several ways to do this.

  1. The Gyro COULD be used for detecting the angle. It would be hard to use, and not have many benefits.
  2. A light sensor can be used with a gradient wheel. Again, a bit tricky to use.
  3. A Touch sensor could tell when the arm is at the top, or bottom, but it can sometimes be hard to get the sensor in exactly the right place.
  4. One easy option is to use the motor encoder.

Assuming the arm always starts in the same position when it’s down (when they start the program), and when the arm is all the way up, it may go to 500 (for example), the program would be something like this psudo-code:

if (Left_Up_Button=pressed and motorEncoder < 500)
ArmMotor speed = 100
else if (Left_Down_Button=pressed and motorEncoder > 0)
ArmMotor speed = - 100 //this number could be smaller, because the arm will come down quickly
else
ArmMotor speed = 0 // stop motor

If you really want to use a mechanical sensor, use the bump sensor. But, assuming they have the new robot built, they can use this without even attaching another sensor.

Hope that helps
Steve

3

Definitely use the motor encoders for this, they are ideal. Just remember to set a datum point at the very start of the program (e.g. move the arm all the way to the lowest extreme of travel and then reset the encoder)
I always use the current feedback for this purpose.
What programming language are you using?

4

I second bumper sensor.

        while (bumper value == 0) motor speed = 100;
        motor speed = 0;
5

Touch for sure. Out team uses this for up and down position as well as a physical “hard stop” which has some advantages this year when it comes to making sure you stay within the size limits at all times.

6

I should clarify, we are trying to do this for use when they are using the remote control. I like the idea of the motor encoder. Trying that but running into difficulty.

7

Also, we are using RobotC.

8

Some actual RobotC code:

if ((getJoystickValue(BtnRUp) == 1) && (getMotorEncoder(ArmR1) <= 710))
{
setMultipleMotors(100, ArmR1, ArmR2, ArmL1, ArmL2);
} else {
if ((getJoystickValue(BtnRDown) == 1) && (getMotorEncoder(ArmR1) > 0))
{
setMultipleMotors(-100, ArmR1, ArmR2, ArmL1, ArmL2);
} else {
stopMultipleMotors(ArmR1, ArmR2, ArmL1, ArmL2);
}
}

9

A common pitfall of using the motor encoder limiting the arm movement, especially with some kind of heavily geared strong arm (cough high dumper cough) is both the plastic flexing, axle twisting and the gear wear and tear. That square hole in a large plastic gear won’t be square for long in such a scenario and I have seen few teams relying on the software limit that had to tune their stop values mid-day on a tournament.
This effect is not as bad if the force on the gears stay pulling to the same side all the time, but becomes especially pronounced if your arm crosses the upper dead centre (cough high dumper cough), where the gravity starts abruptly pulling to the other side.
Worse yet, as soon as the tolerance builds up, crossing the upper dead centre causes bigger impact of the rotating axle on the hub, speeding up the wear.
So if your student’s design is anything like that, I would strongly suggest a mechanical hard stop and preferably a bumper sensor too.