DEV Community: Ștefan Donosă

I have engineered cfix, a sophisticated, high-performance command-line interface (CLI) wrapper specifically designed for the Linux ecosystem, with a primary focus on the Ubuntu distribution, to mitigate the cognitive load associated with troubleshooting complex system-level execution failures. In the contemporary software development landscape, the persistent friction caused by cryptic terminal errors often forces engineers into a suboptimal cycle of context-switching, where the transition from the terminal environment to a web browser for error research significantly degrades productivity and disrupts the psychological state of "flow".

By architecting cfix as a transparent interception layer, I have created a system that monitors the execution lifecycle of any arbitrary shell command and programmatically captures the standard error (stderr) streams upon process termination with a non-zero exit code. This utility serves as a diagnostic sentinel, utilizing the Python programming language's robust subprocess management capabilities to orchestrate a real-time data pipeline between the local execution environment and the cloud-based intelligence of the GitHub Copilot CLI. The core philosophy of cfix is to provide immediate, actionable insights that are not merely generic suggestions but are contextually grounded in the specific runtime conditions of the user's machine.

Technical implementation details involved the strategic use of the Rich library to ensure that the user interface maintains high visual fidelity and legibility, adhering to modern design tokens such as color-coded panels, dynamic spinners, and balanced whitespace. This architectural choice ensures that even the most dense technical output remains accessible and interpretable, transforming a traditionally hostile terminal environment into a collaborative workspace where the machine assists in its own debugging.

Demo

The comprehensive source code, including its modular architecture, extensive documentation, and licensing information, is publicly available for peer review and community contribution at the following location: GitHub repository .

Operational methodology:

Low-level permission diagnostics: When executing commands like cfix cat /etc/shadow, the system detects the EACCES (permission denied) signal and triggers an AI analysis that explains the security constraints of the Linux kernel and provides a safe path for privilege escalation via the sudo mechanism.

Distributed version control conflict resolution: By running cfix git push origin [typo-branch], the utility parses the complex refspec error output from Git and consults the AI to identify the discrepancy between local branch references and remote tracking pointers, suggesting the exact command to rectify the mismatch

Runtime interpreter error analysis: In scenarios involving Python or Node.js execution, such as cfix python3 faulty_script.py, the system captures the full traceback and sends the stack trace to the Copilot engine, which then identifies syntax violations or logical inconsistencies at specific line numbers.

faulty_script.py:

def calculate_logic():
    print("Starting calculation...")
    # Intentional NameError: 'result' is not defined
    final_value = result + 10
    return final_value

calculate_logic()

(Note: The accompanying screenshots demonstrate the orchestration of the Rich panels and the high-density diagnostic output provided by the Copilot backend.)

My Experience with GitHub Copilot CLI

The integration of the GitHub Copilot CLI as the primary diagnostic engine for this project was a transformative experience that highlighted the evolution of developer tooling from static documentation to dynamic, agentic assistance. Throughout the development lifecycle of cfix, the Copilot CLI served not only as a feature of the final product but as a foundational companion that accelerated the prototyping phase through its own intuitive command-line interface.

Detailed technical reflections:

I observed that the GitHub Copilot CLI exhibits an exceptional understanding of POSIX-compliant systems, accurately distinguishing between kernel-level errors, shell-specific syntax issues, and application-level exceptions with high precision.
The decision to utilize the standalone CLI with the -p (prompt) flag facilitated a highly efficient data exchange protocol, allowing cfix to maintain a stateless architecture while still benefiting from the complex state management handled by the Copilot agent.
During rigorous testing, the response times of the Copilot CLI were consistently low enough to prevent any perceived delay in the developer's workflow, a critical requirement for a tool designed to enhance rather than hinder productivity.
I spent significant time optimizing the prompt strings passed to the CLI to ensure that the AI output remained focused on providing a "one-line fix," which involved crafting instructions that prioritized technical brevity over conversational filler.
Managing the authentication lifecycle through copilot -i "auth login" provided a secure and standardized method for handling user credentials, ensuring that cfix could leverage the full power of the GitHub ecosystem without compromising security protocols.
The most profound impact was the reduction in cognitive load; knowing that a safety net was present allowed for more aggressive experimentation within the terminal, as the cost of a mistake was reduced from several minutes of research to a single keystroke.

