Laser PING 2m Rangefinder: How dust, luminosity and vibration affect measurements?

I’m planning on using LaserPING 2m Rangefinder sensors to control an aircraft maintenance platform.
I would like to know how dust (for example when the aircraft is being painted), luminosity and vibrations affect measurements.

Thank you in advance!


  • Tracy AllenTracy Allen Posts: 6,505
    edited 2019-09-05 - 23:33:32
    Here is a graph I made some time back of a laserPing output, when a piece of cardboard was placed 240 mm distant, without vibrations or issues of uneven lighting. I include it to illustrate that there is bobble in the reading at the mm level even with a steady target. What is your expectation for accuracy with this platform? The graph shows the raw data and also that filtered through first a 3-point median filter, followed by a r^(15/16) exponential filter. (Using the serial interface to the laserPing.)

  • Hey Tracy,

    Can you provide a text file of the raw data or an Excel file of everything you did? I'd like to try something.


  • We found similar things with the VL6180 (10cm range), Tracy. The distribution seemed pretty Gaussian, however, so looked like some fitting would yield good results.
    We also managed to run the VL6180 beyond its 50 samples/second spec a bit (maybe 90 samples/sec?)

  • I should say, we're also interested in using the VL6180's in some kind of array, so watching closely
  • Tracy AllenTracy Allen Posts: 6,505
    edited 2019-09-06 - 07:27:25
    I haven't been able to find the original data file that went with that data. Maybe it's on a computer at work, work done near the time ...LaserPing released.

    I think we had surmised that the laserPing was based on an RFD77402 (RF Digital). Ah so ST Micro is in the game too. That's interesting about the VL6180 gesture sensor based on "time of flight" technology. I see there is also the VL53L1X, which seems uncannily comparable to the RFD7702 for longer distance sensing. The ST roadmap for that line of TOF sensors is found here.
  • Tracy AllenTracy Allen Posts: 6,505
    edited 2019-09-10 - 22:45:47
    I don't know what happened to the original file, but I still have the hardware and the program, so I repeated the experiment. This time out to 2000 samples, here with the Excel file. Hmmm, can upload neither excel nor text. Oh, text okay but has to have .txt extension.

    1212 x 506 - 221K
  • I don't know what happened to the original file, but I still have the hardware and the program, so I repeated the experiment. This time out to 2000 samples, here with the Excel file. Hmmm, can upload neither excel nor text.


    Strange; XLS used to be able to be attached. Just ZIP and it should upload. TXT does not upload/attach?
  • Tracy AllenTracy Allen Posts: 6,505
    edited 2019-09-10 - 22:51:21
    Added data for 1 meter distance. The laserPING is looking at bright white paper taped to an off-white wall.
  • Tracy AllenTracy Allen Posts: 6,505
    edited 2019-09-10 - 23:19:27
    The text file wouldn't upload unless it in fact has the txt extension. Error:


    By the way, here is the Propeller program, laserPING0.spin that produced the above data.
    {for Parallax #28041 laserPING module
    After putting laserPING into serial mode(as opposed to pwm mode)
    streams readings from laserPING at 9600 baud.  ~45ms between readings, depends on distance.
    converts ascii stream to long and filters using 3 step median and then exponential filter.
    Streams all three results to serial terminal at 115200.
    author: Tracy Allen, use without restrictions.
      _clkmode = xtal1 + pll16x                '
      _xinfreq = 5_000_000
      PING_PORT = 3
      PING_PIN = 23
      uarts : "fullDuplexSerial4pnf"
    PUB main | char, lowpass, first, x0,x1,x2, median, idx
      uarts.AddPort (PING_PORT,-1,PING_PIN,0,9600)  ' initially transmit on PING_PIN
      uarts.Tx (PING_PORT,"I")           ' This puts the laserPING in serial data mode (three 100µs pulses)
      waitcnt(clkfreq/10+cnt)    ' delay 1/10 second
      uarts.Init                        ' be sure to init before changing uart settings
      uarts.AddPort (0,31,30,0,115200)   ' debug port
      uarts.AddPort (PING_PORT,PING_PIN,-1,0,9600)   ' now PING_PIN is input, only receiving from laserPING
      uarts.Str (0,string(13,"press any key to start",13))
      repeat until idx==2001
        if (char := uarts.Rxcheck(PING_PORT))>0
          if char => "0" and char =< "9"
            result := result*10+(char-"0")
          elseif char == 13
            uarts.DecPW (0,++idx,0,4)
            uarts.DecPW (0,result,0,7)
            if first    ' initialize numerical filters
              lowpass := result << FILTER_EXPONENT   ' exponential
              first := 0
              median := x2 := x1 := x0 := result   ' 3-point median
              x2 := x1
              x1 := x0
              x0 := result
              median := (x0 #> x1) <# (x0 <# x1 #> x2)
              lowpass := lowpass - (lowpass >> FILTER_EXPONENT) + median
            uarts.DecPW (0,median,0,7)
            uarts.DecPW (0,lowpass>>FILTER_EXPONENT,0,7)
            result := 0
  • PublisonPublison Posts: 11,508
    edited 2019-09-10 - 23:01:19
    XLSX is not supported, has to be saved as just XLS. I guess we are behind the times. :(

    I could view the text file.
  • Tracy,

    The text file is fine and easy to import into Excel. Thanks for uploading this! I want to try the data with the mean/median FIR algorithm that I use with CO2 sensor data.

  • Phil,
    I'll be interested to see the results of the algorithm. A five- or seven-point median might be significantly better.

    I just acquired 6 new EE894 CO2 sensors for a project in micro-greenhouses, hoping they will live up to their claim of outstanding long-term stability.

  • Tracy AllenTracy Allen Posts: 6,505
    edited 2019-09-11 - 22:07:15
    The 15 point median improves the focus quite a bit, to +/- 1cm.
    Measurement to white indoor wall at ~1meter, 1985 samples.
    raw, range 921 to 1077 mm.
    3-point median, range 931 to 1062
    7-point median, range 939 to 1013
    15-point median, range 990 to 1007 (less than 1 second's worth of sampling)
    31-point median, range 994-1005 . (not shown on chart)

  • Tracy,

    I ran my filter on your data to see how it compares with the others. What I do is take the 20 most recent values, sort them, and average the central 10, discarding the five at either end. On the graph here, this is what I call the "Avg. of Medians." I also added a 10-reading-wide boxcar average and modified your exponential to

    yi = 0.9 * yi-1 + 0.1 * xi

    keeping the fractional values.

    Here's the graph:


    In my CO2 app, I don't do a running "Avg. of Medians" but, rather, collect n data points, inserting them into an array in order using a binary search, and averaging the central 50%. I then discard the array and start over. The running Avg. of Medians would be harder to do in Spin, since it would require a re-sort for each new data point. I'll have to think about that to see if I can come up with a shortcut.

    What would be more interesting than this static distance measure would be to move the target suddenly to get an idea of the impulse response for each filter.

    1049 x 487 - 41K
  • Tracy AllenTracy Allen Posts: 6,505
    edited 2019-09-12 - 22:27:20
    The impulse and step response a running median filter is easy enough to figure. For a step response to a big enough change, it is a delay, 1/2 the length of the filter (+1). For an impulse, the output is shortened by 1/2 the length of the filter. That may amount to total rejection of the impulse, which is often the goal of the median filter, yes?

    The mixed filter involving the average of the middle quartiles is interesting. A big enough step (running) takes 5 samples to start having an effect in a 20-sample buffer, then 5 more samples to get roughly halfway to the new value. Say 10 samples.

    The equivalent for the exponential, yi = 0.9 * yi-1 + 0.1 * xi
    solve for n, 0.9^n = 1/2 give n = 6.6 samples to 1/2 the distance between the old and the new values.

    Of course all this merely establishes a baseline expectation for the thread topic of the effect of vibration etc.

    For a running median, I keep the data values (longs) in a circular buffer in the order that they occur, and associate with that a ranks table (bytes), which is what gets sorted. The first element points to the lowest data value, the middle element points to the median and so on. The ranks table is already almost sorted when each new element comes in, so it doesn't require total resort for each new element. Bytemove can help speed things up in a variation of an insertion sort.
Sign In or Register to comment.