Last week we ran into the issue of how ROVer can recognize, and respond to, obstacles that he encounters that are not at right-angles to his chassis. I spent a bunch of time over the weekend thinking through different mounting options for either the forward Ultrasonic sensors or even relocating ROVer’s side IR sensors, but I came to the conclusion that it’s a problem that is best addressed in the future, after I have some more real-world testing under my belt.
So, for now, we left the sensors as they are and we’ll see how much of a problem this presents as we start with some dynamic sensor response testing in relation to an updated “Hallway” program that I put together in ROVer’s cloud-based Command Center. We don’t get far with the test that I had intended, but we do make progress in updating ROVer’s code to differentiate between certain sensor events as they relate to the programs and commands being executed.
Yesterday was ugly… I started the day out with the intention of modifying ROVer’s sensor-enhanced navigation and learned that his Ultrasonic Sensors weren’t operating properly… it took all-day to figure out, which is why there was no episode/update 🙁
I turned out that it was a baud rate-conflict of some sort that was throwing off the Ultrasonic sensors only …and.. on top of that… only at very close distances to the obstacle. They were still working, just not working well, which is why I didn’t notice until just then… when I needed them to work very well.
…of course, once I got past that… it got more complicated…
I had originally intended to let ROVer have another try at my hallway, but realized that he wasn’t yet ready.
We’ve got a lot of trial & error with respect to his Drive Settings before he’s ready to try the hallway again. Instead, we use a storage bin/box as a moveable obstacle that ROVer can crash into, over and over again, as we try and determine what distance, speed and acceleration work with the various turn maneuvers to result in the result we’re after.
Yesterday’s crash from ROVer’s 1st autonomous drive test sucked!
That being said, we did learn a bunch and I’ve been hunting through ROVer’s growing code to figure out what happened. As is to be expected, I found more than what I sought out to find, but at the end of this process will be stronger than ever 🙂
It turns out that the crash was not the result of a faulty sensor or anything like that; it was a confluence of factors as is usually the case. ROVer’s programming and hardware, combined, have a lot of ‘moving’ parts and any broken link in the chain will cause the whole thing to come apart – that’s what we saw yesterday.
After so many days of just programming and debugging I really wanted to share a drive test of ROVer’s new autonomous programming, but my rushed implementation of his new side-sensor logic was just that… rushed.
The side sensors kept on triggering for no apparent reason, which had ROVer performing irregularly and caused 2 crashes… one of them occurred with the cameras off, but it did happen. No damage, though… I think.
So… more debugging and troubleshooting in my near future, apparently. The nature of robotics – ain’t it grand! :p