Showing posts with label LiDAR. Show all posts
Showing posts with label LiDAR. Show all posts

GMSL vs Automotive Ethernet for LiDAR point cloud data

Gigabit Multimedia Serial Link (GMSL) and Automotive Ethernet are both technologies used in vehicles

GMSL

GMSL is a serial link technology used for video distribution in cars. It can transport multi-megapixel images without compression, which is useful for safety features like object and pedestrian detection. GMSL is also used for high-speed data transmission (streaming) in industrial applications.


Automotive Ethernet

A specialized form of Ethernet network that enables high-speed data transfer between different car components. It uses a single pair of unshielded twisted wires for lightweight and low cost.



When transmitting LiDAR point cloud data over a network, choosing between TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) depends on your specific data integrity, speed, and complexity requirements.


TCP is a connection-oriented protocol, ensuring that all packets arrive in order and are error-free:
- Reliability: TCP provides built-in error checking and guarantees the delivery of data in the order it was sent. It is crucial when you need complete and accurate data, such as when constructing detailed and precise 3D models.
- Overhead: This reliability comes with a higher overhead, meaning more data is used to ensure the integrity and order of packets, which can reduce the overall transmission speed.


UDP is a connectionless protocol and does not guarantee order or error-checking:
- Speed: UDP is generally faster than TCP because it has lower overhead. It simply sends packets without waiting for confirmation, making it suitable for real-time applications where speed is crucial.
- Loss Tolerance: It's more suitable for situations where losing some data packets is acceptable, such as real-time monitoring or scanning environments where receiving the most current data quickly is more important than having a perfectly complete dataset.


For LiDAR data, if your application demands high accuracy and completeness—for example, in detailed environmental modeling or precise measurements — TCP would be the better choice. If you need fast data transmission for real-time applications, like navigation or object detection in autonomous vehicles, where you can tolerate some data loss, UDP might be more appropriate.


https://en.wikipedia.org/wiki/Gigabit_Multimedia_Serial_Link








As an Amazon Associate I earn from qualifying purchases.

YOLOv8

In this post, I would like to describe the architecture of YOLOv8 from first principles.

Overview

Object classification using bounding boxes

The YOLO algorithm does object classification using bounding boxes.

YOLO uses boxes instead of more natural polygons because they allow the network to represent object locations with just 4 numbers, making computation more efficient and consistent across all grid cells. Polygons would require a variable number of points per object, complicating tensor shapes and slowing training and inference. Boxes are also easier to label, faster to process, and accurate enough for most real-time detection tasks that aim to locate and classify, not to outline exact shapes.

Image preprocessing and input tensor formation

The YOLO algorithm begins with a standard RGB image, typically captured in an 8-bit-per-channel format.
Each pixel’s three color values are first normalized from 0–255 to 0–1, which keeps numerical values small enough for the optimizer to adjust weights effectively.
The image is then resized to a fixed square dimension, such as 640×640, preserving the aspect ratio by adding gray padding (letterboxing) when needed. This keeps every image in a batch at the same height and width, so they can be stacked into a single tensor and processed together by the network.
Finally, the normalized and resized image is reordered from the height-width-channel (HWC) layout to the channel-height-width (CHW) layout, forming a contiguous tensor of shape [3, H, W]. This tensor serves as the model’s input layer, with each of the three planes corresponding to the red, green, and blue channels, which the convolutional filters process in parallel to extract spatial and color features.

What is a tensor?

A tensor is a structured container for numbers with many dimensions. A single number is called a rank-0 scalar, a list is a rank-1 vector, a table is a rank-2 matrix, and an image with multiple color channels is a three-dimensional rank-3 tensor. Each dimension represents an axis, such as height, width, or color channels. Tensors enable the network to perform mathematical operations on entire blocks of data at once, which is why they are efficient for training and running deep learning models on GPUs.

Additional input dimensions

In some systems, more channels can be added to the RGB input to provide extra information. An alpha channel can represent transparency, creating an RGBA image where each pixel holds red, green, blue, and opacity values. A depth channel can store distance information, which is helpful in applications that combine vision with LiDAR or stereo sensors. These additional channels simply expand the tensor’s channel dimension, for example, from [3, H, W] to [4, H, W] or [5, H, W]. The network can then be trained or fine-tuned to interpret these extra inputs as part of its feature extraction process.

Feature extraction backbone

After the input tensor is formed, YOLOv8 passes it through the backbone, a sequence of convolutional layers (CNN) that gradually transform raw pixel values into abstract features.
Early layers detect simple patterns such as edges and colors, while deeper layers capture shapes and object parts.

In YOLOv8, the backbone is a sequence of convolutional layers organized into repeating modules rather than a single long stack. It contains roughly 50–70 layers, depending on the model size (n, s, m, l, or x). These layers are grouped into functional blocks, each performing a specific transformation.

Initial convolution

The first layer expands the 3-channel RGB input into a larger set of feature maps (e.g., 32 or 64 channels) using a 3×3 kernel and stride 2, effectively halving the spatial resolution. This captures low-level textures, such as edges and corners.

C2f modules