In conclusion, the synergy between a locally-executed Python wrapper and the globally-distributed intelligence of GitHub Copilot has resulted in a tool that redefines the relationship between the developer and the command line. cfix is more than just a script; it is a manifestation of the "AI-native" development paradigm, where every terminal session is augmented by a pervasive, intelligent assistant that understands the past, present, and future of the execution environment.

License: MIT
Built by: Ștefan Donosă (My GitHub profile, My DEV profile)

From raw bytes to 3D worlds: visualizing LiDAR data with Python

Ștefan Donosă — Thu, 13 Nov 2025 14:11:13 +0000

Ștefan Donosă | 2025

Introduction

In my previous article, I detailed the detective work required to reverse-engineer the M1C1 rotational LiDAR. We cracked the protocol, identified the "Ghost packets" that were breaking our navigation stack, and learned how to parse the raw hex data.

But a stream of numbers in a terminal isn't enough for a robot—or a human—to navigate. We need a map.

In this article, I will walk you through the exact Python implementation used to transform those raw bytes into:

A high-precision 2D grid map for obstacle avoidance.
A cinematic 3D visualization (5K resolution) that mimics a SLAM point cloud.

Part 1: The mathematical foundation

Before writing code, we need to handle the geometry. The LiDAR doesn't give us X and Y coordinates; it gives us polar coordinates.

Polar to cartesian conversion

The sensor reports:

Angle (theta): The direction the laser is pointing (0° to 360°).
Distance (r): How far away the obstacle is.

To plot this on a computer screen (which uses a grid of pixels), we must convert these into cartesian coordinates (x, y):

x = r * cos(theta)
y = r * sin(theta)

The scaling challenge

A raw coordinate like (3.5m, 1.2m) is useless for an image library like OpenCV. We need to map the physical world to pixels.

Map size: 800x800 pixels.
Center point: The robot sits at pixel $(400, 400)$.
Scale: If we want to see 5 meters in every direction, we calculate a PIXELS_PER_METER factor.

Part 2: The code architecture

The script is divided into three main "engines":

The decoder: Reads serial data and extracts points.
The 2D mapper: Plots points on a top-down grid.
The 3D renderer: Extrudes the 2D data into a 3D mesh.

1. The decoder & "ghost" filtering

This is where we apply the lessons from Article 1. We define a dictionary of PACKET_TYPES to instantly recognize valid data versus status updates.

# Packet Definitions: (Header Byte 3, Header Byte 4) -> (Total Length, Num Measurements)
PACKET_TYPES = {
    (0x01, 0x01): (12, 0, False),  # Type B: Status Packet (IGNORE THIS)
    (0x00, 0x19): (40, 14, False), # Type A: Standard Scan
}

The logic:
When we read a packet, we check if it exists in our PACKET_TYPES dictionary. If it's a Type B packet (the one causing "ghost obstacles"), we skip it entirely. If it's Type A, we extract the 14 measurements inside using bitwise operations.

Key detail: The sensor provides a Start Angle and an End Angle for the packet, but contains 14 distance points. We use linear interpolation to calculate the precise angle for every intermediate point.

2. The 2D mapper (OpenCV)

For the 2D map, I used OpenCV. It's fast and efficient for manipulating pixel arrays.

def draw_2d_map(points):
    # Create a black canvas
    map_image = np.zeros((800, 800, 3), dtype=np.uint8)

    for angle, dist in points:
        # 1. Math: Convert to Cartesian
        x, y = polar_to_cartesian_2d(angle, dist)

        # 2. Scale: Convert Meters to Pixels
        px = int(CENTER_X + x * PIXELS_PER_METER)
        py = int(CENTER_Y - y * PIXELS_PER_METER)

        # 3. Draw: Plot a blue dot
        cv2.circle(map_image, (px, py), 2, (255, 0, 0), -1)

3. The 3D generator (matplotlib & image processing)

This is the most complex part. Since the LiDAR is 2D (it scans a flat line), how do we get a 3D image? We use a technique called 2.5D Extrusion.

The process:

Grid generation: We take the 2D points and place them on a "floor" grid.
Artificial height: We assign a fixed height (ALTITUDE_OBSTACLE) to every point where an obstacle was detected.
Organic smoothing (The "Secret Sauce"): Raw LiDAR data is noisy and scattered. If we plot it directly, it looks like jagged spikes. To fix this, I applied two image processing techniques to the altitude grid:
- Dilation: I used a 7x7 kernel to "fatten" the points. This connects adjacent dots, turning scattered points into solid walls.
- Gaussian blur: I applied a 21x21 blur filter. This smooths the sharp edges, making the terrain look like rolling hills or organic structures rather than digital noise.

