Micro Smart LiDAR Sensor

Similar projects worth following
MappyDot is a smart ranging sensor which provides system designers with the ability to measure accurate distances on drones and robotic platforms for collision avoidance, area mapping, distance measurement, gesture recognition and motion sensing. The MappyDot uses the VL53L0X laser time-of-flight ranging sensor from STMicroelectronics, which is a tried and tested 940nm Class 1 laser sensor in use in millions of devices worldwide.

The MappyDot can be used for example to prevent your drone from colliding with objects or optimise its landing, make star trek like door sensors to open doors automatically, create vibration sensors for the blind or even fashion unique musical instruments.

MappyDot is a part of a planned suite of enhanced sensors that offer additional filtering, ease of use, crosstalk reduction and an automatic bus addressing scheme compared to their standalone counterparts, which can require complicated bus multiplexing and processing overheads.

MappyDots provide distance measurements up to 2 meters at a non-interpolated rate up to 50Hz, with a 25 degree field of view. Multiple MappyDots can be chained together easily to gather multi-dimentional data about an area much like radar, without reducing sampling rate. They are also calibrated out-of-the-box to within ±1mm, and can be easily re-calibrated if integrated into a commercial enclosure. The MappyDot also performs low pass filtering on the motion data that arrives from the sensor, to provide you with the clearest picture of the environment around it. While distance measurement is the name of the game, the MappyDot also offers the following features:

  • Auto addressed bus scheme for chaining up to 112 devices.
  • A 2.8-5.5V signalling and operating voltage range which will work with your platform of choice.
  • A simplified I2C interface for easy integration into new or existing projects with next to zero code and processing requirements.
  • Reduced device initialisation and upkeep times. Many devices can now share the same bus with the fastest possible update rates. For example, you can poll 112 MappyDots, 50 times each, every second for a total of 5600 measurements per second (depending on your host processing speed).
  • Inter-sensor crosstalk reduction and measurement synchronisation to reduce measurement errors.
  • Low pass, real-time filtering to reduce background noise effects.
  • Automatic mode switching to get optimal measurements depending on the environment.
  • More advanced features and device pass-through for complex applications.
  • In-service firmware upgradability via I2C. There’s no need to disconnect already deployed and integrated devices.
  • Open source sensor firmware.
  • Threshold controlled, PWM or interrupt output from an onboard GPIO pin for standalone or distributed applications.
  • A tiny footprint - 13x17.8mm (0.51x0.70").
  • An easy to solder standard 2.54mm (0.1") pinout that can be used for either soldering directly to production boards or to header pins or wires for prototyping and breadboarding.
  • A user controllable LED (PWM, threshold, measurement or manual modes).
  • Device naming for easy recognition.
  • Precalibration for plug and play use, as well as auto user calibration.

All this is possible, without the need for any additional processing on your platform of choice.

When the devices are connected to a power source (2.8-5.5V), they automatically initialise with an array of addresses, which can be easily scanned and polled to determine what is on their I2C bus from a controller. From there the devices can be read with a few lines of code.

Upon first power up, the MappyDot allows users to obtain an accurate position with two lines of Arduino code:

  Wire.requestFrom(address, 2);
  distance = << 8 |; 

It's that simple, there's nothing else to it. No special libraries to load, just read a value from the I2C lines.

The default MappyDot firmware offers different operating modes from the MappyDot Standard mode:

  • Highly Accurate - 1.2m - 5Hz
  • Long Range - 2m - 30Hz
  • High Speed - 1.2m - 50Hz
  • VL53L0X Default - 1.2m - 30Hz
  • MappyDot Standard - 2m auto switching - 50Hz

However, you can always tweak and update the firmware as you please via the I2C bootloader.

All MappyDot code, documentation and design on these project pages are licensed under the GNU General Public License (GPL) unless otherwise stated.

  • MappyDot Soft Launch

    Blecky09/11/2017 at 13:51 0 comments

    A small first batch of MappyDots has been unofficially soft launched on Friday as a way to get postage and packaging sorted out. There's still a few left on the Tindie store if you are interested in getting them early. There will be another larger batch available by the end of the week, so if you miss out there won't be too much delay.

    There are two packaging options, one is a simple mailer sent as a letter for smaller orders without tracking, to try and make things as cheap as possible. The other is for larger orders or if you want tracking. Australia Post only allows tracking on parcels, which has a limit of 500grams for the cheapest option, so since the MappyDots are tiny and only weigh a few grams, I have thrown in a few Aussie sweets to fill the extra weight and provide additional cushioning :)

    Sorting out customs forms and shipping has been interesting. When you create a waybill for a parcel on the AusPost website it creates a series of A5 customs documents for you to print. They require an A5 plastic sleeve to put these in, which is meant to be provided by the AusPost stores for free when you drop them off. Well it turns out the AusPost stores have no idea about this and don't actually stock them, nor do any of the major stationary or office supply stores. So after visiting 4 post stores I got them to contact the corporate center to find out how to actually do this. One store in Melbourne's CBD had them in stock so I took a trip in to grab a few.

    When I got there they first said they didn't have them. I said they were just called about 20 minutes ago and to take another look. Low and behold, they did have them but then they wanted to charge me for them. Since I have already spoken to the corporate center about it all, I said firstly they are free and secondly they don't even have a stock code, so they have no way to bill me for them. A few minutes later the staff member finally gave up on the sales terminal and gave me a large handful and served the next customer.

    Normally this isn't a problem because you fill out these forms by hand, rather than printing them. And they have an abundance of these handwritten forms. But it was interesting to see that our postage services really haven't caught up with international shipping and the internet in 2017.

    So far the MappyDot has been shipped to the US, Hungary and Spain. Hopefully we can dot the entire map!

  • PWM Gesture Demo

    Blecky09/07/2017 at 16:23 0 comments

    Here's a quick gesture recognition demo with multiple MappyDots feeding into a slow and dirty python visualisation script. The MappyDots are also showing that they work when their fields of view overlap as well as a PWM LED output (ignore the differing LED brightness on some of the Dots in the demo, they have different LEDs from different prototype batches). The threshold for the PWM is configurable and currently set to dim at 300mm.

  • A Few Things

    Blecky09/04/2017 at 15:32 0 comments

    For starters, the MappyDots are coming along. I'm just getting them tested and calibrated which is taking a bit longer than expected. Part of this is developing a programming, test and calibration jig to make it easier to lots at a time. I have also been delayed by a few personal reasons, but I hope to have some ready by Wednesday and then another batch next week. So stay tuned.

    A few small changes have been added to the repo -

    The MappyDot Firmware is now up as is the Bootloader code. The MappyDot firmware is quite large, so adding new functionality can be tricky:

    REM ################
    REM Max .text Size 0x7C00 due to bootloader.
    REM ################
    avr-size.exe --format=Berkeley -x MappyDot.elf
               text       data        bss        dec        hex    filename
             0x72fa      0x122      0x19d      30137       75b9 MappyDot.elf

    So we are using about 93% of the total flash space. Most of this is taken up by the VL53L0X APIs (even after shrinking and trimming them down a fair bit). You might be thinking, but why don't the Adafruit or Pololu Vl52L0X libraries have these size issues? This is because they don't have the calibration functions implemented, which take up a fair bit of space on their own.

    The good news is, that to read from the MappyDot via an Arduino, you only require about 4KB of program space (most of that is the Wire libraries) and next to no data memory. On other platforms this can be substantially less than that. So it leaves room for the more important things, like programming up @Arsenijs' mould growth threshold detection algorithm.

    The initial release of the firmware (which will release on the first batch of MappyDots) is missing the MappyDot measurement mode and I2C passthrough. This will be implemented at a later stage, but had be cut due to time constraints. You can still change to other modes though.

    There's also a very simple Arduino I2C test application as well that can be used as a reference. It has a little menu you can use to test the MappyDot. Just press the character corresponding to the function you require.

  • MappyDots Made

    Blecky08/30/2017 at 11:44 1 comment

    The MappyDots are now made up. There's just a few firmware tweaks, firmware programming and calibration to go. All going well they will be for sale early next week.

    That's a lotta dots!

  • PCBs Have Arrived!

    Blecky08/17/2017 at 09:32 2 comments

    The panelised MappyDots have arrived from OSHPark and they are beautiful!

    I also have to give a BIG thank you to Drew and Dan from OSHPark, their help and support have been immensely valuable!

  • Release Date

    Blecky08/12/2017 at 13:46 2 comments

    Just a heads up, the MappyDot should be in stock on the Tindie store around the end of this month. The ATMega328PB MCU's have been out of stock for a little while worldwide, with a long lead time. However I have managed to secure quite a few of them to get the ball rolling.

    The product page is now online if you would like to add the MappyDot to your wish list.

    The firmware for the MappyDots is about 90% complete, with just a few little features to test out and tweak. The sources will be released at the same time the MappyDots become available for you to peruse. A Fritzing part is now available in the repositories.

  • SensorDots Website

    Blecky08/06/2017 at 15:56 0 comments

    In preparation for the sale of the MappyDot in a few weeks on Tindie, I have created a new website to house some of the content.

    Most of the sensor information and documentation will now reside on this site. However, I will still continue to release technical project logs on for those that prefer the nitty gritty details.

    Be sure to take a look and let me know if there are any issues or if there's anything you don't like :)

  • Development Board

    Blecky08/05/2017 at 05:06 0 comments

    I have created a breakout development board for the MappyDot to help people develop different applications. It brings out the ISP programming headers and has a reset button, master select jumper, optional I2C resistors and mounting holes. This is an easier to use alternative for development, than just creating an adapter for the ISP pins.

    The dev board gives you the option to either connect headers to the MappyDot boards for easy removal, or to solder the MappyDot directly to the board.

    The dev board schematic and production files are located on the git repo - Or available here on OSHPark. They will also be available for sale with the MappyDots as a kit with headers.

  • I2C Firmware Updates

    Blecky08/03/2017 at 07:58 0 comments

    Just a quick one to let you know that the I2C firmware updates are now working on the MappyDot. The software flow of the MappyDot firmware update proceedure is as follows:

    The bootloader loads first on startup and waits for a bootloader start message on I2C address 0x07 for 200ms. This is a safety feature that allows you to recover modules with a bad flash or modified firmware that prevent it going into bootloader mode while running. You can power cycle the chip by briefly shorting the reset pin on the MappyDot if it is hard wired in to a bus. If you have multiple MappyDots on a bus that aren't functional, you can hold the reset line low on all of them and just do one at a time.

    When the application is running, you can enter the bootloader to enable flashing at any stage while it's operational using it's auto addressed I2C address. Once it boots into bootloader mode, it switches to I2C address 0x07 for the bootloader process. The programming software automatically changes this address for you during the firmware flashing process.

    The programming software works with any standard Linux I2C device, such as /dev/i2cX on the Raspberry Pi's Broadcom chipset. If you don't have an I2C device, or are using Windows, there is also an Arduino I2C->USB adapter sketch you can use to load the firmware with, which the application supports.

    Here's the output from the software:

    twiboot-arduino -a 0x08 -d /dev/ttyS4 -w flash:MappyDot.hex
    device         : /dev/ttyS4       (address: 0x08)
    version        : MDBOOT328PBv2.1  (sig: 0x1e 0x95 0x16 => ATmega328PB)
    flash size     : 0x7c00 / 31744   (0x80 bytes/page)
    eeprom size    : 0x0000 /     0
    writing flash  : [**************************************************] (9642)
    verifing flash : [**************************************************] (9642)

    If the firmware fails to verify, you can run the flash operation again. If you power cycle the MappyDot after the firmware fails to verify, or you load a modified firmware that doesn't support the bootloader mode command, then you can always recover by entering the bootloader during startup of the MappyDot.

  • Designing a Filter

    Blecky07/23/2017 at 04:38 0 comments

    Like any sensor information, there will always be some inherent noise associated with the output data. This is practically unavoidable as anything that has free flowing electrons will have an associated thermal noise with it, among other sources. This is the main reason why you get grainy images on a digital camera at low light values.

    So how do we deal with it. The first and easiest method is to just ignore it and move on. However, these higher frequency effects can play havoc with some control system. If you look at the MappyDot's raw data output from some still, medium and fast motion (measurement rate of 30Hz), you will see many higher frequency "spikes" on the data, which if used on robotics, can be translated into large acceleration values if you don't account for it on a smaller timescale (by filtering):

    To help with this, each MappyDot will by default actually do some of this filtering for you which reduces the processing overhead required to filter data from numerous sensors at once for general and rapid motion cases. You can turn this filtering off on the MappyDot if you want higher frequency motion data.

    To do this, we first needed to design a filter that would be both useful and not lose too much information. We want something that can limit any higher frequency effects as they arrive into the system. Limit here being the key term, as it will smooth incoming data and still maintain "lower" frequency response.

    If we look at the FFT of the dataset, we can see that after 5-6Hz, there is no significant changes apart from noise:

    Using Matlab, we can create a simple low pass filter to help cut off these values and to analyse the changes made by changing certain coefficients. This won't be the final design of the filter implementation as it needs to work realtime, however we can play around with this to optimise the cutoff frequency for decent looking results.

    filename = '..\filtering_raw_data';
    A = importdata(filename);
    hold on
    fNorm = 3 / (30/2); %3Hz cutoff frequency, 30Hz sample rate
    [b, a] = butter(10, fNorm, 'low'); %Butterworth filter with order 10
    Y = filtfilt(b, a, A);

    Note that filtfilt "performs zero-phase digital filtering by processing the input data, x, in both the forward and reverse directions". So the actual implementation will have a small delay depending on the order value since we don't know the complete waveform as it comes in. This delay however can be exceptionally small (~<33ms), so it shouldn't affect the output so much if the filter is turned on. And since this is performed on the MappyDot, if you are reading this data at a slower rate (<30Hz) with another device, this delay will not be noticed. Some more reading here and here.

    Read more »