These are improved versions of the CSP (Cross Stage Partial) blocks used in earlier YOLO versions. Each C2f module consists of several smaller convolutional layers connected by skip paths. The idea is to allow part of the feature map to bypass heavy computation, which improves gradient flow and efficiency.

Downsampling layers

Between major C2f blocks, 3×3 convolutions with stride 2 reduce the width and height of the feature maps while increasing the number of channels. This concentrates information and allows the network to detect objects of different sizes.


Batch normalization and activation

After each convolution, YOLOv8 applies batch normalization to stabilize training and SiLU (Sigmoid Linear Unit) activation to introduce nonlinearity. SiLU helps the network learn smooth transitions and often outperforms ReLU in detection tasks.

SPPF (Spatial Pyramid Pooling Fast)

At the end of the backbone, a special pooling block combines features from multiple receptive fields using different kernel sizes. This helps the network recognize objects at various scales before passing data to the neck.

The backbone produces a set of multi-scale feature maps (often at three resolutions, such as 80×80, 40×40, and 20×20) that encode both fine detail and high-level semantic information for the next stage, the neck.

The backbone reduces spatial resolution while increasing channel depth, trading image detail for semantic richness.
YOLOv8 uses a variant of the CSP (Cross Stage Partial) architecture with C2f modules, which balance accuracy and efficiency by allowing part of the feature map to bypass heavy computation.
The backbone produces a set of feature maps at multiple scales, ready to be fused by the next stage, the neck.





As an Amazon Associate I earn from qualifying purchases.

Point Cloud Library (PCL) on Mac OS

Install PCL using BREW.

PCL is a Point Cloud Library for C++

$ xcode-select --install

xcode-select: error: command line tools are already installed, use "Software Update" to install updates



After updating Mac OS, please re-install the brew:

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"



$ brew update

Already up-to-date.

$ brew tap homebrew/science
Error: homebrew/science was deprecated. This tap is now empty as all its formulae were migrated.

$ brew tap brewsci/science


Cloning into '/usr/local/Homebrew/Library/Taps/brewsci/homebrew-science'...

DANGER (no need to do it if you re-insalled the brew):
$ sudo install -d -o $(whoami) -g admin /usr/local/Frameworks

$ brew reinstall pcl

🍺  /usr/local/Cellar/pcl/1.9.1_4: 1,173 files, 147.4MB


$ brew upgrade pcl

Error: pcl 1.9.1_4 already installed


Compile the Lidar Simulator (Udacity nd313)

cd /Volumes/DATA/_Drive/_REPOS/SFND_Lidar_Obstacle_Detection/build/

build $ rm ../CMakeCache.txt





build $ cmake ../CMakeLists.txt
-- The C compiler identification is AppleClang 10.0.1.10010046
-- The CXX compiler identification is AppleClang 10.0.1.10010046
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Checking for module 'eigen3'
--   No package 'eigen3' found
-- Found Eigen: /usr/local/include/eigen3 
-- Eigen found (include: /usr/local/include/eigen3, version: 3.3.7)
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE 
-- Boost version: 1.70.0
-- Found the following Boost libraries:
--   system
--   filesystem
--   thread
--   date_time
--   iostreams
--   serialization
--   chrono
--   atomic
--   regex
-- Checking for module 'flann'
--   No package 'flann' found
-- Found FLANN: /usr/local/Cellar/flann/1.9.1_7/lib/libflann_cpp.dylib 
-- FLANN found (include: /usr/local/Cellar/flann/1.9.1_7/include, lib: optimized;/usr/local/Cellar/flann/1.9.1_7/lib/libflann_cpp.dylib;debug;/usr/local/Cellar/flann/1.9.1_7/lib/libflann_cpp.dylib)
-- Checking for module 'flann'
--   No package 'flann' found
-- FLANN found (include: /usr/local/Cellar/flann/1.9.1_7/include, lib: optimized;/usr/local/Cellar/flann/1.9.1_7/lib/libflann_cpp.dylib;debug;/usr/local/Cellar/flann/1.9.1_7/lib/libflann_cpp.dylib)
** WARNING ** io features related to pcap will be disabled
** WARNING ** io features related to png will be disabled
-- Found libusb-1.0: /usr/local/include 
** WARNING ** io features related to libusb-1.0 will be disabled
-- Found Qhull: optimized;/usr/local/lib/libqhull_p.dylib;debug;/usr/local/lib/libqhull_p.dylib 
-- QHULL found (include: /usr/local/include, lib: optimized;/usr/local/lib/libqhull_p.dylib;debug;/usr/local/lib/libqhull_p.dylib)
-- Found OpenGL: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/OpenGL.framework 
-- Found PkgConfig: /opt/local/bin/pkg-config (found version "0.29.2")
-- Checking for module 'glew'
--   No package 'glew' found
CMake Error at /usr/local/share/pcl-1.9/PCLConfig.cmake:58 (message):
  simulation is required but glew was not found
Call Stack (most recent call first):
  /usr/local/share/pcl-1.9/PCLConfig.cmake:361 (pcl_report_not_found)
  /usr/local/share/pcl-1.9/PCLConfig.cmake:545 (find_external_library)
  CMakeLists.txt:10 (find_package)


