The SF40 - upside down :)
The SF40 is a smart sense-and-avoid system that detects obstacles near autonomous vehicles and determines the safest route past them. On-board data analysis reduces the need for complicated processing by an external computer. The built in analytical tools can sense the presence and position of obstacles and locate gaps and spaces with sufficient clearance for safe navigation. Hard-wired alarm outputs make it easy to interface the SF40 with conventional flight controllers and a serial port connection allows for greater interaction when navigation becomes more complex.
How the SF40 works
The SF40 uses a scanning laser rangefinder to measure on a 360 degree disc with a radius of 100m. Collected data is stored in memory and continually refreshed as the laser scans around. The speed of rotation can be set from 1 to 5 revolutions per second corresponding to different measuring resolutions of between 0.03 and 0.25 meters. Time critical functions are managed by an FPGA leaving the 32-bit Arm Cortex-M3 processor to handle the data analysis and monitor system performance and reliability.
Data analysis takes place asynchronously from the data collection so that numerous independent calculations can be carried out very quickly. An analytical tool kit provides the framework for making navigation decisions. Some of the tools run autonomously, such as alarm conditions that are evaluated continuously without the need for intervention by the flight controller. Other tools answer high level navigation questions such as “Is it safe for me to change direction?” or “Which way should I go now?” Tools can be used sequentially and in combination with the situational and internal status information to create sophisticated macros that can handle numerous mission requirements.
Here are some of the navigation tools:
- Alarm zones - autonomously monitors preselected areas to warn of any obstacles
- SearchLight - checks that an area is clear of obstacles before a direction change is made
- Navigator - finds open pathways between obstacles
- Mapper - provides all the distance measurements in a specified region
- VirtualLaserRangeFinder - measures the distance to a target in any direction
Seven configurable alarms zones can be set within the measuring plane to alert the vehicle when an object gets too close. Each zone can be set with an individualized alarm distance, angular width and aiming direction. For example, one zone could cover 360 degrees around the vehicle at close range to alert when people get too close to the moving parts. A forward looking alarm zone can be used to detect obstacles in the direction of motion. Other alarm zones can check that specific directions are clear of obstructions before course changes are made.
The status of the alarms can be read from the serial port and any two alarms can be linked to the hard-wired outputs. The alarm zone definitions are stored in non-volatile memory making them available immediately when power is applied. Once the SF40 is running the alarms are updated continuously without the need for any external commands.
Two alarm zones are overlaid on the SF40 data:
red = 360 degree safety zone, yellow = forward looking alarm zone
In this case the forward alarm has been triggered by an obstacle.
Checking corridors using SearchLight
The SearchLight tool answers two navigation questions. The first is, “Can I safely change to a new direction?” The second is, “Where is the closest obstacle in that direction?”
SearchLight checks that a corridor is clear before the vehicle changes direction. It can be aimed in any direction on the measuring plane and the beam divergence adjusted to cover the width of the corridor of interest. SearchLight finds the closest obstacle within the corridor and reports its distance and angle from the present flight path.
SearchLight is used to confirm that direction changes are safe before they are made rather than waiting for the alarms to warn that a hazardous situation has arisen after the direction change has been made. Several SearchLights can be used together to triangulate the vehicle’s position between fixed objects and wide beam SearchLights can be used to check for clearance in different quadrants.
The flight controller has responded to the forward alarm by asking SearchLight (green) to look
for space at 45 degrees to the right of the flight path. SearchLight has found obstacles
along the proposed path and warns the flight controller.
Finding clear pathways using Navigator
The Navigator tool answers the question “Which way can I go now?” It examines a specified region and finds the direction of the clearest pathway. The results can be used to direct the vehicle into open space and away from obstacles.
Navigator can be run at any time or activated when a forward looking alarm zone detects an approaching obstacle. The flight controller can configure Navigator with a directional bias so that the recommended escape route is away from known hazards. This can be useful during search and rescue missions when flying close to a cliff face. A bias away from the cliff face would be the safer option.
The flight controller asks Navigator to search in the right front quadrant for an escape route.
There is one safe passage that is clear for 45 m.
The flight controller wants to get further away so it asks Navigator
to find a better corridor in the front left quadrant. Navigator finds a
65m long corridor centered 84 degrees left of the current flight path
Holding station using the VLRF
The virtual laser range finder (VLRF) tool is used to find the distance in any direction on the measuring plane. VLRF can assist with keeping station at a fixed distance from a target or measuring how far away an obstacle is. Any number of VLRFs can be created that aim in different directions. This allows for accurate position holding within a confined space and provides confirmation of GPS location using buildings or other known structures as reference points.
Mapping an area
The Mapping function provides detailed two dimensional maps in polar coordinates of a specified region. These maps can be analyzed by the host controller so that additional measurements or navigation decisions can be made. This is a conventional SLAM mapping feature that won't be needed on most missions.
In addition to collecting and analyzing data from the scanning laser, the SF40 continuously monitors the status of internal systems and the status register can be read by the host controller. System status checks include monitoring the battery voltage, the smooth running of the motor and the correct functioning of the laser. Status flags can be linked to the hard-wired alarms to provide a warning of critical system faults, such as the battery running low.
There is provision to control an external servo motor that can be used to position the SF40 or for any other purposes. The end points of the servo can be trimmed to allow for precise positioning using commands sent through the serial port.
A spare digital input is continuously monitored and its state is reflected in the system status register. This input can be linked to a hard-wired alarm and read using the serial port. This could be used as a landing switch indication.
The SF40 includes a high performance motor controller and efficient power supplies that allows it to run from different battery types and voltages ranging from 6.5 V DC up to 30 V DC. The power consumption is constant at 4.5 Watts.
I hope you enjoyed this brief update :) LD
Cool to hear you want to pursue the survey grade LIDAR route! I think new markets can emerge around such products... Looks like modified SF40 could do the initial job but I understand it may be better and cleaner for you to do it with a completely new product. This surely is a rather complicated and hi-tech electronics industry so I greatly appreciate you are one of the "affordable" LIDAR pioneers. The product size/weight may not be a big issue for surveying but if you are able to keep original specs in a smaller (and cheaper?) product then it is ok.
May I ask you about the planned timeframe for a survey-ready SF40 successor (when will it be for sale)? I would be even interested in "hacking" the SF40 but that would need to include your cooperation I think since your SW seems to be locked (AES encrypted) as you said in another post and I dont really want to bother you...
That sounds like a great idea!
We have a long term strategic plan to offer survey grade LiDARs but we want to make them really small and reasonably priced. Making units available initially for sense-and-avoid helps us to refine our production and improve product performance.
The next generation of technology for use in our LiDAR scanners is already being tested in the LW20 announced a few weeks ago. These laser modules are so small that it is possible to make survey grade LiDAR with a weight of less than 50g. We haven't done this yet but it is already in development, so we want to apply our efforts to this next generation rather than upgrading the SF40.
PS: As usually I forgot something - does the motor have some FPS limits? Can it do more than those 4.5 FPS (say 10, 20, 50 FPS etc.) while still being able to track its position (encoder)?
Thanks for your reply! I know precise mapping is a different market, but as the prices for the equipment you name (IMU, RTK GPS etc.) go constantly down (including LIDAR) I think there is a lot of potential in the field of community precise mapping. Actually, I am thinking about starting a community project for precise mapping (a kind of "OpenStreetMap on steroids") so I am looking for possible equipment. Stereo cameras have a great value in 3D scanning but they have few disadvantages... I think there may be a nice market niche for affordable mapping lidar solution.
So if I understand correctly the SF40 is theoretically able to supply say 36000 measurements/s with 0.03m precision but ony is not able to communicate that out? You say it could be done with a push - have you thought or even tried some solution to this problem? How difficult would be the HW/SW modifications to get the full amount of data from the unit?
Also, what about the live point feed I asked about or the position HW trigger (for synchronization with GPS, cameras etc.)?
@Kozuch - The SF40 is designed for sense-and-avoid rather than mapping applications. For a precision mapping system there is a mixture of LiDAR, IMU, GPS, photogrammetry and RTK data. This is beyond the scope of the current SF40 project where the data communications have been simplified to meet the capabilities of regular flight controllers and internal functions perform the collision detection.
Because of this specific use case, high speed data streaming is not a requirement even though it can be done at a push, and the communications protocol has been chosen to match the PixHawk and other regular flight controllers.
PS2: I am not a HW developer but 100 Mbit Fast Ethernet may be an option too, I guess the HW may be simpler than USB stack? Regardless of the solution a C/C++ driver for the host device would probably be needed to take advantage of the low latency response.
PS: I found your other post where you reply to some questions - you say resolution of 0.03m means going down to 1145 readings per second. I guess this is only because the 900 kbit serial port (USB) limit and the unit can also do 0.03 m resolution at 36000 measurements/s but can not output the data? This seems to be an "artificial" restraint of the sensor... I am exactly looking for this missing feature - low cost but high resolution/FPS lidar sensor. Are you planning to upgrade the communication bottleneck? Even an old USB 2.0 would blow the serial port... I guess there may be some HW USB stack you may use with your microcontroller, am I right?
Hi, I am looking for an affordable laser scanner for mobile mapping solution where the lidar is not horizontal but is mounted at an angle (similar thing what for example HERE maps company does - they are using Velodyne though). I have 2 questions:
1) How precise are the distance measurements? What is the range accuracy? The datasheet does not specify it (your standard lidars have +-0.1m) Is there a measurement noise (a stationary obstacle will give different readings each time)? On this video there seem to be some range noise in the top of the picture. How does this compare to Velodyne products?
2) Is it possible to stream a "live feed" of range measurements from the sensor? While mapping on moving platform I need to know when exactly was a given point measured... or some kind of synchronization is needed - if I know the RPM it may be enough to just have a signal from lidar when it is pointing at 0 angle (front) or something like that. Is that possible?
Thanks for your answers?
Yeesh. Just saw my typo.