What beam break sensors are folks using currently? Do you like them?
We’ve used these Banner QS18VN6LV sensors in the past on robots though have noticed some smaller and more compact versions on robots recently. Another bonus might be sensors that can operate at 5V, though I’d expect most industrial parts will be similarly 12-24V-range.
We use automation direct rectangular beam break sensors. They are pricey at around $66 per pair, but then again we’re using the same ones we’ve been using since 2012, passing them along robot to robot.
We had some issues with those due to some arena lighting emitting IR light, causing our intake to not work at all at the beginning of the Colorado regional.
Personally, we’ve tried many, many, many kinds of sensors. There are always problems with sensors except “Through-Beam” or “Beam Break Sensors”. These type of sensors always work for the game piece, but require you to mount an emitter body and right across from it a receiver body. I would typically recommend Banner for quality reasons. Also Banner has many options depending on your needs, like sensitivity adjustment.
If you use any other sensor, it’s always flaking out for some reason or other…colors, shiny surface, glossy surface, etc…Thru Beam, ALWAYS works, so long as it’s not a translucent game piece, which we have not had. The recommendation below is for a 20 meter sense range, they make a 3 meter sense range, but finding stock on that is tougher. Below are some links and documents to help you see part numbers and a general direction.
We’ve used these in the past and loved them. Excellent for the price. The 3mm version is great, too, if the gap is 10" or less (they were perfect in 2020).
After trying the Adafruit IR sensors last year and having issues with false triggers due to arena lighting, we switched to Playing With Fusion’s Time of Flight sensors and using the distance reading to perform a basic present / not present detection. They are accessible via CAN which is nice, and we did not have any problems from ambient light like we had with the IR-based sensors. Highly recommend
For these sensors by themselves, they’re definitely picky to IR in venue lighting as mentioned.
We’ve found that embedding them in printed hoods (that also take care of the mounting & cable management) tends to eliminate most interference issues outside of direct sunlight… in the morning shining through venue windows in the pits… right down the hoods
We’ve competed under some intense arena lighting before and haven’t seen issues, but it’s not a 100% guarantee as light can always make it to places you don’t expect. However for us the hoods have made them a reliable, cheap, and lightweight solution over the past 2 years.
We use them to trigger or halt robot motion (as a limit switch input on the spark maxes typically).
Very helpful this year to not stall motors with game-pieces in your intake like shown - for last year we used them to trigger the indexer state machine for cargo handling.
If anyone wants the model they’re in our 2022 CAD, PN 2301 ^,^
We also use these, they work great and are inexpensive. Sometimes you need to sharpie around the outside of the sensor to prevent issues from ambient light.
Have also use the Time of Flight from Playing with Fusion on multiple robots, it also works great.
Yes. Power from 12V, preferably something regulated to stay above 10V or you might have to do some brownout filtering. Specific (DIO <9…0> on the DIO port, CS <3…0> on the SPI port, and DIO <13…0> on the MXP) ports on the RoboRio have the pull-up resistor you need already on the board to sense an NPN (switched to GND) signal.
We made this Rio-sized proto board to make it easier to wire these circuits on demand. Now that I’m looking at it I realize there’s no picture in the repo.
Wow lots of great ideas in this thread. Thank you all!
We’ve heard of the CANController Area Network ToF sensor and thought about picking some up. Definitely will based on the reviews.
This is a really interesting idea to feed an IR sensor into a CANController Area Network motor controller, effectively making the digital input a remote CANController Area Network device. I could see applications both using the HW limits enabled and also SW querying the limit state only. 12V already exists over at the motor controller.
Yes the RoboRio signal GND and power GND shared with the rest of the robot are effectively the same. Unfortunately, the RoboRio does not have a 12V sensor power source. I suppose you could boost it up from 12V (say with a small Pololu regulator), which is sounding more reasonable now that you mention this concern. This split wiring is part of the reason I posted here to see if there are any plug-and-play solutions now.
If you’re worried about individual rails from the PDP/PDH having small differences or bounces, it seems possible though likely isn’t a huge concern (at 12V power / 3.3V signalling) as long as you’re using different connections off the PDP/PDH for controls and motors. There is some kind of sensing and filtering per rail to log this data to CAN, though I don’t know what the mechanism (high side or low side or hall effect) is.
Honestly, if you have the time I think you should go a different route for ToF sensors.
You can get a good number of ToF sensors off various hobbyist electronics sites (Adafruit, Sparkfun, Pololu)* which use the same STM sensor or even more capable, for cheaper. Also not on the CANbus which for me is a plus for things other than ESCs.
Note that you’ll need an I2C bus on the robot as well as a C library (which I guarantee doesn’t play well with the WPI/NI HAL. Not to mention I2C on-Rio is essentially completely broken.)
We originally put a microcontroller on our 2023 bot just for driving these sensors, but that got expanded to driving LEDs and other sensors as the electrical design was fleshed out. Unfortunately they didn’t make it in time for competition but we’re spending offseason time fully maturing this.
*I’ve noticed that PWF also basically sells one of these higher-end sensors, with a nice-looking enclosure, for a comparable price.
We had the same problem with the Hiletgo infrared sensors when the sensitivity was turned all the way down so the sensing distance is around 2-3 inches. It stopped “seeing through the cube” when the sensitivity was turned up to around 6-7 inches.