Posted 03/20/16

In my last post, I described my efforts to integrate a CK Devices Mongoose 9DOF IMU module into my Wall-E2 wall-following robot. In that post, I had collected  a set of azimuth (heading) data from the Mongoose showing that the Mongoose was operating properly and that significant error compensation was possible using a simple sine function.  This led me to believe that it would be feasible to install the Mongoose on the robot and create a similar compensation function.  Unfortunately, that turned out not to be the case.  When I collected a similar set of heading data in the installed case, the data showed non-linear behavior for which function-based compensation  would be difficult, if not impossible to achieve.

The image  below shows results from the ‘bare’ (desktop) uninstalled configuration, where it is clear that the Mongoose raw heading values closely follow the actual magnetic heading, and that a simple sine function is sufficient to reduce heading error to approximately +/- 2 deg.

Mongoose Mag Heading & Error on desk before installation on robot

The next set of  images shows the Mongoose installed on the robot between the upper and lower decks.  The idea was to place the Mongoose in a location reasonably well protected physically, but away from high-current elements.  I also wanted to avoid placing it on the upper deck to avoid the additional inter-deck wiring and attendant maintenance/troubleshooting complexity.

Mongoose installed on robot, side view

Mongoose installed on robot, top view

After installation, the same set of measurements were taken, with the results shown in the following plots.  As can be seen, the Mongoose heading readings in this case are hugely different than the desktop run.  Instead of being able to compensate the heading error to within +/- 2 deg, the compensated error is greater than the uncompensated one!  Looking at the Installed Raw Heading plot, it appears that the readings are relatively linear (but heavily suppressed) out to about 315 deg, where something bad happens and the reported heading falls rapidly to near zero.  I made another run in the installed configuration with the magnetometer gain turned down as far as possible, but this did not materially improve the situation.  Clearly something on the robot was drastically affecting the Mongoose magnetometer, to the extent that compensation was  impossible. Moreover, due to the retrograde readings between 315 and 360 degrees, even a lookup table solution seems problematic.

As I often do when faced with what appears to be an insurmountable obstacle, I tabled the problem and did something else for a while and let my subconscious work on the problem for a while.  After a couple of days of this, I decided to go back to the uninstalled (desktop) case, re-establish my measurement baseline, and then see if I could determine what on the robot was causing such huge magnetic heading variations.   After playing around for a while, I was able to determine that the cause of the problem was the permanent magnets in the DC wheel motors – well DUH!!  After smacking myself on the forehead a couple of times for not thinking of this days ago, I realized that I had carefully determined that Wall-E’s chassis was constructed of aluminum that shouldn’t (I thought) cause problems with the magnetometer, forgetting entirely the fact that in addition to not affecting the magnetometer, it also wouldn’t shield the magnetometer from the strong magnetic fields generated by the motor magnets – oops!

So, what to do?  As much as I would like to avoid it, it appears now that the only viable solution (other than abandoning the magnetometer idea entirely) is to put the Mongoose on the top deck, as far away from the motors as possible.  I am at least a little optimistic that this will work, for two reasons; with the gain turned down, the Mongoose  almost worked where it was, and because mag fields decrease with R³, a few cm could make a significant difference.

Stay tuned!

Frank

Posted  March 14, 2016

In my last post from about a week ago, I described my ongoing efforts to integrate the CK Devices Mongoose 9DOF IMU into my ‘Wall-E2’ wall-following robot.  Since that time, I have gotten the Mongoose successfully integrated into the robot, and am able to see magnetometer & accelerometer readings being passed through the host Arduino Mega to the PC via the Mega’s serial port.

After getting all the hardware and software issues worked out, I have now started on the issue of getting the magnetometer calibrated for it’s new home in the robot.  All magnetometers need to be calibrated after installation to compensate for errors caused by nearby metal (ferrous and non-ferrous) objects; otherwise the reported magnetic heading can be substantially off.  I have considered just using a 360-element lookup table containing offset values, but that’s a bit tacky even for one with my low standards, so I have been researching available magnetometer calibration techniques and tools.  I found a nice  discussion at DIY Drones here, but I have been having trouble getting the tools to work.  The discussion (and tools) center around the widely available  GY-273 HMC5883L  breakout board, and this ain’t quite the same animal as the Mongoose.

