Tag Archives: robots

IR Light Follower for Wall-E2, Part VI

Posted 04 November 2016

As I described in my previous post on this subject, the OSEPP IR Follower is a nice module, but its IR detector arrangement seems to be ill-suited for my intended application, which is to implement an IR homing capability to allow my wall-following robot to autonomously home in on a charging station so it can recharge its batteries and (hopefully) wander the house indefinitely (or at least until one of the cats figures out how to kill it!).

As shown in the following detection vs angle plot for the OSEPP module, there is a dead zone of about 20 º between IR detector beam edges. This dead zone makes it very difficult to determine the proper steering value to feed to the motors for homing, as it is basically impossible to determine which dead zone the IR beacon beam is hitting.

Results from fourth heading tests on bench-top range. For this test, the idea was to determine the approximate beamwidth of each detector

It would be much nicer if the individual IR detector beams overlapped at their respective half-power points, so that dead zones would be completely eliminated. This requires that the beam centers be spaced at the same value as the half-power beamwidths, i.e. about 15 º. So, a six-detector array would span 90 º instead of 180 º

Looking over my electronics parts hoard, I see that I have some Oshram SFH309FA-4 phototransistors on hand that should do the trick, and as a bonus, these units have a 24 º half-sense beamwidth instead of 15 º, which means I can do a 72 º span with just four units – yay!!

OSRAM SFH309FA-4 phototransistor specs, page 1

OSRAM SFH309FA-4 phototransistor specs, page 2

Using the wonderful DipTrace schematic capture package, I whipped up a circuit using 4ea of the above phototransistors, 4ea 1K load resistors, and a 0.1uF noise suppression cap for good measure, as shown below

Wall-E2 IR Follower circuit diagram

My first try at a module design is shown below. Because the print time is so short (~9 min) and the cost is so trivial, it’s easier and faster to just take a stab at the design, print it, and then repeat as necessary to optimize the solution. The down side, if you can call it that, is that it is so easy to make small adjustments to the design that it is hard to stop – there’s always ‘one more small thing’ that can be done to make the product just a little bit better ;-).

First try at a 4-element IR Follower array

Posted 07 November 2016: USA Presidential Election Eve!

After a few more versions, I had one that I liked. To test the idea, I mounted the new module onto the old ‘sunshade’ just for mechanical stability, and added the 6-pin right-angle header (4 detectors plus pwr & gnd) and one photodetector, as shown here

Trial assembly of 4-detector module

This seemed to be OK, so I went ahead and built up the 4-detector module, as shown in the following photos

Bottom side of assembled 4-detector module, showing all 4 detector emitters tied to ground

Top view of completed 4-detector module. Note load resistors are now 330K for better sensitivity

Front edge view of completed 4-detector module

Edge view of completed 4-detector module

After verifying that the module was indeed operational, I ran a range test at 24″ from the IR LED. I really didn’t have a good way of attaching a heading circle printout to the new module, so I simply taped the 4-detector module to the top of the OSEPP module’s sunshade as shown. This let me use the same heading circle printout I used before – clever if I do say so myself! ;-).

Completed 4-detector module taped to original OSEPP module to utilize existing heading printout

After getting everything working, and modifying the Arduino program for 4 detectors vice 6, I ran a detector output vs angle test at a range of 24″ from the IR emitter, as shown.

24″ test range for the completed 4-detector module

4-detector heading test results

The results came out better than I could have hoped. As can be seen from the data and the plot, I’m getting close to the expected 24 º beamwidth, and it is clear that there are no dead zones between detector minimums. For every angle between 45 º and 130 º there is no ambiguity as to which detector(s) are active, and how to steer to home in on the emitter.

A couple of side notes:

My original design (see above) used 1K load resistors, but I soon found that to be way too low – the detectors could barely detect the IR emitter from less than 6″ away. After some empirical testing, I finally settled on 330K as a reasonable compromise that allows decent response from approximately 1m away.
I discovered that the OSRAM photodetectors are not at all sensitive to my LED bench lamps, or to my overhead LED track lighting, due to (I believe) the visible light rejection coating on the detector lens assembly. This means I no longer need the sunshade at all, which should make the physical mounting issue much easier to deal with.

