Where does time fly? Phase 2 Sac Area Robotics table top challenge completed!
To accomplish this I added more sensors to Zumo platform with the intent of using them each with single purposes; not great design but met goal and increase knowledge of different kinds of sensors - so its a WIN. Also I didn't want to modify the blade front of the bot.
Challenge 2 was to find a block, push it off table and not fall off (built upon prior challenge). The neat part was to see how other accomplished this. For example, my solution was brute force, another's was cartesian based (he shared his code, I am still digesting it...) and a Lego Mindstorm.
Sensors added: Maxbotix MB1010 (sonar), Sharp GP2Y0D810 (IR), 2x QTI (IR). With the exception of laser or radar I ended up with the several common non-contact object defection devices.
Why so many sensors? The problem was time to get it working -vs- brute force strategy -vs- minimum sensor distance reporting limitations. I didn't buy all of these sensors at once, more or less it was sensor creep as found the limitation of each sensor, I added another one to compensate.
The Maxbotix provides Sonar object detection with reported minimum measurement of 6in while providing distance from 6 to 200+. I could find the block and track it provided I was greater than 6 inches from it, getting closer than 6 it would appear to the block was missed (this is due in part to the angle I mounted it, is above angled down rather than straight on). Also if I had encoders and knew I was straight on I could find it then drive to it. However within 6 inches of travel, in testing depending on battery voltage the bot would head left or right and miss the block.
The Sharp sensors had an effective range down to ~.7 inches reporting True or False, no distance. When the Maxbotix reported 6 inch, the bot began tracking with the Sharp adjusting the motors to keep the object in sight. Again due to angle the object detection was clear if the bot had contact yet with the object.
The QTI sensors were downward facing just above the block. Once the bot touches the block the QTI sensors would detect it. I considered at contact sensors, given I didn't want to modify the front blade on the bot so the non-contact QTI worked well; also at this point I had QTIs already on hand, didn't have a suitable switch to use as a whisker contact.
The end result was a series of SPIN methods invoked each sensor depending on how far from the bot the block was. This worked with about 85% (WAG) reliability. Issues came up when other objects not on the table were detected - ie people.
I now have a variety of non-contact object detection sensors in my parts bin to play with in the future. Given that I found limitations while attempting to apply them, my future designs will perhaps take that into consideration...!?!