With a range in excess of 100m and able to measure over water, the SF11/C is the most cost effective laser altimeter for drones on the market today. Compatibility with Pixhawk and derivative flight controllers and its multiple interfaces including serial, I2C, analog and USB make the SF11/C the easiest plug-and-play solution for altitude holding, terrain following and safe landing.
The SF11/C was developed to handle the unpredictable real-world conditions that sensors face when attached to a drone. Environmental factors including vibration, wind, noise, temperature fluctuations and extreme contrasts in lighting from brilliant sunshine to pitch dark are all managed by the SF11/C, and whilst all this is going on, the SF11/C measures to rapidly changing terrain, giving stable results over wet and dry surfaces without producing false readings.
Tests conducted by the Center for Research into Ecological and Environmental Modeling at the University of St Andrews in Scotland demonstrated the abilities of the SF11/C over wetlands and open water. Their requirement for consistent results under these difficult conditions were easily met by the SF11/C, contributing to important conservation work.
An important characteristic of the SF11/C is its long measuring range. This is especially useful during changes of roll or pitch angle. Data from the IMU is used to correct for geometric effects during such maneuvers, but this only works correctly when there is valid measurement data from the laser. The long measuring range of the SF11/C makes this possible as you can see from the graph below.
The green line is the roll angle, the purple line is the barometric height referenced to sea level and the red line is the uncorrected, AGL altitude from the SF11/C. During tight turns the measured distance increases significantly but the long range capability of the SF11/C keeps the ground clearly in view.
More details about the SF11/C can be downloaded from the website. The SF11/C is manufactured by LightWare Optoelectronics (Pty) Ltd based in South Africa. LightWare has been designing and manufacturing laser altimeters for the drone market for 5 years and is committed to providing high quality products to the industry. The official distributors in the USA are Parallax and Acroname.
Special thanks go to the dev team for their contributions to the driver software and Tridge for his tireless and occasionally incendiary flight testing ;).
@Steven Verver - Hi Steven, my apologies for the problem that you are experiencing but thank you for the excellent data. I was able to duplicate you conditions and compare my results with yours.
Before continuing, I must mention that the SF11/C was originally designed for long range operation and we didn't specifically optimize the short range performance for hovering close to the ground. Instead, we kept the SF10 family available for high accuracy, short range applications.
However, we have seen a tremendous increase in the number of people looking for both close range and high altitude operation. Terrain following and other tightly controlled flight profiles have become an important requirement for commercial drones so we decided several months ago to extend the capabilities of the SF11/C to make it a more universal solution, with both high stability at short range and long range capability in a single unit.
I've taken one of the latest SF11/C units (firmware revision 1.2) and repeated your tests on USB power and on my PixHawk. There was no noticeable difference in the distance reading or the stability of the results. One possible difference in the testing is that my PixHawk isn't powering anything else so there might be an issue with noise on your the power rails.
The most important difference in my results when compared with yours is the short range stability. I'm getting an error of ±1cm at 4.8m with the filters off. This makes me think that both the instability and the reading offset that you are seeing is a problem with the SF11/C and not necessarily because of the power supply voltage or noise from other devices connected to the same rail.
If you can send your unit back to us we will repair and upgrade it for you. I would be very interested to see if your results will then be significantly better. Here are my results:
I would also like to know about performance over forested areas, and forested mountain areas. Would like to use this on a multirotor for mapping purposes.
Hi Laser Developer, I'm having a hard time implementing a SF11/C on a Pixhawk-based drone (DJI F550 frame+DJI E305 ESC\motor combo).
My goal is to get a very precise hover in an indoor environment (so no gps) for inspection purposes. The target height is 10-30 meters. The first step for this is to get a good stable altitude. I'm trying to use the SF11/C as an addition to the internal barometer to get a precise altitude hold. It is connected to the Serial4 port of the pixhawk. My problem is that the altitude hold performance always degrades instead of improves when I enable the SF11/C. On seemingly random moments, the drone goes up and down 1-3 meters when the SF11 is on.
So, I did a lot of testing by enabling and disabling the median and adaptive filters in the SF11 settings menu's. I immediately noticed that when both filters are off, the drone would jitter continuously, as if the laser readings where very inconsistent.
To dig in this further, I mounted the SF11 statically to a wall, such that it would point at the opposite wall in a room which is at a distance of 4 meters. The room is lit with normal lights and the wall it covered with matte wallpaper. I compared the results with the adaptive filters on and off, and also compared the results when the SF11 is powered by the pixhawk or not. The results are here:
As you can see, there is a vast difference in precision when the SF11 is powered by the Pixhawk versus powered by the USB cable. The results aren't very good when it is powered by the Pixhawk, especially when the filters are off. One measurement was only 2,94 meter, which is 1,06 meter off from the real distance. Note that during these tests the SF11 is mounted statically to a wall, so it is completely still during the whole test.
As I suspected that my pixhawk might by suppling a dirty 5V, I also tried to power the SF11 via a BEC, the results are here:
As you can see results have improved a bit, but still the readings aren't very precise when both filters are off.
So, I have a few questions about all this stuff:
OK, that's great information. What you have managed to identify is that the unit is reading incorrectly on surfaces that are producing very strong return signals. By turning down the gain, the situation gets better because the signals become smaller.
You can think of this adjustment as providing a partial cure to the problem, but it would be much better to prevent the problem from happening in the first place. The SF11/C has a set of functions that specifically manage the way the unit handles signals of different strength so we can now take a close look at these.
A bit of background information might be appropriate here. When pulsed signals traveling at the speed of light enter into a detection and amplification circuit, there are delays as the photons are converted into electrons and the electrons travel through the various amplifiers. Normally, we would choose components that are fast enough that these delays would be insignificant but unfortunately it is not possible to design electronic components that respond fast enough to have no delay at all. To complicate matters further, as the signal strength changes, the number of photons that are converted to electrons changes and the bulk characteristics of the electron pulse changes. This is mainly due to the effects of circuit capacitance and inductance that affect amplifier slew rates and group delay characteristics.
The SF11/C is designed to handle a very wide dynamic range of signals ranging from bright, nearby surfaces to dark remote surfaces. For each level of reflectivity there is a unique internal delay that needs to be measured and corrected for. In most cases the change in delay is relatively small so it isn't a problem, but at the extremes of performance when "close and bright" or "far and dark" the delays become non-linear and less predictable. We need to extend the capabilities of the SF11/C in order to prevent these extreme delays from introducing errors. This is how:
Put the APD value back to the original setting -4. Set up a target at the distance where you know there are significant errors. Measure this distance accurately using a tape measure. You will need to mount the unit so that it is steady.
From the static user menu use the left arrow to reach the calibration area. There you will see a tabulated correction table that contains data about the internal delays. Change the value listed under "R" to the distance of your target. This is the reference distance that the unit will use to measure and correct its own internal delays under the conditions that you have set up.
Press the <space> key to start the unit measuring in calibration mode. Let it run for about 10 seconds until the distance reading becomes stable. Press the <space> key to stop measuring. Press the <S> key to save the new result.
You should now find a new value added to the table - note that the table automatically sorts so the new value won't always be at the end of the table. You can repeat this process as often as you like as long as the table doesn't get full - always leave at least one open location at the end of the table. There are also editing functions so that you can delete or manually add data. If you're not sure of the result edit it out to zero and try again. It might be a good idea to record the original data set so that you can set it back to factory values if necessary.
With the new data added, the SF11/C will now recognize your particular target surface and know precisely how to handle the electronic delays associated with its characteristic reflectivity. You can use different targets at different distances to add more intelligence just so long as you tell the unit where these targets are using the reference distance.
The method described above gives the SF11/C the ability to handle a wider dynamic range of signal strengths. This reduces measurement errors and is a better solution than turning down the gain.
For those interested to know how we handle customer reports of problems with our lasers, we run an ISO 9001 system that feeds the information back to product development and the production manager so that we can continuously improve our processes and the quality of our products. Right now there is a "CAR" (Corrective Action Request) open for this particular issue which will drive a process change on the production line to extend the testing criteria to include greater extremes of signal strength. Future products will be better because of Jimmy's hard work.
The sun came out and I lowered the values some more, I'm -10 from the starting value now. The lidar is reading better, but still about 10-20% off in the bright sunlight. Should I lower APD 1 more or is there another setting to adjust?
Thank you! I have followed your instructions and lowered the APD value by 4. After doing this the lidar is reading much more accurately outside. Of course it's overcast now so I will test in bright sunlight and hopefully my issue is solved!
That's great, thanks.
It looks like the signal is very strong and the noise limiter is kicking in, suggesting too much gain on the detector. Both the gain and noise characteristics are automatically set during production, however, it is possible that the signal wasn't calibrated at these strong values and as result a distance error is being introduced that shouldn't be there.
To verify this effect, you could try measuring to a darker surface. This will reduce the size of the signal to a more manageable value.
If this works we can also reduce the sensitivity of the detector as follows:
Arrow right until you get to the "APD settings". Record the value in item 1, then subtract 2 from it and enter the new value. Check that the new value is entered correctly then go back to the dynamic system screen so that you can see the effect. You can continue to reduce the value by 1 at a time if the initial change is not enough but you shouldn't need to go more than 10 below the starting value.
Ideally you want to have some noise in the system and in sunlight the noise limiter will switch on and off so that is normal, and if the gain goes too low then the range is compromised. If you can't reach a comfortable compromise then let me know and we'll arrange to get you a replacement.
Thanks for the instructions, I have found the following results:
Indoors, distance approx 12m horizontal:
Live: 11.92 Filter: 11.59:1 | Signal:17.0 Noise: 0 Limit:No | CPU:23%
Live: 11.83 Filter: 11.60:1 | Signal:17.2 Noise: 0 Limit:No | CPU:23%
Live: 11.91 Filter: 11.62:1 | Signal:16.9 Noise: 0 Limit:No | CPU:23%
Live: 11.83 Filter: 11.63:1 | Signal:17.2 Noise: 0 Limit:No | CPU:23%
Live: 11.82 Filter: 11.64:1 | Signal:17.2 Noise: 0 Limit:No | CPU:23%
Live: 11.82 Filter: 11.65:1 | Signal:17.3 Noise: 0 Limit:No | CPU:23%
Indoors, distance approx 1.8m vertical:
Live: 1.68 Filter: 1.71:1 | Signal:16.7 Noise: 1 Limit:No | CPU:23%
Live: 1.69 Filter: 1.71:1 | Signal:16.7 Noise: 1 Limit:No | CPU:23%
Live: 1.72 Filter: 1.71:1 | Signal:16.9 Noise: 1 Limit:No | CPU:23%
Live: 1.73 Filter: 1.71:1 | Signal:16.9 Noise: 1 Limit:No | CPU:23%
Live: 1.68 Filter: 1.71:1 | Signal:16.7 Noise: 1 Limit:No | CPU:23%
Live: 1.72 Filter: 1.71:1 | Signal:16.9 Noise: 1 Limit:No | CPU:23%
Indoors, distance approx 1m vertical:
Live: 1.04 Filter: 1.12:1 | Signal:16.4 Noise: 1 Limit:No | CPU:23%
Live: 1.11 Filter: 1.11:1 | Signal:17.1 Noise: 0 Limit:No | CPU:23%
Live: 1.09 Filter: 1.11:1 | Signal:16.9 Noise: 0 Limit:No | CPU:23%
Live: 1.04 Filter: 1.10:1 | Signal:16.4 Noise: 0 Limit:No | CPU:23%
Live: 1.06 Filter: 1.10:1 | Signal:16.6 Noise: 0 Limit:No | CPU:23%
Live: 0.99 Filter: 1.09:1 | Signal:16.3 Noise: 0 Limit:No | CPU:23%
Outdoors, distance approx 12m horizontal:
Live: 9.68 Filter: 10.36:1 | Signal:12.4 Noise: 6 Limit:Yes | CPU:23%
Live: 9.83 Filter: 10.29:1 | Signal:12.5 Noise: 6 Limit:Yes | CPU:23%
Live: 9.85 Filter: 10.24:1 | Signal:12.6 Noise: 5 Limit:Yes | CPU:23%
Live: 10.01 Filter: 10.19:1 | Signal:12.9 Noise: 5 Limit:Yes | CPU:23%
Live: 10.03 Filter: 10.16:1 | Signal:12.9 Noise: 5 Limit:Yes | CPU:23%
Live: 10.02 Filter: 10.14:1 | Signal:13.0 Noise: 4 Limit:Yes | CPU:23%
Outdoors, distance approx 1.8m vertical:
Live: 0.91 Filter: 0.66:1 | Signal:14.9 Noise: 4 Limit:Yes | CPU:23%
Live: 0.95 Filter: 0.67:1 | Signal:15.0 Noise: 4 Limit:Yes | CPU:23%
Live: 0.86 Filter: 0.68:1 | Signal:14.7 Noise: 4 Limit:Yes | CPU:23%
Live: 0.86 Filter: 0.69:1 | Signal:14.7 Noise: 4 Limit:Yes | CPU:23%
Live: 0.87 Filter: 0.69:1 | Signal:14.8 Noise: 4 Limit:Yes | CPU:23%
Live: 0.95 Filter: 0.70:1 | Signal:15.0 Noise: 3 Limit:Yes | CPU:23%
Outdoors, distance approx 1m vertical:
Live: 0.34 Filter: 0.43:1 | Signal:15.1 Noise: 4 Limit:Yes | CPU:23%
Live: 0.33 Filter: 0.43:1 | Signal:15.1 Noise: 4 Limit:Yes | CPU:23%
Live: 0.32 Filter: 0.43:1 | Signal:15.1 Noise: 4 Limit:Yes | CPU:23%
Live: 0.29 Filter: 0.42:1 | Signal:14.9 Noise: 4 Limit:Yes | CPU:23%
Live: 0.32 Filter: 0.42:1 | Signal:15.1 Noise: 4 Limit:Yes | CPU:23%
Live: 0.38 Filter: 0.41:1 | Signal:15.2 Noise: 3 Limit:Yes | CPU:23%
We also plan on using this LIDAR on our UAS which will fly almost exclusively over crops or soil, if that makes a difference.
I hope this information is useful, thanks.
Sorry about that - time zones can be a pain.
OK, so now that you can navigate around the unit, the way to diagnose a fault condition is to compare the behavior of the data under working conditions with the data when things go wrong.
So, picking the user screens first, when the unit is running the only information that you get is about the distance. This is quite limiting in that the distance is the final result after a bunch of things have already done their jobs.
Moving over to the right, the next screen gives a high level system overview. When running, the dynamically displayed data gives three primary types of information:
1. The first two data streams show the raw, unprocessed result and the result after any filters have been applied.
2. The next three streams show the quality of the signal including its strength, the amount of background noise and whether or not the noise limiter has taken action to reduce the effects of background noise.
3. Finally, there is a CPU activity monitor that normally runs around 23% indicating that the processor is handling the data without any problems.
This dynamic data should give us the first clue as to what the difference is between those conditions when the unit is running correctly, and those conditions when, for example, the unit is picking up interference or improperly handling background light.
If you can test the unit under different conditions you should see some significant differences in the values produced. Depending upon which values go out of normal bounds, we can select which diagnostic to use to confirm the effect and then change a setting that alters that particular behavior.