# Smoothing the terrain for a better visual
kernel = np.ones((7, 7), np.uint8)
grid_dilated = cv2.dilate(altitude_grid, kernel, iterations=1)
grid_smooth = cv2.GaussianBlur(grid_dilated, (21, 21), 0)

Rendering: Finally, we use Matplotlib to render this surface. I enabled antialiasing and set the resolution to 5K for a crisp, professional output.

The complete code

Here is the full, open-source implementation. You can run this on a Raspberry Pi or any PC with a USB-to-UART converter.

#!/usr/bin/env python3
# -----------------------------------------------------------------
# Copyright (c) 2025 Ștefan Donosă
# Licensed under the MIT License.
# -----------------------------------------------------------------

import serial
import time
import math
import numpy as np
import cv2
import argparse
import matplotlib.pyplot as plt
from mpl_toolkits.mplot3d import Axes3D

# --- Configuration ---
SERIAL_PORT = "/dev/serial0"
BAUD_RATE = 115200
DEFAULT_SCAN_DURATION_SECONDS = 30

# Packet Definitions based on Reverse Engineering
PACKET_TYPES = {
    (0x01, 0x01): (12, 0, False),  # Status Packet (Ignore)
    (0x00, 0x19): (40, 14, False), # Standard Scan
}

# Add variable length packets (Type D)
for i in range(1, 25):
    if i == 0x19: continue
    PACKET_TYPES[(0x00, i)] = (10 + (i * 2), i, False)

# Map Settings
MAP_SIZE = 800
MAX_METERS = 5
PIXELS_PER_METER = MAP_SIZE / (MAX_METERS * 2)
CENTER_X, CENTER_Y = MAP_SIZE // 2, MAP_SIZE // 2

def decode_lidar_packet(packet, num_measurements, has_checksum):
    """
    Extracts distance and angle data from the raw bytes.
    Uses Linear Interpolation to fill in angles between Start and End.
    """
    points = []
    try:
        # Bytes 6-7: Start Angle (in 0.01 degrees)
        start_angle = (packet[6] | (packet[7] << 8)) / 100.0
        # Bytes 8-9: End Angle
        end_angle = (packet[8] | (packet[9] << 8)) / 100.0

        # Handle the wrap-around (e.g., 359 deg -> 1 deg)
        angle_diff = end_angle - start_angle
        if angle_diff < 0: angle_diff += 360.0

        step = angle_diff / (num_measurements - 1) if num_measurements > 1 else 0

        for i in range(num_measurements):
            current_angle = (start_angle + i * step) % 360

            # Distance is at offset 10, 2 bytes per measurement
            idx = 10 + i * 2
            if idx + 1 >= len(packet): break

            # Little-Endian decoding of distance
            dist_mm = packet[idx] | (packet[idx + 1] << 8)

            if dist_mm > 0:
                points.append((current_angle, dist_mm / 1000.0))

    except Exception as e:
        print(f"Decoding error: {e}")
        return points
    return points

def polar_to_cartesian(angle, dist):
    """Converts Polar (Angle, Dist) to Cartesian (X, Y)."""
    rad = math.radians(angle)
    # Note: Y is inverted for screen coordinates usually, but kept standard here
    return -dist * math.sin(rad), dist * math.cos(rad)

