Developing a new product starts with a pretty clear idea of what you expect the finished thing to do. Mathematically, you can can work out the expected performance and logically you can understand how this performance translates into useful applications. But I'm always fascinated by the qualitative feel of a product, that intangible experience that makes you think "Wow, that is so cool!"
I'd like to share a few experiences that I had during the testing of our new SF30 laser range finder. We decided to make a laser sensor that could measure so fast that even narrow obstacles like overhead power cables could be detected reliably, even from a moving UAV. Additionally, we wanted the SF30 to produce high density point clouds when used in a scanning system. We felt that without this high level of performance, reliable obstacle detection and collision avoidance would be impossible.
Quantitatively, we knew that the SF30 could measure 36633 times per second. What we didn't know was how that "felt" in practice. The yellow 'scope trace above shows the data output from the serial port of the SF30. The baud rate is 921600 and on the blue trace you can see a synchronization marker.
Looking at this high speed data stream for the first time, we couldn't get a feeling for what an obstacle with a high relative velocity would look like. We were also concerned that there weren't many embedded processing platforms available that could make obstacle detection decisions within the 27 microseconds between readings, whilst flying a UAV.
So we added an old fashioned analog output with an alarm that has a programmable activation distance. In the image below the yellow line is an analog representation of the measured distance and the blue line is an active low alarm that warns of a close obstacle.
Qualitatively, this is a much clearer picture of an obstacle than the earlier data stream and we can see that the obstacle was in front of the SF30 for about 4 milliseconds. So here's the cool part. The obstacle is an elastic band flicked at full force through the laser beam. The band was traveling at about 20 meters per second and the SF30 hit it 137 times.
My immediate response to this result was - this is going to work! My intuitive understanding of what it takes to hit a small obstacle from a fast moving platform is that you need to hit it lots of times to be absolutely certain that it is a real threat. Hitting the fastest thing that I could find 137 times is just amazing.
Of course, the next issue is how the host controller is going to catch a fast alarm signal. Certainly much more easily than a fast data stream but how about latching the alarm until the controller is ready to acknowledge it? In the image below, the blue alarm line has stayed low after the obstacle detection event. The alarm is reset by a command from the host sent through the serial port.
So now we end up with a remarkable solution to detecting obstacles that have a high relative velocity. On the one hand, the SF30 can measure even small obstacles many times no matter how fast they are moving. On the other hand, a simple alarm signal can warn the UAV about the presence of an obstacle without occupying all the processing capacity of the flight controller.
Comments
Hi Rob,
I think that for anything other than the simplest uses we are all thinking about a auxiliary computer dedicated to dealing with the rangefinder, scanned or otherwise.
That said whatever we can get the rangefinder to do expands its capabilities and unloads whatever you are sending it to, flight controller or auxiliary computer.
The fact is that as soon as we get into scanned applications, doing more than the simplest most basic obstacle avoidance an Nvidia Jetson is about the minimum you need to deal with it.
https://developer.nvidia.com/jetson-tk1
Best Regards,
Gary
Interesting discussion, and a really nice product.
I would suggest that what might be needed is some sort of settable min-distance sampling period. For example, for a super simple object detector, we might set a sampling period of 1 second. The rangefinder would return the shortest measurement within a given period, then reset. This is what I was doing on my object avoidance code. I had a 1 second sweep time, and a filter that looked for the shortest return during that time period, then reset. That shortest return was assumed to be the distance to the object. This worked ok on a 1 second sweep with a 12hz sample rate, but it would be impractical at the sampling time you are talking about.
I think really, what we need to get to, is having enough smarts on the sensor, that it can tell flight controller where the obstacles are, and not depend on the flight controller to do the raw data processing. Because to do really high fidelity object detection, at high speeds, is a lot of processor overhead to ask of the flight controller.
Hi Gary,
I take your point and we've put hysteresis into the alarm set point so that objects coming head-on don't cause multiple alarm events.
Handling sudden, unexpected events is not so simple, especially in scanning situations where there may be no direct spacial relationship between successive readings. We've set very conservative thresholds so that things like dust particles aren't going to cause false readings, however bees might just be detectable. So rather like a human might take pause as a bee buzzes past their head, so might a UAV take a moment to evaluate an alarm condition before moving cautiously on.
At first glance it appears to be a balance between Type I and Type II errors but a properly oversampled bee may have exactly the same signature as a telephone line anyway. Notwithstanding that particular example, I agree with you that a device that is over-sensitive can always be tamed in software and it's better to do that at the source.
As you know, we do have a solution for the specific case of a scanning system that produces data with tight spacial and temporal relationships and I think that this holds great promise for reducing the probability of false alarms in the way that you suggest. The ability to oversample the space ahead is precisely what is needed in order to achieve "zero gaps" capability in a collision avoidance scanner.
The alarm reset command is checked every reading, so depending upon what measurement update rate you select, the alarm recovery time can be very short.
I forgot to mention that there is a Kalman filter included as a selection option so that you can reduce the speed of response to unwanted alarms.
Hi LD,
Just wondering, would it be possible or reasonable to have a specifiable number of readings within a specifiable range to trigger the alarm latch?
Obviously the information you want from an alarm varies according to circumstance and a rubber band (or bee or large dust or smoke particle) setting off the alarm latch may not be what you are looking for.
I suspect if the alarm was software adjustable it could provide reasonable immunity to false (or undesired) alarms while still providing the appropriate alarm when necessary and it would certainly be nice to have this function available on the rangefinder rather than having to sort it on the attached computer.
It is also important to know how long after the computer sends the alarm reset command before the alarm is once again active.
Just a few thoughts.
Best Regards,
Gary
Absolutely John, I'm glad you raised this issue.
One of the things we are finding with really fast update rates is that slow moving targets present "edge ambiguity". This is one of those theoretical concepts that you don't expect to see in a practical situation but it is very real with the SF30. It goes something like this:
What is the definition of the edge of an object? Consider the practical case of the laser beam aiming at a wall 50m away. The signal is strong and the distance reading is unambiguous. An obstacle moves slowly into the beam at a distance of 10m away. When can you say that the obstacle is in the laser beam, and therefore going to be measured in preference to the wall?
It turns out that even tiny variations in the power of each laser shot, partly caused by quantum effects but mostly by macro electrical noise, will change the strength of the signal received from the edge of the obstacle. The edge drifts in and out of existence, or at least measurability, for a significant time compared with the rate at which laser pulses are flying by.
The surprising effect of this edge ambiguity is that the reading will jump from one laser shot to the next between the two possible answers - 50m or 10m - with a statistical value in proportion to how often of the edge is being detected, and will only settle on the 10m result once a sufficient amount of the edge is in the beam to guarantee detectability with every laser shot.
Our concern is that multiple alarms could be generated by slow moving obstacles and we didn't want to impose multiple interrupts onto an already busy processor. That having been said, if the interrupt is managed properly, it won't be an issue and the latching feature of the alarm can be switched off.
Catching a fast pulse will not be a problem as long as you use a pin change interrupt instead of polling the I/O pin in SW. Even the 16Mhz 8-bit AVR has ns timing accuracy when using a dedicated pin interrupt.
Fantastic as usual LD, a really excellent capability.
It should also be really useful in a scanned application.
Best Regards,
Gary
Hi Gisela and Joe, it's really nice to hear from you again.
I think we might need to develop a new language to describe the "range" of a device that specifically looks for obstacles. Large things like walls might be easy to locate from a long way away whilst the twigs at the top of trees or telephone lines are more likely to be missed altogether if the update rate isn't high enough, even though they may be measurable in a static situation.
The fast measuring speed of the SF30 makes it almost immune to velocity as a factor in taking a measurement so the useful range on a high speed UAV is the same as the static range. For the SF30/C, we can see this in the elastic band test where the dynamic range under bright light conditions (100% returns) is about 14m and the limit of detection under ideal conditions is 23m, which are exactly the same as the static range limits. It is quite freaky how easily the SF30 measures things that move so fast that you can't follow them with your eye, contrary to our intuitive response.
We've also looked at cables as a potential collision hazard and are using a standard 5mm diameter, grey USB cable to represent a guy wire and this can be detected with 100% certainty under bright conditions up to about 20m away with the limit of detection under ideal conditions being 41m away.
Other objects that we've tested include some dark foliage (Acacia trees in winter time) that can be seen 80m away in bright sunlight and 110m away when it's overcast. This is a big target so it gives a much bigger signal than, say, a wire at the same distance.
In urban landscapes, white painted walls are common and these can be detected 140m away and then there's always the fun of measuring road signs that are easily picked up at the limit of range, 175m away.
The sensitivity to reflective targets suggests that an SF30 built into a scanning system could be used to locate landing areas if they are appropriately marked with reflective tape.
You have done it Again! Fantastic device - I need to contact you re a few more SF10's, and hope Ican add the SF30 to the order!
an you give a liitle mor info on range,, etc?
The Nampilot..