LimitSwitch as Command Button

[notmattlythgoe]

Originally Posted by Joe Ross

That is designed for a driver station digital i/o, not on the robot. To do it on the robot, it would not be hard to create a class to extend Button that reads from a digital i/o on the robot. Alternately, you could create an InternalButton object and periodically call the setPressed method with the state of the limit switch.

My only worry is getting multiple triggers with one press from noise on the channel. We're trying to implement a frisbee counter that count frisbees coming in and leaving the robot. We tried using the Counter class, but we kept getting random increases in the count from the limit switches. I'm assuming there was noise as the switch was pressed which made it think that there were multiple presses.

[BigJ]

Whoops, my bad. Yeah you should be able to extend Button then and use your own like Joe said. If you only want one activation in a certain amount of time you could make a Timer object internal to your class to make sure only one activation happens per amount of time.

[Joe Ross]

Originally Posted by notmattlythgoe

My only worry is getting multiple triggers with one press from noise on the channel. We're trying to implement a frisbee counter that count frisbees coming in and leaving the robot. We tried using the Counter class, but we kept getting random increases in the count from the limit switches. I'm assuming there was noise as the switch was pressed which made it think that there were multiple presses.

The counter class acts as an interrupt and counts every single edge of the switch bounce, which isn't what you want.

The simplest method for dealing with switch bounce is to poll the switch slower then the duration of the switch bounce. This works as long as the process actuating the switch is "slow", which my guess is that a frisbee counter is. For example, if the switch bounces for 10ms, polling it every 20ms will give you at worst one reading during switch bounce. If you happen to sample low during the bounce, you're reading of the switch will be delayed 20ms (the next sample will be high). If you happen to sample high during the switch bounce, you will react immediately (and the next sample will be high). If you extend button to read the switch, it would automatically get called at 20ms.

The following paper has lots of examples of switch bounce, as well as examples of both hardware and software debouncing, if you determine you do need to debounce. http://www.eng.utah.edu/~cs5780/debouncing.pdf

If you extend Button, you could implement your debouncing algorithm in get method.

[notmattlythgoe]

Originally Posted by Joe Ross

The counter class acts as an interrupt and counts every single edge of the switch bounce, which isn't what you want.

The simplest method for dealing with switch bounce is to poll the switch slower then the duration of the switch bounce. This works as long as the process actuating the switch is "slow", which my guess is that a frisbee counter is. For example, if the switch bounces for 10ms, polling it every 20ms will give you at worst one reading during switch bounce. If you happen to sample low during the bounce, you're reading of the switch will be delayed 20ms (the next sample will be high). If you happen to sample high during the switch bounce, you will react immediately (and the next sample will be high). If you extend button to read the switch, it would automatically get called at 20ms.

The following paper has lots of examples of switch bounce, as well as examples of both hardware and software debouncing, if you determine you do need to debounce. http://www.eng.utah.edu/~cs5780/debouncing.pdf

If you extend Button, you could implement your debouncing algorithm in get method.

You can set the Counter class up to only read the leading or trailing edges, so that isn't a worry. We'll probably end up extending the Button class and doing it that way. We might end up with IR pairs as the counters so the Button class would give us the most flexibility. Thanks for the info.

[notmattlythgoe]

Thanks guys, overriding the Button class worked great, and there was no bouncing at all. The thread must process slower than the bounce happens so we didn't have to worry about it.

[gixxy]

It is quite easy actually. You just extend Button and implement your own get() method to return the limit switch input. Add your own debouncing and you are good.

Here is my code (I haven't implemented any debouncing)

/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */
package edu.wpi.first.frc3946.MyTest;

import edu.wpi.first.wpilibj.DigitalInput;
import edu.wpi.first.wpilibj.buttons.Button;

/**
 *
 * @author Gustave Michel
 */
public class IOButton extends Button {
    DigitalInput button;
    
    public IOButton(int port) {
        button = new DigitalInput(port);
    }
    
    public boolean get() {
        return button.get();
    }
    
}