def generate_3d_map(frontal_points):
    """
    Generates a 5K resolution 3D surface map using Gaussian smoothing.
    """
    print("Generating 3D Mesh...")

    # 1. Create the Grid
    altitude_grid = np.zeros((MAP_SIZE, MAP_SIZE), dtype=np.float32)
    obstacle_height = 13.5 # cm

    # 2. Populate Grid
    for angle, dist in frontal_points:
        if dist > MAX_METERS: continue
        x, y = polar_to_cartesian(angle, dist)
        px = int(CENTER_X + x * PIXELS_PER_METER)
        py = int(CENTER_Y - y * PIXELS_PER_METER)

        if 0 <= px < MAP_SIZE and 0 <= py < MAP_SIZE:
            altitude_grid[py, px] = obstacle_height

    # 3. Apply Image Processing (Dilation + Blur)
    # This connects individual points into solid walls
    kernel = np.ones((7, 7), np.uint8)
    dilated = cv2.dilate(altitude_grid, kernel, iterations=1)
    # This makes the walls look "organic" rather than pixelated
    smooth_grid = cv2.GaussianBlur(dilated, (21, 21), 0)

    # 4. Render with Matplotlib
    print("Rendering 5K Image...")
    dpi = 300
    fig = plt.figure(figsize=(5120/dpi, 2880/dpi))
    ax = fig.add_subplot(111, projection='3d')

    # Subsample grid for performance (render every 8th pixel)
    stride = 8
    X, Y = np.meshgrid(np.arange(MAP_SIZE), np.arange(MAP_SIZE))

    ax.plot_surface(
        X[::stride, ::stride], 
        Y[::stride, ::stride], 
        smooth_grid[::stride, ::stride], 
        cmap=plt.cm.Reds, 
        antialiased=True, 
        alpha=0.9
    )

    # Set view angle (Front-Left)
    ax.view_init(elev=25, azim=165)
    ax.set_facecolor('#111111')
    fig.set_facecolor('#111111')

    plt.savefig("lidar_3d_render.png", dpi=dpi, facecolor='#111111')
    print("Saved: lidar_3d_render.png")

def main():
    parser = argparse.ArgumentParser()
    parser.add_argument('--duration', type=int, default=DEFAULT_SCAN_DURATION_SECONDS)
    args = parser.parse_args()

    all_points = []

    # --- Serial Collection Loop ---
    try:
        ser = serial.Serial(SERIAL_PORT, BAUD_RATE, timeout=0.1)
        print(f"Scanning for {args.duration}s...")
        start_time = time.time()
        buffer = bytearray()

        while time.time() - start_time < args.duration:
            if ser.in_waiting:
                buffer.extend(ser.read(ser.in_waiting))

                # Find Header 0xAA 0x55
                idx = buffer.find(b'\xaa\x55')
                if idx == -1:
                    if len(buffer) > 100: buffer = buffer[-100:]
                    continue

                buffer = buffer[idx:]
                if len(buffer) < 4: continue

                # Check Packet Type
                header = (buffer[2], buffer[3])
                if header in PACKET_TYPES:
                    length, count, _ = PACKET_TYPES[header]
                    if len(buffer) >= length:
                        if count > 0:
                            pts = decode_lidar_packet(buffer[:length], count, False)
                            all_points.extend(pts)
                        buffer = buffer[length:]
                else:
                    buffer = buffer[2:] # Unknown packet, skip header

    except Exception as e:
        print(f"Error: {e}")
        return

    # --- Generate Outputs ---
    if all_points:
        # 1. Generate 2D Map
        img_2d = np.zeros((MAP_SIZE, MAP_SIZE, 3), dtype=np.uint8)
        for a, d in all_points:
            x, y = polar_to_cartesian(a, d)
            px = int(CENTER_X + x * PIXELS_PER_METER)
            py = int(CENTER_Y - y * PIXELS_PER_METER)
            cv2.circle(img_2d, (px, py), 2, POINT_COLOR_2D, -1)
        cv2.imwrite("lidar_2d_map.png", img_2d)
        print("Saved: lidar_2d_map.png")

        # 2. Generate 3D Map (Frontal Arc Only)
        # We filter for 315deg to 45deg to get a clean "Driver's View"
        frontal = [p for p in all_points if p[0] >= 315 or p[0] <= 45]
        if frontal:
            generate_3d_map(frontal)

if __name__ == "__main__":
    main()

Conclusion

By combining low-level byte parsing with high-level computer vision techniques (OpenCV and Matplotlib), we transformed a cheap sensor into a powerful visualization tool.

The transition from "ghost obstacles" to a clear, high-resolution 3D mesh validates the importance of understanding your hardware protocols. This script now serves as the foundation for the robot's local path planner.

Have you ever had to reverse engineer a hardware component? Or maybe you have a different approach to visualizing LiDAR data? Let's discuss in the comments below! 👇

Reverse Engineering the M1C1 LiDAR: cracking the protocol without documentation

Ștefan Donosă — Thu, 13 Nov 2025 14:10:48 +0000

Ștefan Donosă | 2025

The "Black box" problem

