Posted 04/01/2015 (not an April fool’s joke!)

As I mentioned in my last post (Baby Gets a New Bumper) one of the outstanding issues with the robot is that it still gets stuck when it runs into something that is too low (like the feet of our coat rack or my wife’s slippers) to trigger the front sensor obstacle avoidance routine.  It then sits there, spinning it’s wheels fruitlessly, forever (or until someone takes pity on it and waves a foot in front of its front ping sensor).

The current obstacle detection  scheme is simply to monitor the front ping sensor distance readings and trigger the avoidance routine whenever the front distance falls below a set threshold.   Unfortunately there are some configurations like the ones mentioned above where this detection scheme fails.

So, the idea is to enhance this with an algorithm that detects the situation where the wheels are still engaged, but the robot isn’t moving.  So, how to detect “isn’t moving”?  If the robot isn’t moving, then subsequent distances reported by  any of the ping sensors will be the same, so that might work.  I actually used this algorithm initially for obstacle detection avoidance by comparing adjacent front ping sensor distance measurements. The idea was that if adjacent measurements matched, the robot was stuck.  However, I soon found at least two significant issues with this algorithm:

• Ping sensors report a distance of zero whenever the actual distance is beyond the max detection range (set to 200 cm for my robot), so the obstacle detection scheme would trigger when there was nothing ahead at all.
• It is quite possible for the reported distance to change 1 or 2 units either way, just due to round-off/truncation errors, so just comparing two adjacent measurements will be error-prone.

I can address the first of the issues above by using all three sensors, on the theory that the robot can’t be 200 cm from all three sensors at the same time (and if it  is, it needs to go somewhere else anyway!).  Unfortunately, this will require three times the work, but oh well ;-).

The second issue can be addressed with some sort of filtering/averaging scheme, which pretty much by definition implies some sort of multi-reading state memory and associated management code for each of the three sensors.  Fortunately my recent timing study revealed that the time required for the current movement/detection/movement code is insignificant compared to the delays inherent in the ping sensors themselves, so the additional time required to implement a more sophisticated ‘stuck’ detection scheme shouldn’t be a problem.

So, what about ‘stuck’ detection and filtering?  Assume we want to detect the ‘stuck’ condition within a few seconds of its occurrence (say 5?), and that each sensor is reporting about 20-50 readings per second.  So, 5 seconds worth of readings at 50 readings/sec is 250 readings.  Times 3 sensors is 750 readings, assuming I want to store the entire 5 seconds for all three sensors.

750 readings means 750 short integers (the distance range is 0-200 cm, which I should be able to store in an 8-bit unsigned short int), which should translate to just 750 bytes in RAM.  The Arduino Uno I’m using has 2048 bytes of RAM, of which I am currently using only 246 bytes.  So, I should have plenty of RAM space, assuming nothing in my code makes the stack grow too much.

Another way to skin the cat might be to just store the 5 second running average differential for each sensor, on the theory that the average differential would be some non-zero value while the robot is actually moving, but would trend to zero if it grinds to a halt somewhere.  Have to think about how I would actually implement that…..

The central problem here is how to differentiate the ‘stuck’ condition from one where the robot is following a wall as normal, with no other wall or forward obstacle within range, or no forward obstacle but the ‘other’ wall is a constant distance away (a hallway, for example).  In both of these cases, all three ping sensors could, conceivably, report constant values (distance to left wall, distance to right wall, distance to forward obstacle).  IOW, holding a constant position with respect to both walls and having no forward obstacle would be indistinguishable from the ‘stuck’ condition.  The good news here is that even the best that Wall-E can do in terms of wall following involves a lot of back-and-forth ‘hunting’ movements, so there should be enough  short term variation in the left/right distances to distinguish active wall following from the ‘stuck’ state.  The bad news is that since the variation is cyclic, it is possible to select a period such that the short term variation gets aliased (or averaged) out – resulting in false positives.