View all 18 project logs

Enjoy this project?



jean.perardel wrote 09/12/2017 at 08:19 point

Really cool sensors! 

Thanks for sharing! 

  Are you sure? yes | no

Blecky wrote 09/12/2017 at 10:20 point

Thank you Jean :)

  Are you sure? yes | no

Dan DWRobotics wrote 08/23/2017 at 18:30 point

This looks like a very interesting project indeed. I imagine you would be able to mount multiple units on a rotating cylinder and pole the units in a scanning motion as they traverse the forward facing plane. In effect you could make a rudimentary imaging sensor, much like the lidar on the boston dynamics bots. I imagine the data would be usable despite the wide angle of focus by combining data from each section of the scan to get a map of distances that would translate to 3d map of distances of everything in a forward facing 2 meter arc. Would be most useful for a full size robot!!

  Are you sure? yes | no

Farid Stein wrote 08/21/2017 at 20:55 point

This project looks extremely interesting and I can't wait to have a look at your firmware. I use the sensor myself in some projects and have had my share of trouble with it.

Any estimation when you will make it public?

  Are you sure? yes | no

Blecky wrote 08/27/2017 at 16:00 point

Hi Farid, the source code will be made public at the end of the month to coincide with the product's release :)

  Are you sure? yes | no

Cody Barnes wrote 08/21/2017 at 20:53 point