The next step is a big one, and will require a fair amount of work. I’ll need to physically mount the new module on Wall-E2, wire it into the Mega controller, and modify the program to exploit the new capability. At the moment, Wall-E2 is a mild state of dis-repair, so this all may take some time. No worries – I’ve got plenty of that (I hope).

IR Light Follower for Wall-E2, Part V

Leave a reply

Posted 04 November 2016

As a result of my now extensive testing with the OSEPP IR Follwer module, I have become convinced that it’s just not going to work for my intended IR homing application. As shown in the following plot (copied from a previous post), the six detectors each have a usable spatial detection width of about 10-15 º. However, because they are mounted to cover a 180 º, there is a ‘dead zone’ of about 20 º between each detector position.

Results from fourth heading tests on bench-top range. For this test, the idea was to determine the approximate beamwidth of each detector

If the IR homing beam falls into one of these dead zones, it will be very difficult to generate an appropriate steering value, so steering behavior will probably be more like a ‘bang-bang’ setup than something that can be used to home in on my planned charging station.

The good news is I learned a lot during this exercise, and one of the things I learned is that I don’t really need most of the circuitry on the OSEPP module. I wound up using only the analog outputs from the OSEPP module, and according to the OSEPP schematic shown below, this is just the raw detector voltage.

OSEPP IR Follower schematic. Note the analog out is just the raw detector voltage

So, using my trusty PowerSpec 3D Pro 3D printer I should be able to fabricate my own IR detector array, with the detectors spaced closely enough so that their half-power beam edges overlap significantly. That should mean that I can determin the IR homing beam angle-of-arrival (AOA) within just a few degrees, which in turn should mean much more accurate and continuous steering information.

Stay tuned!

Frank

IR Light Follower for Wall-E2, Part IV

Leave a reply

Posted 02 November 2016

After arriving at a ‘sunshade’ design that completely blocked overhead IR source interference, I went back to my bench-top range to re-do the directionality testing. To do this I printed out a scaled copy of my 4-Inch Heading Circle graphic from a previous project, and modified it to serve as a heading indicator for the IR follower tests, as shown below

Heading circle image, modified for heading tests. Penciled numbers are detector designators

Heading test setup. IR emitter LED is clamped to the bench vise in the background.

To perform the tests, I created a small Arduino program to read and print out the analog readings from all six IR photodetectors, and recorded the results in a Excel spreadsheet. Then, using Excel’s superb graphing tools, I plotted the outputs, as shown below.

Results from first heading tests on bench-top range. Minimum values for each photodetector are highlighted

As can be seen in the above results, the photodetectors read around 700-900 when no IR is present, and 50-60 when the detector aligned with the IR beam. As can be seen, the heading response for each individual detector was rather narrow, with the minimum occurring at only one heading, with essentially zero detection on either side of the minimum value. These results are a bit problematic, as the wide ‘dead zones’ between detection angles may make it difficult to derive good motor steering commands for IR homing.

To determine if the above ‘dead zone’ issue is due to the inherent directivity of the detectors or to the optical isolation provided by the sunshade vanes, I decided to manually pare back the isolation vanes in small steps to determine their influence on the dead zones, and to determine if I could do so without adversely impacting overhead IR source suppression. As a control, I took A/D readings with the LED emitter disabled, but with one overhead LED bench light turned on (this is known to be a strong IR emitter), as shown below:

A/D reading test with LED emitter OFF and one LED bench light ON. Note black foam piece blocking reflection from power strip in background

With this setup, I got the following readings with the IR LED disabled and the bench light ON:

LED1 LED2 LED3 LED4 LED5 LED6
712 796 847 864 731 818

