Posted 04/22/15

In my last post, I showed some results from Wall-E’s EEPROM data captures, including a run where Wall-E got stuck on the wife’s evil stealth slippers – and then unexpectedly got ‘unstuck’.  I couldn’t explain Wall-E’s miraculous recovery from the captured EEPROM sensor data, so I was left with two equally unpalatable conclusions; either I didn’t understand Wall-E’s program, or Wall-E was ‘seeing’ something besides what was captured in the EEPROM.

So, I decided to modify Wall-E’s programming to capture additional data when/if Wall-E got stuck – and then unstuck – on future runs.  The mods were described in the last post, but basically the idea was to capture the contents of both the 50-point front and top front sensor data arrays, along with the current values of all four sensors.  To do this I re-purposed  the first 100  EEPROM locations to store the sensor array data, figuring that the earliest points would be the least likely to be relevant for post-run analysis.

After making the mods, and testing them on the bench in debug mode, I took Wall-E out for another field trial, hoping he would do the same thing as before – namely getting stuck and then un-stuck on/from the evil stealth slippers.

As it turned out, Wall-E’s next run produced good news and bad news. The good news is that Wall-E did indeed get stuck and then un-stuck, providing some very good decision data.  The bad news was that it got stuck on a coat rack leg (an easier problem for Wall-E) instead of the stealth slippers.  Still, it  did provide an excellent field validation of the new data collection scheme, as shown below.

Remaining EEPROM Contents at the point where Wall-E declares ‘Stuck’.

Top and Top Front Sensor Array Contents at the point where Wall-E declares ‘Stuck’

Analysis:

• T + 13:  Wall-E gets stuck on a coat rack leg.  He got stuck because I  hadn’t yet updated the left front bumper to the new non-stick style, but this was a good thing ;-).  Just before Wall-E hits the leg, the left sensor distance reading changes rapidly from about 40 cm to about 20, as the left sensor picks up the coat rack leg on its left.
• T + 13-15: Wall-E tries to drive around the coat rack leg it is stuck on, causing it to turn about 45 degrees to the left. During this period the right, front, and top-front sensor readings vary wildly, but the left sensor reading stays quite stable (almost certainly  reading the distance to the coat rack leg on the left).
• T + 16:  Wall-E has stopped moving, and consequently the top and top-front  sensor readings settle down.  Interestingly, the right distance sensor readings  don’t  settle down, even thought there are no obstacles within the max detection distance (200 cm) on that side – no idea why.
• T + 20: Wall-E declares the ‘stuck’ condition.  This is almost certainly due to  the total deviation of the current contents of  the front sensor reading arrays falling below the threshold (5 cm in this case).  From the data, the front sensor array deviation is 4 cm, while the top-front deviation is still high (161) due to a 209 value that hasn’t quite yet fallen off the end.

So, the captured for this run is entirely consistent with the stuck condition and recovery, with the possible exception of the anomalous right sensor readings that should show a constant 200 cm but doesn’t for some unknown reason.

Next up – another try at getting Wall-E stuck on the stealth slippers, with (hopefully) a ‘stuck’ condition’ detection to boot!

Stay tuned…

Frank