Posted 02/16/16

Wall-E2, my 4WD wall-following robot, is doing pretty well these days.  He can navigate autonomously around the house quite nicely, and almost never gets irretrievably stuck. Up until the addition of front wheel  guards  a couple of months ago, Wall-E2 was quite adept at literally climbing the walls and winding up in the ‘scared tractor’ (from ‘Cars’) pose, or turning himself completely over on his back. Since then he has been much better behaved, but has still managed to very occasionally get himself into trouble (he has, on more than one occasion, managed to hang himself on a loose power or data cable, kinda like a horse rider getting scraped off by a low branch.  When this happens, Wall-E2 winds up on his back with his wheels spinning uselessly in the air.

So, my new ‘great idea’ is to give Wall-E2 a sense of direction, literally.  About 5 years ago I ginned up a pretty cool helmet-mounted attitude sensing device for my dressage-riding wife using a ‘Mongoose’ 9DOF board from CK Devices (I would post a link, but I don’t think they are being made anymore – see the Sparkfun ‘Razor’ IMU instead).  Anyway, I still had this miraculous little board hanging around, and decided to see if I could integrate it into Wall-E2.  The idea is that if I could detect an incipient ‘scared tractor’ event, I could short-circuit it by stopping or reversing the motors, or maybe taking some other action if that didn’t work.  In addition, I’m thinking maybe I could use the gyro & magnetometer sensors to have Wall-E2 report his current magnetic heading.  If I were to couple this with left/right/front distance readings, Wall-E2  *might* be able to determine where  he was in the house.  And, if he could do that, then maybe he could tell when he was close to a charging station, and hook himself for a quick electron meal (charging station yet to be designed/implemented, but hey – one thing at a time!)

So, I dug out the Mongoose board, and tried (unsuccessfully) to remember how I had gotten the darned thing to work 5 years ago (I can’t remember what happened 5 minutes ago, so 5 years was more than a stretch!).  Fortunately, I never, ever, throw files away (disk storage being effectively infinite, you know), so I was eventually able to track down my old Arduino ‘Motion Tracker’ project and bootstrap myself back up.  I did have a bit of a kerfluffle when I couldn’t get my Mongoose board to talk to the CK Devices Visualizer program, but that got solved after some head-scratching and a few emails to Cory (last name unknown) of CK Devices.

Using the very nice Visualizer program, as shown in the movie clip below, I was able to verify proper Mongoose operation.  I was also able to track down my old ‘Motion Tracker’ program (basically a very rudimentary hack of the ‘base’ Arduino program supplied by CK Devices) and verify that it still worked.  The next step(s) will be to figure out how to mount the Mongoose on Wall-E2, and how to integrate the IMU information into Wall-E2’s operations.

Stay tuned!

Posted 01/12/16

A few weeks ago I had what I thought was a great idea – a way of making Wall-E2 react more intelligently to upcoming obstacles as it tracked along a wall.

As it stood at the time, Wall-E2 would continue to track the nearest wall until it got within a set obstacle clearance distance (about 9 cm at present), at which point it would stop, backup, and make a 90-deg turn away from the last-tracked wall direction.  For example, if it was tracking a wall to its left and detected a forward obstacle within 9 cm, it would stop, back up, and then turn 90 deg to the right before proceeding again.  This worked fine, but was a bit crude IMHO (and in my robot universe MY opinion is the only one that matters – Heh Heh!)

So, my idea was to give  Wall-E2 the ability to detect an upcoming obstacle early enough so that it could make a smooth turn away from the currently tracked wall so that it could intelligently navigate the typical concave 90-deg internal corners found in a house.  This required that Wall-E2’s navigation code recognize a third  distinct forward distance ‘band’ in addition to the current ones (less than 9cm and greater than 9 cm).  This third band would be from the obstacle avoidance distance of 9cm to some larger range (currently set at 8 times the obstacle avoidance distance).

After coding this up and setting Wall-E2 loose on some more test runs, I was able to see that this idea really worked – but not without the usual unintended consequences.  In fact, after a number of test runs I began to realize that the addition of the third distance ‘band’ had complicated the situation  to the point where I simply couldn’t acquire (or maintain) a sufficiently good understanding of all the subtleties  of the logic; Every time I thought I had it figured out, I discovered all I had done was to exchange one failure mode for another – bummer!

So, I did what I always do when faced with a problem that simply refuses to be solved – I quit!  Well, not actually, but I did quit trying to solve the problem by changing the program; instead I put it aside, and began thinking about it in the shower, and as I was lying in bed waiting to go to sleep.  I have found over the years that when a problem seems intractable, it usually means there is a piece or pieces missing from the puzzle, and until I ferret it or them out, there is no hope of arriving at a complete solution.

So, after some quality time in the showers and during the ‘drifting off to sleep’ periods, I came to realize that I was not only missing pieces, but I was trying to use some pieces in two different contexts at the same time – oops!  I decided that I needed to go back to the drawing board (literally) and try to capture  all the variables  that comprise the input set to the logic process that results in a new set of commands to the motors.  The result is the diagram below.

Overall Logic Diagram

As shown in the above diagram, all Wall-E has to work with are  the inputs from three distance sensors.  The left & right sensors are acoustic ‘ping’ sensors, and the forward one is a Pulsed Light ‘Blue Label’ (V2) LIDAR sensor.  All the other ‘inputs’ on the left side are derived in some way from the distance sensor inputs.  The operating logic uses the sensor information, along with knowledge of the previous operating state to produce the next operating state – i.e. a set of motor commands.  The processor then updates the previous  operating state, and then does it all over again.

The logic diagram breaks the ‘inputs’ into four different categories. First and foremost is the raw distance data from the sensors, followed (in no particular order) by the current operating mode (i.e. what the motors are doing at the moment), the current tracking state (left, right, or neither), and the current distance ‘band’ (less than 9cm, between 9 and 72cm, and greater than 72cm).  The processor uses this information to generate a new operating mode and updates the current distance band and current tracking state.

After getting a handle on the inputs, outputs, and state variables, I decided to try my hand at using the Karnaugh mapping trick I learned back in my old logic circuit design days 40 or 50 years ago.  The technique involves mapping the inputs onto one or more two-dimensional grids, where every cell in the grid represents a possible output of the logic process being investigated.  In it’s ‘pure’ implementation, the outputs are all ‘1’ or ‘0’, but in my implementation, the outputs are one of the 8 motor operations modes (tracking left/right, backup-and-rotate left/right, step-turn left/right, and rotate-90-deg left/right).  The full set of Karnaugh maps for this system are shown in the following image.

Karnaugh Map using variables from logic diagram

The utility of Karnaugh maps lies in their ability to expose possible simplifications to the logic equations for the various desired outputs.  In a properly constructed K-map, adjacent cells with the same output indicate a potential simplification in the logic for that output.  For instance, in the diagram above, the ‘Backup-and-Rotate-Right’ output occurs in all four cells in the top row of the ‘Tracking Left’ map (shown in green above).  This indicates that the logic equation for that desired output simplifies down to simply “distance band ==  ‘NEAR’.  In addition, the Backup-and-Rotate-Right’ output occurs for all four cells in the ‘Stuck Recovery’ column, indicating that the logic equation is simply “operating mode == Stuck Recovery”.  The sum (OR) of these two equations gives the complete logic equation for the ‘Backup-and-Rotate-Right’ motor operating mode, i.e.

Backup-and-Rotate-Right = Tracking Left && (NEAR || STUCK)

The above example is admittedly the least complicated, but the complete logic equations for all the other motor operation modes can be similarly derived, and are shown at the bottom of the K-map diagram above.  Note that while for completeness I mapped out the K-map for ‘Tracking Neither’, it became evident that it doesn’t really add anything to the logic.  It can simply be ignored for purposes of generating the desired logic equations.

Now that I have what I hope and believe is the complete solution for the level of intelligence I wish to implement with Wall-E2, actually coding and testing it should be MUCH easier.  At the moment though, said implementation and testing will have to wait until I and my wife return from a week-long duplicate bridge tournament in Cleveland, OH.

Stay tuned! ;-))

