Monthly Archives: June 2015

LIDAR-in-a-Box: Testing the spinning LIDAR

Posted 6/26/2015

After getting the Pulsed Light LIDAR-Lite mounted on a spinning pedestal, and the whole thing mounted on Wall-E, it is now time to try and figure out how to use this thing to accurately map a room for navigation.

In my previous work I had developed a 10-gap (actually 9, with the 10th gap replaced by an index plug) interrupter (I no longer use the term tachometer, as it is no longer used for speed control) wheel so I could generate a rotationally-constant set of LIDAR measurement trigger signals, so I could generate 18 measurements per revolution (one for the start and end of each interrupter wheel gap.  The idea was to capture these measurements (along with a computed angle and a time stamp) into an 18-element array.  The array contents would be continually refreshed in  real time, and then the navigation algorithm could then simply grab the latest values from the array as needed.

As always, there were a number of ‘gotcha’s’ associated with this strategy

  • As currently constituted, the LIDAR is spinning at about 120 rpm – i.e. about 500 msec per rotation or about 1.4 deg/sec.  Divide 500 by 18 and you get about 28 msec per interrupt time.  However, a single measurement takes about 10-20 msec, which means that the distance number returned by the measurement routine isn’t where you think it is – it is rotationally skewed about 15-20 degrees – oops!
  • The number returned by the measurement routine is computed by measuring the width of a pulse generated by the LIDAR that is proportional to distance.  Unfortunately, this number incorporates a constant offset which must somehow be calibrated out so the result is the actual distance from some physical reference point.

In summary, we aren’t quite sure where we are looking when we measure, and there is an unknown constant error in the distance measurements.  So, how to address?  The answer is the LIDAR-in-a-Box technique, as shown in the following photo.

LIDAR positioned as close as possible to center of box

LIDAR positioned as close as possible to center of box

The idea here is to constrain the experiment to a well known geometry, which should allow both the angular and distance offsets to be determined independently of the measurements themselves.  In the photo above, the LIDAR unit itself was positioned as close to the center of the box as possible, and the LIDAR line of sight was adjusted relative to the interrupter wheel such that the LIDAR unit points straight ahead when the interrupt at the trailing edge of the index plug occurs.  This resulted in the following ‘radar’ plot:

Excel 'Radar' plot of  LIDAR Lite mounted as centrally in a 28 x  33 cm box

Excel ‘Radar’ plot of LIDAR Lite mounted as centrally in a 28 x 33 cm box

In the above ‘Radar’ plot, the salient points are:

  • There is an offset of approximately 30 cm in all the distance measurements
  • Measurements appear to be skewed angularly about 60 degrees from physical reality.  I would have expected one of the two short sides to be lined up perpendicular to the 0-180 degree line, but it isn’t.  Unfortunately, it is hard to tell from this plot which of the 4 sides is the ‘front’ and which are the back and/or sides.

So, I set up another experiment, with the LIDAR unit positioned as close as possible to one of the short (28 cm) sides (as shown in the following photo), and 30 cm subtracted from each measurement.

LIDAR positioned as close as possible to one end of box

LIDAR positioned as close as possible to one end of box

The LIDAR unit relationship with the interrupter wheel was again adjusted so that it is pointed straight ahead when the index plug trailing interrupter gap starts. This was verified by triggering the co-axially mounted red laser pointer with this same interrupt, as shown in the following video (watch where the laser pointer ‘dash’ appears)

 

This time the Excel ‘Radar’ plot is a bit more understandable

LIDAR unit positioned as close as possible to one short side

LIDAR unit positioned as close as possible to one short side

Now the plot more accurately reflects the actual box dimensions, and it is now clear which end is the ‘front’ side.  Moreover, it is easy to see now that the ‘forward’ direction on the plot is skewed about 30-60 degrees from the actual physical situation.  The point labelled ‘1’ on the plot should contain the value that is actually plotted opposite point ‘2’, so I suspect what is happening is that the time required for the measurement subroutine to actually return a value is on the order of one interrupt gap time after the time at which the measurement is triggered.  If this is true (to be determined with future experiments), I should be able to correct for this with some ‘index gymnastics’ i.e. putting the measurement from interrupt N in the table at location N-1.

06/28/15 Update:  Here’s a plot with measurements stored in the location immediately preceding the interrupter gap number.  For instance, the measurement at gap 3 is stored in the 2nd dta_array location rather than the third, and so on.  As can be seen, the box outline is now much better aligned with ‘straight ahead’.

Excel 'Radar' plot under the same conditions as before, but with the measurement storage location shifted one location 'down'

Excel ‘Radar’ plot under the same conditions as before, but with the measurement storage location shifted one location ‘down’

Stay tuned!

Frank

 

 

LIDAR-Lite Visible Laser Testing

Posted 6/20/15

In my last post (Lidar-Lite Gets it’s Own Motor), I discussed how I might test the new LIDAR installation, and one of the options was to mount a visible laser diode on the LIDAR, to act as a pointing reference.  This post shows some results from that effort.

First, I used TinkerCad and my trusty 3D printer to design and fabricate a mount for the laser diode.  The collar rings are spring-loaded onto the LIDAR optical tubes, with the laser diode mounted on the LIDAR’s central axis, as shown below:

Laser diode mounted along LIDAR central axis

Laser diode mounted along LIDAR central axis

Next, as an initial feasibility test, I connect the laser diode power line to a digital output that toggled on/off at each successive interrupt signal from the LIDAR tach wheel.  These interrupts occur at approximately 25-35 msec intervals, so I was curious to see whether or not such a short laser pulse would be visible.  To answer this question, I mounted a piece of paper in an arc around the LIDAR/laser diode unit, and watched – sure enough, the laser pulses were visible!

The following shots show a) the LIDAR pointing toward the camera with the laser ON; b) the LIDAR pointing toward the paper with the laser ON; c) a movie of the operation.

