Has anyone thought of hacking up one of the cheap laser rangefinders by Bosch or Stanley?
Bosch's DLE 50 only weighs about 180g including it's own batteries (could be removed and powered by onboard powersupply).
I am thinking of getting one of the units and seeing if I can somehow mod it to use it as an altimeter.

Views: 3418

Reply to This

Replies to This Discussion

After poking around for a good 15mins looking for information I can't find anything about how long it takes to get a measurement..
I am thinking it would wait for a stable measurement anyways (useless for us.. we will never get one whilst flying), so it's more so the actual laser diode and reciever setup that I am interested in.
If I could get it to give me the raw data I could filter it pretty easily and it would make a very nice altimeter. :)
Yet to find a DIY project for a time of flight laser rangefinder yet..
If anyone has anymore info regarding this please share, I am very interested in developing a low cost laser altimeter for UAV landing purposes.
I only have this info on the Sharp IR distance sensors. Not very expensive (Sparkfun has couple of versions). Do not know how stable it may be (attached couple of links).

Some here posted some results with the EZ4 sonar sensor, that hd 1cm resolutions down to 0cm (so the manufacturer claims) and out to 5m. I think it needed some filtering, and taller grass caused some issues.

I think some people got good results with the SCP1000, which what I have been reading, in theory can achieve 8cm resolutions.
Cheers Tom.

Will see if I can get ahold of a couple and get something happening with them.
Also I am landing on tarmac or mowed strips so sonar is defintely an option for me because I have nice flat surfaces to work with.
Cheers mate
Shame the thread never got anywhere but good info all the same.
Will see if I can get one and get something started with it.

I was messing around the EZ4 sonar sensor using this program I found. It allows you to smoothen the readings out by taking a series of readings (you set the number) and averages them at the end.

Under ideal conditions it seems to work very accurately (about 1 inches incerments), but when moving it around a room with several objects (furniture, etc), I get a lot of false or maxed out readings. I think the program needs a little more discriminative coding to make it work reliably as a short distance sensor.

Will mess around some more to see if I use it stricktly as a "down-pointing altimeter" instead of horizontal distance measurment device would lead me to reliable readings.
Thanks again Tom,
I was thinking of doing a little bit more complex filtering than just an average of the previous few results but yep the idea is the same.
I think the issue with sonar based sensors is multipathing.
As in the signal can bounce off lots of stuff and arrive back at the reciever via a number of paths, each longer and shorter. This makes the readings inaccurate of course.
Primary this would be caused by conditions such as you described, a closed room full of furniture.
The sound would bounce foward and back but it could also bounce off a chair, up into a wall, then the ceiling and finally back to the sensor, but the two readings will be vastly different.
I am thinking the best option will still be a laser altimeter for this reason as the beam is much narrower and multipathing is effectively impossible.
Just thinking out loud.... I am sure this could be/has been put in a better way.

I think with some AI-like programming, one could isolate in most cases the right bounced back signal, or skip some of the false ones.

For example, in a simplified way, if you assume that the last several readings (let's say 40 out of 50) were returning 30 inches, and 10 returned 20 inches, for the duration of the 50 reading pulse the program should return 30 inches as the result, vs the average of the 50 readings at 28 inches.

Now if for example 10 sets of 50ea readings return a gradually changing reading over time (1st 50= 28; 2nd 50 = 27; 3rd 50=26, etc) , or a sudden, but firm change (1st 50 =30; 2nd 50 = 30; 3rd 50 = 20; 4th 50 =20; 5th 50 = 20, etc) , and if other parameters are considered (speed input, orientation of sensor, etc) the program could assume that the readings are correct. This would filter any suspect data for example 1st 50 = 30; 2nd 50 = 30; 3rd 50 = 100; 4th 50 = 80; 5th 50 = 30; 6th 50 =30, etc) instead of taking the averages of the readings as the final value. In this example, it would return 30 as the value. The question is, how can we find a balance between a responsive and usable reading code vs time passing processing the filtering.

Would like to find a code that has such logic and see how they solved the filtering. This just shows how far behind I am when it comes to data filtering... :)
Hmm, I think there is only so much time you can spend on the filtering.. like really how many readings per second does this thing take?
On a more serious note about a solution to this it would be more viable to just take the sensor out attached to an Arduno or something and just take a whole bunch of readings at know altitudes and save them or transmit them via serial for logging so that you could get a good idea of the variation in data.
That is what I would do and plan on doing with any system that will be developing for altitude readings.
Agree. Empirical data, outdoors, should make a much better laboratory than inside a room.

Please post any progress.

I got the parts and planning to test the SCP1000 and the Sharp IR distance sensor soon.
I've looked into ideas for a cheap laser range finder, and what I'd like to try is a CMUcam1 ($109, link below) and a powerful laser pointer. Optical filters can be purchased and fitted over the lens of the camera to filter out unwanted light wavelengths. The CMUcam has pre-programmed algorithms for tracking specific colors that it picks up, so just tell it to track the color of the laser. Sturdily mount the camera and laser at a fixed distance from each other, and the laser dot will move up and down on the screen as the assembly is moved back and forth from the surface.

Aye, the trigonemetry method.
Those this method has it's uses I would much prefer to use a time-of-flight setup.
Much more accurate and alot less sensitive to issues.

Reply to Discussion



Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service