Our team is using sonic sensors for ball detection and serializing, but we started randomly having issues where it would think it collected two balls when we only had one. After some testing, we discovered that if you put your hand in front of the sensor and pulled it away, it would stop sensing after a delay, sometimes a second or more. We came back in today and the issue went away, but we don’t want it to happen at comp. Has anyone else had this and know a fix or at least know what the issue is?
WPILib polls ultrasonic sensors in a round-robin to make sure they don’t interfere with one another. This can cause very short spikes to be missed. This year we’ve also had issues with ultrasonic sensors, I suspect that the shape and density of CARGO this year makes ultrasonic sensors not very suitable for detecting this year’s CARGO, especially from more than a few centimeters. If someone has some proof/science in either direction, I’d be interested.
1 Like
Have you guys tried anything else that works well? Are the color sensors alone a suitable replacement?
My two go-to solutions:
Boolean proximity sensor - they’re adjustable for at what range they switch at. But they just hook up to a DIO, and simply tell you “yes a thing” or “No, no thing”. If you position and calibrate them right, you can detect the presence of a ball. We’re using two of them on our “hopper” thingy to detect when both storage positions have a ball in them.
In 2020, we used a time of flight sensor. It returns a “distance to target” measurement, rather than a digital true/false. This is nice to let you do two things:
- Tune the detection threshold of “ball present” in software
- Watch for peaks or valleys in the distance measurement signal to count balls as they pass.
2 Likes
We also used a REV color sensor to detect CARGO presence and color and it worked, but it can also miss quick changes. There is also the I2C issue that limits us to 1 sensor (we decided not to risk the onboard port or use a multiplexer/coprocessor).
There are many different types of sensors that could be used to detect whether or not a ball has been acquired. The performance you receive from any particular sensor can differ not only from type to type such as a proximity sensor, color sensor, IR sensor, etc. but also the model you get. If you are able to provide any specific part number or datasheet, the manufacturer usually will give you some key specifications that may help in troubleshooting.
In the real world - sensors NEVER work correctly. You have sensing response time. You have measurement variation. You have measurement variation confounded with battery voltage.
For instance, on an ultrasonic sensor, it will send back a series of readings. Usually these readings take time to reach the correct distance.
For instance, you might get:
Distance:
200
160
130
135
120
110
Where 200 is the ‘no object’ there number, and 110 being the ‘object there’ number. Note that if you were to graph this, it wouldn’t be smooth. It decreases to 130, jumps to 135, then goes back to decreasing.
This is common in the world of sensors, especialy voltage / current sensors. As a result, people apply different forms of ‘conditioning’ to the signal. You might average it. 3 sample average, 10 sample average, discard the high and low and 3 sample average. You might apply filters. You might apply hysteresis to the signal (which is often required for consistent operation).
A simple “is greater” or “is less” will result in multiple counts as you are seeing. Especially ultrasonic sensors, which are not really suited to part present measurements due to their latency, lag, and variance.
Even beam break and photo / IR sensors can struggle. We have a sensor pointing straight up - and when it is directly below our high intensity gym lamps it will flicker on and off. This is an expensive sensor with built it filtering, but we still have to apply hysteresis and timers to it to clean up the signal. In addition, the ‘fuzz’ and color on the balls make it react slightly differently to different balls.
Your hand is a ‘best case’ where you have a wall, then you don’t. Consider the ball almost a worse case, since it has a slanted surface and the angle of incidence of the ball changes as it moves past the sensor. The only way it could be harder was if it had holes.
For instance - when we count, we take a bunch of things into account. Was our conveyor moving the correct direction (we check the velocity). Did the sensor change from one loop to the next (we use hysteresis on the sensor signal, along with adjusting the sensor range). Did the next sensor down stream see a change as well. This series of cross-checks helps weed out the ‘wierdness’ you see in sensor measurements.
For instance, we use the color sensor, but we use it as a proximity sensor. We double check that we get either a red or blue color, or we ignore the sensor trip. We use hysteresis on the distance reported as well.
I realized since I used the term so much I should explain hysteresis.
Back to my example with distance, you’re going from 200 from 110. We would determine a threshold at the midpoint of the measurement. So 155. Then we would pick a tolerance. Let’s say 20.
So when the sensor is going from 110 to 200, it will flip when it passes 155, but it can see variations all the way back down to 135 without flipping back. Likewise, when the sensor is going the other way, from 200 to 110, when it passes 155 it will flip, but it can’t flip back unless it moves higher than 175.
This prevents sensor ‘flicker’ on and off.
A naive way to do this is to just set your code so it doesn’t change until it’s above 175 or below 135.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.