LIDAR facing the camera, with the laser diode ON

LIDAR facing the camera, with the laser diode ON

LIDAR pointed toward the paper screen with the laser diode ON.

LIDAR pointed toward the paper screen with the laser diode ON.

 

As a further test, I modified the test program to only enable the laser diode for the 10 msec period immediately after index plug detection, and then manually rotated the LIDAR mount relative to the tach wheel so the LIDAR unit was pointing (more or less) straight ahead when the interrupt at the end of the index plug occurred.  If everything was working properly, I should see a single 10msec laser pulse at the same spot on the paper every revolution.  The following short movie shows the result

From the testing so far, two things have become clear:

  • The visible laser diode is an effective tool for visually refrerencing the LIDAR’s look direction under rotation
  • Laser pulses as short as 10msec can be easily detected by eye on a suitable target in typical office lighting, at least for relatively short ranges.  Longer ranges can be achieved by simply turning off the lights in the room.

The Duplicate Bridge ‘Blame’ Chip

Posted 6/17/2015.

A favorite topic among duplicate bridge players is just who’s to blame for a particular screw-up.  Bridge is a somewhate unique sport in that it requires two players per side, and both players in a partnership contribute to success or failure.  A really good player can make up for many (but not all) mistakes by a weaker player, but winning partnerships require that both players minimize their mistakes. Most established (and all successful) partnerships have developed a way of handling the blame issue in a way that doesn’t degrade or destroy the partnership.  One pair that I know describes this process as ‘blame management’.  The idea, so they say (somewhat tongue-in-cheek) is to bid in a way that ensures that any blame for mistakes will fall on one’s partner rather than oneself.  This incentivizes each partner to bid as correctly as possible given the partnership agreement (their convention card) and the particular circumstances at the time.  Having ‘a bright idea’ and ‘going off piste’ might work, but if it doesn’t the blame will fall squarely on the errant partner (and even if it does work, it might incur significant blame for not adhering strictly to the partnership agreement).

I liked this idea of ‘blame management’ so much that I have tried to incorporate it into my own partnerships; I try to get the idea of blame management out in the open early on, so my partner is (hopefully) comfortable with the idea of assigning blame in an open and humorous way, rather than letting issues fester.  Lately I have started describing this as ‘moving the blame chip from one side of the table to the other’, and that got me thinking that maybe I could use my engineering and 3D printing capabilities to fabricate an actual, physical ‘Blame Chip’.

I started this project as I do almost all my new projects – researching on the internet with Google.  I found card and pip images, and then I found a set of zip files with 3D models of all the various card elements.  From this I extracted the 4 pips I needed (clubs, hearts, spades, diamonds), and arranged them circularly around the word ‘BLAME’, as shown in the following screenshot.

TinkerCad design for the Duplicate Bridge Blame Chip

TinkerCad design for the Duplicate Bridge Blame Chip

Then I printed it on my MicroCenter 3D Pro 3D printer, using blue and white (the two colors I had on the machine at the time).  Here are some photos of the result.

3D printed version of the 'Duplicate Bridge Blame Chip'.  The chip laying on the pen is actually two chips glued together to form a 2-sided chip.

3D printed version of the ‘Duplicate Bridge Blame Chip’. The chip laying on the pen is actually two chips glued together to form a 2-sided chip.

