This document explains component choice, HW specifications & mounting, FW

specifications & libraries and SW interfaces & libraries.

Summary: I (thijs) found some cool-looking LiDARs on Aliexpress, and the one we bought
had the best range, resolution & likelihood-of-code-support to price ratio. I didn’t like (and
couldn’t effectively use) the existing code base, so i made my own C++ (Arduino) library to
read the data, then a custom cone-finding code to sift through all the data, then a
communication scheme for getting the cone-data to a PC in a timely manner. None of this is
official, regulation-compliant or standard, so I apologise to my successors for the
inconvenience (but i mean, come on… my code is way faster in some (niche) cases :) )

The LiDAR i chose:

aliexpress page
datasheet (on drive)
protocol sheet (on drive)
Compared to alternatives at a similar price point, this one offers the most range (~12m),
reasonable resolution (both in terms of distance and sample rate) and an acceptable degree
of manufacturer support (SLAMTEC is an established company and they offer an API)

On the drive you can find a 3D model (from the manufacturers website). I made some basic
mounts for at the last minute (I would like it to be known; I was the only electrical and
mechanical engineer on the driverless team) out of wood. This is not what I wanted to do,
but since 2D LiDARs need to be so close to the ground, the mounts need to be somewhat
sturdy. Here on the drive you can find a few more files related to mounting.

The RPLidar A1M8 requires 5v for the logic circuitry (but 3.3v logic level, don’t fret) and
5-10v for the motor. There is a connection layout in EasyEDA and the rest of the connections
should be identifiable from the prototype boards.

The lidar is connected to an ESP32 which handles preliminary data processing (because
python USB serial interface code has a lot of overhead, and the lidar spits out a lot of data).
The conversion from dot matrix to cone positions is fairly straightforward (in 2D). By knowing
the diameter of the cone (at the height that the lidar is scanning it!), you can draw lines from
the observed surface to the center of the cone for each pair of measurements. The fact that
the lidar always rotates in the same direction also helps to order the datapoints correctly
(although I did make some math for handling slightly asynchronous/non-chronological data).
See the images below for some examples.
It should be noted that the RPlidar A1M8 has multiple data-transfer modes, one of which can
produce data where the angle value is not strictly increasing. I ported this code, then chose
to disable it in my Arduino library for the RPlidar, because it seems silly (frankly, the
documentation on that particular communication format leaves a lot to be desired). If you
choose to use the existing SDK for use with ROS, be aware of this fact.

Here are quick links to the Arduino library I wrote for the RPlidar A1M8
on the drive
on github

Here is a quick link to the firmware (currently only on the drive, github stuff was ‘cleaned up’
and is therefore not working).

The LiDAR ESP receives post-SLAM position updates from the main PC, as well as speed &
steering data from the kart ESP in order to estimate (and more importantly, interpolate) the
position of the car at the exact moment a measurement is recorded. This is the main
challenge in processing lidar data, as this position must be very accurate to provide SLAM
with useful information. As FSN2022, the kart had some issues with SLAM (or at least, it had
the least issues when the LiDARs were off, making SLAM not work, and letting the car
basically drive blind). It may have simply been a case of lack of filtering, but I suspect there
may also be bugs in the LiDAR ESP’s position update code or something. I have not had
sufficient time to suss out the exact origin of these FSN issues, but since we’re switching (at
least at time of writing) to a new LiDAR, ROS and some real (filtered) SLAM, this probably
won’t matter all that much.
The ESP32’s second core is used for a number of tasks, mainly communication with the
main PC. By using the #define statements at the top of the Arduino firmware, you can enable
the use of a measurementBuffer, which shifts the responsibility of identifying cones from the
measurement data from the main core (which also has to handle communication with the
LiDAR) to the second core (which has more free time). By default this is not needed, even at
the highest data rates, but it should spit out some errors if it does become an issue.
Furthermore, what data is transmitted to the main PC can also be modified; If you wish to
know where the ESP thought the car was when the measurement was made, enable
saveMeasurementOrigin and fix some stuff in the python (main PC) communication code.
The way the code stores the measurements between raw data and fully formed cone
positions, is called a ‘blob’. You can also choose to transmit the blob instead of the cone
position (if you’d rather do that processing on the main PC), but I strongly recommend
against it, as blob objects are significantly larger than cone-position objects. All of the
abovementioned compilation options are things I played around with, but found to be
ultimately not worth it.

The communication scheme between the LiDAR ESP and the main PC (as well as between
the LiDAR ESPs and the main kart ESP (responsible for steering and throttle)), is one of my
own creation. Python does not have the best library for interfacing with COM port serial data
(lots of overhead), and i wanted a data integrity check to be included, so i made a custom
packaging scheme. On the firmware (arduino) side, see ‘conn_common.h’ for the basic data
types and functions, and ‘conn_to_PC.h’ and ‘conn_to_kartMCU.h’ for the packets specific to
the PC and kart ESP respectively. On the software (python on main PC) side, see
‘HWserialConn.py’ for all the communication code, and subsequent implementations of
those functions for the rest. In Alex’s sim, the LiDAR interface code should be working, but I
don’t know where that code is. In my sim (at time of writing it’s the
‘Thijs-sim-(RC-car-tested)-DEPRICATED’ branch), the file ‘realLidars.py’ contains the rest of
the code for interfacing with the LiDAR ESPs.

Lastly, when considering the potential range of the LiDARs, the following infographics and
math may be useful. (use the excel sheet to automatically calculate the range limits).