Laser PING 2m Rangefinder: How dust, luminosity and vibration affect measurements?
maria_noronha_costa
Posts: 11
Hey!
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!
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!
Comments
Can you provide a text file of the raw data or an Excel file of everything you did? I'd like to try something.
Thanks,
-Phil
We also managed to run the VL6180 beyond its 50 samples/second spec a bit (maybe 90 samples/sec?)
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.
Strange; XLS used to be able to be attached. Just ZIP and it should upload. TXT does not upload/attach?
By the way, here is the Propeller program, laserPING0.spin that produced the above data.
I could view the text file.
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.
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)
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.
-Phil
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.