0% found this document useful (0 votes)
66 views3 pages

LiDAR A1M8 Setup and Custom Code Guide

This document summarizes the component choices, hardware specifications, firmware specifications, and software interfaces for a LiDAR system used on an autonomous vehicle. It describes choosing a LiDAR sensor from Aliexpress for its range, resolution, and likelihood of code support. Custom C++ and Arduino libraries were created to read and process the LiDAR data to identify cones and communicate results to a PC. The LiDAR sensor is connected to an ESP32 microcontroller for preliminary data processing.

Uploaded by

Syed Hammad Arfi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
66 views3 pages

LiDAR A1M8 Setup and Custom Code Guide

This document summarizes the component choices, hardware specifications, firmware specifications, and software interfaces for a LiDAR system used on an autonomous vehicle. It describes choosing a LiDAR sensor from Aliexpress for its range, resolution, and likelihood of code support. Custom C++ and Arduino libraries were created to read and process the LiDAR data to identify cones and communicate results to a PC. The LiDAR sensor is connected to an ESP32 microcontroller for preliminary data processing.

Uploaded by

Syed Hammad Arfi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

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
‘[Link]’ 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 ‘[Link]’ 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).

Common questions

Powered by AI

The choice of using an ESP32 affects the efficiency of the LiDAR navigation system by offloading preliminary data processing from the main PC, reducing data overhead introduced via Python USB serial interfaces. The ESP32's dual-core architecture is used strategically, with the second core managing communication to free up the main core. This architectural decision enhances data handling and increases system responsiveness, especially given the ESP32’s role in bridging the LiDAR data with PC-based higher-level processing, thus improving overall processing and communication efficiency .

Disabling certain LiDAR data-transfer modes, such as those with non-strictly increasing angle values, limits flexibility but simplifies data handling, as these angles can complicate ordering data points accurately. This trade-off prioritizes ease of integration and reduced complexity, which might improve real-time processing but at the expense of potentially losing richer datasets offered by varied transfer modes. This choice reflects a strategic decision to favor reliable, predictable data flow over exploiting all available data configurations, balancing system stability against potential analytical depth .

The custom cone-finding algorithm processes the LiDAR data by filtering the dot matrix to identify cone positions based on known cone dimensions and the consistent rotational direction of the LiDAR. By drawing lines from observed surfaces to calculated cone centers, the algorithm allows for more efficient identification and navigation towards targets, reducing computational overhead and increasing the system's real-time response capabilities. This interaction leverages specific geometric and temporal characteristics of the LiDAR operation to streamline data processing, enhancing overall system efficacy .

Mounting solutions impact the LiDAR system by providing the necessary stability and positioning required for accurate data collection. The last-minute wooden mounts, while makeshift, serve to physically secure the LiDAR close to the ground, enhancing its ability to detect surface and object details accurately. This proper alignment and stability are crucial, as misalignment or instability could introduce data inaccuracies, affecting navigation algorithms and ultimately the functionality of the driverless system .

The selected LiDAR sensor, acquired from Aliexpress, was chosen for its optimal range, resolution, and likelihood of code support relative to its price. Thijs, responsible for the integration, developed custom software, including a C++ Arduino library to read data and a cone-finding algorithm, reflecting the need for tailored solutions in the absence of suitable existing code bases. The integration required creating wooden mounts due to last-minute constraints and the need for sturdy support close to the ground. This customization was driven by the sensor's range of approximately 12 meters and the manufacturer's support level. Additionally, the project needed the LiDAR to work with an ESP32 processor for preliminary data processing, bypassing high overhead from Python's USB serial interface .

The second core of the ESP32 is used primarily for managing communication tasks, separating it from data processing and handling roles managed by the main core. This separation allows for efficient multitasking and helps avoid performance bottlenecks that could arise from overloading a single core. By dedicating the second core to communication, the system can optimize resources, ensure timely data transmissions and processing, and maintain a high level of system performance and responsiveness, crucial for the real-time demands of a driverless vehicle system .

Challenges in SLAM and LiDAR processing, such as issues with FSN2022 when LiDARs were inactive, suggest a need for better filtering and possibly bug fixes in position update code. Future improvements could include enhanced error-checking protocols, higher accuracy in real-time position interpolation, and possibly leveraging more advanced SLAM algorithms with better filtering techniques. Additionally, changes like adopting new LiDAR models or upgrading the system architecture to handle high throughput more effectively could help address existing limitations and improve robustness and accuracy in future projects .

The communication scheme required designing a custom data packaging method with included data integrity checks due to Python's COM port serial data interfacing overhead. This custom design involved creating specific packets for both the main PC and the kart MCU, with basic data types and functions defined in 'conn_common.h' and specific implementations in 'conn_to_PC.h' and 'conn_to_kartMCU.h'. The choice to build custom protocols reflects the need for reliable, low-latency communication, crucial for real-time systems like driverless cars. The design impacts the system by requiring specific code on both Arduino and Python sides, influencing processing efficiency and system responsiveness .

Certain features or compilation options, such as using the measurementBuffer, were available but ultimately deemed unnecessary due to their limited utility at even the highest data rates, and the propensity to generate errors. The option to transmit the 'blob' data between raw data and cone positions was also available but discouraged due to its larger size compared to cone-position objects, making it inefficient to process. This evaluation reflects the need to balance raw processing capability with data handling efficiency, especially in resource-constrained environments like embedded systems .

Not transmitting 'blob' data, which is significantly larger than the processed cone-position data, reflects a strategy focused on minimizing data bandwidth and storage requirements. By opting to process data on the ESP32 and transmitting only concise, relevant information, the system design emphasizes efficient data handling and reduced latency. This decision optimizes processing resources and communication channels, enhancing overall system performance while ensuring that only necessary data is passed onto the PC for further processing .

You might also like