-- Configuring incomplete, errors occurred!
See also "/Volumes/DATA/_Drive/_REPOS/SFND313_Lidar_Obstacle_Detection/CMakeFiles/CMakeOutput.log".
See also "/Volumes/DATA/_Drive/_REPOS/SFND313_Lidar_Obstacle_Detection/CMakeFiles/CMakeError.log".





$ brew install glew

Updating Homebrew...
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/core).
No changes to formulae.

Warning: glew 2.1.0 is already installed and up-to-date
To reinstall 2.1.0, run `brew reinstall glew`
(turi) uki  16:17 build $





References











As an Amazon Associate I earn from qualifying purchases.

Point Cloud Library (PCL) on Mac OS

Install PCL using BREW.

PCL is a Point Cloud Library for C++

$ xcode-select --install

xcode-select: error: command line tools are already installed, use "Software Update" to install updates



After updating Mac OS, please re-install the brew:

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"



$ brew update

Already up-to-date.

$ brew tap homebrew/science
Error: homebrew/science was deprecated. This tap is now empty as all its formulae were migrated.

$ brew tap brewsci/science


Cloning into '/usr/local/Homebrew/Library/Taps/brewsci/homebrew-science'...

DANGER (no need to do it if you re-insalled the brew):
$ sudo install -d -o $(whoami) -g admin /usr/local/Frameworks

$ brew reinstall pcl

🍺  /usr/local/Cellar/pcl/1.9.1_4: 1,173 files, 147.4MB


$ brew upgrade pcl

Error: pcl 1.9.1_4 already installed


Compile the Lidar Simulator (Udacity nd313)

cd /Volumes/DATA/_Drive/_REPOS/SFND_Lidar_Obstacle_Detection/build/

build $ rm ../CMakeCache.txt





build $ cmake ../CMakeLists.txt
-- The C compiler identification is AppleClang 10.0.1.10010046
-- The CXX compiler identification is AppleClang 10.0.1.10010046
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Checking for module 'eigen3'
--   No package 'eigen3' found
-- Found Eigen: /usr/local/include/eigen3 
-- Eigen found (include: /usr/local/include/eigen3, version: 3.3.7)
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE 
-- Boost version: 1.70.0
-- Found the following Boost libraries:
--   system
--   filesystem
--   thread
--   date_time
--   iostreams
--   serialization
--   chrono
--   atomic
--   regex
-- Checking for module 'flann'
--   No package 'flann' found
-- Found FLANN: /usr/local/Cellar/flann/1.9.1_7/lib/libflann_cpp.dylib 
-- FLANN found (include: /usr/local/Cellar/flann/1.9.1_7/include, lib: optimized;/usr/local/Cellar/flann/1.9.1_7/lib/libflann_cpp.dylib;debug;/usr/local/Cellar/flann/1.9.1_7/lib/libflann_cpp.dylib)
-- Checking for module 'flann'
--   No package 'flann' found
-- FLANN found (include: /usr/local/Cellar/flann/1.9.1_7/include, lib: optimized;/usr/local/Cellar/flann/1.9.1_7/lib/libflann_cpp.dylib;debug;/usr/local/Cellar/flann/1.9.1_7/lib/libflann_cpp.dylib)
** WARNING ** io features related to pcap will be disabled
** WARNING ** io features related to png will be disabled
-- Found libusb-1.0: /usr/local/include 
** WARNING ** io features related to libusb-1.0 will be disabled
-- Found Qhull: optimized;/usr/local/lib/libqhull_p.dylib;debug;/usr/local/lib/libqhull_p.dylib 
-- QHULL found (include: /usr/local/include, lib: optimized;/usr/local/lib/libqhull_p.dylib;debug;/usr/local/lib/libqhull_p.dylib)
-- Found OpenGL: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/OpenGL.framework 
-- Found PkgConfig: /opt/local/bin/pkg-config (found version "0.29.2")
-- Checking for module 'glew'
--   No package 'glew' found
CMake Error at /usr/local/share/pcl-1.9/PCLConfig.cmake:58 (message):
  simulation is required but glew was not found
Call Stack (most recent call first):
  /usr/local/share/pcl-1.9/PCLConfig.cmake:361 (pcl_report_not_found)
  /usr/local/share/pcl-1.9/PCLConfig.cmake:545 (find_external_library)
  CMakeLists.txt:10 (find_package)


-- Configuring incomplete, errors occurred!
See also "/Volumes/DATA/_Drive/_REPOS/SFND313_Lidar_Obstacle_Detection/CMakeFiles/CMakeOutput.log".
See also "/Volumes/DATA/_Drive/_REPOS/SFND313_Lidar_Obstacle_Detection/CMakeFiles/CMakeError.log".





$ brew install glew

Updating Homebrew...
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/core).
No changes to formulae.

Warning: glew 2.1.0 is already installed and up-to-date
To reinstall 2.1.0, run `brew reinstall glew`
(turi) uki  16:17 build $





References











As an Amazon Associate I earn from qualifying purchases.

apt quotation..