The items that come off the printer are blank on the reverse side, so to get a real 2-sided ‘poker chip’ style item, I simply printed two chips and glued them together.  In the photo above, the chip leaning on the pen is a 2-sided version, while the others are single-sided.

I’m not really sure where I’m going with this, as the sudden appearance of a real, physical ‘blame’ chip at the table may have unintended (read ‘disastrous’) consequences.  My wife has suggested these might make great bridge party favors, and I may try giving some of these away to established partnerships before I get too ambitious. Also, I will probably try printing some with white pips on a red background to see how they look.

Frank

 

LIDAR-Lite Gets its Own Motor

Posted June 16, 2015

In my last post (http://fpaynter.com/2015/05/lidar-lite-rotates/ – over a month ago – wow!) I described the successful attempt to mate the Pulsed Lite LIDAR with a 6-channel slip ring to form a spinning LIDAR system for my Wall-E wall-following robot.  As an expedient, I used one of Wall-E’s wheel motors as the drive for the spinning LIDAR system, but of course I can’t do that for the final system.  So, I dived back into Google and, after some research, came up with a really small but quite powerful geared DC motor rated for 100 RPM at 6 VDC (In the image below, keep in mind that the shaft is just 3mm in diameter!)

 

Very small 100RPM geared DC motor.  See http://www.ebay.com/itm/1Pcs-6V-100RPM-Micro-Torque-Gear-Box-Motor-New-/291368242712

Very small 100RPM geared DC motor. See http://www.ebay.com/itm/1Pcs-6V-100RPM-Micro-Torque-Gear-Box-Motor-New-/291368242712

In my previous work, I had worked out many of the conceptual challenges with the use of an offset motor, O-ring drive belt, and slip ring, so now the ‘only’ challenge was how to replace Wall-E’s temporarily-borrowed wheel motor with this little gem, and then somehow integrate the whole thing onto the robot chassis.

The first thing I did was come up with a TinkerCad design for mounting the micro-motor on the robot chassis, and the pulley assembly from the previous study onto the motor shaft.  Wall-E’s wheel motor has a 6mm shaft, but the micro-motor’s shaft is only 3mm, so that was the first challenge.  Without thinking it through, I decided to simply replace the center section of the previous pulley design with a center section sporting a 3mm ‘D’ hole.  This worked, but turned out to be inelegant and WAY too hard.  What I should have done is to print up a 3mm-to-6mm shaft adapter and then simply use all the original gear – but no, I had to do it the hard way!  Instead of just adding one new design (the 3mm-to-6mm adapter), I wound up redesigning both the pulley and the tach wheel – numerous times because of course the first attempts at the 3mm ‘D’ hole were either too large or too small – UGGGGGHHHH!!

Anyway, the motor mount and re-engineered pulley/tach wheel eventually came to pass, as shown below.  I started with a basic design with just a ‘cup’ for the motor and a simple drive belt pulley.  Then I decided to get fancy and incorporate a tach wheel and tach sensor assembly into the design.  Rather than having a separate part for the sensor assembly, I decided to integrate the tach sensor assembly right into the motor mount/cup.  This seemed terribly clever, right up until the point when I realized there was no way to get the tach wheel onto the shaft and into the tach sensor slot – simultaneously :-(.  So, I had to redesign the motor ‘cup’ into a motor ‘sleeve’ so the motor could be slid out of the way, the tach wheel inserted into the tach sensor slot, and then the motor shaft inserted into the tach wheel ‘D’ hole – OOPS! ;-).

Assembled Miniature DC Motor Mount

Assembled Miniature DC Motor Mount

Miniature DC motor with chassis mount and belt drive wheel

Miniature DC motor with chassis mount and belt drive wheel

Miniature DC motor partially installed in chassis mount

Miniature DC motor partially installed in chassis mount

MotorTachAssy1

Miniature DC motor mount, with tach sensor attachment, side/bottom view

Miniature DC motor mount, with tach sensor attachment, side view showing motor contact cover

Miniature DC motor mount, with tach sensor attachment, side view showing motor contact cover

Miniature DC motor mount, with tach sensor attachment, top view

Miniature DC motor mount, with tach sensor attachment, top view

Completed assembly, with drive belt pulley and tach wheel

Next up – the LIDAR mount.  The idea was to mount the LIDAR on the ‘big’ side of the 6-channel slip ring assembly, and do something on the ‘small’ side to allow the whole thing to slide toward/away from the motor mount to adjust the drive belt tension.  As usual, I didn’t have a clue how to accomplish this, but the combination of TinkerCad and 3D printing allowed me to evolve a workable design over a series of trials.  The photo below shows the LIDAR mounted on the ‘big’ side of the slip ring, along with several steps in the evolution of the lower slide chassis mount

Evolution of the slide mount for the LIDAR slip ring assembly

Evolution of the slide mount for the LIDAR slip ring assembly

The last two evolutionary steps in this design are interesting in that I realized I could eliminate a lot of structure, almost all the mounting hardware, and provide much easier access to the screw that secures the slide mount to the robot chassis.  This is another huge advantage to having a completely self-contained design-fabrication-test loop; a new idea can be designed, fabricated, and tested all in a matter of a half-hour or so!

Original  and 2nd versions of the LIDAR slip ring assembly mount

Original and 2nd versions of the LIDAR slip ring assembly mount

Once I was satisfied that the miniature motor, the tach wheel and tach sensor assembly, and the spinning LIDAR mount were all usable, I assembled the entire system and tested it using an Arduino test sketch.

 

After a few tests, and some adjustments to the tach sensor setup, I felt I had a workable spinning LIDAR setup, and was optimistic that I would have Wall-E ‘back on the road again’ within a few days, proudly going where no robot had gone before.  However, I soon realized that a significant fly had appeared in the ointment – I wasn’t going to be able to accurately determine where the LIDAR was pointed – yikes!  The problem was this; in order to tell Wall-E which way to move, I had to be able to map the surroundings with the LIDAR.  In order to do that, I had to be able to associate a relative angle (i.e. 30 degrees to the right of Wall-E’s nose) with a distance measurement.  Getting the distance was easy – just ask the LIDAR for a distance measurement.  However, coming up with the relative angle was a problem, because all I really know is how fast the motor shaft is turning, and how long it has been since the index plug on the tach wheel was last ‘seen’.  Ordinarily this information would be sufficient to calculate a relative angle, but in this case it was complicated by the fact that the LIDAR turntable is rotating at a different rate than the motor, due to the difference in pulley diameters – the drive ratio.  For every 24mm diameter drive pulley rotation, the 26mm diameter LIDAR pulley only rotates 24/26 times, meaning that the LIDAR ‘falls behind’ more and more each rotation.  So, in order to determine the current LIDAR pointing angle, I would have to know not only how long it has been since the last index plug sighting, but also how many times the drive pulley has rotated since the start of the run, and the exact relative positions of the drive pulley and the LIDAR at the start of the run.  Even worse, the effect of any calculation errors (inaccurate pulley ratio, roundoff errors, etc) is cumulative, to the point where after a few dozen revolutions the angle calculation could be wildly inaccurate.  And this all works only if the drive belt has never slipped at all during the entire run.  Clearly this was not going to work in my very non-ideal universe :-(.

After obsessing over this issue for several days and nights, I finally came to the realization that there was only one real solution to this problem.  The tach wheel and sensor had to be moved from the motor drive side of the drive belt to the LIDAR side.  With the tach wheel/sensor on the LIDAR side, all of the above problems immediately and completely disappear – calculation of the LIDAR pointing angle becomes a simple matter of measuring the time since the last index plug detection, and calculation errors don’t accumulate.  Each time the index plug is detected, the LIDAR’s pointing angle is known precisely; pointing angle calculation errors might accumulate during each rotation, but all errors are zeroed out at the next index plug detection.  Moreover, the pointing angle calculation can be made arbitrarily accurate (to the limit of the Arduino’s computation capability and timer resolution) by using any per-revolution error term to adjust the time-to-angle conversion factor.  As a bonus, the motor no longer has to be speed-controlled – I can run it open-loop and just measure the RPM using the tach wheel/sensor.  As long as the motor speed doesn’t change significantly over multiple-revolution time scales, everything will still work.

So, back to TinkerCad for major design change number 1,246,0025 :-).  This time I decided to flip the 6-channel slip ring so the ‘big’ half was on the chassis side, and the ‘small’ half was on the LIDAR side, thereby allowing more room for the new tach wheel on the spinning side, and allowing for a smaller pulley diameter (meaning the LIDAR will rotate faster for a given motor speed).  The result of the redesign is shown in the following photo.

Revised LIDAR and DC motor mounting scheme, with Tach wheel and sensor moved to LIDAR mount

Revised LIDAR and DC motor mounting scheme, with Tach wheel and sensor moved to LIDAR mount

In the above photo, note the tach sensor assembly is still on the motor mount (didn’t see any good reason to remove it.  The ‘big’ (non-spinning) half of the slip ring module is mounted in a ‘cup’ and secured with two 6-32 set screws, and the tach wheel and LIDAR belt pulley is similarly mounted to the ‘small’ (spinning) half.  The tach sensor assembly is a separate peice that attaches to the non-spinning ‘cup’ via a slotted bracket (not shown in the photo).  The ‘big’ slip ring half is secured in the cup in such a way that one of the holes in the mounting flange (the black disk in the photo) lines up with the IR LED channel in the tach sensor assembly.  The tach wheel spins just above the flange, making and breaking the LED/photo-diode circuit.  Note also how the slip ring ‘cup’ was mounted on the ‘back’ side of the drive belt tension slide mount, allowing much better access to the slide mount friction screw.  The right-angle LIDAR bracket was printed separately from the rest of the LIDAR assembly to get a ‘cleaner’ print, and then press-fit onto the pulley/tach wheel assembly via an appropriately sized hole in the LIDAR bracket.   The following movie shows the whole thing in action

 

In the above movie, note the quality of the tach sensor signal; it is clamped to the voltage rails on both the upper and lower excursions, and the longer ‘high’ signal of the index plug is clearly visible at the far right of the oscilloscope screen.

Details of the Tach Wheel:

Wall-E’s spinning LIDAR system features a tachometer wheel with an ‘index plug’, as shown below.  Instead of a series of regularly spaced gaps, the gap in one section is missing, forming a triple-width ‘plug’ that allows me to detect the ‘index’ location.  However, this means that instead of 20 equally spaced open-to-opaque or opaque-to-open transitions, there are only 18, as two of the transitions are missing.  In addition, the LIDAR pointing angle isn’t as straightforward to calculate.  If the trailing edge of the ‘index plug’ is taken as 0 degrees, then the next transition takes place at 18 degrees, then 36, 54, 72, 90, … to 306 degrees.  However, after 306, the next transition isn’t 324 degrees – it is 360 (or 0) as the 324 and 342 degree transitions (shown in red in the diagram below) are missing.  So, when assigning pointing angles to the interrupt number, I have to remember to multiply the interrupt index number (0 – 17) by 18 degrees (17*18 = 306).  This also means that there is no ability to ‘see’ obstacles in the 54 degree arc from 306 to 360 degrees.

 

Diagram of the tach wheel for Wall-E's spinning LIDAR system

Diagram of the tach wheel for Wall-E’s spinning LIDAR system

Next Steps: Now that I have a LIDAR rotation system that works, the next step is to design, implement and test the program to acquire LIDAR distance data and accurately associate a distance measurement with a relative angle.  With the new tach wheel/sensor arrangement, this should be relatively straightforward – but how to test?  The LIDAR will be spinning at approximately 100 RPM, so it will be basically impossible to simply look at it and know where it is/was pointing when a particular measurement was taken, so how do I determine if the relative angle calculations are correct?

  • I could put the whole think in a large cardboard box like I did with the XV-11 NEATO spinning LIDAR system (see ‘Fun with the NEATO XV-11 LIDAR module‘); If the (angle, distance) data pairs acquired accurately depict the walls of the container over multiple runs, that would go a long way toward convincing myself that the system is working correctly.  I think that if the angle calculation was off, the lines plotted in one run wouldn’t line up with the ones from subsequent runs – in other words the walls of the box would blur or ‘creep’ as more data was acquired.  I could also modify the box with a near-distance feature at a known relative angle to Wall-E’s nose, so it would be easy to tell if the LIDAR’s depiction of the feature was in the right orientation.
  • I could mount a visible laser (similar to a common AV pointer) to the LIDAR so I could see where it is pointing. This would be a bit problematic, because this would simply paint a circle on the walls of the room as the LIDAR spins.  In order to use a visible laser as a calibration device, I’d need to ‘blink’ it on and off in synchronism with the angle calculation algorithm so I could tell if the algorithm was operating correctly.  For instance, if I calculated the required time delay (from the index plug detection time) for 0 degrees relative to the nose, and blinked the laser at that time, I should see a series of on/off dots directly in front of Wall-E’s nose.  If the dots appear at a different angle but are stationary, then I have a constant error term somewhere.  It they drift left or right, then I have a multiplicative factor error somewhere.

I think I’ll try both techniques; the box idea sounds good, but it may take a pretty large box to get good results (and I might even be better off using my entire office), and it might be difficult to really assess the accuracy of the system.  I already have a visible laser diode, so implementing the second idea would only require mounting the laser diode on top of the LIDAR and using two of the 6 slip ring channels to control it.   I have plenty of digital I/O lines available on the Arduino Uno, so that wouldn’t be a problem.

RobotGeek Laser, Item# ASM-RG-LASER available from Trossen Robotics (TrossenRobotics.com)

RobotGeek Laser, Item# ASM-RG-LASER available from Trossen Robotics (TrossenRobotics.com)

Stay tuned!

 

Frank