Next, I removed 8mm from the central sunshade vane, as shown in the following photo, and repeated the heading test. The results don’t vary significantly from the first one, and lead me to wonder if the vanes are actually doing anything, or it just seemed that way because they were combined with a larger overhang going from sunshade V4 to V6.

Central vane length reduced by 8mm

Results from second heading tests on bench-top range, with central vane length reduced by 8mm. Minimum values for each photodetector are highlighted

Since the results from the test with 8mm removed from the central vane didn’t seem to be much different from the original, I removed another 4-5 mm so the front edge of the central vane matched the outer edge of the IR follower PCB, and repeated the test, as shown below

Central vane length reduced by 12mm

Results from third heading tests on bench-top range (12mm removed from central vane). Minimum values for each photodetector are highlighted

So, it is clear from the above that at least the central vane does not significantly alter detector behavior. After this, I decided to try and determine the approximate beamwidth of each detector. For the beam-edge point, I used an arbitrary reading of 200, as shown in the following Excel table and plot.

Results from fourth heading tests on bench-top range. For this test, the idea was to determine the approximate beamwidth of each detector

From the above, the approximate beamwidth for these detectors is about 10-15 deg. Since the vanes are set 36 degrees apart, they are well outside the photodiode detection angle, so that explains why removing the central vane had no significant effect. However, it does point up a potentially serious problem when attempting to use this arrangement for IR following; the photodiodes are set 36 degrees apart, with 15 degree beamwidths, so there will be a dead zone of approximately 20 degrees between each ‘live’ sector. This has two negative implications:

My idea of mathematically blending detector readings to produce a continuous steering error term for motor drive probably won’t work, or won’t work very well
The narrow detector beamwidth may be susceptible to multipath effects, where a narrow detector beam intersects a spurious reflection term from the IR emitter.

The next step is to produce another version of the sunshade with all 5 vanes cut back to the edge of the PCB, to verify that detector behavior doesn’t depend on the vanes, and to try some different IR emitters. The IR LEDs I have on hand at the moment are also narrow (i.e. 10-15 deg) beamwidths, but I have some 30 deg ones on order. Also, the current full saturation detection range is only about 20 cm, so I want to try some higher power emitters to see if I can get the range up to something practical – like 1.5-2 m.

Stay tuned!

Frank

03 November 2016 Note:

After installing the new sunshade with all vanes cut back to the outer edge of the PCB as shown below, the bench-top detector response vs angle test was performed again, with basically identical results to the previous one. This shows that the vanes aren’t needed at all, at least not the portion that extends past the edge of the PCB.

Sunshade with all vanes pared back to outer edge of PCB

04 November Note:

I acquired some Vishay TSAL6200 100mA 17 deg beamwidth IR LEDS (see spec sheet excerpt below), and ran some quick detection range tests with an LED current of about 60 mA, I was able to easily detect the IR signal at well over 1m. This distance is probably sufficient for initial detection in time for IR homing into my planned charging station, so I am reasonably optimistic that this just might come together ;-).

Vishay high-power IR LED. Max forward current = 100mA

IR Light Follower for Wall-E2, Part III

Leave a reply

Posted 29 October 2016

In my last post, I described the evolution of an IR ‘sunshade’ for the OSEPP IR follower board. The version 3 shade did indeed cut out most of the direct IR term from the overhead lighting, and most of the high-elevation multipath as well.

So, I set up some directional tests on my bench using an IR LED clamped in a small vise, with the OSEPP board sitting on a pad of post-it notes to achieve the proper elevation relative to the IR diode. I then wrote a short Arduino program to print out the IR detector analog values, to see if the board was directive enough for use as part of a IR homing setup.

Benchtop directionality testing setup. The transmitting IR LED is visible in the background, clamped in my bench vise

Unfortunately, the initial test results were not what I hoped for. Directionality response was erratic, with LED 1 (3 O-clock using the connector strip as 6 O-clock) responding better when the board was oriented directly toward the IR led than when boresighted on the IR emitter.

