0

According to Official documentation of the Vex Bumper, it states that the bumpers will cause:

the robot sometimes [counts] a press twice. This issue is also caused by the robot counting too fast and as the limit switch is released, a second press is registered by the robot.

The documentation suggests this code:

task main() {
    while(true) {
         string presses = buttonPresses;
         if(presses != last) {
             writeDebugStreamLine(presses);
         }
         last = presses;

         if(SensorValue(bump) == 1) {
             wait1Msec(5);
             while(SensorValue(bump) == 1){}
             buttonPresses++;
         }
    }
}

However, if you are like me, this didn't work at all, multiple button presses were registered from holding down the button for a moment and releasing it.

Bennett Yeo
  • 133
  • 5

2 Answers2

0

Because this problem was so infuriating and strange, I managed to do a workaround which the program refused to take a sudden addition to button counts after taking a first one. This enabled me to use the button without multiple extra counts.

string last;
float buttonPresses = 0;
float time = time1[T1];
bool isFirstTime = true;

task main()
{
    ClearTimer(T1);
    clearDebugStream();
    while(SensorValue(go) != 1) {

        string presses = buttonPresses;
        if(presses != last) {
            writeDebugStreamLine(presses);
        }
        last = presses;

        if(SensorValue(bump) == 1 && buttonPresses < 6) {
            if(isFirstTime || time1[T1] - time > 50) {
                isFirstTime = false;
                wait1Msec(15);
                while(SensorValue(bump) == 1){time = time1[T1];}
                buttonPresses++;
            }
        }

    }
}

If you want extra probability against multiple extra "presses" you can widen the interval of tolerance (in this case the 50 value) to something larger, but it makes it less accurate at registering quick taps.

Bennett Yeo
  • 133
  • 5
0

When you are testing buttons within a loop that runs repeatedly, there's no need for lengthy monolithic delays like wait1Msec(15), and no need to store and test start times, like time = time1[T1] and time1[T1] - time > 50.

Instead, you can change your loop so it takes at least some small time (as via wait1Msec(1) in following code sample), and add a holdoff counter that inhibits sensor testing during probable bounce periods.

string last;
long bumpCount = 0;
byte holdoff=0, isbump=0;

task main() {
  while (SensorValue(go) != 1) {
    string presses = bumpCount;
    if(presses != last) {
      writeDebugStreamLine(presses);
    }
    last = presses;
    wait1Msec(1);
    if (holdoff) {      // Ignore bump sensor during holdoff
      --holdoff;
    } else {
      if (SensorValue(bump)) {
        if (isbump==0) {
          ++bumpCount;  // Count a new closure
          holdoff = 40; // Start a holdoff period
        }
        isbump = 1;     // We detected bump is on
      } else {
        isbump = 0;     // We detected bump is off
      }
    }
  }
}

The code shown above acts as follows:

• Initially, bumpCount, holdoff, and isbump are zero, to indicate we haven't counted any bumps, are not inhibiting bump sensing, and think the bump sensor is off.

• Under initial conditions and while the bump sensor is off, we will pass through the outer while loop, each time waiting a millisecond, then taking the else branch of if (holdoff) and the else branch of if (SensorValue(bump)), so will repeatedly set isbump = 0, thus maintaining initial conditions.

• When the bump sensor goes on, we take the first branch of if (SensorValue(bump)). From initial conditions, isbump==0 so we increment bumpCount and set holdoff = 40. Lastly, set isbump = 1 to reflect sensor state.

• During the next 40 milliseconds or so (that is, during the holdoff period) we repeatedly decrement holdoff, while ignoring the bump sensor, which may bounce a number of times or not, as it pleases, but we don't care.

• After the holdoff period, SensorValue(bump) may still be true. But since isbump==0 is false, we don't change bumpCount.

• If the bump sensor opens after the holdoff, isbump will go zero, restoring two of the initial conditions. If it opens during the holdoff and stays open, the same thing happens at the end of the holdoff.

James Waldby - jwpat7
  • 8,840
  • 3
  • 17
  • 32