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

01/26/15

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! 😉

01/25/15 10:00

After getting the robot to follow a wall  at all, I have now graduated to the task of tuning the feedback loop for ‘best performance’.  Part of the problem is trying to define what ‘best performance’ means in terms of wall following capabilities.

In my UpdateWallFollowMotorSpeeds() function, I compare the current distance to the previous one, and adjust left/right motor speeds up or down to  turn away from the wall if the distance is decreasing, or toward it if the distance is increasing.  The amount of adjustment applied is a program constant that can be ‘tuned’ for optimum performance, whatever that means.  Wheel speeds can vary from 50 to 200 (out of a 0 to 255 range)

• Small wheel-speed adjustment values result in a smooth  sinusoidal path with a slowly increasing amplitude – which eventually diverges to the point where the robot either departs from the wall entirely, or runs into it head-on, as shown in the following video, taken with an adjustment value of 5
• Larger adjustment values increase the ‘available control authority’, but also increases the correction magnitude to the point where a small error in distance measurement causes the robot to diverge and spin in place.
• An intermediate value of 25 seem to be a good compromise between smoothness and sufficient control authority to keep the robot going straight (on average, anyway)

Speed Adjustment Value = 5

Speed Adjustment Value = 50

Speed Adjustment Value = 25.  On this video you can also see the two green LED’s which serve as ‘commanding left turn’ and ‘commanding right turn’ debug indicators.

This is OK, but still not quite what I want for my wall following robot.  However, it may well be that I will never be able to completely suppress the oscillations, as this is a fairly complex feedback loop.  And, as I know from my 40+ years as an Electrical Engineer, all feedback loops can cause oscillations when the loop phase shift approaches 180 degrees.  This particular arrangement has both electrical and mechanical phase terms that make it even more interesting

• The position of the sensors relative to the axis of rotation introduces a large phase shift term, as small rotation changes cause large distance changes. As we saw earlier, the original phase relationship with the sensors at the rear was positive (a small turn toward the wall causes a large increase in distance measurement, exactly opposite of the expected result), while the phase relationship in the current configuration with the sensors at the front is negative   (a small turn toward the wall causes a large    decrease in distance measurement, the expected result but amplified).
• There is a time/phase lag between the time the program makes a decision to the time the wheel speeds actually change, so by the time the robot starts to compensate for an error term, the error has had time to get larger.  This in turn means the robot will continue to correct well past the point where it should, leading to overshoot in the other direction.

The above leads me to believe that I (aka the robot) should be making corrections based on the value of  the distance-vs-time curve slope, rather than  just the sign of the slope (positive or negative).  If I use the value of the slope, then I can make bigger corrections for larger slopes, and smaller ones for smaller slopes.  This could get a little tricky, as the slope calculation  requires some knowledge of time; IOW, each point in the curve is a (dist,time) pair, and both have to be known to calculate the slope between two pairs (dist0,time0) and (dist1,time1).  I could simply assume that the time between distance measurements is a constant, which would mean that the slope is proportional to  (dist1 – dist0).  So, I think I’ll try a very simple setup, and make the adjustment value = 25 * |d1-d0|.