Cliff Sensors..... are there really good options?
photomankc
Posts: 943
So I have been pondering ways to keep my patrolling robot from taking a destructive excursion down the staircase it is blissfully ignorant of at present. Problem is that I see a lot of difficulties in making something that is both practical for a bot that has to navigate around cluttered space and reliable enough to trust that it really wont go over the edge even in a case where it has wedged itself into a fairly sizable navigation challenge near a "cliff".
So there is physical sensors: Some type of spring loaded feeler that makes or breaks contact if the floor moves away more than a preset amount. This seems the most straight-forward and least likely to false trip but also I see lots of issues. Tile -> carpet transitions for some plunger might lead to getting hung up and the same with any of the ever changing array of challenging terrain features my daughter leaves lying around. Wire feelers out in front/back could handle that more gracefully but I still see issues with them getting snagged on everything around. Some type of ski-foot on the plunger could help with transitions and uneven locations but then I have to listen to that drag around everywhere. Then if a plunger goes down over the edge... well... how do you retract it?
IR Distance / Prox: I could use the same sensors I use as short range collision detection in the opposite role. Failure to trigger the module indicates the floor has dropped away. In practice I have found the prox sensors to be noisy and far from ideal. They often fail to see certain surfaces in the house and I have had to debounce them heavily to keep false triggering at bay. This means that my sample rate is somewhat slow on them. Getting them mounted far enough ahead to be sure the wheel can't roll off the edge on an angle may be touchy as well. Using the IR distance sensor style might work but has the same issues in that avoiding false spikes in distance would likely mean averaging/filtering and that takes time and the wheels are moving right along.
Sonar: Can't see a practical way to do it. Can't be aimed down at an angle. I have found that hard surfaces that are struck at oblique angles are all but invisible to my bots sensors. It has a very difficult time in the painted concrete walls of my office because of that. Sticking two out to stare straight down is ugly and would need to be done pretty high off the floor to deal with minimum distances. Then that's two more sensors that must allow for 'quiet' time to not interfere with the other sonars. I don't see that as practical at all.
Then I got to thinking from another angle. So why engineer a solution to operating in random 'cliff' environments (tables, benches, other houses, ect.) when the plan is to operate in MY house with that one staircase? Perhaps it would be better to simply use an IR 'fence' there to mark that spot as a no-go area and simply place IR receivers on the nose and tail of the bot to pick that up. Not as clever/flexible as some other designs but also solves the problem without even more of battery chewing IR blasters or snagging, dragging physical floor sensors.
Am I missing any really cool mobile technology to prevent my bot from pulling a Thelma - Louise moment? Anyone had good luck in a home environment with some particular type of cliff sensor?
So there is physical sensors: Some type of spring loaded feeler that makes or breaks contact if the floor moves away more than a preset amount. This seems the most straight-forward and least likely to false trip but also I see lots of issues. Tile -> carpet transitions for some plunger might lead to getting hung up and the same with any of the ever changing array of challenging terrain features my daughter leaves lying around. Wire feelers out in front/back could handle that more gracefully but I still see issues with them getting snagged on everything around. Some type of ski-foot on the plunger could help with transitions and uneven locations but then I have to listen to that drag around everywhere. Then if a plunger goes down over the edge... well... how do you retract it?
IR Distance / Prox: I could use the same sensors I use as short range collision detection in the opposite role. Failure to trigger the module indicates the floor has dropped away. In practice I have found the prox sensors to be noisy and far from ideal. They often fail to see certain surfaces in the house and I have had to debounce them heavily to keep false triggering at bay. This means that my sample rate is somewhat slow on them. Getting them mounted far enough ahead to be sure the wheel can't roll off the edge on an angle may be touchy as well. Using the IR distance sensor style might work but has the same issues in that avoiding false spikes in distance would likely mean averaging/filtering and that takes time and the wheels are moving right along.
Sonar: Can't see a practical way to do it. Can't be aimed down at an angle. I have found that hard surfaces that are struck at oblique angles are all but invisible to my bots sensors. It has a very difficult time in the painted concrete walls of my office because of that. Sticking two out to stare straight down is ugly and would need to be done pretty high off the floor to deal with minimum distances. Then that's two more sensors that must allow for 'quiet' time to not interfere with the other sonars. I don't see that as practical at all.
Then I got to thinking from another angle. So why engineer a solution to operating in random 'cliff' environments (tables, benches, other houses, ect.) when the plan is to operate in MY house with that one staircase? Perhaps it would be better to simply use an IR 'fence' there to mark that spot as a no-go area and simply place IR receivers on the nose and tail of the bot to pick that up. Not as clever/flexible as some other designs but also solves the problem without even more of battery chewing IR blasters or snagging, dragging physical floor sensors.
Am I missing any really cool mobile technology to prevent my bot from pulling a Thelma - Louise moment? Anyone had good luck in a home environment with some particular type of cliff sensor?
Comments
I have another idea using capacitance based upon Theremin Vision. This was a product that sold a few years back, but no longer. Over in the Propeller forum I posted a video of a Propeller Theremin doing the same thing. I basically used a 555 timer with an antenna as a capacitor to control the frequency. When the ground falls away the oscillator changes its output frequency and the Propeller can measure it. Here's the thread :
http://forums.parallax.com/showthread.php?143135-Propeller-Chip-and-555-timer-make-a-Theremin
IR seems like a reasonable option but they are getting pricey for me in power. I guess I need some way to power down the IR subsystem if the bot isn't moving. The simple prox sensors are decent but they eat about ~5mA each. These would eat more since the little LED that indicates a prox detection would stay on all the time. I could remove that I suppose.
It uses a line following module to follow an edge.
For some projects, I have used IR rangers (like the Sharps), mounted higher on the platform, and aiming down at about 45 degrees. This lets me use the ranger as BOTH a "low object" and a cliff detector -- if the range is too far, it's a cliff, if the range is too short, it's a low object. Basically, the range has to be in the sweet spot. This is also nice because it gets around the limitation of these rangers, wherein objects that are very very close (< 4cm or so) register as "very far". In that case, a "low object" may give a false positive as a "cliff" but never a false negative.
There also the old trick from pre-electronic toys of having a gravity switch -- basically a wheel on a heavy wire that rolls on the floor, and falls further at an edge, either breaking/making contact to a switch. This might help with your concerns about a whisker tripping up on tile/carpet transitions and the like.
I like the IR distance sensor too. I was contemplating that but had read cautions about them being at an angle but in this case the real issue is sudden changes in distance not accuracy of the distance reading.
I'm new here.
I feel like an idiot asking this in the wrong place, but I have looked everywhere and couldn't find where to go to start a new thread.
Any help?
Hi, and welcome to the forum. When you are looking at the list of posts, click on the "+ Post New Thread" button in the upper left corner.
I don't know how I missed that.
Good day.
Is there some way to run your IR systems in a kind of duty mode? In other words, instead of having them operating continuously on, could you have them turn on for a few milliseconds, take a reading, then turn off for a few milliseconds, then turn on, etc. at such a rate that your bot would still be safe from driving over the edge? Unless your bot is zipping around at high speeds, I would think you could save power by operating the IR only periodically. I think a 50 per cent duty mode would save you roughly 50 per cent power for the IR systems.
For these purposes, I usually count "hits" during a 1ms emitter pulse and use a threshold (e.g., if the detector is sampled every 10us, I add up the number of samples during a 1ms emitter pulse; if the count is over 75% or so, it's definitely a "hit" -- this virtually guarantees no false positives nor negatives).
At these ranges, you can certainly run the IR led at very low current anyway, so power shouldn't be too much of an issue. If you use rangers, they can be power hungry, but in theory you could turn power them on and off with a transistor and pin. I would think there would be settling time, however, when the device is first powered up so, not sure what kind of sampliing rate you'll get.
I think that light conditions can confuse the IR sensors so it fails to see the cliff. I've had a few false positives too, but they're not as much of a concern.
Edit: Uploading now...
I think I have insight into how my edge detection fails. My motor driving code is running in one cog while the sensor code is running in another. I am using RC decay to measure the reading for four QTI like sensors. The darker the reflectance the longer the decay takes and I am doing it four times. On a dark side of the table it can take long enough that by the time the sensor cog realizes something is wrong the motor cog has sent the robot off the edge.
If I slow the bot down a bit and only check the outside QTI's then I would have more time for the motor cog to react. Conversely I think edge sensors should be digital using a comparator which should be much faster.
My experience is that a "cliff" will give you *very* long RC decay times -- when I use cliff detectors and RC decay, I generally choose an upper threshold for the RC time -- if the value exceeds that threshold, I treat it as a cliff and I terminate the state machine that is for the RC discharge (the state machine switches right back to charging up the cap for the next sampling cycle). I also choose R and C values that give very fast charge/discharge times. Not quite as accurate, but the thresholds are far enough apart that it doesn't matter, and the faster sampling is better -- for obvious reasons
Second, I ususally have code do the calibration and I set healthy thresholds for white/gray/black/infinite (paper, surface, black line, cliff). The code prompts the user to move the 'bot to different positions to take readings (including the cliff, where I hang robot over the edge). These values are used for comparison when reading the values returned by the sensor. It takes all the guess work out, and if you are ever using your 'bot in a different environment, there are no worries about "will this still be a line", "will this be a cliff", etc.
This is why I am not a fan of circuitry (nor code) that treats the sensor as purely digital -- you'd be surprised how much the threshold values can change from place to place. Especially the cliff -- I've found when using our demo table that the color of the floor, as well as the height to the floor, can influence what a "good" cliff reading is, so with firmware calibration, we can get good values painlessly at any time.
Third, a shroud or something around the sensor is really good -- especially if you have flourescent lights or really high UV light (like we do here at 5500 feet).
For others, I will offer one solution to a "trap" when testing cliff detection -- your instinct when testing will be to "catch" your 'bot from underneath if it might not stop at the edge of the surface. But your hands will fool the 'bot into thinking the surface continues, and it will just keep driving. Of course, you can catch it at that point, but it's not very test-worthy. The better method is to catch it from above, so you can see if the detection works but not let it crash to the floor. A string held in your hand and tied to the 'bot can be helpful too (like a safety harness). Foam padding or pillows on the floor around the test edge help also.
http://forums.parallax.com/showthread.php?142485-Sharp-Analog-Sensor-as-Digital-Proximity-Sensor&highlight=sharp+sensor+digital
With tracks I've had the nose go pretty far over and recover, as well as extend just off the edge and resist a lateral slide off the table. As a result I've been able to keep the sensors closer to the discussion bot.
Clappier Sensor lived in Riverside CA, and
Clod Sensor has lived in Seattle WA.
For cliff sensing the detector would remain on while the emitter takes samples intermittently. I'm going to guess the comparison between values would improve reliability.
My approach in firmware is usually to check for IR signal on the detector *before* emitting a pulse -- if there is other IR in the vicinity, the firmware waits until there's been about a 3ms blank period with no interference, then it emits the pulse (either to transmit comms to other 'bots or to do obstacle/cliff detection chores).
Of course, if you are getting consistent interference from high UV bright sunlight or fluoroescent bulbs, that's another story altogether...
I browsed your site and noted that transmitting ir data bits would also help eliminate noise.