Following the general line of the discussion at DIY Drones, I downloaded the ‘MagMaster’ ZIP files, and attempted to get the MagViewer visualizer program linked up with my Mega/Mongoose combination, without much success.  After flailing around for a while with the robot/Mongoose setup, I decided to simplify things by isolating the Mega/Mongoose combination from everything else going on with the robot.  I had a spare Mega, so I simply connected the Mongoose to Tx1/Rx1 on the spare (same as on the robot) and loaded a modified version of the robot controller onto the Mega.

The modifications basically stripped away everything to do with the robot, leaving only the code that interfaces with the Mongoose.  According to the DIY Drones discussion, this  should have allowed the MagViewer program to see the same magnetometer data as for the GY-273, but apparently not.  The viewer program never shows any activity – bummer!

Posted  March 16, 2016

Well, I’m still not sure why the MagViewer program didn’t recognize the Mongoose mag data (I posted to the DIY Drones forum, but no replies yet), so  I decided I would try a variant on my original idea of a lookup table.

First, I needed a way to accurately orient  my Mongoose module to different headings.  I Googled around a bit, and found a protractor printing site  that offered 360-degree heading graphics like the one shown below

4-inch heading circle, calibrated in degrees

Then I taped a narrow strip of paper to the bottom centerline of the Mongoose module to make an accurate pointer, and proceeded to record the actual Mongoose heading reading for each 5-degree increment around the circle.  I started this process by orienting the paper heading circle so that the 0/360 point corresponded to a Mongoose heading reading of 0 degrees, i.e. aligned with magnetic north as measured by the Mongoose.  The data were recorded in an Excel spreadsheet, and the error term (difference between the nominal heading value and the Mongoose reading) was calculated and graphed, as shown below.

Mongoose reading versus actual magnetic heading, with error plot

Well, when the graph first popped up, I just about fell off my chair, as I recognized an almost perfect sine wave graph.  This immediately told me two things:

1. The Mongoose sensor, the test setup and the data was all valid.  There is no way I could have managed that smooth of a curve by accident, and also no way it could have been that smooth if there was any significant mag field distortion
2. At least for this case, with no significant installation errors, almost perfect heading compensation could be accomplished with just a simple sine function with a slight negative DC offset corresponding to the average value of all errors (about -1.35 according to Excel)

To test this theory, I  used Excel to calculate the required sin function values, and added the result to the calculated error values for each measured angle.  Then I plotted the compensation and comp+error curves on the same plot as before, as shown below.

Angle Error, Comp values, and Comp+Error

From the plot, it is clear that the compensation  is effective, although not perfect. The compensated error amplitude looks to be about 2-2.5 degrees, more than adequate for my purposes.  I think the remaining error is due to the fact that the sensor data traces out an ellipse rather than a circle.

So, the next step is to install the Mongoose sensor back on the robot, and do a similar test utilizing an 8″ diameter version of the heading graphic.  Assuming I get similar compensation results, I’ll probably call it a day and start running field tests.  After all, I’m not sure I care if Wall-E thinks a hallway is oriented at 270, 260, or 280 degrees magnetic, as long as the next time it goes down the same hallway it gets more or less the same results!

Stay tuned!

Frank

Posted 03/07/16

In my last post on this subject, I described my efforts to renew my acquaintance with CK Devices’ Mongoose 9DOF IMU board, with the intent of integrating it into my wall-following robot project.  This post describes the first step toward that integration goal.

The Mongoose board operates on 3.3V and communicates via RS-232 protocol over a 6-pin 0.1″ header block, compatible with the CK Devices ‘FTDI Pro’ programmer  module, as shown in the following photo.

Mongoose 9DOF IMU board, with FTDI Pro USB-Serial adapter

Integrating this board into Wall-E requires addressing two distinct but related issues – the voltage difference between the 5V Arduino Mega controller and the 3.3V Mongoose, and  the coding changes required to retrieve the desired heading/attitude information from the Mongoose.

The Hardware

