30 September, 2015

Sad to say, but I believe I have ‘hit the wall’ on development of an effective spinning-LIDAR navigation system for Wall-E.  Even with a souped-up spinning platform (approx 3 rev/sec), I have been unable to reliably navigate a straight hallway, much less recover from stuck conditions.  In addition, the combination of drive motor currents and the increased current required to drive the spinning platform at the increased rate drains  the battery in just a few minutes.  So, I have reluctantly concluded that the idea of completely replacing the acoustic sensors with a spinning-LIDAR system is a dead end; I’m going to have to go back to the original idea of using the acoustic sensors for wall following, and a fixed-orientation LIDAR for stuck detection/recovery.

I started down the spinning-LIDAR road back in April of this year, after concluding a series of tests  that proved (at least to me) that the use of multiple acoustic sensors was not going to work due to intractable multi-path and self-interference problems.  In a follow-up post at the end of that month, I speculated that I might be able to replace all the acoustic sensors  with  a spinning-LIDAR system for both wall following and ‘stuck detection’.  At the time I was aware of two good candidates for such a system – the NEATO XV-11 robot vacuum’s spinning-LIDAR subsystem, and the Pulsed Light ‘LIDAR-Lite’ component.  I chose to pursue the Pulsed-Light option because it was much smaller and lighter than the XV-11 module, and I thought it would be easier to integrate onto the existing Wall-E platform.  Part of the appeal of this option was the desire to see if I could design and build the necessary spinning platform for the LIDAR-Lite device, based on a 6-wire slipring component available through AdaFruit.

In the time since that post at the end of April, I successfully integrated the LIDAR into the Wall-E platform, but only recently got to the point of doing field tests.  The first set of tests showed me that the original spin rate of about 120 RPM (about 2 RPS) was way too slow for successful wall following using my original ‘differential min-distance’ technique, and so I spent some time investigating PID control techniques as a possibility to improve navigation.  Unfortunately, this too proved unfruitful, so I then investigated ideas for increasing the LIDAR’s spin rate.  The LIDAR spinning platform is driven by a drive belt (rubber O-ring) attached to a pulley on a separate 120 RPM DC motor.  My original setup used a pulley ratio of approximately 1:1, so the motor and LIDAR both rotated at approximately 120 RPM.  By increasing the diameter of the drive pulley, I was able to increase the LIDAR rotation rate to approximately 180 RPM (about 3 RPS), but unfortunately even that rate was too slow, and the increased drive motor current rapidly drained the batteries – rats!

So, while I had a LOT of fun, and learned a lot in the process, it’s time to say ‘Sayonara’ to the spinning-LIDAR concept (at least for Wall-E – still plan to try the XV-11 module on the 4WD robot) and go back to the idea of using acoustic sensors for wall following and a forward-looking LIDAR for obstacle avoidance and ‘stuck’ detection.

Stay tuned!

Posted 17 September, 2015

After getting the improved tachometer assembly  integrated into Wall-E’s spinning LIDAR setup, I decided to repeat the hallway  field testing that I performed back in July of this year (see this post for the details).  My ‘theory of navigation’ for wall following is that I should be able to determine Wall-E’s orientation relative to a nearby wall by looking at where the spinning LIDAR’s minimum distance measurement occurs relative to Wall-E’s ‘nose’.

Just as I did back in July, I placed  Wall-E a short distance away from a long straight wall, in three different orientations – parallel, 45-deg nose-in, and 45-deg nose-out.  For each of these orientations I let the spinning LIDAR ‘look’ at the wall for about 10 revolutions, and then I manually changed the orientation. The distance and angle (actually the interrupt number, but that is the same as the angle) values were recorded in a text log.

The text log was arranged as shown in the following screenshot.

Next, I wrote an Excel VBA script to parse the text log file and extract just the half of each revolution where the LIDAR was scanning the nearby wall, skipping over the half.  For each such scan, I searched the distance data for the minimum value, capturing that value and its associated interrupt number (i.e. angle).  All the extracted distance values and the min dist/min angle numbers were written to the spreadsheet, and then I plotted the mininum distance interrupt  number (i.e. angle) vs rev number for about 90 LIDAR revolutions.

If my theory holds water, then I should be able to see variations in the minimum interrupt number over time that corresponds to the orientation changes.  As shown in the following plot, that is exactly what happens.

As can be seen in the above plot, the Min-Dist-interrupt (MDI) starts out between 4 and 5, and stays there for the first 9-10 revolutions.  At about rev 11, it jumps to the 7-8 range, where it stays until about rev 20. The it drops back to 5-6 for 10 revs, and then drops again to the 2-3 range.  This pattern then repeats for the duration of the plot.  In my current spinning LIDAR configuration, Interrupt 1 starts at Wall-E’s tail, and proceeds along Wall-E’s left side to interrupt 10 at the nose.  So, an MDI of 4-5 should correspond to the parallel orientation, while a lower number should correspond to nose-out and a higher one to nose-in.  From the test condition description, Wall-E was placed parallel for 10 revs, then nose-in for 10, then nose-out for 10, then back to parallel, repeat.    It is clear from the plot that the actual behavior of the MDI matches the predicted behavior quite nicely – EUREKA!! ;-).

