user9842: I just watched this excellent video tutorial that shows a simple Arduino program that toggles an LED via a pushbutton. Very cool!
Being brand new to electronics/robotics, I was shocked that something as simple as a pushbutton required his debounce behavior. That's something I would have never thought about in a million years. What is the 'rule of thumb' for when this type of debounce behavior (regardless of what sensor we're talking about, pushbutton or otherwise) must be accounted for? Is it simply that any type of analog sensor can generate this kind of unexpected 'noise'?
Can someone provide other examples for when special code must be put in place to accommodate unexpected sensor noise?

user368: Switch bounce is a physical issue that can be cleaned up with filtering. Since the sense states are very simple, only very crude (time-based) filtering is required to clean up its signal.
Other mechanical sensors that can exhibit similar characteristics are bump sensors, tilt sensors, and accelerometers. Bump and tilt sensors are also very simple, and similar filtering will clean up their signals.
Accelerometers on the other hand react to very minute perturbations, so they may require more advanced filtering based on the application they will be used in; orientation sensing can use time-based filtering, whereas things such as motion tracking including dead reckoning will require one or more layers of calculus in order to clean up the signal.

9842: <p>I just watched this <a href="https://www.youtube.com/watch?v=_LCCGFSMOr4" rel="nofollow">excellent video tutorial</a> that shows a simple Arduino program that toggles an LED via a pushbutton. Very cool!</p>

<p>Being brand new to electronics/robotics, I was shocked that something as simple as a pushbutton required his <code>debounce</code> behavior. That's something I would have never thought about in a million years. What is the 'rule of thumb' for when this type of <code>debounce</code> behavior (regardless of what sensor we're talking about, pushbutton or otherwise) must be accounted for? Is it simply that any type of <em>analog sensor</em> can generate this kind of unexpected 'noise'?</p>

<p>Can someone provide other examples for when special code must be put in place to accommodate unexpected sensor noise?</p>
 368: <p>Switch bounce is a physical issue that can be cleaned up with filtering. Since the sense states are very simple, only very crude (time-based) filtering is required to clean up its signal.</p>

<p>Other mechanical sensors that can exhibit similar characteristics are bump sensors, tilt sensors, and accelerometers. Bump and tilt sensors are also very simple, and similar filtering will clean up their signals.</p>

<p>Accelerometers on the other hand react to very minute perturbations, so they may require more advanced filtering based on the application they will be used in; orientation sensing can use time-based filtering, whereas things such as motion tracking including dead reckoning will require one or more layers of calculus in order to clean up the signal.</p>