The 5V/3.3V issue requires that 5V serial data levels from the Arduino Mega be stepped down to 3.3V, and 3.3V serial data levels from the Mongoose be stepped up to 5V.  Simply ignoring these problems does seem to work (the 5V data from the Mega doesn’t appear to harm the Mongoose, and the 3.3V data from the Mongoose does seem to be recognized by the Mega), but it is inelegant to say the least.  Also, a recent addition to Wall-E’s superpowers included Pololu’s  ‘Wixel Shield’ module, which fortuitously included some spare circuitry for just this purpose, as shown in the schematic drawing excerpt below.  The upper right corner shows the full step-up circuit used to connect the 3.3V Wixel Tx line to the 5V Arduino Rx line, and the top  center  shows the step-down circuit used to connect the 5V Arduiono Tx line to the 3.3V Wixel Rx line.  The lower area shows the spare parts available on the Wixel shield – and the important thing is that there are  two general-purpose N-channel MOSFETs. These can be used to construct the same step-up circuit to connect the 3.3V Mongoose Tx line to the 5V Arduino Mega Rx1 line, and one of the 4 available 2/3 voltage dividers can be used to step down the 5V Arduino Mega Tx line to the 3.3V Mongoose Rx line.

The following image  is a small section of my overall Scheme-it (Digikey’s free online schematic capture app) schematic for Wall-E, showing the addition of the Mongoose IMU.

The photo below shows the serial up/down converter connections on the Wixel Shield board.  On the near side, Red = Mongoose Rx, Org = Mongoose Tx.  On the far side, Org = Mega Rx1, White = Mega Tx1.

Mongoose Serial Up/Down Converter Connections. Near side Red = Mongoose Tx, Org = Mongoose Rx. Far side: Org = Mega Rx1, White = Mega Tx1.  Yel = Mongoose 3.3V, Grn = Mongoose Gnd.

The Software:

After getting the hardware wired up and tested, I naturally thought All I had to do was plug in the Mongoose with the full set of reporting software, and I’d be ready to go –  NOT!  So, after the obligatory yelling and cursing and the appropriate number of random code changes hoping something would work, I was forced to fall back on my somewhat rusty (but not completely worthless) trouble-shooting skills.  I started by creating a new, blank Arduino project.  Into this project I placed code to simply echo whatever I typed on the serial command line to the serial view window.  To this I added a few lines to make the laser pointer blink on/off, just to provide a visual “I’m alive!” indication, and then tested it.  After all errors were made/corrected, etc, the final code was as shown below.

asd;lfkjsaf;
al;skfdj

The next step was to extend the echo loop to include Serial1, with a simple jumper between Tx1 and Rx1 on the Mega board.  In the software all this required was Serial1.begin(9600) in Setup() and the addition of the code to route command line bytes out Tx1 and to route received bytes on Rx1 to Tx0 so that it would get displayed on the serial monitor.  The code to do this is shown below:

The next step was to extend the loop beyond Serial1 and into the Mongoose, by replacing the jumper from Tx1 to Rx1 with the Mongoose board’s Rx & Tx lines respectively, and replacing the normal Mongoose code with the turn-around (echo) code.  No change should be required to the Arduino code, as it will still be echoing whatever shows up at Rx1 to Tx0.

The Mongoose code is:

When this code was loaded into the Mongoose  and run stand-alone, I got the following output by typing ‘this is a test’ on the serial port command line.

After  the Mongoose was disconnected and placed into the robot circuit, I got the following output from the Robot project on a different comm port.

So, it is clear from the above that the Mongoose board connected (through the step-up/down circuitry on the Wixel shield) to Rx1/Tx1 is successfully receiving and echoing whatever shows up on its serial port.

Now it was time to reload my modified version of CK Devices ‘Mongoose_base’ firmware back onto the Mongoose and get it running with Wall-E’s firmware.  After the usual number of hiccups and such, I got it running and nicely reporting ‘Tilt’ (X-axis accelerometer) and ‘Heading’ (derived from 3-axis magnetometer values) along with the normal robot telemetry values, as shown in the printout below.

Final version showing Mongoose Tilt & Hdg values integrated into normal robot telemetry

Although  the Mongoose module  has been successfully integrated into the robot system from a technical standpoint, there is still plenty of work to be done to complete the project.  At the moment (see the photo below), it is just kind of ‘hanging around’ (literally), so some additional work will be required to mount it properly.  Stay tuned! ;-).

Mongoose installed loosely on Wall-E2

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