Board orientation for max response on LED1 (LED1 is oriented toward 3 O-Clock)

By moving an opaque 1/2″ mixing stick around, I was able to discern that the odd response angle It appears to be caused by IR energy being reflected from other internal structures on the board, although this doesn’t explain the lack of response on-boresight. So, I decided to add some internal isolation vanes to the sunshade in a ‘vane attempt’ (pun intended) to suppress internal reflections, as shown in the following image.

Sunshade V4, with detector isolation vanes installed

02 November 2016 Post:

As it turned out, the above sunshade wasn’t quite big enough, so I wound up going through two more versions before arriving at one that completely blocked overhead IR sources. The final design is shown below:

‘Final’ sunshade design

‘Final’ sunshade design. Note the manually cut away portions to clear PCB components

Final (hopefully) version of the sunshade, incorporating the PCB component clearance cutouts

IR Light Follower for Wall-E2, Part II

Leave a reply

Posted 28 October 2016

In my last post on this subject, I described the OSEPP IR Follower circuit I found at MicroCenter a few days ago, and my thoughts about incorporating it onto Wall-E2, my wall following robot. After a few tests, it became apparent that the OSEPP circuit is quite sensitive to IR, and in fact the LED track lighting in my lab puts out enough IR to swamp out the signal from my test IR emitter. So, I set about developing an ‘IR Shade’ to shield the detectors from elevated IR emitters (this turns out to be harder than I thought, due to IR multipath effects, but I digress).

So, my first attempt was a 3D printed ‘sunshade’ as shown below

IR Shade V1 – Top View: 1 mm thick, with approx 5 mm overhang

IR Shade V1 – Side View: 1 mm thick, with approx 5 mm overhang

This shade was 1mm thick, with about a 5 mm overhang on the IR detectors. The shade is supported via two posts that mate with mounting holes on the OSEPP board. When I tested this shade with my LED bench lamp, it basically didn’t do much. Apparently 1mm is nowhere near enough material :-(.

Next, I tried placing some black electrical tape on the shade, as shown below.

IR Shade V1 with black electrical tape – Top View

The black electrical tape helped significantly, which is how I found out about the IR multipath problem. Not only am I having to contend with blocking the direct path, reflections from nearby objects can also cause problems.

To address the direct path problem, I modified the shade design to be 3 mm thick, with 80% fill density vs the original 40%. Hopefully this will be enough to cancel out the direct path, leaving only the multipath issue. I don’t think there is much I can do about the multipath, other than assume that the field (i.e. the hallways in my house) won’t have that problem, as the lighting is mostly incandescent, and the ceilings are mostly 10 ft (3.3 m) away – we’ll see.

IR Shade V2. 3mm thickness, 80% fill

Even this one didn’t work as well as I’d hoped, so on to version 3 – with a larger overhang – about 8 mm. This one blocked all the direct path IR and most of the multipath as well. I’ll stick with this on for now, and move on to some steering tests.

The version 3 IR ‘sunshade’ with 7-8 mm overhang

IR Light Follower for Wall-E2, Part I

1 Reply

Posted Oct 26, 2016

As I was browsing among the aisles in my local MicroCenter store the other day, I ran across the OSEPP ‘IR Light Follower’, an Arduinio-compatible board featuring 6 IR photodiodes arrayed in a semicircle, as shown in the following screen grab.

IR follower description from the OSEPP website

After a moment of thinking ‘what the heck would you do with this?’, it hit me – I might be able to use this device to get Wall-E2, my wall following robot, to home in on my planned charging station by placing an IR emitter on the station, pointed along a likely wall-following approach route. Then, when Wall-E2 detects the IR emitter, it could transition from wall-following to IR homing mode, and voila – capture by the charging station! So, I decided to buy one and give it a whirl.

When I fired this guy up on my bench, I was surprised to find that ALL the small blue ‘IR detected’ LEDs lit up, as shown in the following photo

IR Follower on my bench. Note all the indicator LED’s are ON due to IR emissions from overhead LED lighting

After a bit of head-scratching, I realized that the sensor board’s optics were being ‘flooded’ by my lab’s overhead LED track lighting (I had noticed this behavior on an earlier IR-related project, so it wasn’t too big of a leap). After turning the room lights off, and rigging up an IR emitter a few inches away, I got the following results

Had to turn off the lights to eliminate IR flooding. The blue LED at upper left is the power-on indicator. IR emitter is at far right

At first blush, these initial results are very encouraging. the board is obviously sensitive enough to detect the output from a single IR LED emitter at a distance of about 6″, and has what appears to be reasonable directivity, but that’s about all I know at the moment. I have no idea whether or not that will translate into sufficient tracking accuracy for charging station capture, but I do plan to find out!

The current idea is to mount the board on the front ‘shelf’ of the robot, as shown in the following photo

Planned location for the IR follower board. I’ll have to build a ‘sunshade’ to prevent IR flooding from overhead lights

Of course, I’ll have to build some sort of sunshade to keep the sensor from being flooded by overhead lighting, but that’s what 3D printers are for ;-).