Although the above test results are quite encouraging, it is still not entirely clear that this technique can actually be used for effective navigation at practical travel speeds.  There is undoubtedly some correlation between the spinning LIDAR rotation rate and the maximum travel speed at which the LIDAR can provide information fast enough for effective steering.  For instance, the NEATO XV-11 spinning LIDAR system rotates at about 300 RPM (5 RPS), and it seems to travel no faster than about 1-2 m/sec.  This might mean that my 120 RPM (2 RPS) spin rate would only support travel speeds in the 0.5-1 m/sec range.  In addition, my current 18-degree resolution may be too coarse for effective steering.  Again using the XV-11 as a baseline, it has a resolution of 1 degree, 18 times mine.  With the much faster speed of the new V2 ‘Blue Label’ Pulsed Light LIDAR, I could probably double or even triple my current angular resolution, but 18X might be a bit much ;-).

Next up – analyzing the data from a simulated navigation test, where I manually pushed Wall-E along the hallway, simulating as close as possible how I think Wall-E might navigate, assuming the spinning LIDAR data is fast enough and accurate enough.  As I moved Wall-E along, I recorded the same distance and interrupt number data as before, so it will be interesting to see if this data continues to support my current ‘theory of navigation’ – stay tuned!

22 September 2015 Update:   The data from the simulated navigation test was a mess – nothing recognizable as a pattern.  The one thing it  did do was convince me that the ‘angle of least distance’ idea wasn’t going to work – and that something else was going to have to be done. What, I don’t know  yet…

Frank

 

Posted 16 September, 2015

Back in June of this year I posted about my initial efforts to implement a tachometer subsystem as part of a spinning-LIDAR system (see ‘LIDAR-Lite Gets its Own Motor‘),  This implementation used a ‘plugged gap’ technique for detecting the index position of the LIDAR, as shown below.

The idea was that when the time between gap interrupts was more than 2 gap durations (assuming a relatively constant rotation speed), then the ‘plugged gap’ must be between the IR LED and the photo-diode.  This design  works OK, but has a couple of nagging drawbacks:

• It depends on a fixed  open-loop timing delay; if the motor RPM varies enough, the fixed delay threshold might be too large or too small.
• The plugged-gap technique removes two interrupt positions from the wheel, meaning that position information is missing during that 54-degree arc.

So, after getting my V2 ‘Blue Label’ LIDAR from Pulsed Light and figuring out how to use it (see this post), I decided to see what I could do about addressing  both the above problems.  At first I  thought I might be able to simply add a second photo-diode on the sensor side of the tach sensor assembly, coupled to the existing single IR LED via a slanted channel in the tach wheel, as shown below.  The idea was that when the interrupt was fired at the edge of the index gap, the value of the  ‘other’ sensor could be read – if the value was below a certain threshold (meaning more impinging IR energy), then that sensor must be lined up with  the index hole.  This meant that the index hole needed to be offset from the index gap, so the max energy receive position would coincide with the position at which the interrupt fired, which occurs at the gap edges,  not the center.

This turned out to be a miserable failure.  The IR LED’s have a very narrow illumination sector, and there wasn’t enough off-axis energy to reliably detect the index hole.

So, some five versions later, along with a complete redesign of the sensor assembly, I have what I think is a nicely working implementation.  The single LED slanted-hole design was scrapped in favor of a two-LED/sensor one, and the index sensing hole was replaced by a circumferential gap, as shown below.

 

For the tach sensor assembly, the single IR LED was replaced by two independent IR LED’s, each with its own 240-ohm current-limiting resistor (I tried running them in series with a single resistor, but that didn’t work very well either).  The original enclosed sensor slot was replaced by an exposed ‘trough’ with two retainer bars (the trough without the retainer bars didn’t work either).  See below for the ‘new improved’ tach sensor assembly.

 

 

After running some preliminary tests, I mounted  the new tach wheel and sensor assemblies and ran some O’scope tests to see how the new design worked.  I was  very pleased to see that it appears  to be working better than I could have hoped.  In the following O’scope photo, the top trace is the index sensor, and the bottom trace is the normal tach-gap sensor.  Both are 2 volts/cm and exhibit full 5-volt swings.

The gap interrupt of interest occurs at the first rising edge of the bottom trace.  As can be seen from the photo, reading the value for the index gap sensor (top trace) at this point will retrieve a stable ‘0’ value, perfect for index gap detection!

The following photos show the new tach wheel and sensor assembly mounted on Wall-E, with the LIDAR assembly removed for clarity.

Stay tuned for more test results from this configuration!

Posted 17 September, 2015:

After re-installing the LIDAR and making all the right connections (not a trivial task, btw), I fired the system up using my ‘DAFAP_Plus’ (that’s. “Distance as Fast as Possible’ plus modifications for interrupt handling) sketch and took some index sensor measurements.  In the screenshot below, the ‘Sensor’ values are from the index sensor.  As expected, they are near the top of the 10-bit A/D range for interrupt numbers 1-19 (a reading of 700 implies about 3.5VDC).  However, the sensor reading for interrupt 20 is now  much better than it was before; before implementing the improved LED driver and new tach wheel layout, the max readings were about the same, but the minimum reading was occasionally  over 400 (i.e. about 2VDC) – making it harder to reliably discriminate between non-index and index gap  cases.  Now the index gap reading is a reliable ‘0’, providing a 3.5VDC differential – more than double the 1.5VDC  differential before – yay!!

Another item of note in the readout below is the ISR Ms value.  This is the time required to service the associated interrupt,  including the time required for the Pulsed Light ‘Blue Label’ LIDAR to take a distance measurement. Note that all of these times are in the single digit range – meaning I could probably double the number of tach wheel gaps (i.e. double the system angular resolution) if I wanted to.  Note that there is an extra value shown for each ‘interrupt 20’ line; this ‘Idx Ms’ value is the total time between index gap appearances, i.e. the total rotation time.  So, the LIDAR is rotating just a tad shy of 120 RPM (2 RPS), which should be fast enough for decent wall-following navigation.

 

Frank