Frank

January 16 Update:

As I was coding up the results of the above study, I realized that the  original Karnaugh map shown above wasn’t an entirely accurate description of the problem space.  In particular, I realized that  if Wall-E2 encounters an ‘open corner’ (i.e. both left & right distances are > max) just at the Far/Near boundary, it is OK to assign this condition to  either the ‘Step-Turn’ (i.e. start a turn away from the last-tracked wall)  or the ‘Open Corner’ (i.e. start a turn toward the last-tracked wall).  And if I were to arbitrarily (but cleverly!) assign this to ‘Step-Turn’, then the K-map changes from the above layout to the revised one shown below, where the ‘Open Corner’ condition has been reduced to just the one cell in the lower right-hand corner of both the left and right K-maps.

Revised Motor Control Logic Karnaugh Map

So now the logic expressions for the two  ‘Open Corner’ motor response cases (i.e. start a turn  toward the last-tracked wall) are:

Rotate 90 Left = Tracking Left && Open Corner&& Far
Rotate 90 Left = Tracking Left && Open Corner&& Far

But the  other implication of this change is that now the ‘Step-Turn’ expression can be simplified from the  ‘sum’ (logical  OR) of two 3-term expressions to a single 3-term one, as shown by the dotted-line groupings in the revised K-map, and the following expressions for the ‘Left Tracking’ case:

previous: Step-turn Right = Tracking Left && Step && (Wall Tracking || Step Turn)
new: Step-turn Right = Tracking Left && Step && !Stuck

much easier to implement!

OK, back to coding…..

Frank

Posted 12/22/2015,

As I write this, I’m watching the Space-X video webcast  following their historic launch and first stage recovery at Cape Canaveral.  I am absolutely ecstatic that  someone (in this case Elon Musk and Space-X) finally got a clue and got past the “throw everything away” mentality of previous generations.  Also, as  a retired civil servant, I am more than a little embarrassed that our great and mighty U.S. Government, with its immense resources couldn’t get its collective head out of it’s collective ass and instead gets its ass handed to it by Elon Musk and Space-X.  I’m sure for Elon this was just another day in his special toy factory, but it was a  great day for U.S. entrepreneurship and individual initiative, and just another shameful lapse for our vaunted U.S. Government space ‘program’.

OK, so much for my ranting :-).  The reason for this post is to describe two major upgrades to the Wall-E2 4WD robot; a new, more powerful battery pack, and the addition of a Pololu Wixel wireless link to the robot.

New Battery Pack:

For Wall-E1 I used a pair of 2000maH Li-Po cells from Sparkfun, coupled with their basic charger modules and a relay to form a 7.4V stack.  This worked fine for  the 2-motor  Wall-E1, but I started having problems when I used this same configuration for the 4-motor Wall-E2. Apparently, these Li-Po cells incorporate some current limiting technology that disconnects a cell when it senses an over-current situation.  Although I’m not sure, I suspect they are using something like a solid-state polyfuse, which transitions from a low resistance state to a high resistance state when it gets too hot. When this happens, it can take several minutes for the polyfuse to cool back down to the point where it transitions back to the low resistance state.  I discovered this when Wall-E2 started shutting down for no apparent reason, and voltage measurements showed my 2-cell stack was only producing 3.5V or so, i.e. just one cell instead of two :-(.  At first I thought this was a wiring or relay (I use a relay to switch the cells from series to parallel configuration for charging) problem, but I couldn’t find anything wrong, and by the time I had everything opened up to troubleshoot, the problem would go away!  After two or three iterations of this routine, I finally got a clue and was able to observe the battery voltage transition from 3.5V or so back to the normal 7.4V, all without any intervention from me.  Apparently the additional current required to drive all 4 motors was occasionally exceeding the internal current trip point on at least one of the cells – oops!

So, I started looking for a Li-Po battery pack without the too-low peak current limitation, and immediately ran into lots of information on battery packs for RC cars and aircraft. These jewels have abou the same AH rating as my current cells, but have peak current ratings in the 20-40C range – just what I was looking for.  Now all I had to do was to find a pack that would fit in/on my robot, without looking like a hermit crab carrying a shell around.  I eventually settled on the  GForce 30C 2200mAh 2S 7.4V LiPO from Value Hobby, as shown in the following screenshot.

New battery pack for Wall-E2

This pack is quite a bit larger (102mm X 34mm X 16mm) than the original 2000mAH cells from Sparkfun, and also requires a different (and much more expensive) charger.  At first I thought I would have to mount this monster on the top of the top deck, as shown below,

Original mounting idea for the new battery

but then I figured out that I could actually mount it on the underside of the top deck, leaving the top deck area available for other stuff (in case one of the cats decides to take a ride), as shown in the next two photos.

under-deck mounting, looking from rear of robot

under-deck mounting, looking from side of robot

After getting the battery pack mounted, I removed the existing battery pack and associated wiring from the motor compartment, and spliced in the new battery wiring through the existing power switch, as shown below (the power switch is shown at the extreme right side of the photo. The red wire is from the battery + terminal, and the black wire from the battery was spliced into the existing ground wire.

Empty battery compartment showing new battery wiring at front

Pololu Wixel Wireless Link:

As I continued to improve Wall-E2’s wall following ability, I became more and more frustrated with my limited ability to monitor what Wall-E2 was ‘seeing’ as it navigated around my house.  When ‘field’ testing, I would follow it around observing it’s behavior, but then I would have to imagine how the observed behavior related to the navigation code.  Alternatively, I could bench test the robot with it tethered to my PC so I could see debugging printouts, but this wasn’t at all realistic.  What I really needed was a way for Wall-E2 to wirelessly report selected sensor and programming parameters during field testing.  A couple of years ago I had purchased a pair of Wixels from Pololu for another project, but that project died before I got  around to actually deploying them.  However, I never throw anything away, so I still had them hanging around – somewhere.  A search of my various parts bins yielded not only the pair of Wixels, but also a Wixel ‘shield’ kit for Arduino microcontollers – bonus points!!

After re-educating myself on all things Wixel, and getting (with the help of the folks on the Pololu support forum) the Wixel Configuration Utility installed and running, and after assembling the Wixel shield kit, I was able to implement a wireless link from my PC to the Arduino on the robot.  Pololu has a bunch of canned Wixel apps, and one of them does everything required to simulate a hard-wired USB cable connection to the robot – very nice!! And, the Wixel shield kit comes with surface-mounted resistive voltage dividers for converting the 5V Arduino Tx signals to 3.3V Wixel Rx levels, and a dual-FET non-inverting upconverter to convert 3.3V Wixel Tx signals to 5V Arduino Rx levels – double nice!  Even better, the entire thing plugs into the existing Arduino header layout, for a no-brainer (meaning even I would have trouble getting it wrong) installation, as shown in the following photo.

Wixel shield mounted on top of Arduino ‘Mega’ micro-controller

After getting everything installed and working, it was time to try it out.  I modified Wall-E2’s code to print out a timestamp along with all the other parameters, so I could match Wall-E2’s internal parameter reporting with the timeline of the video recording of Wall-E’s behavior, and this turned out to work fantastically well.  The only problem I had was the limited range provided by the Wixel pair, but I solved that by putting my laptop (with the ‘local’ Wixel attached) on my kitchen counter, approximately in the middle of my ‘field’ test range.  Then I set Wall-E2 loose and videoed its behavior, and later matched the video timeline with the parameter reports from the robot.  I found that the two timelines weren’t exactly synched up, but they were within a second or two – close enough so that I could easily match observed behavior changes with corresponding shifts in measured parameters.  Here’s a video of a recent test, followed by selected excerpts from the parameter log.

The video starts off with a straight wall-following section, and then at about 10  seconds Wall-E2 encounters the  door to the pantry, which is oriented at about 45 degrees to the direction of travel.  When I looked at the telemetry from WallE2, I found the following section starting at 11.35 seconds after motor start:

Time Left Right Front Tracking Variance Left Spd RightSpd
11.46 21 200 400 Left 474 90 215
11.51 21 200 63 Left 475 90 215
11.56 21 200 400 Left 435 90 215
—- Starting Stepturn with bIsTrackingLeft = 1
11.60 21 200 56 Left 476 255 50
11.65 20 200 53 Left 525 255 50
11.71 20 200 52 Left 589 255 50
11.76 20 200 53 Left 640 255 50
11.81 20 200 52 Left 692 255 50

[deleted section]
12.31 26 200 53 Left 1107 255 50
12.35 24 200 55 Left 1136 255 50
12.40 23 200 61 Left 1155 255 50
12.46 23 200 99 Left 1151 175 130
12.51 22 200 188 Left 1320 215 90

The lines in green are ‘normal navigation lines, showing that Wall-E2 is tracking a wall to its left, about 20-21 cm away (the first value after the timestamp), and is doing a good job keeping this distance constant.  It is more than 200cm away from anything on its right, and the distance to any forward obstruction is varying between 400+ (this value is truncated  to 400cm) and 63 cm (this variation is due to Wall-E2’s left/right navigation behavior).

Then between 11.56 and 11.60 sec, Wall-E2 detects the conditions for a ‘step-turn’, namely a front distance measurement less than about 60 cm (note the front distance of 56 cm – third value after the timestamp).  The ‘step-turn’ behavior is to apply full power to the motors on the same side as the wall being tracked, and slow  the outside motors, until the front distance goes back above 60cm.  The telemetry and the video shows that Wall-E2 successfully executes this maneuver for about 1 second, before the front-mounted LIDAR starts ‘seeing’ beyond the pantry door into the hallway behind, as shown by the pointing laser ‘dot’.

Similarly, at about 28 seconds on the video, Wall-E2  gets stuck on the dreaded furry slippers (the bane of Wall-E1’s existence), but gets away after a few seconds of spinning its wheels.  From the telemetry shown below, it is clear that Wall-E2’s new-improved ‘stuck’ detection & recovery algorithm is doing it’s job.  The ‘stuck’ detection algorithm computes a running variance of the last 50 LIDAR distance measurements.  During normal operation, this value is quite high, but when Wall-E2 gets stuck, the LIDAR measurements become static, and the computed variance rapidly decreases.  When the variance value falls below an adjustable threshold (currently set at 4), a ‘stuck condition’ is declared, and the robot backs up and turns away from the nearest wall.  As you can see from the telemetry excerpt below, this is precisely what happens when Wall-E2 gets stuck on the ‘slippers from hell’.  In the excerpt below, I have highlighted the calculated variance values.

30.96 77 26 26 Left 99 255 50
31.01 77 27 27 Left 88
31.36 77 27 26 Lef
31.51 77 28 22 Left 21 255 50
31.56 77 28 23 Left 18 255 50
31.61 77 26 25 Left 14 255 50
31.67 76 27 26
31.71 76 26 27 Left 9 255 50
31.76 76 27 25 Left 6 255 50
31.81 76 27 26 Left 5 255 50
———- Stuck Condition Detected!!———–
31.86 77 26 28 Left 4 127 127
34.13 61 200 117 Left 167 255 50
34.18 62 200 118 Left 325 215 90

This ‘field’ trial lasted less than two minutes, but the combination of the timestamped video and the timestamped telemetry log allowed me a much better understanding of how well (or poorly) Wall-E’s navigation and obstacle-avoidance algorithms were functioning.  Moreover, now that I can record and save video/telemetry pairs, I can more precisely assess the effects of future algorithm developments (like maybe the addition of PID-based wall following).

So, the combination of the new battery pack and the Wixel wireless link has given Wall-E2 some new super-powers.  It can now drive around with much greater energy, and it can now tell its human masters what it is thinking while it goes about its work – doesn’t get much better than that!

Stay tuned!

Frank

Posted 11/22/15

At the conclusion of last month’s  episode of “Bringing up Baby” (AKA our new 4WD Robot), my grandson and I had gotten it to the point of doing ‘The Robot Jig’ (a test program to show that all the motors ran in the same direction and at the same speed), but without any sensors or navigation capability.  After Danny went back home I sorta let the 4WD robot out to pasture while I concentrated on reworking Wall-E to remove all the spinning LIDAR stuff and add acoustic sensors.  This effort was pretty successful, so I thought it was now time to add this same capability to the 4WD robot – now christened ‘Wall-E2’.

The plan for adding sensor capability to Wall-E2  was to move  the ‘Blue Label’ LIDAR and two acoustic ‘ping’ sensors from Wall-E.  This entailed printing up a new LIDAR bracket (not really necessary, but aesthetically pleasing), and redesigned ping sensor brackets (the retainer latches on the old ones were  way too fragile).  For a while I toyed with the idea of discarding the 4WD robot’s ‘upper deck’, but in the end I decided that  giving up all that future expansion real estate was just too stupid for words.  However, retaining the second deck brought with it the challenge of managing the inter-deck cabling in a way that allowed the upper deck to be removed for troubleshooting without having to disconnect anything.  IOW, I wanted to be able to run everything on the second deck, while the deck  was physically off the robot.  Eventually I decided on a hybrid approach to the cabling issue; I added a terminal strip to the underside of the deck, and ran +5VDC and GND wires to it from the main terminal strip, with inline disconnects.  Then I permanently connected +5 & GND wires to each acoustic sensor, but ran the ping sensor control lines back to the main deck through inline disconnects. The LIDAR cable was run all the way from the LIDAR to the main deck without disconnects, but this was OK because this cable connects to the LIDAR itself via a multipin locking connector.  All the cabling runs have enough slack so that the upper deck can be placed on the bench beside the robot without having to disconnect anything – yay!  The following photos show the disassembled and assembled states of Wall-E2.

Disassembled robot. Note the inline disconnects on the power/gnd cable and the ping sensor and laser pointer control lines

Rear view of the assembled robot

Right side view of the assembled robot

Front view of the assembled robot

Left front quarter view

Left side view

So, at the end of this episode, all the mechanical and electrical work has been accomplished, but nothing has been tested yet.  It’s late, so I think I’ll wait until I have more than two neurons to rub together to check things over and test things out.  I have found over time that late-night testing almost invariably leads to next-day wailing and gnashing of teeth 😉

Stay tuned,

Frank