Looking at the most recent video  of Wall-E in action (see below), it appears the ‘hunting’ motion has a period of  about 1 second, which would indicate the best time frame for distinguishing ‘stuck’ from ‘active’.  So, if I store measurements for about 1 second (i.e. about 20 – 50 measurements) from all three sensors, then the ‘active’ condition should show a full cycle of ‘hunting’ behavior from the left and/or right sensors, while the ‘stuck’ condition should have little/no variation across that time frame.  The forward sensor won’t show the ‘hunting’ behavior in ‘active’ mode, but it  should show either 0 (no obstacle within range) or a constantly declining value as an obstacle is approached.  For the forward sensor, there is no way to distinguish  the ‘stuck’ condition from the ‘active’ condition with no obstacle in range- oh well.

So, I think I’m getting a feel for the algorithm.  Set up an array of distance readings for the left, right and front sensors sufficient to hold about one second of readings each.  Each time through the movement loop, calculate the max deviation from one end of each  array to the other.  If the deviation for all three  arrays is below some threshold, declare the ‘stuck’ condition.

Next up – implementation and testing.

Frank

Posted 03/30/15:

Now that the robot is starting to achieve real wall following more times than not, I’ve decided to address a serious robot  personality issue; my robot  loves chair legs!  If Wall-E gets within a meter or so of any chair in the house, it immediately hugs one leg between one side or the other of the chassis and that side’s wheel.  This causes the robot to go around and around the chair leg (or just spin it’s wheels in place), basically forever.  As you might understand, this is less than optimal performance from my point of view, regardless of Wall-E’s obsession with chair legs.

So, I’ve decided that Wall-E needs a bumper or fairing to keep chair legs from getting caught between the chassis and a wheel, as shown in the following photos and video.

Wall-E stuck on a chair leg. Note the blurring of the wheel spokes as Wall-E churns away to no effect!

So, after some quality time in  TinkerCad (and one failed version), I came up with a bumper design that doesn’t interfere with the current left/right ping sensor mounting, and seems to keep Wall-E from getting stuck on chair legs.  The photos below show the right side bumper – the left side is a simple mirror image.

Front oblique view of Baby’s new bumpers

Top view of Baby’s new bumpers

At this point, Wall-E is starting to mature as an autonomous wall-following robot.  There are still at least two significant problems that need to be addressed

• Wall-E still gets stuck – even with the new bumpers.  Not as often, but still…  I think I’ll need to develop a secondary ‘stuck state’ detection algorithm, maybe based on all three (left/right/forward) sensor distances remaining fixed for some period of time.
• The little plastic castering nose wheel collects lint and cat fur like crazy, and soon has enough stuff wound around its axle to make it more of a castering skid than a wheel.  I don’t really have any good ideas about addressing this, short of replacing it with something else entirely.  That will be a major PITA, as I built the charging platform  around the nose wheel mount.

Stay tuned!

Frank

Posted 3/25/2015

After a very enjoyable time with my grandson and his family (see  or this) , plus a not-so-enjoyable bout with the flu, it’s time to once again visit Wall-E’s wall following performance.

In the last post I moved the left and right ping sensors from their previous position well forward of the drive wheels to a position right over the axis of rotation, thinking that might allow for smoother wall-following.  What I found instead was that performance was severely degraded, to the point where Wall-E was more a wall-banging robot than a wall-following one ;-).

So, back  to the drawing board.  With the sensors themselves restored to their former positions, I decided to take another look at the wheel speed adjustment algorithm.  Wheel speed values range from 0 to 255, with 0 being stopped and 255 being full motor speed.  Currently, I start both motors at half speed (128) and then adjust the left/right motor speeds in a complementary fashion to achieve wall following.  When the current ping distance is less than the previous one, I speed up the inside motor and slow down the outside motor by the same fixed amount – 50 –  empirically derived  from a number of runs with different values.

This fixed adjustment or ‘tweak’ value of 50 is HUGE, especially when you consider that it is added to one motor speed value and subtracted from the other; this is effectively 50%  of the total range available to either motor.  This is clearly why Wall-E’s wall-following performance looks so jerky – it works, but it looks like he’s forever in danger of going out of control (which does happen on occasion).  However, on the plus side, it means that Wall-E does OK about negotiating corners, as it only takes two adjustment steps to get to an almost stopped wheel on one side and an almost full speed wheel on the other.