Stay tuned,

Frank

Wall-E2 Charging Station, Part I

Leave a reply

Posted 09/28/16

Ever since I started the Wall-E wall-following project, my goal has been to give Wall-E the ability to periodically recharge his battery without human intervention. Then Wall-E would be free to roam the house indefinitely, striking fear into the hearts of humans and cats alike! ;-).

The concept for the Wall-E charging station has gone through a lot of iterations, at least during my drifting-off-to-sleep conceptual design sessions. Eventually I settled on a concept where Wall-E would be captured by some sort of lead-in railing which would force it onto a raised platform containing the charging power supply. The platform would contain a set of spring-loaded contacts that would mate with contacts on the underside of Wall-E for charging power and for charging state control.

To start the process, I ran some tests to determine the basic requirements for the lead-in structure. To support these tests, I modified Wall-E’s code to emulate its tracking behavior, but with an on-off push-button so I could run multiple tests without Wall-E running away.

As the following video snippet shows, my first idea of a low-sided lead-in wall was defeated in short order by Wall-E’s motor torque and soft, knobby wheels.

Giving Wall-E2 A Sense of Direction, Part X

1 Reply

Posted 15 August 2016

In my last post on this subject, I described a series of ‘field’ tests of the magnetometer on Wall-E2, my wall-following robot. These tests demonstrated that the magnetometer was operating properly, but heading results were unusable due to significant distortion of the magnetic field along the west (garage-side) wall of the entry hallway.

This post describes a similar test in an interior hallway. The interior hallway in our home is oriented orthogonally to the entry hallway, i.e. at 110/290 deg magnetic. The walls are about 1 m wide, and constructed of standard wooden stud and sheet rock construction. There are several rooms opening off this hallway, but all the entry doors were closed for this test.

As shown in the movie and the associated Excel chart, the robot starts at the west end headed east, travels the length of the hallway, maneuvers around for a while, and finishes up headed west. During the first and last 10-15 seconds of the run, Wall-E2 is physically heading in a more or less constant direction (about 110 deg in the first part, about 290 deg in the last part).

Wall-E2 heading results from interior hallway run

Unfortunately, the Excel chart shows a different story. During the first 15 seconds of the run, there is a definite linear change in the average heading, from about 25 deg to about 75 deg, even though the robot is physically tracking along a wall that is oriented at about 110/290 deg. During the last 15 seconds or so, the opposite happens; there is a linear downward trend from about 300 deg to about 225 deg. These trends are physically impossible, so the only possible explanation is that either the magnetometer readings are in error, or there is something in or near the interior hallway that is distorting the earth’s magnetic field enough to produce these results.

I had hoped that the interference noted in the previous post was due to the common wall with the garage and its associated metal structures, and that the interior hallway would be free of such problems, but apparently this is not the case. So, I’m now forced to consider other ideas for interior geo-location.

Stay tuned!

