Yesterday and today I have been working through some ‘issues’ with the wall-following robot. The darned thing insists on doing exactly what I tell it to do, rather than what I want it to, despite the liberal use of the RPM (Read Programmer’s Mind) command throughout the code. This time I had managed to make modifications to the left & right motor speeds in two different locations (instead of encapsulating all changes in one function), and used value/copy arguments instead of reference arguments in one place where refs were absolutely necessary.
Anyway, I got the ‘issues’ squared away, and then decided to make some ‘improvements’ (never a good thing!) by changing the distance acquisition code to use the NewPing library’s ‘ping_median()’ function. The ping_median() function makes a number (5 by default) of pings in quick succession and then ( after throwing out any out-of-range values) returns the median distance. I thought this might smooth things out a bit, but what it actually did was slow things down sufficiently so the robot quickly got outside the loop capture range and departed the area. One change that actually did improve things was to add some code in setup() to start the robot moving straight at low speed after acquiring an initial distance estimate (I did use the ping_median() function for this), as this reduced/eliminated startup divergences.
After making these changes, I ran some more wall-following tests, with some interesting results. On one test the robot ran off the end of the straight-wall test section (aka ‘Kitchen’) and onto the rug in our living room. On the rug sits a footstool with a round base. Watch the action :-).
So, at this point the robot is doing a fair job of following walls, although it still has a number of deficiencies that have to be addressed before it gets let loose in the wild to roam the hallways.
- Gaps give it fits. There is a gap of about 10-12cm between the fridge and the pantry wall in the kitchen, and when the robot gets to this spot, it invariably nose-dives right into it, as the distance measurement instantly increases a lot right there. I don’t really know if anything can be done about this, as this same behavior is what allows it to follow wall variations in the first place.
- After reversing the definition of ‘forward’ on the robot (see my earlier post), the ‘front’ ping sensor is actually mounted on the new ‘rear’. I still need to reposition it (or make that end the front again). I’m thinking seriously of repositioning the left and right ping sensors so they are on or near the line between wheel axles, to suppress/eliminate the mechanical element of the feedback the wall-following feedback loop. If I do that, then I can turn the robot around again, and not have to reposition the ‘front’ sensor.
- It still runs on non-rechargeable AA alkalyne batteries (I’ve got rechargeables on the way, but…). Even when I get rechargeables installed, I still have to figure out how to get the robot to charge itself.
Stay tuned! 😉