So, what I’m after is a more measured (pun intended) approach, where the ‘tweak’ value isn’t constant but rather is some function of the change in distance between one ping and the next.

There are 4 cases to consider:  Assume D_n and D_n-1 are the distances returned by two adjacent pings from the left or right sensor.

1. Left wall is closer, D_n – D_n-1 < 0
2. Left wall is closer, D_n – D_n-1  > 0
3. Right  wall is closer, D_n – D_n-1 < 0
4. Right  wall is closer, D_n – D_n-1  > 0

What I want is some sort of  algorithm like:

new left motor speed LSPD_n = LSPD_n-1  –  K * (D_n – D_n-1)
new right motor speed RSPD_n = RSPD_n-1  +  K * (D_n – D_n-1).

This works great for left wall following, where (D_n – D_n-1) < 0 indicates  an increase in the left and a decrease in the right motor speeds, but the signs in red need to be swapped for right wall following, where (D_n – D_n-1) < 0 indicates  a decrease in the left and an increase in the right motor speeds.

So, the above 4 cases can be reduced to 2 – left wall closer, and right wall closer:

1. Left wall: LSPD_n = LSPD_n-1  –  K * (D_n – D_n-1); RSPD_n = RSPD_n-1  +  K * (D_n – D_n-1)
2. Right wall: LSPD_n = LSPD_n-1  + K * (D_n – D_n-1); RSPD_n = RSPD_n-1  – K * (D_n – D_n-1)

So, for a 2 cm smaller distance to the left wall, LSPD_n = LSPD_n-1  –  K * (-2) = LSPD_n-1  +  2K,
RSPD_n = RSPD_n-1  +  K * (-2) = RSPD_n-1  –  2K, which is correct.  For a 2 cm larger distance, the signs in red would swap, which is also correct.

For the right wall we have:  LSPD_n = LSPD_n-1  +  K * (-2) = LSPD_n-1  –  2K,
RSPD_n = RSPD_n-1  –  K * (-2) = RSPD_n-1  +  2K, which is correct.  For a 2 cm larger distance, the signs in red would swap, which is also correct.

So, now all I need to do is code this up and give it a whirl.  I think I will start with K = 10, and limit the per-instance wheel adjustment to 50 (same as it is now, essentially).

Stay Tuned!

Frank

Posted 3/16/15

In my last post I  mentioned that I thought  moving the left/right distance sensors from their current positions well ahead of the axis of rotation to a position closer to (ideally on) the axis of rotation might result in better/smoother wall following performance, and today I got a chance to try that out.  I designed and printed a sensor bracket that could be super-glued to the already-existing ‘fenders’ over the drive wheels, as shown in the photo below.  The old sensor location is the one well forward of the drive wheel, mounted upside down underneath the robot carriage with double-sided foam tape.  The new location is directly above the drive wheel, mounted using my new spiffy mounting bracket (adapted from the front sensor mount design).

Robot left side showing both distance sensor locations

My theory was that the more pronounce swinging motion out at the old sensor location was contributing to over-correction, especially when the robot’s angle to the wall got to be greater than about 30 degrees – after which the distance to the wall would tend to  increase rather than decrease with further rotation.

To prove or disprove this theory, I added a second set of ping sensors directly above the wheels as shown in the above picture.  Then, without changing anything else, I made several test runs using the axial pair of sensors instead of the forward mounted ones.

The result was that the left/right wandering tendency while wall following  was significantly  worse with the axially-mounted sensors than with the forward-mounted ones, as shown in the following video clip.  Theory  disproved! 🙁

Future Work:

Now that I have unfortunately debunked my own theory about the side-mounted ping sensors, I’ll have to search in other places for ways to improve wall following performance.  In earlier work I had noted that if the pings are too close together, distance reporting can get flaky, as the acoustic reverberations from one ping don’t have time to die out before the next one gets received.  I  had addressed this issue by spacing the pings out in time, but that spacing interval might be too long (or still too short, for that matter).  This needs to be studied some more.  In addition, I need to revisit the amount by which each wheel’s speed is adjusted to effect course corrections (the ‘adjustment tweak’ value).  It may be that modifications to one or both (ping spacing interval and wheel speed ‘tweak’ value) may achieve some performance improvements.

Frank