In the world of robotics, sensors are the eyes of the machine. For the development of a custom autonomous navigation algorithm, I selected the M1C1 Rotational LiDAR. It is a cost-effective sensor ideal for mass production, but it came with a significant caveat common to low-cost hardware: a near-total absence of technical documentation.

The lack of a datasheet or integration guide became a major roadmap blocker. Without knowing how to interpret the stream of bytes flowing from the serial port, the sensor was useless. Rather than switching to a more expensive, well-documented alternative, I decided to reverse engineer the communication protocol to integrate it into our navigation stack.

Step 0: Hardware reconnaissance (UART & baud rate)

Before I could write a single line of code, I had to establish a physical connection. The M1C1 lacks a user-friendly USB connector, opting instead for a raw UART interface (Universal Asynchronous Receiver-Transmitter).

Connecting the sensor to my development board (Raspberry Pi 5 8GB) involved identifying the TX (Transmit) and RX (Receive) lines. Once wired, the next challenge was "tuning in" to the right frequency. Since I didn't have a datasheet, I didn't know the communication speed (baud rate) or the correct startup parameters.

I engaged in a process of trial and error, listening to the address /dev/serial0. I cycled through standard rates—9600, 38400, 57600—seeing nothing but digital garbage. Finally, at 115200 baud, the random noise stabilized into a consistent stream of hexadecimal values. The connection was established; now I just had to understand what it was saying.

However, hitting the correct baud rate wasn't the final piece of the puzzle. Initially, the line remained completely silent. I realized the sensor operates in a default "idle" mode. It requires a specific initialization command sent over the TX line to wake up—similar to an AT+START command used in modem protocols. Without sending this specific "Start scanning" byte sequence, the motor remains off and no data is transmitted.

Step 1: Data acquisition

To understand the language of the sensor, I first needed to listen to it. I wrote a Python script to capture the raw byte stream coming from the LiDAR over the serial port (/dev/serial0). The goal was to dump the hexadecimal data into a text file for static analysis.

Below is the extraction tool I developed:

#!/usr/bin/env python3
# -----------------------------------------------------------------
# Copyright (c) 2025 Ștefan Donosă
# Licensed under the MIT License.
# -----------------------------------------------------------------

import serial
import time
import os
import sys

# --- Configuration ---
SERIAL_PORT = "/dev/serial0"
BAUD_RATE = 115200
SCAN_DURATION_SECONDS = 30
OUTPUT_FILE = "lidar_raw_dump.txt"
BYTES_PER_LINE = 16 # For cleaner formatting in the text file

# --- Main program ---
def main():
    buffer = bytearray()
    total_bytes_written = 0

    try:
        ser = serial.Serial(SERIAL_PORT, BAUD_RATE, timeout=0.1)
        print(f"Serial port {SERIAL_PORT} opened. Reading raw data...")

        # Open output file
        with open(OUTPUT_FILE, "w") as f:
            print(f"Saving all raw data to '{OUTPUT_FILE}' for {SCAN_DURATION_SECONDS} seconds...")
            print("Press Ctrl+C to stop early.")

            start_time = time.time()

            while time.time() - start_time < SCAN_DURATION_SECONDS:
                try:
                    if ser.in_waiting > 0:
                        # Read all available data
                        incoming_data = ser.read(ser.in_waiting)

                        for byte in incoming_data:
                            # Write byte in hex format
                            f.write(f'0x{byte:02x} ')
                            buffer.append(byte)
                            total_bytes_written += 1

                            # New line every 16 bytes for readability
                            if len(buffer) >= BYTES_PER_LINE:
                                f.write('\n')
                                buffer.clear()

                        # Display progress
                        print(f"\rBytes written: {total_bytes_written}...", end="")

                except Exception as e_loop:
                    print(f"\nError in read loop: {e_loop}")
                    time.sleep(0.1)

            print(f"\nCollection finished. Total {total_bytes_written} bytes written to file.")

    except serial.SerialException as e:
        print(f"ERROR: Could not open serial port: {e}")
    except KeyboardInterrupt:
        print(f"\nCollection interrupted by user. {total_bytes_written} bytes written.")
    finally:
        if 'ser' in locals() and ser.is_open:
            ser.close()
            print("Serial port closed.")

if __name__ == "__main__":
    main()

Step 2: Pattern recognition

After running the script, I obtained a dump (lidar_raw_dump.txt) containing thousands of lines of hex data. Here is a snippet of what I found:

0xaa 0x55 0x01 0x01 0x67 0x00 
0x67 0x00 0xab 0x54 0x00 0x00 0xaa 0x55 0x00 0x19 0xdb 0x00 0xe1 0x0b 0xd0 0x4e 
0x24 0x08 0x00 0x08 0xf4 0x07 0xfc 0x07 0x04 0x08 0x10 0x08 0x18 0x08 0x20 0x08 
0x24 0x08 0x1c 0x08 0x2c 0x08 0x6a 0x08 0x00 0x00 0x00 0x00 0xde 0x08 0xd0 0x08 
0xc0 0x08 0xc4 0x08 0xd8 0x08 0xec 0x08 0x04 0x09 0x18 0x09 0x30 0x09 0x48 0x09 
0x64 0x09 0xaa 0x55 0x00 0x19 0x41 0x0c 0x3b 0x17 0xa4 0x5b 0x80 0x09 0x98 0x09 
0xb8 0x09 0xd4 0x09 0xf8 0x09 0x18 0x0a 0x3c 0x0a 0x60 0x0a 0x88 0x0a 0xb4 0x0a 
0xdc 0x0a 0x08 0x0b 0x38 0x0b 0x68 0x0b 0x9c 0x0b 0xd4 0x0b 0x0c 0x0c 0x48 0x0c 
0x84 0x0c 0xc8 0x0c 0x0c 0x0d 0x54 0x0d 0xa6 0x0d 0xf4 0x0d 0x4e 0x0e 0xaa 0x55 
0x00 0x19 0xb1 0x17 0xaf 0x22 0x92 0x56 0xaa 0x0e 0x0a 0x0f 0x6e 0x0f 0xda 0x0f 
0x4e 0x10 0xce 0x10 0x56 0x11 0xea 0x11 0x86 0x12 0x26 0x13 0xe2 0x13 0xaa 0x14 
0x86 0x15 0x6e 0x16 0x72 0x17 0x8a 0x18 0xc6 0x19 0x26 0x1b 0xbe 0x1c 0x82 0x1e 
0x6a 0x20 0x92 0x22 0x1a 0x25 0x4e 0x28 0x86 0x2b 0xaa 0x55 0x00 0x19 0x25 0x23 
0x23 0x2e 0xc8 0x40 0x66 0x2d 0x3c 0x2d 0x30 0x2d 0x20 0x2d 0x1c 0x2d 0x10 0x2d 
0x0c 0x2d 0x00 0x2d 0x04 0x2d 0xfc 0x2c 0x04 0x2d 0x08 0x2d 0x04 0x2d 0x10 0x2d 
0x18 0x2d 0x24 0x2d 0x2c 0x2d 0x38 0x2d 0x50 0x2d 0x80 0x2d 0x00 0x00 0x66 0x06 
0x58 0x06 0x54 0x06 0x5c 0x06 0xaa 0x55 0x00 0x19 0x97 0x2e 0x99 0x39 0xaa 0x5c 
0x6c 0x06 0x88 0x06 0xa4 0x06 0xc8 0x06 0xfe 0x06 0x00 0x00 0xc6 0x05 0xa4 0x05 
0x82 0x05 0x5a 0x05 0x2a 0x05 0xfe 0x04 0x00 0x00 0x6a 0x04 0x60 0x04 0x5c 0x04 
0x54 0x04 0x4c 0x04 0x40 0x04 0x38 0x04 0x34 0x04 0x30 0x04 0x2c 0x04 0x28 0x04 
0x20 0x04 0xaa 0x55 0x00 0x19 0x0f 0x3a 0x15 0x45 0xca 0x1e 0x0c 0x04 0x0c 0x04 
0x10 0x04 0x18 0x04 0x20 0x04 0x28 0x04 0x38 0x04 0x4c 0x04 0x00 0x00 0x00 0x00 
0x0e 0x07 0x42 0x07 0x76 0x07 0xf6 0x07 0x2a 0x08 0x54 0x08 0x00 0x00 0x00 0x00 
0x26 0x31 0x78 0x30 0xec 0x2f 0x56 0x2e 0xc4 0x2d 0x4c 0x2d 0xd0 0x2d 0xaa 0x55 
0x00 0x19 0x8b 0x45 0x89 0x50 0x00 0x7c 0x3c 0x2d 0xf0 0x2c 0x84 0x2c 0x00 0x2c 
0x96 0x26 0xba 0x22 0x20 0x22 0xe4 0x21 0xb4 0x21 0x9c 0x21 0xd2 0x20 0xfa 0x1f 
0x70 0x1f 0x2c 0x1f 0x00 0x1f 0xe0 0x1e 0xcc 0x1e 0xa0 0x1e 0x6c 0x1e 0x4c 0x1e 
0x34 0x1e 0x14 0x1e 0xe0 0x1d 0xe0 0x1d 0xd8 0x1d 0xaa 0x55 0x00 0x19 0xff 0x50 
0xfb 0x5b 0x1c 0x40 0xb8 0x1d 0xac 0x1d 0x9c 0x1d 0x9c 0x1d 0x00 0x00 0x74 0x09 
0x88 0x09 0xc2 0x1b 0xe8 0x1b 0xb8 0x1b 0xac 0x1b 0xcc 0x1b 0xf4 0x1b 0x20 0x1c 
0x48 0x1c 0x00 0x00 0x00 0x00 0x00 0x00 0x38 0x07 0x40 0x07 0x58 0x07 0x78 0x07 
0x6c 0x07 0x00 0x00 0x00 0x00 0xaa 0x55 0x00 0x19 0x71 0x5c 0x6f 0x67 0xb4 0x77 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0xaa 0x55 0x00 0x19 0xe3 0x67 0xeb 0x72 0xa2 0x59 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xaa 0x55 
0x00 0x19 0x5f 0x73 0x61 0x7e 0x94 0x41 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xaa 0x55 0x00 0x19 0xd7 0x7e 
0xdd 0x89 0xa0 0xbb 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0xaa 0x55 0x00 0x19 0x53 0x8a 0x5b 0x95 0xa2 0x53 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0xaa 0x55 0x00 0x19 0xd1 0x95 0xd1 0xa0 0xaa 0x79 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xaa 0x55 
0x00 0x19 0x47 0xa1 0x53 0xac 0xbe 0x41 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xaa 0x55 0x00 0x10 0xc9 0xac 
0xad 0xb3 0xce 0x5a 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00 0x00 0x00 0xaa 0x55 0x01 0x01 0x1b 0x00 0x1b 0x00 0xab 0x54 0x00 0x00 
0xaa 0x55 0x00 0x19 0x91 0x00 0x97 0x0b 0x00 0x40 0x00 0x00 0x18 0x08 0xf4 0x07 
0xf4 0x07 0xfc 0x07 0x08 0x08 0x14 0x08 0x1c 0x08 0x24 0x08 0x20 0x08 0x18 0x08 
0x56 0x08 0x00 0x00 0x00 0x00 0x00 0x00 0xe2 0x08 0xc8 0x08 0xbc 0x08 0xcc 0x08 
0xe0 0x08 0xf8 0x08 0x0c 0x09 0x24 0x09 0x3c 0x09 0x54 0x09