Frank

Giving Wall-E2 A Sense of Direction, Part IX

Leave a reply

Posted 12 August 2016

For the last several months (or was it years – hard to tell anymore) I have been trying to implement a magnetic heading sensor for Wall-E2, my wall-following robot. What started out last March as “an easy mod” has now turned into a Sisyphean ordeal – every time I think I have one problem figured out, another (bigger) one pops up to ruin my day. The first problem was to re-familiarize myself with the CK Devices ‘Mongoose’ IMU, and get it installed on the robot. The next one was to figure out why it didn’t work quite the way I thought it should, only to discover that sensitive magnetometers don’t really appreciate being installed millimeters away from dc motor magnets – oops! So, that little problem led me into the world of in-situ magnetometer calibration, which resulted in my creation of a complete 3D magnetometer calibration utility based on a MATLAB routine (the tool uses Windows WPF for 3D visualization, and Octave for the MATLAB calculations – see this post). After getting the calibration tool squared away, I used it to calibrate the Mongoose unit (now relocated to Wall-E2’s top deck, well away from the motors), and once again I thought I was home free. Unfortunately, reality intruded again when my ‘field testing’ (in the entry hallway of my home) revealed that there were places in the hallway where the magnetometer-based magnetic heading reports were wildly different than the actual physical robot orientation, as reported in my July post on this subject.

After the July tests, I knew something was badly wrong, but I didn’t have a clue what it was, so I decided to put the problem down for a while and let my subconscious poke at it for a while. In the interim I had a wonderful time with my two grandchildren (ages 13 & 15) and a real 3D printing geek-fest with the younger of the two. I also got involved in creating a small audio amplifier in support of the Engineering Outreach program here at ‘The’ Ohio State University.

So now, after almost a month off, I’m back on the case again, trying to make sense of that clearly erroneous (or at least non-understandable) data, as shown below (repeated from my previous post)

July continuous run test, showing two areas where the reported headings don’t match reality

The two areas marked with ‘???’ correspond to the times where the robot was traversing along the west (garage side) wall of the entry hall, the first time going north, and the second time going south. The robot was clearly going in a mostly constant direction, so the data obviously doesn’t reflect the robot’s actual heading. However, on the other (east) side of the entry hallway, the data looks much better, so I began to think there was maybe something about the west wall that was screwing up the magnetometer data.

As usual with experimentation, it is important to design experiments where the number of variables is kept to the minimum, ideally just one. By keeping all other parameters fixed, any variation in the data must be due solely to that one variable. In this case, there were several variables that needed to be considered:

The anomalous data might be due to some changes in motor current. When the robot is wall following, there are constant small changes to the left & right motor currents. When the robot encounters an obstacle, it backs up and spins around, and this entails radical changes in motor current direction and amplitude.
The anomaly might be due to some timing issue. It could be, for instance, that the heading data from the magnetometer is coming in too fast for the comm link to handle, so it starts becoming decoupled from the actual robot position/orientation, and then catches up again at some other point.
The anomaly might be due to some physical characteristic of the entry hallway. The west side is where the most obvious anomalies occurred, and that wall is common with the garage. Maybe something in the garage (cars, tools, electrical wiring, …) is causing the problem.

Using my new magnetometer calibration utility, Wall-E2’s magnetometer has been calibrated with the motors running and with them off, and there was very little difference between the two calibration matrices. Moreover, my bench testing has shown very little heading change regardless of motor current/direction. So although I couldn’t rule it out completely, I didn’t see the first item above as a viable suspect.

Although I haven’t seen any timing issues during my bench testing, this one remained a viable suspect IMHO, as did the idea of a physical anomaly, so my experimental design was going to have to discriminate between these two variables. To eliminate timing as the root cause, I ran a series of experiments in the entry hallway where the robot was placed on a pedestal (so its wheels were clear of the floor) at several fixed spots in the entry hallway, and heading data was collected for several seconds at each point. The following images show the layout and the robot/pedestal arrangement

