Posted 29 August 2018
In my last post on this subject, I demonstrated Wall-E2’s new found ability to make heading-based turns instead of timing-based ones, making the turns much more terrain-independent. Unfortunately, as I continued to test this capability, it became clear that Wall-E2’s heading superpower wasn’t quite ready for prime time. Sometimes he turned 45 deg or even 180 deg when asked to do 90 – oops!
So, I went back to my small test setup – a spare Mega and a small solderless breadboard, as shown below, and started going through the problem slowly and methodically. Eventually I figured out that most of the problem was caused by the way I was retrieving yaw data from the Inversense MPU6050 (I have the DFRobots version). I had the module set up to produce interrupts at 20Hz, and the code was trying to keep up with that (unsuccessfully, as it turned out). Once I figured that out, I backed the code off to where it only checks for heading changes at a 10Hz rate, and things started working much better.
I also figured out that the algorithm I was using for detecting the desired heading was fatally flawed. I was trying to watch for the case where the current heading passed the target heading, but with all the special cases (both directions, the -180 – to – +180 cut, etc) I kept getting it wrong. I finally found this post that describes a very simple formula for comparing two compass headings. The formula assumes both values are in degrees in the range 0-360. Mine are in degrees but in the range -180 to +180, but I took care of that by adding 360 to negative headings. After some experimentation I settled on a match ratio of about 0.90 for the ‘slow down’ threshold, and 0.98 for ‘match’. The 0.98 threshold provides about a 6 degree error margin, which with 10 measurements/sec means that the robot would have to rotate more than 60 deg/sec to get through 6 deg between measurements. Experiments show that a 90 deg turn takes about 3 sec, meaning 30 deg/sec. So there should always be at least 2 measurements at 0.1sec/measurement in the 0.2 sec it takes the robot to rotate 6 deg – a 2/1 safety margin.
The short video clip below shows the robot doing a series of 180 deg K-turns, simulating an avoidance maneuver.
So, at this point I think I’m pretty much done with adding turn management capability to Wall-E2’s superpower repertoire; however, I still have to update Wall-E2’s operating system software to replace the current timed-turn routines with the new heading-based turn routines.
08 September 2018 Update:
In my current Wall-E2 OS, when the robot gets stuck or runs into an obstacle, it backs straight up, and makes a timed turn away from the nearest wall if there is one, otherwise it turns the opposite way it did from the last time it was in a similar situation. This is all fine and good, but now that Wall-E2 has heading-aware turn capability, he should be able to respond a little more intelligently. As indicated in the diagram below, the idea is that Wall-E2 could back straight up from an obstacle, and then go around it by making two linked 45-90º turns one way or the other (away from the nearest wall if there is one.
As an experiment, I programmed this maneuver into Wall-E2 using linked 45º degree turns, just to see how it would work out. As the following short video shows, it seems to work very well.