In serial communications, protocols typically use a "Header" or "Starter" — a unique sequence indicating the start of a new packet. A visual scan of the data revealed a recurring pattern: 0xAA 0x55.

The failed hypothesis

Initially, I assumed every packet starting with 0xAA 0x55 contained distance data. I attempted to parse every packet using the same logic.

The result? The autonomous navigation algorithm detected "ghost obstacles" — walls that didn't exist. This prevented any reliable path planning and totally confused the localization system. I realized that the sensor was "speaking," but I was misunderstanding the grammar.

Step 3: The breakthrough

By isolating the packets based on the byte length and the bytes at indices 2 and 3, I realized there were distinct Packet types. The sensor wasn't just sending distance; it was sending status updates mixed with measurement data.

I classified the protocol into four distinct types:

Type A: The standard scan packet

Identifier: 0xAA 0x55 0x00 0x19
Length: Fixed at 40 bytes.
Content: This is the "gold mine." It contains 14 measurements.
Data Encoding (Little-Endian): Each distance is stored in 2 bytes. Crucially, they are encoded in Little-Endian format (least significant byte first).
- Example: If the raw bytes are 0x90 0x09, the value isn't 0x9009 (which would be huge), but 0x0990.
- Why? If read as Big-Endian, the values exceeded 8 meters (the sensor's max range).
- Formula: Distance = (Byte_High << 8) | Byte_Low
RPM & Angles: Bytes 4-5 store the Rotation Speed (RPM). Bytes 6-7 and 8-9 store the Start Angle and End Angle of the batch.
Checksum: The last two bytes are a checksum. For performance in the real-time navigation loop, I opted to verify packet integrity via structure rather than calculating the checksum for every frame.

Type B: The status packet (the "ghost" maker)

Identifier: 0xAA 0x55 0x01 0x01
Length: Fixed at 12 bytes.
Function: This packet reports sensor health/status. It contains zero distance measurements.
The Fix: My initial code was trying to read distance data from this packet, interpreting status flags as physical obstacles. Identifying and ignoring Type B packets solved the "ghost wall" problem immediately.

Type C: The null packet

A variant where measurement bytes are 0x00. This indicates no echo (infinite distance or absorption).

Type D: Variable scan

Similar to Type A, but the byte at position 3 indicates a variable number of measurements.

Conclusion

By strictly defining these packet types and handling the Little-Endian conversion correctly, I turned a stream of nonsense bytes into precise environmental data. This reverse-engineering effort was the foundation for the next step: visualizing the world in 2D and 3D.

In the next article, I will share the Python code used to turn these raw packets into a high-resolution 3D map of the robot's environment.

Have you worked with undocumented sensors before? I'd love to hear your approach in the comments below!

CSS HALLOWEEN ART - by STEFAN DONOSA

Ștefan Donosă — Sun, 09 Nov 2025 22:22:12 +0000

This is a submission for Frontend Challenge - Halloween Edition, CSS Art, by Stefan Donosa.

Inspiration

The inspiration behind this piece was the desire to create a "maximalist" Halloween scene, a single artboard that captures the entire essence of the holiday in one diorama. I wanted to move beyond a simple animation and build a complete, immersive digital painting using only CSS.

The central theme is a haunted cabin perched precariously on a hill, set against a supernatural, malevolent sky. The color palette of the sky (blue-violet-orange-red) and the stark, white spectral moon were the starting points for setting a tense and magical atmosphere.

I wanted the scene to feel "alive," so I integrated classic horror elements: an ancient graveyard, a vigilant black cat, ethereal ghosts, a sinisterly glowing Jack-o'-lantern, and the composition's centerpiece, a full skeleton rising from its grave. The addition of the River Styx in the corner was meant to ground the piece in a deeper mythology, hinting at a gateway between worlds.

Demo

To see the painting in its full animated glory, please visit the live demo below:

Here

Journey

This project was a monumental challenge in layering and detail management. The goal was to build a scene with incredible depth using exclusively HTML and CSS, with no JavaScript.

The process

It all started with a clear vision: a complete tableau. I built the scene layer by layer, starting from the background (z-index: 0) and working my way to the foreground (z-index: 30+). The primary challenge was ensuring every element was visible and interacted correctly. For example, the River Styx (.river-styx) had to flow "over" the grass field (.hill-bg), but the tombstones and skeleton had to sit "on" the grass, "next to" the river. This required meticulous z-index management.

What I learned

CSS texturing: To prevent elements from looking "empty" or "transparent" (an early problem), I used complex repeating-linear-gradient tricks to create a detailed brick-like texture for the cabin and a lush, dark grass effect for the unified ground.
Complex shape creation: The full skeleton is, by far, the element I am most proud of. It's built from dozens of divs and pseudo-elements (::before, ::after), each styled with border-radius and transform to create an articulated skull, spine, ribcage, and arms.
Atmosphere is everything: A static scene is boring. The real challenge was orchestrating the animations:
1. Lightning (.lightning) uses a keyframes animation that triggers abruptly at long intervals.
2. Rain (.rain-container-fg) is composed of 300 individual divs, each with a unique animation-delay, to create a dense and chaotic effect.
3. Ghosts (.ghost) were intentionally scaled down (transform: scale(0.6)) and blurred (filter: blur(2px)) to make them feel more distant and ethereal.
4. The Pumpkin was simplified; I removed all complex inset shadows in favor of a flat shape, where the flickering light of the carved face is the only light source.

Future hopes

While I'm incredibly proud of the final result (over 1200 lines of code), the next step would be to add interactivity. Perhaps a hover effect on the tombstones that makes the skeleton jolt, or a lightning flash triggered by a click. For now, it stands as a piece of pure, animated digital art.