Experimental layout. Blue spots correspond to numbered/lettered position in layout diagram

Wall-E2 on a pedestal so motors can run normally without moving the robot

Wall-E2 on a pedestal (at position ‘A’ in diagram) so motors can run normally without moving the robot

10-12 August Mag Heading Field Test Layout

Data was collected at the positions shown by the numbers from 1 to 5 along the west (garage) wall, and by the letters from A to F along the east wall. At each position the robot was placed on a pedestal and allowed to run for several seconds. If the heading errors are caused by the physical characteristics of the hallway, then the collected data should be constant for each spot, and the data should correspond well to the heading data from my earlier continuous runs.

The above graphic shows the results of all 10 test positions. For each position, data was collected with the robot oriented ‘north’ (actually about 020 deg) and ‘south’ (actually about 200 deg), as denoted by the small black orientation arrows. The ‘north’ heading results are represented by the blue arrows, and the ‘south’ heading results are represented by the orange arrows. There is no meaning associated with the length of the arrows.

Results:

Northbound and southbound data are almost exactly opposite each other at all points. To me, this indicates that the 3-axis magnetometer data and the heading values derived from that raw data are valid.
The data clearly shows that there is a significant magnetic interferer in the vicinity of the west (garage) wall of the entry hallway. The west wall data is skewed more significantly than the east wall results, indicating that the magnitude of the interference decreases from west to east. Since mag field intensity decreases as the cube of the distance, I infer that the interferer is very close to the west wall (if it were farther away, then the difference between the east and west wall results would be smaller, because the distance difference would be smaller).
The data at each position corresponds well with data from the same position and orientation from the various continuous runs. Given a continuous run and the knowledge of the interference pattern, it is possible to determine the robot’s location to a fair degree. The following image shows the heading results from a 10 August continuous run, labelled with the position numbers from the entry hall layout diagram. The positions were deduced from a movie of the run.

10 Aug continuous run, labelled with positions from the entry hall layout diagram

Conclusions:

The magnetometer and the heading calculation algorithm are probably working correctly
Magnetic interference is certainly a problem in the entry hallway next to the garage, and may (or may not) be a problem elsewhere
Magnetic heading information may not be reliable/accurate enough to determine location with any precision, even coupled with left/right/front distances.

My next task is to run some continuous and step-by-step tests in other areas of the house, to determine if the entry hallway issue is unique to the house or an ubiquitous problem.

Stay tuned!

Frank

Giving Wall-E2 A Sense of Direction, Part VIII

Leave a reply

Posted 07/19/16

In my last post on this subject, I described moving my CK Devices ‘Mongoose’ IMU from a wooden stalk mounted on the 2nd deck to a more compact bracket mounted in the same location, and showed some data that indicated reasonable heading performance. This post describes some ‘field’ (a hallway in my home) test results using the bracket-mounted configuration.

Field Test Site:

My ‘field test’ site consists of two hallway sections in my home. The two sections are oriented about 45 degrees to each other, as shown in the following diagram.

Field test area physical layout, oriented north-up

For my first ‘Field Test’, I simply set Wall-E2 loose at position 1, pointed in the direction shown in the diagram, and recorded via the wixel-pair wireless connection implemented last December. Wall-E2 successfully navigated (with a few ‘back-and-forth’ iterations) from point 1 to point 8 in the diagram, as shown in the following short video.

The captured telemetry data included the run time in seconds and the magnetic heading in degrees, and I sucked this information into Excel, where I graphed the mag heading versus time, as shown in the following screenshot.

Heading vs Time for Wall-E2 continuous run. Areas of puzzlement marked by ‘????’

As the caption notes, most of the graph makes sense, but there are at least two different areas where there is a more-or-less linear change of heading versus time, where there shouldn’t be any (or at least, where I don’t *think* there should be any). Either Wall-E2 has some tricks up his sleeve that he wasn’t telling me about, or I don’t fully understand how the data and the physical record (the video) correspond.