I have just joined this forum and would appreciate help with the correct value for sensor configuration for the Lidarlite-3HP. The library says:
configuration: Default 0.
0: Default mode, balanced performance.
1: Short range, high speed. Uses 0x1d maximum acquisition count.
2: Default range, higher speed short range. Turns on quick termination
detection for faster measurements at short range (with decreased
accuracy)
3: Maximum range. Uses 0xff maximum acquisition count.
4: High sensitivity detection. Overrides default valid measurement detection
algorithm, and uses a threshold value for high sensitivity and noise.
5: Low sensitivity detection. Overrides default valid measurement detection
algorithm, and uses a threshold value for low sensitivity and noise.
lidarliteAddress: Default 0x62. Fill in new address here if changed. See
operating manual for instructions.
------------------------------------------------------------------------------*/
In my application, I am interested in fast acquisition of objects that are about 25 feet away. What is the optimal value?
Depending on how fast you need your measurement needs to be I’d say you should aim at either 3 (slower) or 0. That being said, since every environment is different and many factors can come into play the best would be to simply create a test rig (known target at multiple known distances) in the environment you expect to use the sensor and run a few dozen measurements under the different expected conditions using the values 0, 1, 2, 3, 4, 5 and see what gets you the best results. This would show you quickly what works best.
I have a lot of experience with these sensors extending to over 10 months.
The problem with your recommendation is that it is not possible to test in our case because we are counting THOUSANDS of short interval incidents per day. The object (incident) is 25 feet away from the sensor but the typical incident time is only about 130 ms.
In this case, what value is the most appropriate? BTW, 3 does not work (incidents are too few relative to what is observed). 0 is a compromise but still not good.
Thanks again and I would appreciate your thoughts.
My application is a car counter. We place a Lidarlite on an overpass looking down on a lane at the traffic below (please see attached image). We then check if the beam is broken which indicates the passage of a vehicle. We then count the number of vehicles.
We have tried using different sensor config values but each ends up giving a different number of vehicles. It is also not easy to compare to manual counts given that some lanes may have upwards of 13000 vehicles daily .
So my question is what is the optimal sensor config value for this application?
@jimmie
Thank you for all the details. This certainly gives me a better idea of what you need!
It may very well be that you have the wrong sensor, actually. The LIDAR-Lite (and many other LIDARs) are meant for collision avoidance or distance measurement, but not necessarily for counting objects. Especially since you are using it close to its maximum range and in a non-optimal situation (poor reflectivity, non-optimal angle, varying interference, etc.) which can delay the readings therefore providing erroneous data.
If you wish to stick with LIDARs, this series of products probably make a lot more sense. They have multiple beams and are meant for outdoor use in many situations including with cars.
Another product that may be even better is mm-wave radar technology/sensors such as these. These literally have traffic monitoring as one of their typical applications in the product brief.
If you do decide to stick with the LIDAR-Lite, I’d recommend that you find a way to both reduce the distance between the sensor and target and also place it perpendicular to the travel direction instead. This working will also depend on how fast the vehicles are traveling vs the sensor measurement rate. In such a case you’d want to have the sensor aiming at a reflective plate that the vehicle passes in front of. That way the sensor always gets a signal back (that is strong, either the plate or the vehicle) and therefore can perform measurements faster, too.
Thank you for your time in responding to my inquiry .
I have been an early adopter of Leddartech products. We have been using their sensors for years (including in a similar application). It will not work here because of cost. They are more than 5 times more expensive. It is true they can handle more than one lane but cost is still an issue.
As far as sensor placement, for practical and safety reasons, it cannot be placed in the direction of travel also because we need a count for each travel lane. This is the same reason radar will not work (hard to restrict its beam coverage) to a single lane.
The best way to help me is to communicate my question to Garmin. They have an excellent product but non-existing technical support! I believe anyone in Garmin with knowledge of that sensor should be able to respond to my inquiry.
I do not buy enough sensors from Garmin for them to give a damn but you do :-).
As far as I know the software suite for the OMN products can handle multiple objects in their FoV. You may be able to actually only use one for multiple lanes.
I’ll see what I can do but cannot promise a working solution/answer. You are after all using it for a use case that it is not designed for in a situation that accentuates the weaknesses of such a technology. Don’t get me wrong, the sensor has great specs in this price range but it is optimized for specific uses that are not yours. I’ve contacted the manufacturer on your behalf and I’ll post here again once I have more info.
I’m certain they (Garmin as a whole) care too in their own special way…
As for an actual answer, here’s what I have for you:
It is possible (if your sensors are from late 2018 - late 2019) that they have a (somewhat) faulty filter. What has happen with some customers is that the sensor - while operating at higher temperatures but still in specs - has the laser drift into a higher frequency. This is normally completely fine except some of the models have a filter that has a slightly off band and therefore can partially or completely block the return signal. This can cause anything from faulty/erratic values to no values at all (1 or 5 cm results; indicating no return signal). In your case since the sensors are used outside this may be a factor to consider.
I strongly recommend that you first check your sensor data for 1 / 5 cm values and also for erratic values, If you can, you can also try and collect range measurements in pair with temperature readings from a thermistor attached to the sensor/sensor enclosure (if you use/have one) and see if you have more misreads at a certain temperature range. Also, make sure to ensure maximum reading speed of the sensor using the example mentioned above (found here, line 220).
If you’ve purchased your LLV3 sensors from us directly we can offer to exchange them if the issue seems to be from temperature/laser frequency drift/filter blocking signal. Otherwise, contact your supplier for these sensors and see if they will provide an exchange. Any new (post 2020-01-01) stock has a proper filter that will work for the full temperature range that the sensor is spec’d for - all of our stock has this new filter worldwide.
We hope this information helps. Let us know how it goes!
THANK YOU VERY MUCH @scharette. I appreciate it and you have gone beyond the call. Also, please thank Garmin for me. As I said, it is actually impossible to reach their technical support staff (for me).
.