This could be useful to my work on the Eyedrivomatic project as a safety to prevent people from driving wheelchairs off of curbs or worse. What is the accuracy and resolution in "Highly Accurate" mode?

  Are you sure? yes | no

Blecky wrote 08/27/2017 at 16:19 point

For something like that I'm assuming that you would be aiming to detect a change in distance as you reach the curb's drop off point. The main thing to consider is the slightly limited ranging capabilities of the VL53L0X sensor outdoors.

It does start to degrade on bright days (it will still work, but the standard deviation increases). Temperature can also give a few cm's of error, however this can be re-calibrated easily though with a command (say every few minutes).

For shorter measurements less than 60cm on a bright sunny day (I haven't had any recently to test this myself), the highly accurate mode should give you around about +-4cm when measuring distance from the pavement. This is a worst case estimate, but generally it will be better than that, especially for shorter distances.

  Are you sure? yes | no

Ted Yapo wrote 06/28/2017 at 13:07 point

I looked at the VLX53L0X datasheet, and the field-of-view is 25 degrees, which seems wide if you want to use them in a narrow array.  I guess you could angle them into a coarse array, but I wonder about collimating optics of some sort.  I saw the application note about issues with crosstalk even using flat windows, so I'm not sure using a common lens system would be practical because of reflections in the lens system.  Ideally, you could slap a 12.5mm webcam lens on there, but it probably wouldn't work. The part is probably too small to easily fit separate lenses on top.  I guess it could also make the laser less eye-safe. What is your thought?

  Are you sure? yes | no

Blecky wrote 06/29/2017 at 11:52 point

Hi Ted,

I will be modelling these effects with the prototype boards to see what works and doesn't work. The main thing is that you would be using this for collision avoidance, so 25degrees is useful as you don't require as many devices to cover an entire area. In terms of reducing cross talk for narrower applications, shielding these overlaps with non reflective black surfaces will remove cross-talk effects in these cases.

I may consider an optional tubular add on for these types of requirements.

  Are you sure? yes | no

Radomir Dopieralski wrote 06/21/2017 at 11:36 point

I see someone found the VL53L0X sensor! Personally I'm mostly interested in how you are going to achieve the levitation effect ;-)

  Are you sure? yes | no

Blecky wrote 06/21/2017 at 12:39 point


  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates