DEV Community: Md Shaifur Rahman

Fleet-Scale Robotics: Reliable USB Device Binding on NVIDIA Jetson Orin

Md Shaifur Rahman — Wed, 15 Jul 2026 21:44:31 +0000

If you have ever built an autonomous mobile robot, you have likely run into the dreaded "Shuffled USB Port" problem.

You boot up your robot, fire up your ROS 2 launch files, and... crash. Your LiDAR driver is trying to parse data from your IMU, and your IMU node is screaming about invalid serial frames. Because Linux assigns virtual serial paths like /dev/ttyUSB0 and /dev/ttyUSB1 based purely on which device initialized milliseconds faster, relying on default OS paths is a recipe for system instability.

When you are scaling up to dozens of Jetson Orin nodes—each equipped with an RPLIDAR C1 and a Yahboom 10-axis IMU—manually hardcoding paths or writing rigid scripts on every individual machine isn't viable.

Here is how production-grade robotics fleets handle plug-and-play USB binding dynamically using configuration-driven udev rules.

The Core Concept: Vendor ID vs. Physical Port vs. Serials

Linux's udev (device manager) allows us to dynamically create stable symbolic links (symlinks) like /dev/rplidar and /dev/imu when hardware is plugged in. How we identify those devices determines our fleet's flexibility:

USB Serials: Unique to each individual chip. Highly secure, but requires registering every single replacement sensor in your codebase.
Physical USB Ports (KERNELS): Tied to a physical slot on the carrier board. Great if you have identical sensors, but forces technicians to plug cables into highly specific, undocumented ports.
Vendor ID (VID) & Product ID (PID): Identifies the USB-to-serial converter chip on the sensor board.

Because the RPLIDAR C1 uses a Silicon Labs CP210x chip (10c4:ea60) and the Yahboom IMU uses a QinHeng CH340 chip (1a86:7523), they use completely distinct silicon. This means we can map them dynamically and reliably using just their VID/PID—allowing field technicians to plug them into any USB port on the Jetson without breaking the system.

Step 1: The Configuration-Driven File (`devices.conf`)

Hardcoding vendor rules inside shell scripts or configuration managers lacks flexibility. Instead, we separate our hardware definitions from our setup logic.

Create a file named devices.conf:

# symlink_name,vendor_id,product_id
lidar,10c4,ea60
imu,1a86,7523

This simple, comma-separated format can be easily parsed by our installation scripts, checked into Git, and updated if we change sensors down the line.

Step 2: The Automated Provisioning Script

This Bash script reads devices.conf line-by-line, dynamically generates a /etc/udev/rules.d/99-robot-usb.rules file, handles user permission groupings, applies the rules, and verifies the symlinks.

Save the following as setup_usb.sh:

#!/usr/bin/env bash

# Exit immediately if a command fails
set -e

CONF_FILE="devices.conf"
RULE_FILE="/etc/udev/rules.d/99-robot-usb.rules"

echo "=========================================================="
echo "    Jetson Fleet Provisioning: Config File Reader"
echo "=========================================================="

# 1. Verify the config file exists
if [ ! -f "$CONF_FILE" ]; then
    echo "ERROR: Configuration file '$CONF_FILE' not found!"
    exit 1
fi

# 2. Write the rules to a temporary file first
TMP_RULES=$(mktemp)
echo "# Auto-generated udev rules from $CONF_FILE" > "$TMP_RULES"
echo "# Do not edit this file directly. Edit $CONF_FILE instead." >> "$TMP_RULES"
echo "" >> "$TMP_RULES"

echo "Reading configurations from $CONF_FILE..."

# Parse the config file line by line
while IFS=, read -r name vid pid || [ -n "$name" ]; do
    # Strip leading/trailing whitespace using xargs
    name=$(echo "$name" | xargs)
    vid=$(echo "$vid" | xargs)
    pid=$(echo "$pid" | xargs)

    # Skip comments and empty lines
    if [[ -z "$name" || "$name" == \#* ]]; then
        continue
    fi

    echo "  → Configured mapping: /dev/$name (VID: $vid, PID: $pid)"

    # Write the formatted udev rule to our temp file
    echo "# $name mapping rule" >> "$TMP_RULES"
    echo "SUBSYSTEM==\"tty\", ATTRS{idVendor}==\"$vid\", ATTRS{idProduct}==\"$pid\", SYMLINK+=\"$name\", MODE=\"0666\"" >> "$TMP_RULES"
    echo "" >> "$TMP_RULES"

done < "$CONF_FILE"

# 3. Copy the finished rules file to the secure system directory
sudo cp "$TMP_RULES" "$RULE_FILE"
rm "$TMP_RULES"

# 4. Ensure user is in dialout group
echo "Adding user '$USER' to the 'dialout' group..."
sudo usermod -aG dialout "$USER"

# 5. Reload and trigger the system rules
echo "Applying new udev rules..."
sudo udevadm control --reload-rules
sudo udevadm trigger

echo "----------------------------------------------------------"
echo "SUCCESS: Rules applied!"
echo "----------------------------------------------------------"
echo "Verifying device bindings based on $CONF_FILE:"

# 6. Read the config again to dynamically verify if the links successfully bound
while IFS=, read -r name vid pid || [ -n "$name" ]; do
    name=$(echo "$name" | xargs)
    if [[ -z "$name" || "$name" == \#* ]]; then
        continue
    fi

    if [ -L "/dev/$name" ]; then
        echo "   ✓ Device successfully mapped to -> /dev/$name"
    else
        echo "   ✗ /dev/$name is NOT active. Is this device plugged in?"
    fi
done < "$CONF_FILE"

echo "=========================================================="
echo "NOTE: Close this SSH session and log back in to apply"
echo "the dialout group permission updates."
echo "=========================================================="

Make the script executable and run it on your Jetson:

chmod +x setup_usb.sh
./setup_usb.sh

Step 3: Integrating with ROS 2 Launch Files

Now that your OS guarantees your devices will always mount at /dev/lidar and /dev/imu with read/write (0666) permissions, we can configure our ROS 2 launch configurations safely.

Furthermore, production-grade drivers should always utilize automatic reconnection and node respawn parameters to handle transient power drops or physical cable vibrations during navigation.

# rplidar_launch_example.py excerpt
from launch import LaunchDescription
from launch_ros.actions import Node

def generate_launch_description():
    return LaunchDescription([
        Node(
            package='rplidar_ros',
            executable='rplidar_composition',
            output='screen',
            respawn=True,         # Auto-restart the node if it crashes
            respawn_delay=2.0,    # Wait 2 seconds before retrying
            parameters=[{
                'serial_port': '/dev/lidar', # Map directly to the udev symlink
                'serial_baudrate': 460800,
                'frame_id': 'laser_frame'
            }]
        )
    ])

Fleet Deployment & Ansible Automation

For larger scale operations (dozens of Jetsons), running this script manually on every single node is inefficient. Since the generated /etc/udev/rules.d/99-robot-usb.rules is purely generic (it targets chip models, not serial numbers), we can easily push the file to all hosts using an Ansible playbook task:

- name: Push universal udev rules to all robots
  copy:
    src: files/99-robot-usb.rules
    dest: /etc/udev/rules.d/99-robot-usb.rules
    owner: root
    group: root
    mode: '0644'
  notify: Reload Udev Daemon

By transitioning to configuration-driven hardware mapping, you remove physical port dependencies, simplify your disk cloning pipeline, and prevent silent data mixups across your fleet. Happy hacking!

Squeezing Every Megabyte: Optimizing an 8GB NVIDIA Jetson Orin Nano for Headless ROS 2 and Edge-AI

Md Shaifur Rahman — Tue, 14 Jul 2026 00:52:26 +0000

When building an autonomous robot, compute efficiency is everything. If you are running on an NVIDIA Jetson Orin Nano (8GB), you are dealing with Unified Memory (UMA)—meaning your CPU and GPU share the exact same physical RAM pool.

Out of the box, JetPack 7.2 running Ubuntu 24.04 LTS boots a full GNOME graphical desktop that devours 1.5 GB to 2.0 GB of RAM just idling. If you are loading an Edge-AI model (like Gemma 4 E2B), running dual IMX219 CSI cameras, processing 2D LiDAR data, and running a ROS 2 navigation stack, that desktop environment is a luxury you cannot afford.

In this guide, we will walk through a complete, step-by-step engineering log to:

Connect and configure a headless Jetson over a direct Ethernet/USB interface.
Systematically strip down the OS to reclaim over 1 GB of precious RAM (bringing idle usage down to ~600 MiB).
Install a native, lightweight ROS 2 Jazzy Jalisco environment.

Part 1: Headless Connection & Setup

When working on a mobile robot, you rarely want an HDMI monitor dangling off your vehicle. Connecting to your Jetson headlessly over a direct Ethernet link or the USB-C device port is the gold standard.

Local Hostname Resolution

Ubuntu uses the Avahi mDNS stack. Instead of searching for IP leases in your router's client list, you can connect directly using your Jetson's hostname:

ssh username@your-jetson-hostname.local

Tip: If you are connecting via a direct Ethernet cable between your laptop and the Jetson, ensure your laptop's Ethernet interface is set to "Link-Local Only" or "Share to other computers" to auto-assign compatible IP addresses.

Part 2: Squeezing Memory for Headless Operations

Let's look at the actual optimization path. Our starting point on a fresh, graphical JetPack 7.2 installation was 913 MiB of active RAM usage (with no monitor attached, using SSH). We want to bring this down as low as possible.

Step 1: Deactivate the Graphical User Interface (GUI)

The single biggest RAM culprit is the graphical environment. Since our robot is autonomous and headless, we can safely instruct systemd to boot directly to a text-only target.

# Set the default system target to multi-user (headless)
sudo systemctl set-default multi-user.target

# Instantly terminate the active desktop manager session
sudo systemctl isolate multi-user.target

Result: Idle memory drops instantly from **913 MiB* to 699 MiB, saving over 200 MiB.*

Step 2: Ruthlessly Pruning Background Services

Even in headless mode, standard desktop Ubuntu environments run helper programs, network daemons, and background profiling tools that are completely useless on an embedded robot.

Let's list running services:

systemctl list-units --type=service --state=running

Based on this analysis, we can safely disable several heavy-hitting daemons.

The "Safe to Disable" List

lttng-sessiond.service: A kernel tracing tool useful for core OS developers, but unnecessary for robotics applications.
iperf3.service: A bandwidth benchmarking tool left running as an open port in the background.
smbd.service & nmbd.service: Samba file sharing engines designed to host network folders for Windows/macOS network discovery.
kerneloops.service: Collects and submits crash signatures back to Canonical.
bluetooth.service: (Optional) Unless you are pairing a wireless gamepad directly to the Jetson to steer the car, disable this to free up resources.

Disable them all in one command:

sudo systemctl disable --now lttng-sessiond.service iperf3.service smbd.service nmbd.service kerneloops.service bluetooth.service

What We MUST Keep Running

nvargus-daemon.service: Absolutely essential if you are running CSI cameras (like IMX219s) because it handles the direct hardware Image Signal Processor (ISP) routing.
nvfancontrol.service: Crucial for active cooling! It dynamically regulates fan speed based on thermal zones.
jtop.service: The daemon for jetson-stats—virtually zero footprint, but indispensable for system profiling.

Step 3: Adjust Swappiness and Drop Caches

Because the Jetson uses flash storage (like an NVMe SSD), aggressive swapping can wear down your drive and introduce latency. By default, Linux has a high "swappiness" value (60), meaning it starts swapping idle memory pages early.

We want to lower this value to 10, telling the kernel to swap only as an absolute last resort:

# Temporarily set swappiness to 10
sudo sysctl vm.swappiness=10

# Make it permanent
echo "vm.swappiness=10" | sudo tee -a /etc/etc/sysctl.conf

Additionally, you can manually drop inactive system file caches to clear up immediate memory blocks right before loading high-impact AI pipelines:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Part 3: Native ROS 2 Jazzy Installation

With our OS footprint optimized, we now have a perfect foundation for ROS 2 Jazzy Jalisco (the Tier-1 supported LTS release for Ubuntu 24.04).

Since we are running a headless robot, we will opt for the ros-base package installation. This avoids bringing back any desktop GUI tools (like RViz or rqt) which would pull in hundreds of megabytes of heavy X11/Qt visual dependencies.

Step 1: Add ROS 2 Repositories

# 1. Ensure locales are configured for UTF-8
sudo apt update && sudo apt install locales -y
sudo locale-gen en_US en_US.UTF-8
sudo update-locale LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8
export LANG=en_US.UTF-8

# 2. Enable the Ubuntu Universe repository
sudo apt install software-properties-common -y
sudo add-apt-repository universe -y

# 3. Add the ROS 2 GPG key
sudo apt update && sudo apt install curl -y
sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key -o /usr/share/keyrings/ros-archive-keyring.gpg

# 4. Add the repository to your sources list
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] http://packages.ros.org/ros2/ubuntu $(. /etc/os-release && echo $UBUNTU_CODENAME) main" | sudo tee /etc/apt/sources.list.d/ros2.list > /dev/null

Step 2: Install ROS 2 Base

sudo apt update
sudo apt install ros-jazzy-ros-base ros-dev-tools -y

Step 3: Source the Environment Permanently

To make the ROS 2 tools available automatically every time you log in via SSH:

echo "source /opt/ros/jazzy/setup.bash" >> ~/.bashrc
source ~/.bashrc

Verify your installation:

ros2 --help

The Ultimate Payoff

With all of these steps completed, let's look at our final memory profile:

mdshaifur@shaifur-orin-nano:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.4Gi       607Mi       6.2Gi        12Mi       817Mi       6.8Gi
Swap:           15Gi          0B        15Gi

By transitioning to headless mode and optimizing background services, our baseline memory plummeted to an astonishing 607 MiB!

This leaves you with 6.8 GiB of fully available, ultra-fast unified memory. You are now in the perfect position to safely run:

LLM Inference: Host local models like Gemma 4 E2B via llama.cpp using ~1.5–2 GB of VRAM on the Jetson's GPU.
Dual CSI Cameras: Feed high-bandwidth IMX219 streams into your ROS 2 stack without running out of frame buffers.
Complex Robotics Pipelines: Execute localization, navigation, and obstacle avoidance simultaneously.

Optimizing your hardware limits isn't just about resource conservation—it is what makes robust, low-latency, and reliable edge robotics possible!

Have you optimized your Jetson platform for edge-AI or robotics? Let me know your favorite tricks in the comments below!

50 Low-Level Primitives to Master Linux Systems & Kernel Engineering

Md Shaifur Rahman — Fri, 03 Jul 2026 01:49:49 +0000

As systems programmers, kernel developers, and device driver engineers, our world revolves around boundary conditions, predictable execution, and absolute control over memory.

Whether you are preparing for high-intensity systems architecture interviews, designing embedded firmware, or looking to harden your understanding of low-level abstractions, practicing core operating system mechanics is the ultimate way to level up.

I have cataloged 50 distinct problems that isolate and model standard Linux kernel data structures (kfifo, slab, rbtree), driver state machines (PM states, USB enumeration, UART FSMs), bit-level accessors, and snapd/systemd patterns.

🔬 Skill Evaluation & Value

These 50 cataloged problems target the core architectural patterns required for high-reliability systems programming, Linux device driver engineering, and kernel-space development. Evaluating candidates or engineers on these primitives assesses their deep understanding of boundary conditions, memory efficiency, and deterministic execution:

Memory Ownership & Allocation: Implementing memory pools, buddy allocators, or slabs requires an explicit mastery over physical/virtual alignments, cache-line fragmentation, and avoiding memory leaks without runtime garbage collection.
Concurrency Primitives: Building lock-free queues, ticket locks, and spinlocks tests the foundational knowledge of CPU cache coherency models, atomic instructions (__atomic assembly builtins), and memory barriers.
State Machines & Protocol Parsers: Low-level logic handling UART FSMs, Netlink variable-length streams, or USB states models the exact high-stress, asynchronous environments found in real interrupt handlers, where zero-allocation parsing and structural safety are absolute requirements.

🛠️ Building & Testing Framework

This repository utilizes CMake to generate cross-platform build configurations, manage dependency tracking, and organize compilation targets efficiently across all 50 problem modules. Rather than calling raw compiler strings repeatedly, CMake automatically detects changes, optimizes object compilation, and links the execution binaries against modern testing frameworks.

Prerequisites

Ensure your system has a proper C/C++ toolchain, CMake build tool, and GoogleTest (GTest) development packages installed.

On Ubuntu/Debian-based systems, run:

sudo apt update
sudo apt install build-essential cmake libgtest-dev

If you want to implement these files yourself or explore my structural solutions, architectural paradigms, and full GoogleTest validation hooks, head over to the main repository!

👉 Visit the GitHub Repository: shaifurcodes/linux-systems-catalog

📋 Problem Catalog (P01 - P50)

P01 - Kernel-style ring buffer (kfifo-like) `[DS]`

Description: Used by: kernel log, serial drivers, DMA descriptors. Constraint: capacity must be a power of two (allows mask instead of modulo). full when (head - tail) == cap, empty when head == tail.
Hint: 💡 head & tail are ever-increasing; index = val & (cap-1)
Function Signatures:

int      rb_init(RingBuffer *rb, uint32_t cap);
void     rb_destroy(RingBuffer *rb);
int      rb_push(RingBuffer *rb, uint8_t byte);
int      rb_pop(RingBuffer *rb, uint8_t *out);

P02 - Simple inode cache (hash table + LRU eviction) `[DS]`

Description: Mimics Linux dcache/icache behaviour. Fixed capacity INODE_CACHE_SIZE=64 slots. On lookup miss + cache full: evict the least recently used entry.
Function Signatures:

void         ic_init(InodeCache *c);
void         ic_insert(InodeCache *c, uint64_t ino, uint32_t mode, uint64_t size);
void         ic_evict(InodeCache *c, uint64_t ino);
int          ic_count(const InodeCache *c);

P03 - Fixed-size slab allocator (kernel kmem_cache style) `[DS]`

Description: Pre-allocates a slab of N objects of fixed obj_size. alloc() returns a free slot in O(1); free() returns it. Use a free-list of indices stored inside free slots (intrusive).
Function Signatures:

SlabCache *slab_create(size_t obj_size, size_t capacity);
void       slab_destroy(SlabCache *sc);
void      *slab_alloc(SlabCache *sc);
void       slab_free(SlabCache *sc, void *ptr);

P04 - Wait-queue (simulated, no real threads) `[DS]`

Description: Models Linux wait_queue_head_t: tasks block until a condition is met. Simplified: tasks are represented by integer IDs. wake_one() removes and returns the head task; wake_all() drains the queue.
Function Signatures:

void wq_init(WaitQueue *wq);
int  wq_add(WaitQueue *wq, int task_id);
int  wq_wake_one(WaitQueue *wq);
int  wq_wake_all(WaitQueue *wq, int *out, int out_sz);

P05 - kfifo bulk read/write (byte stream, not single byte) `[DS]`

Description: Extend P01: push/pop N bytes at once (like serial driver DMA burst). Returns bytes actually written/read (may be less than requested if near full/empty).
Function Signatures:

int    kf_init(KFifo *kf, uint32_t cap);
void   kf_destroy(KFifo *kf);
size_t kf_write(KFifo *kf, const uint8_t *data, size_t len);
size_t kf_read(KFifo *kf, uint8_t *out, size_t len);

P06 - Device registry (udev-style) `[Driver]`

Description: Register devices by (bus, devnum). Lookup by either. Supports probe/remove lifecycle callbacks (function pointers). Max 32 devices.
Function Signatures:

void         dr_init(DeviceRegistry *r);
int          dr_register(DeviceRegistry *r, uint8_t bus, uint32_t devnum, const char *name, probe_fn p, remove_fn rm);
DeviceEntry *dr_lookup(DeviceRegistry *r, uint8_t bus, uint32_t devnum);
int          dr_remove(DeviceRegistry *r, uint8_t bus, uint32_t devnum);

P07 - GPIO interrupt mask register operations `[Driver]`

Description: Simulates a 32-bit MMIO interrupt mask register (each bit = one GPIO line). Common in Linux gpio/irqchip drivers.
Function Signatures:

void     gpio_irq_init(GpioIrqCtrl *g);
void     gpio_irq_enable(GpioIrqCtrl *g, int pin);
void     gpio_irq_disable(GpioIrqCtrl *g, int pin);
bool     gpio_irq_is_enabled(const GpioIrqCtrl *g, int pin);

P08 - MMIO register read/write helpers `[Driver]`

Description: Simulates readl/writel/readw/writeb used in Linux device drivers. Uses a byte array as the "device MMIO window". All accesses must be volatile and respect alignment.
Function Signatures:

void     mmio_init(MmioRegion *r);
void     mmio_write32(MmioRegion *r, uint32_t offset, uint32_t val);
uint32_t mmio_read32(const MmioRegion *r, uint32_t offset);
void     mmio_write8(MmioRegion *r, uint32_t offset, uint8_t val);

P09 - sysfs attribute parser `[Driver]`

Description: Parse key=value pairs as written to a sysfs node. Format: "key=value\n" or "key=value" (newline optional). Supports int, bool (0/1/true/false/on/off), and string values.
Function Signatures:

int sysfs_parse(const char *buf, SysfsAttr *out);
int sysfs_parse_int(const char *buf, long *out);
int sysfs_parse_bool(const char *buf, bool *out);

P10 - /proc/meminfo style parser `[Driver]`

Description: Parse lines of the form "FieldName: <value> kB" from a buffer (not from the actual filesystem — buffer passed in). Return the value for a given key, or -1 if not found.
Function Signatures:

long proc_get_field_kb(const char *buf, const char *key);
long proc_get_field_bytes(const char *buf, const char *key);
int  proc_count_fields(const char *buf);

P11 - Software timer wheel (simplified Linux hrtimer/timer_list) `[DS]`

Description: Fixed 256-slot wheel, 1 tick = 1ms. Timers fire when the wheel hand reaches their slot. Supports single-shot and periodic timers.
Function Signatures:

void tw_init(TimerWheel *tw);
int  tw_add(TimerWheel *tw, TimerNode *t, uint32_t delay_ticks, uint32_t period);
void tw_tick(TimerWheel *tw);
int  tw_cancel(TimerWheel *tw, TimerNode *t);

P12 - Snap version string comparison `[snapd]`

Description: Snap uses epoch:upstream~debian style versioning (subset of deb). Implement comparison returning <0, 0, >0 (like strcmp). Rules: compare epoch first (int), then upstream char-by-char digits compared numerically, non-digits compared by ASCII.
Function Signatures:

int  snap_version_cmp(const char *a, const char *b);
bool snap_version_satisfies(const char *ver, const char *constraint);

P13 - Debian control file parser (subset) `[snapd]`

Description: Parse "Field: value\n" multi-line format as found in /var/lib/dpkg/status. Support multi-line values (continuation lines start with a space).
Function Signatures:

int         deb_parse(const char *buf, DebControl *out);
const char *deb_get(const DebControl *c, const char *key);

P14 - udev uevent filter `[snapd]`

Description: uevents arrive as "KEY=VALUE\0KEY=VALUE\0..." null-separated strings. Implement a simple rule matcher: match if ALL specified key=value pairs match. Used in udev rules and snapd device assignment.
Function Signatures:

void uf_init(UeventFilter *f);
int  uf_add_rule(UeventFilter *f, const char *key, const char *val);
bool uf_matches(const UeventFilter *f, const char *uevent_buf, size_t len);
const char *uf_get_value(const char *uevent_buf, size_t len, const char *key);

P15 - cgroup resource counter (memory.usage_in_bytes style) `[snapd]`

Description: Hierarchical counter: child charges propagate up to parent. Supports limit enforcement and overflow detection.
Function Signatures:

void     cgt_init(CGroupTree *t);
int      cgt_add(CGroupTree *t, const char *name, uint64_t limit, int parent_idx);
int      cgt_charge(CGroupTree *t, int idx, uint64_t bytes);
void     cgt_uncharge(CGroupTree *t, int idx, uint64_t bytes);

P16 - Netlink message ring (variable-length messages) `[FSM]`

Description: Store variable-length netlink-style messages in a contiguous ring buffer. Each message is prefixed with a 4-byte length header. If a message does not fit, drop it and increment drop_count.
Function Signatures:

int    nlr_init(NlRing *r, uint32_t cap);
void   nlr_destroy(NlRing *r);
int    nlr_push(NlRing *r, const void *msg, uint32_t len);
int    nlr_pop(NlRing *r, void *out, uint32_t *len);

P17 - ioctl command dispatch table `[Driver]`

Description: Map ioctl command numbers to handler functions (like a driver's unlocked_ioctl). Supports up to 32 registered commands. Unknown cmd returns -ENOTTY (-25).
Function Signatures:

void ioctl_table_init(IoctlTable *t);
int  ioctl_register(IoctlTable *t, uint32_t cmd, ioctl_fn fn);
long ioctl_dispatch(const IoctlTable *t, uint32_t cmd, unsigned long arg);
int  ioctl_unregister(IoctlTable *t, uint32_t cmd);

P18 - DMA scatter-gather list builder `[Driver]`

Description: DMA transfers use scatter-gather lists: arrays of (phys_addr, length) pairs. Build an sg list from a virtual buffer, respecting a max_seg_size constraint. (Simulated: phys_addr = (uintptr_t)virt_addr for testing.)
Function Signatures:

int sg_build(SgList *sg, const void *buf, size_t total_len, size_t max_seg);
size_t sg_total_len(const SgList *sg);
int    sg_nents(const SgList *sg);

P19 - Device power state machine (Linux PM: D0/D1/D2/D3) `[Driver]`

Description: Implement transitions and transition validation. Invalid transitions must be rejected. Track transition count and time-in-state (simulated tick counter).
Function Signatures:

void   pwr_init(PowerDev *d);
int    pwr_transition(PowerDev *d, DState target);
void   pwr_tick(PowerDev *d);
bool   pwr_is_active(const PowerDev *d);

P20 - Software watchdog timer `[Driver]`

Description: A watchdog must be "kicked" (reset) before its timeout expires. If not kicked in time, it fires a callback (simulating a system reset). Supports enable/disable and timeout reconfiguration.
Function Signatures:

void wdt_init(Watchdog *w, uint32_t timeout, wdt_expire_fn fn, void *arg);
void wdt_enable(Watchdog *w);
void wdt_disable(Watchdog *w);
void wdt_kick(Watchdog *w);

P21 - mmap region tracker `[Driver]`

Description: Track mapped memory regions [start, start+len). Support overlap detection, merge of adjacent regions, and unmapping. Max 32 regions.
Function Signatures:

void  mm_init(MmapTracker *t);
int   mm_map(MmapTracker *t, uintptr_t start, size_t len, int prot);
int   mm_unmap(MmapTracker *t, uintptr_t start, size_t len);
bool  mm_is_mapped(const MmapTracker *t, uintptr_t addr);

P22 - Device tree property parser `[Driver]`

Description: Device tree properties are byte blobs. Common types: u32 cell list, string list, reg (addr+size pairs). Parse a property blob into typed values.
Function Signatures:

int  dt_read_u32(const uint8_t *prop, size_t len, int idx, uint32_t *out);
int  dt_read_u64(const uint8_t *prop, size_t len, int idx, uint64_t *out);
int  dt_read_string(const uint8_t *prop, size_t len, int idx, char *out, size_t out_sz);
int  dt_read_reg(const uint8_t *prop, size_t len, int idx, uint32_t *addr, uint32_t *size);

P23 - Firmware image CRC32 verifier `[Driver]`

Description: Firmware images end with a 4-byte CRC32 (little-endian). Verify integrity and compute CRC for new images. Use CRC32 polynomial 0xEDB88320 (IEEE 802.3, same as Linux kernel).
Function Signatures:

uint32_t fw_crc32(const uint8_t *data, size_t len);
bool     fw_verify(const uint8_t *image, size_t image_len);
void     fw_append_crc(uint8_t *image, size_t data_len);

P24 - Linux kernel boot argument parser `[snapd]`

Description: Parse cmdline strings like "console=ttyS0,115200 root=/dev/sda1 ro quiet" Extract: presence of flags, values of key=value params.
Function Signatures:

bool        bootarg_has_flag(const char *cmdline, const char *flag);
const char *bootarg_get_value(const char *cmdline, const char *key, char *out, int out_sz);
int         bootarg_count(const char *cmdline);
int         bootarg_parse_console(const char *cmdline, char *dev, int dev_sz, int *baud);

P25 - Kernel circular log buffer (dmesg-style) `[snapd]`

Description: Variable-length text messages stored in a ring. Each record: [uint16_t len][uint8_t level][char text[len]]. Oldest records are overwritten when buffer is full.
Function Signatures:

void log_init(LogBuf *lb);
int  log_write(LogBuf *lb, uint8_t level, const char *msg);
int  log_read_next(LogBuf *lb, uint8_t *level, char *out, size_t out_sz);
int  log_count(const LogBuf *lb);

P26 - PID table (kernel pidmap-lite) `[snapd]`

Description: Allocate and free PIDs from a bitmap. Max 1024 PIDs. PID 0 and 1 are always reserved. alloc_pid() returns the lowest available PID.
Function Signatures:

void pid_map_init(PidMap *pm);
int  pid_alloc(PidMap *pm);
void pid_free(PidMap *pm, int pid);
int  pid_in_use(const PidMap *pm, int pid);

P27 - /proc/mounts parser `[snapd]`

Description: Format: "device mountpoint fstype options dump pass\n". Build a searchable table of mount entries.
Function Signatures:

int          mt_parse(const char *buf, MountTable *out);
int          mt_count_fstype(const MountTable *t, const char *fstype);

P28 - Signal set / bitmask (sigset_t-lite) `[snapd]`

Description: Linux signals 1..64 stored in a two-word bitmask. Implement the full sigset_t API subset.
Function Signatures:

void sigset_empty(SigSet *s);
void sigset_fill(SigSet *s);
void sigset_add(SigSet *s, int signo);
void sigset_del(SigSet *s, int signo);

P29 - sysctl node table (proc_dointvec style) `[snapd]`

Description: Register integer sysctl variables with min/max validation. Read/write via path strings like "kernel/pid_max".
Function Signatures:

void sysctl_init(SysctlTable *t);
int  sysctl_register(SysctlTable *t, const char *path, int *var, int min, int max);
int  sysctl_read(const SysctlTable *t, const char *path, int *out);
int  sysctl_write(SysctlTable *t, const char *path, int val);

P30 - OOM killer score calculator `[snapd]`

Description: Linux OOM killer selects the process with the highest oom_score. score = (rss_pages * 1000 / total_pages) + oom_score_adj. oom_score_adj range: -1000..1000. Select the victim from a table of processes.
Function Signatures:

void oom_init(OomTable *t, uint64_t total_pages);
int  oom_add_proc(OomTable *t, int pid, uint64_t rss, int adj, const char *name);
int  oom_score(const OomTable *t, int idx);
int  oom_select_victim(const OomTable *t);

P31 - Packed sensor data frame (IoT protocol encoding) `[Bits]`

Description: Sensor transmits 4-byte frames: [temp:12bit][humidity:10bit][status:4bit][alert:6bit]. All big-endian bit-packed from MSB. Implement encode/decode without structs (raw uint32_t).
Function Signatures:

uint32_t sensor_encode(uint16_t temp_raw, uint16_t humid_raw, uint8_t status, uint8_t alert);
void     sensor_decode(uint32_t frame, uint16_t *temp, uint16_t *humid, uint8_t *status, uint8_t *alert);
bool     sensor_frame_valid(uint32_t frame);

P32 - Endianness conversion (like Linux cpu_to_be32 / le32_to_cpu) `[Bits]`

Description: Implement without relying on compiler builtins (for portability). Also implement network byte-order helpers (htons/htonl equivalent).
Function Signatures:

uint16_t bswap16(uint16_t x);
uint32_t bswap32(uint32_t x);
uint64_t bswap64(uint64_t x);
uint32_t cpu_to_be32(uint32_t x);

P33 - CRC32 with incremental update (like Linux lib/crc32.c) `[Bits]`

Description: Used for: block device checksums, firmware integrity, snap assertions. Support incremental computation across multiple buffers.
Function Signatures:

uint32_t crc32_init(void);
uint32_t crc32_update(uint32_t crc, const uint8_t *buf, size_t len);
uint32_t crc32_final(uint32_t crc);
uint32_t crc32_buf(const uint8_t *buf, size_t len);

P34 - Hardware register bitfield accessor (FIELD_GET/FIELD_PREP style) `[Bits]`

Description: Linux kernel uses FIELD_GET(mask, val) and FIELD_PREP(mask, val). Implement a portable version without typeof/__builtin_ctzl. mask encodes both position and width: e.g. 0x00FF0000 = bits 16..23.
Function Signatures:

uint32_t reg_field_get(uint32_t reg, uint32_t mask);
uint32_t reg_field_prep(uint32_t val, uint32_t mask);
uint32_t reg_field_set(uint32_t reg, uint32_t mask, uint32_t val);
uint32_t reg_field_clear(uint32_t reg, uint32_t mask);

P35 - Run-length encoding for binary firmware patches `[Bits]`

Description: Format: [count:u8][byte:u8] pairs. count=0 is invalid (skip). Used in delta firmware update compression.
Function Signatures:

int rle_encode(const uint8_t *in, size_t in_len, uint8_t *out, size_t out_cap);
int rle_decode(const uint8_t *in, size_t in_len, uint8_t *out, size_t out_cap);

P36 - Hex dump formatter (like kernel print_hex_dump) `[Bits]`

Description: Output: "0000: 01 02 03 04 05 06 07 08 |........|\n" 16 bytes per line, offset prefix, ASCII column. Used for debugging memory, registers, and network packets.
Function Signatures:

int  hex_dump(const uint8_t *buf, size_t len, char *out, size_t out_cap);
int  hex_parse(const char *hexstr, uint8_t *out, size_t out_cap);
void byte_to_hex(uint8_t b, char *hi, char *lo);

P37 - argv/getopt-style argument parser `[Bits]`

Description: Parse a command-line string into argc/argv (like wordexp without shell). Support quoted strings and escaped spaces. Also implement a simple flag parser: -f, --flag, --key=value.
Function Signatures:

int  argv_parse(const char *cmdline, ArgList *out);
bool argv_has_flag(const ArgList *al, const char *flag);
const char *argv_get_value(const ArgList *al, const char *key);

P38 - Environment variable store (snapd/systemd unit env parsing) `[Bits]`

Description: Parse "KEY=VALUE\n" format environment files. Support variable expansion: VALUE can reference $OTHER_KEY. Max depth 4 expansion.
Function Signatures:

void        env_init(EnvStore *e);
int         env_set(EnvStore *e, const char *key, const char *val);
const char *env_get(const EnvStore *e, const char *key);
int         env_parse_file(const char *buf, EnvStore *e);

P39 - Lock-free stack using GCC atomics (used in kernel-bypass paths) `[DS]`

Description: Implement using __atomic_compare_exchange_n. Nodes are caller-allocated (intrusive). Max 64 nodes.
Function Signatures:

void  lfs_init(LFStack *s);
void  lfs_push(LFStack *s, LFNode *node);
LFNode *lfs_pop(LFStack *s);
bool  lfs_empty(const LFStack *s);

P40 - Spinlock and ticket lock simulation `[DS]`

Description: Implement a test-and-set spinlock and a ticket lock using GCC __atomic. Track contention statistics (times spun, total acquires).
Function Signatures:

void spin_init(SpinLock *l);
void spin_lock(SpinLock *l);
bool spin_trylock(SpinLock *l);
void spin_unlock(SpinLock *l);

P41 - Work queue (kernel workqueue-lite) `[DS]`

Description: Deferred work items executed in submission order. Supports delayed items (run after N ticks) and cancellation.
Function Signatures:

void wq_init(WorkQueue *wq);
int  wq_submit(WorkQueue *wq, work_fn fn, void *arg, uint32_t delay_ticks);
int  wq_cancel(WorkQueue *wq, int id);
int  wq_run_pending(WorkQueue *wq);

P42 - Reference counting with saturation (like Linux kref / refcount_t) `[DS]`

Description: Saturates at UINT32_MAX (never wraps). Decrement to 0 calls release cb. Protect against use-after-free by detecting get() on a zero refcount.
Function Signatures:

void rc_init(RefCount *rc, void *obj, release_fn fn);
bool rc_get(RefCount *rc);
bool rc_put(RefCount *rc);
uint32_t rc_read(const RefCount *rc);

P43 - UART framing FSM `[DS]`

Description: Protocol: [START:0xAA][LEN:u8][PAYLOAD:LEN bytes][CRC8:u8] FSM processes one byte at a time (interrupt-driven style). States: IDLE -> SYNC -> LENGTH -> PAYLOAD -> CHECKSUM -> DONE/ERROR
Function Signatures:

void uart_fsm_init(UartFsm *f);
int  uart_fsm_feed(UartFsm *f, uint8_t byte);
void uart_fsm_reset(UartFsm *f);
uint8_t uart_crc8(const uint8_t *data, uint8_t len);

P44 - USB device enumeration state machine `[DS]`

Description: Models the USB device state machine from USB 2.0 spec: Attached -> Powered -> Default -> Address -> Configured -> Suspended. Implement legal transitions and violation detection.
Function Signatures:

void usb_dev_init(UsbDev *d);
int  usb_dev_event(UsbDev *d, UsbEvent ev);
bool usb_dev_is_ready(const UsbDev *d);
const char *usb_state_name(UsbState s);

P45 - Memory pool with alignment support `[DS]`

Description: Arena allocator: bump pointer inside a fixed buffer. Supports alignment requirements (4, 8, 16, 64 byte). reset() frees entire pool at once (no per-object free).
Function Signatures:

int   mp_init(MemPool *mp, size_t cap);
void  mp_destroy(MemPool *mp);
void *mp_alloc(MemPool *mp, size_t size, size_t align);
void  mp_reset(MemPool *mp);

P46 - Buddy allocator (simplified Linux page allocator) `[DS]`

Description: Manages 64 pages of size PAGE_SIZE=4096. Allocate in power-of-two page counts only. On free, merge with buddy if both are free.
Function Signatures:

void  buddy_init(BuddyAlloc *b);
int   buddy_alloc(BuddyAlloc *b, int npages);
void  buddy_free(BuddyAlloc *b, int page_idx, int npages);
bool  buddy_page_free(const BuddyAlloc *b, int page_idx);

P47 - Lightweight red-black tree (subset) `[DS]`

Description: Kernel uses rbtree for process scheduling (CFS), mm, timers. Implement: insert, lookup, in-order traversal only. Color balancing required for insert (left-rotate, right-rotate, recolor).
Function Signatures:

void     rbt_init(RbTree *t);
int      rbt_insert(RbTree *t, RbNode *node, uint64_t key, void *val);
void     rbt_inorder(const RbTree *t, void (*visit)(RbNode *));
int      rbt_count(const RbTree *t);

P48 - LRU cache with hash map (like Linux page cache / dcache) `[DS]`

Description: Combine a hash table for O(1) lookup with a doubly-linked LRU list. On capacity: evict LRU entry before inserting new one. Capacity: 32 entries, key: uint64_t, value: uint64_t.
Function Signatures:

void     lru_init(LruCache *c);
void     lru_put(LruCache *c, uint64_t key, uint64_t val);
bool     lru_get(LruCache *c, uint64_t key, uint64_t *val);
void     lru_evict_lru(LruCache *c);

P49 - CPU affinity map (cpumask_t-lite) `[snapd]`

Description: Track which CPUs are allowed for a task (like taskset / sched_setaffinity). Operations on bitmasks up to 64 CPUs.
Function Signatures:

void     cm_zero(CpuMask *m);
void     cm_fill(CpuMask *m, int ncpus);
void     cm_set(CpuMask *m, int cpu);
void     cm_clear(CpuMask *m, int cpu);

P50 - Snap health check state tracker (snapd snap.health API) `[snapd]`

Description: Snaps report health: ok/waiting/blocked/error with optional message. Track history (last 8 states), detect repeated errors, emit alerts.
Function Signatures:

void   sh_init(SnapHealth *h);
void   sh_report(SnapHealth *h, HealthStatus s, const char *msg);
void   sh_tick(SnapHealth *h);
bool   sh_is_critical(const SnapHealth *h);

Three Small Shell Scripts That Make HackerRank/DevSkiller C++ Take-Homes Way Less Painful

Md Shaifur Rahman — Tue, 30 Jun 2026 21:48:34 +0000

If you've ever done a timed C++ coding assessment on a platform like HackerRank or DevSkiller, you know the friction isn't really the algorithm — it's the loop. Download a zip with a weird filename, unzip it, hunt for the project root, configure CMake, build, run GTest, fix one failing test, repeat... and somewhere in there you've burned ten minutes of your one-hour window just fighting the harness instead of writing code.

These platforms' in-browser editors are fine for quick problems, but for anything involving multiple files (headers, sources, a real test suite), I'd rather work in my own terminal and editor. The catch is that you still have to get the project out of the browser sandbox, build it locally with the exact same toolchain (CMake + GTest), and then package it back up in a way the grader will accept.

So I wrote three small bash scripts to remove that friction entirely. Sharing them here in case they save someone else the same ten minutes.

The workflow

Download the project archive from the platform (zip or tar.gz, filename is whatever the platform gives you — often randomized)
Extract it — script 1 handles this regardless of filename or archive type
Iterate — script 2 configures CMake once, then repeatedly builds and runs GTest, optionally watching for file changes
Package — script 3 strips build artifacts and any local helper scripts, then zips it back up under a name that won't collide with the original download, ready to re-upload

Script 1: `extract_and_setup.sh`

Most of these platforms hand you an archive with an unpredictable filename. This script extracts whatever you point it at (.tar, .tgz, .tar.gz, or .zip), figures out which directory it unpacked to by diffing the folder listing before and after, and drops the build script into it automatically.

#!/usr/bin/env bash
# extract_and_setup.sh
# Extracts $fname (tar, tgz, tar.gz, or zip) into the CURRENT folder,
# then copies run_build.sh into the directory that was created.
#
# Usage:
#   ./extract_and_setup.sh <fname>
#   ./extract_and_setup.sh project-download.tar.gz

set -euo pipefail

if [[ $# -lt 1 ]]; then
    echo "Usage: $0 <archive-file>" >&2
    exit 1
fi

fname="$1"

if [[ ! -f "$fname" ]]; then
    echo "File not found: $fname" >&2
    exit 1
fi

# Snapshot directory contents before extracting so we can tell what's new.
before_listing="$(mktemp)"
find . -maxdepth 1 -mindepth 1 -type d | sort > "$before_listing"

echo "==> Extracting $fname into $(pwd)"

case "$fname" in
    *.tar.gz|*.tgz)
        tar -xzf "$fname"
        ;;
    *.tar)
        tar -xf "$fname"
        ;;
    *.zip)
        unzip -q "$fname"
        ;;
    *)
        echo "Unsupported archive type: $fname" >&2
        exit 1
        ;;
esac

after_listing="$(mktemp)"
find . -maxdepth 1 -mindepth 1 -type d | sort > "$after_listing"

new_dir="$(comm -13 "$before_listing" "$after_listing" | head -n1 | sed 's|^\./||')"
rm -f "$before_listing" "$after_listing"

if [[ -z "$new_dir" ]]; then
    echo "Could not determine the extracted directory (archive may not contain a top-level folder)." >&2
    exit 1
fi

echo "==> Extracted into: $new_dir"

script_dir="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
cp "$script_dir/run_build.sh" "$new_dir/run_build.sh"
chmod +x "$new_dir/run_build.sh"

echo "==> Copied run_build.sh into $new_dir/"
echo "==> Next: cd $new_dir && ./run_build.sh"

A small detail worth calling out: a bare .gz isn't supported here on purpose. Unlike .tar.gz, a plain .gz only ever wraps a single file — it has no concept of a directory tree, so it can't hold a multi-file project (headers, sources, tests, CMakeLists.txt). Assessment platforms package projects as .zip or .tar.gz, never bare .gz, so there was no reason to support a case that can't actually occur.

Script 2: `run_build.sh`

This is the one you'll run over and over while solving the problem. It configures CMake exactly once (it checks for CMakeCache.txt so repeated runs skip straight to make), builds with all your cores, and runs the GTest binary with colored output.

#!/usr/bin/env bash
# run_build.sh
# Repeatedly: configure (cmake) -> build (make) -> test (gtest).
# Lives inside the project directory; re-run any time after editing code.
#
# Usage:
#   ./run_build.sh            # configure once if needed, then build+test
#   ./run_build.sh --clean    # wipe build/ and reconfigure from scratch
#   ./run_build.sh --watch    # loop: build+test every time a source file changes

set -euo pipefail

CLEAN=0
WATCH=0

for arg in "$@"; do
    case "$arg" in
        --clean) CLEAN=1 ;;
        --watch) WATCH=1 ;;
        *) ;;
    esac
done

if [[ "$CLEAN" -eq 1 ]]; then
    echo "==> Cleaning build directory"
    rm -rf build
fi

configure_build_test() {
    mkdir -p build
    cd build

    if [[ ! -f CMakeCache.txt ]]; then
        echo "==> Configuring (cmake)"
        cmake .. -DCMAKE_BUILD_TYPE=Debug
    fi

    echo "==> Building (make)"
    make -j"$(nproc)"

    echo "==> Running tests (gtest)"
    ./unit_tests --gtest_color=yes

    cd ..
}

if [[ "$WATCH" -eq 1 ]]; then
    if ! command -v inotifywait >/dev/null 2>&1; then
        echo "inotifywait not found. Install it with: sudo apt install -y inotify-tools" >&2
        exit 1
    fi
    echo "==> Watch mode: rebuilding on changes in src/ include/ tests/ (Ctrl+C to stop)"
    configure_build_test || true
    while inotifywait -r -e modify,create,delete src include tests >/dev/null 2>&1; do
        configure_build_test || true
    done
else
    configure_build_test
fi

The --watch flag (needs inotify-tools: sudo apt install inotify-tools) is the part I use the most. It rebuilds and reruns tests automatically every time you save a file, so you get a tight "edit → see red/green" loop without retyping the build command between every change — useful when you're working through a stub-by-stub implementation under a timer.

The || true after each build call is intentional: without it, set -e would kill the whole watch loop the moment a test fails, which during active development is most of the time. With it, a failing run just gets reported and the watcher keeps going.

Script 3: `package_submission.sh`

Once ./run_build.sh --clean passes green, you need to get a clean archive back to the platform — generally without your local build/ directory, compiled object files, or the helper scripts you added for your own workflow (those weren't part of the original scaffold, and submitting them is unnecessary noise at best).

This script works on a temporary staging copy, so your live working directory (and run_build.sh in it) is left completely untouched — you can keep developing after packaging without anything having been deleted out from under you.

#!/usr/bin/env bash
# package_submission.sh
# Run this from the directory ONE LEVEL ABOVE your project folder.
# It removes build/ and any compiled artifacts, then zips the project
# back up in a clean, upload-ready archive.
#
# Usage:
#   ./package_submission.sh <project_dir>
#   ./package_submission.sh my-project
#   ./package_submission.sh my-project --format tar.gz   # default: zip
#
# Output:
#   <project_dir>-submission-ready.zip      (or .tar.gz)
#   sitting next to <project_dir>, ready to upload.
#   (suffixed so it never collides with the original input archive)

set -euo pipefail

if [[ $# -lt 1 ]]; then
    echo "Usage: $0 <project_dir> [--format zip|tar.gz]" >&2
    exit 1
fi

PROJECT_DIR="$1"
FORMAT="zip"

shift
while [[ $# -gt 0 ]]; do
    case "$1" in
        --format)
            FORMAT="$2"
            shift 2
            ;;
        *)
            echo "Unknown argument: $1" >&2
            exit 1
            ;;
    esac
done

if [[ ! -d "$PROJECT_DIR" ]]; then
    echo "Directory not found: $PROJECT_DIR" >&2
    exit 1
fi

# Strip trailing slash for clean naming.
PROJECT_DIR="${PROJECT_DIR%/}"

# Work on a throwaway copy so the live project (and your run_build.sh) is untouched.
STAGE_PARENT="$(mktemp -d)"
STAGE_DIR="$STAGE_PARENT/$PROJECT_DIR"
echo "==> Staging a clean copy of $PROJECT_DIR"
cp -r "$PROJECT_DIR" "$STAGE_DIR"

echo "==> Cleaning build artifacts"
rm -rf "${STAGE_DIR:?}/build"
find "$STAGE_DIR" -name "*.o" -delete
find "$STAGE_DIR" -name "CMakeCache.txt" -delete
find "$STAGE_DIR" -name "compile_commands.json" -delete
find "$STAGE_DIR" -type d -name "CMakeFiles" -prune -exec rm -rf {} +

echo "==> Removing local helper scripts (not part of original scaffold)"
rm -f "$STAGE_DIR/run_build.sh" "$STAGE_DIR/build_and_test.sh"

case "$FORMAT" in
    zip)
        OUT="$(pwd)/${PROJECT_DIR}-submission-ready.zip"
        rm -f "$OUT"
        echo "==> Zipping into $OUT"
        (cd "$STAGE_PARENT" && zip -rq "$OUT" "$PROJECT_DIR" -x "*.git*")
        ;;
    tar.gz)
        OUT="$(pwd)/${PROJECT_DIR}-submission-ready.tar.gz"
        rm -f "$OUT"
        echo "==> Tarring into $OUT"
        tar --exclude=".git" -czf "$OUT" -C "$STAGE_PARENT" "$PROJECT_DIR"
        ;;
    *)
        echo "Unsupported format: $FORMAT (use zip or tar.gz)" >&2
        exit 1
        ;;
esac

rm -rf "$STAGE_PARENT"

echo "==> Done: $OUT"
echo "==> Ready to upload."

Putting it together

# 1. Extract whatever the platform handed you
chmod +x extract_and_setup.sh run_build.sh package_submission.sh
./extract_and_setup.sh "project-download (1).zip"

# 2. Build + iterate
cd project-download
./run_build.sh --watch
# ... implement, save, watch tests go green, Ctrl+C when done ...

# 3. Final clean check
./run_build.sh --clean

# 4. Package for upload
cd ..
./package_submission.sh project-download
# → project-download-submission-ready.zip, ready to drag back into the platform

Why this is worth the five minutes of setup

A timed assessment window is short, and every minute spent fighting cmake/make invocations or hunting for the right directory to zip is a minute not spent on the actual problem. None of these scripts are clever — they're just removing repetitive, error-prone manual steps (figuring out the extracted folder name, remembering whether you've already run cmake .., making sure build/ doesn't end up in your submission) so the only thing left to think about is the code.

If you do C++ take-homes with CMake + GTest reasonably often, this setup pays for itself the first time you use it. Feel free to adapt the paths and test runner name (./unit_tests) to whatever your specific harness expects.

Building a ROS 2 Hardware Bridge for Yahboom 520 Motor Drivers (Without Serial Conflicts!)

Md Shaifur Rahman — Sun, 28 Jun 2026 01:15:54 +0000

Driving a robot in simulation is easy. Bringing it into the real world? That's where the fun — and the headaches — begin.

If you're building a custom 2WD differential drive robot using the Yahboom 4-Channel Encoder Motor Driver Board and 520 DC Motors, you'll quickly hit a classic hardware challenge: how do you send velocity commands (cmd_vel) and read back encoder data (odom) over a single serial pipeline without crashing your nodes?

In this post, we'll cover how the Yahboom board handles raw data packets, why multi-node serial setups fail, and how to write a unified ROS 2 Python bridge that solves the whole problem cleanly.

How the Yahboom 4-Channel Driver Actually Works

Unlike passive motor drivers (like an L298N) that require your main processor to count high-frequency square waves via hardware interrupts, the Yahboom 4-Channel Board acts as an intelligent coprocessor. Its onboard STM32F103RCT6 microcontroller handles all the time-critical work: reading Hall-effect encoders, running PID control loops, and managing state changes.

Because the STM32 handles the heavy lifting, your primary processor (Jetson Orin Nano, Raspberry Pi, etc.) only needs to talk to it via simple async strings over UART Serial (or I2C, depending on your board's dip-switch config).

Decoding the Serial Protocol

Every message uses clear start/stop sentinels to prevent corruption:

$ (Header) — tells the receive buffer to start collecting characters. Everything before this is ignored.
# (Footer) — signals the payload is complete and ready to parse.

1. Motor Type Configuration — `$mtype:x#`

Before sending any speed commands, you must declare your motor profile so the STM32 applies the correct gear ratios and PID settings.

$mtype:1#

This sets the driver explicitly for Yahboom 520 encoder motors.

2. Writing Speed — `$speed:A,B,C,D#`

Speed commands pass a comma-separated array of four integer values, one per channel. The accepted range is -1000 to 1000 — positive is forward, negative is backward.

For a 2WD chassis, motors map to Channel A (Left) and Channel C (Right). Channels B and D stay pinned to 0.

$speed:500,0,500,0#   # Move forward at half speed

3. Reading Encoders — `$read#` → `$data:...#`

To calculate odometry, poll the board by sending:

$read#

The board immediately responds with cumulative pulse counts:

$data:A_pulses,B_pulses,C_pulses,D_pulses#

Your ROS 2 node strips the tags and extracts indices 0 (left) and 2 (right) for wheel odometry calculations.

The Pitfall: The Serial "Resource Busy" Error

The natural instinct in ROS 2 is to keep things modular:

An Odometry Node that polls encoder ticks with $read#
A Velocity Node that listens to /cmd_vel and writes $speed:A,0,C,0#

If you run these as two separate processes targeting the same port (e.g., /dev/ttyUSB0), Linux throws this immediately:

SerialException: [Errno 16] Device or resource busy.

Linux prevents multiple processes from binding to the same serial device to avoid data corruption. The fix: a Unified Bridge Node that owns a single shared file handle and handles both reading and writing asynchronously.

The Architecture: Closed-Loop Control

Here's how the unified node sits between Nav2 and your physical wheels:

[ Nav2 Path Planner / Teleop ]
            │
            ▼  (Publishes target speed)
       Topic: /cmd_vel
            │
            ▼
┌────────────────────────────────────────┐
│       Yahboom Unified Robot Bridge     │
│  ────────────────────────────────────  │
│  ► Subscribes to /cmd_vel  ──────────► Writes $speed:Left,0,Right,0#
│  ► Main Loop Timer (20Hz)  ◄────────── Reads  $data:A,B,C,D# Telemetry
└────────────────────────────────────────┘
            │
            ▼  (Publishes local coordinates)
     Topic: /odom & /tf
            │
            ▼
[ Nav2 Path Planner / RViz2 ]

The Code: `yahboom_robot_bridge.py`

This script is your complete hardware driver. It initializes the coprocessor, reads encoder feedback at 20 Hz, keeps the odometry frame updated, and handles incoming velocity commands immediately.

import rclpy
from rclpy.node import Node
import serial
import math
import time

from nav_msgs.msg import Odometry
from geometry_msgs.msg import TransformStamped, Quaternion, Twist
import tf2_ros


class YahboomRobotBridge(Node):
    def __init__(self):
        super().__init__('yahboom_robot_bridge')

        # 1. Unified Serial Port Connection — opened ONCE
        self.ser = serial.Serial('/dev/ttyUSB0', 115200, timeout=0.05)
        self.ser.write(b"$mtype:1#")  # Configure for 520 motor profile
        time.sleep(0.1)
        self.ser.reset_input_buffer()

        # 2. Physical Robot Parameters — adjust to match your chassis
        self.WHEEL_BASE    = 0.150    # Distance between wheels (meters)
        self.WHEEL_RADIUS  = 0.0325   # Wheel radius (meters)
        self.TICKS_PER_REV = 1320.0   # 520 motor output ticks per revolution
        self.SCALE_FACTOR  = 1000.0   # Maps m/s → raw motor range (-1000 to 1000)

        # 3. Odometry state
        self.x  = 0.0
        self.y  = 0.0
        self.th = 0.0  # Heading in radians
        self.prev_left_ticks  = 0
        self.prev_right_ticks = 0
        self.last_time = self.get_clock().now()

        # 4. ROS 2 interfaces
        self.odom_pub       = self.create_publisher(Odometry, '/odom', 10)
        self.tf_broadcaster = tf2_ros.TransformBroadcaster(self)
        self.cmd_vel_sub    = self.create_subscription(
            Twist, '/cmd_vel', self.cmd_vel_callback, 10
        )

        # 5. Odometry timer — 20 Hz
        self.odom_timer = self.create_timer(0.05, self.update_and_publish_odom)
        self.get_logger().info("Unified Yahboom Robot Bridge started.")

    def euler_to_quaternion(self, roll, pitch, yaw):
        qx = math.sin(roll/2)*math.cos(pitch/2)*math.cos(yaw/2) - math.cos(roll/2)*math.sin(pitch/2)*math.sin(yaw/2)
        qy = math.cos(roll/2)*math.sin(pitch/2)*math.cos(yaw/2) + math.sin(roll/2)*math.cos(pitch/2)*math.sin(yaw/2)
        qz = math.cos(roll/2)*math.cos(pitch/2)*math.sin(yaw/2) - math.sin(roll/2)*math.sin(pitch/2)*math.cos(yaw/2)
        qw = math.cos(roll/2)*math.cos(pitch/2)*math.cos(yaw/2) + math.sin(roll/2)*math.sin(pitch/2)*math.sin(yaw/2)
        return Quaternion(x=qx, y=qy, z=qz, w=qw)

    def cmd_vel_callback(self, msg):
        """Convert Nav2 velocity commands → motor speed and write to serial."""
        linear_x  = msg.linear.x
        angular_z = msg.angular.z

        # Inverse differential kinematics
        left_vel  = linear_x - (angular_z * self.WHEEL_BASE / 2.0)
        right_vel = linear_x + (angular_z * self.WHEEL_BASE / 2.0)

        # Scale to raw motor range
        left_cmd  = max(min(int(left_vel  * self.SCALE_FACTOR), 1000), -1000)
        right_cmd = max(min(int(right_vel * self.SCALE_FACTOR), 1000), -1000)

        # Channel A = Left, Channel C = Right, B & D locked to 0
        command = f"$speed:{left_cmd},0,{right_cmd},0#"
        try:
            self.ser.write(command.encode('utf-8'))
        except Exception as e:
            self.get_logger().error(f"Write error: {str(e)}")

    def update_and_publish_odom(self):
        """Poll encoders, integrate position, publish /odom and /tf."""
        current_time = self.get_clock().now()
        dt = (current_time - self.last_time).nanoseconds / 1e9
        if dt <= 0.0:
            return

        try:
            self.ser.write(b"$read#")
            response = self.ser.readline().decode('utf-8').strip()

            if response.startswith("$data:") and response.endswith("#"):
                clean_data = response.replace("$data:", "").replace("#", "")
                ticks = clean_data.split(",")

                current_left  = int(ticks[0])
                current_right = int(ticks[2])
                delta_left    = current_left  - self.prev_left_ticks
                delta_right   = current_right - self.prev_right_ticks
                self.prev_left_ticks  = current_left
                self.prev_right_ticks = current_right

                # Ticks → meters
                meters_per_tick = (2 * math.pi * self.WHEEL_RADIUS) / self.TICKS_PER_REV
                dist_left  = delta_left  * meters_per_tick
                dist_right = delta_right * meters_per_tick

                delta_dist = (dist_left + dist_right) / 2.0
                delta_th   = (dist_right - dist_left) / self.WHEEL_BASE

                vx  = delta_dist / dt
                vth = delta_th   / dt

                # Integrate global position
                self.x  += delta_dist * math.cos(self.th + (delta_th / 2.0))
                self.y  += delta_dist * math.sin(self.th + (delta_th / 2.0))
                self.th += delta_th

                odom_quat = self.euler_to_quaternion(0.0, 0.0, self.th)

                # Broadcast /odom → /base_link transform
                t = TransformStamped()
                t.header.stamp     = current_time.to_msg()
                t.header.frame_id  = 'odom'
                t.child_frame_id   = 'base_link'
                t.transform.translation.x = self.x
                t.transform.translation.y = self.y
                t.transform.translation.z = 0.0
                t.transform.rotation = odom_quat
                self.tf_broadcaster.sendTransform(t)

                # Publish /odom message
                odom = Odometry()
                odom.header.stamp          = current_time.to_msg()
                odom.header.frame_id       = 'odom'
                odom.child_frame_id        = 'base_link'
                odom.pose.pose.position.x  = self.x
                odom.pose.pose.position.y  = self.y
                odom.pose.pose.orientation = odom_quat
                odom.twist.twist.linear.x  = vx
                odom.twist.twist.angular.z = vth
                self.odom_pub.publish(odom)

                self.last_time = current_time

        except Exception as e:
            self.get_logger().error(f"Read error: {str(e)}")

    def destroy_node(self):
        """Safe shutdown — stop motors before closing serial."""
        self.get_logger().info("Stopping robot wheels...")
        try:
            self.ser.write(b"$speed:0,0,0,0#")
            self.ser.close()
        except Exception:
            pass
        super().destroy_node()


def main(args=None):
    rclpy.init(args=args)
    node = YahboomRobotBridge()
    try:
        rclpy.spin(node)
    except KeyboardInterrupt:
        pass
    finally:
        node.destroy_node()
        rclpy.shutdown()


if __name__ == '__main__':
    main()

The Math Behind the Code

Two kinematic concepts drive the odometry loop.

1. Inverse Kinematics — `/cmd_vel` → Wheel Speeds

When Nav2 commands a rotation, it passes an angular velocity (angular.z). To turn left, the left wheel slows or reverses while the right wheel accelerates. The track width scales how much each side adjusts:

2. Forward Kinematics — Ticks → Global Position

Each odometry cycle computes how far each wheel traveled during a small time slice dt. The current heading θ decomposes that distance into X and Y components on the map:

Deployment Tips

Calibrate SCALE_FACTOR on your actual surface. Place the robot on the floor, command it to drive exactly 1 meter via a teleop script, and check if RViz2 shows x = 1.0. Carpet, tile, and hardwood will all give different results — adjust accordingly.

Use a persistent udev rule. If you have a LiDAR plugged in alongside the driver board, the port assignments (/dev/ttyUSB0 vs /dev/ttyUSB1) can swap on reboot. Create a udev rule to lock your driver board to a static path like /dev/yahboom_driver:

# /etc/udev/rules.d/99-yahboom.rules
SUBSYSTEM=="tty", ATTRS{idVendor}=="xxxx", ATTRS{idProduct}=="xxxx", SYMLINK+="yahboom_driver"

Replace the vendor/product IDs with the output of udevadm info -a /dev/ttyUSB0 | grep idVendor.

Happy building! Drop a comment if you're adapting this for a 4WD Mecanum chassis — the channel mapping and kinematic equations change, but the unified serial architecture stays exactly the same.

9 GitHub Projects Worth Building If You're Serious About Physical AI and Robotics

Md Shaifur Rahman — Thu, 25 Jun 2026 19:32:35 +0000

If you're trying to break into physical AI or robotics, you've probably already noticed that the field has a specific problem: everyone's resume looks the same.

ROS 2. Python. Computer vision. Familiar with deep learning.

None of that tells anyone anything useful. What actually matters in this field is whether you can take a pile of hardware, write the software to make it work, and ship something that runs reliably in the real world. That's a very different skill from knowing the right keywords.

This post is a list of projects I think are worth building if you're serious about this space. Not because completing a checklist will land you a job, but because these projects cover the gaps I see most often between what people say they can do and what they can actually demonstrate.

Pick one. Build it properly. Document it honestly. That's worth more than ten resume lines.

If any of these overlap with what you're already working on, drop a comment or reach out — always happy to compare notes or collaborate.

The Hardware Stack These Projects Assume

You don't need an expensive lab. A serious but accessible setup looks something like this:

An edge compute module with a capable GPU (8GB+ recommended)
Differential drive rover chassis with encoder motors
2D LiDAR sensor
6-DOF robotic arm
Two matched cameras for stereo vision + one wide-angle camera for scene coverage
An ARM-based microcontroller

Total cost: under $1,500. Very doable for a serious side project.

Project 1 — Autonomous Navigation Robot

Skills covered: ROS 2, Nav2, LiDAR SLAM, EKF, UKF, Sensor Fusion, IMU, Wheel Odometry

Build a fully autonomous differential drive rover that maps an unknown environment and navigates to goals without human intervention.

Fuse your LiDAR with IMU and wheel odometry using an Extended Kalman Filter for robust localization. Mount a wide-angle camera as a forward obstacle detection feed into your Nav2 costmap. Deploy the full Nav2 stack on your edge compute module and get it running in real time.

This is table stakes for most robotics roles but surprisingly few people have done it end-to-end on real hardware rather than in simulation. If you've only ever run Nav2 in Gazebo, this is the project to start with.

Project 2 — Stereo Vision Pick and Place

Skills covered: MoveIt 2, Trajectory Optimization, Stereo Vision, Depth Estimation, 3D Object Detection, PCL, OpenCV

Mount two matched cameras as a calibrated stereo pair on your robotic arm. Calibrate using OpenCV's stereo calibration pipeline, compute a disparity map, extract metric depth, and use that to localize target objects in 3D space. Plan and execute pick-and-place trajectories using MoveIt 2 with CHOMP.

The README writeup matters as much as the code here. Document your stereo baseline selection and calibration tradeoffs. The reasoning behind your decisions is what separates a real portfolio project from a tutorial followthrough.

Project 3 — Edge LLM Robot Assistant

Skills covered: Edge LLM Deployment, Llama.cpp, VLA, VLM, TensorRT, ONNX, ONNX Runtime, PyTorch

Deploy an open-source LLM or VLA model on your edge compute module using a quantized inference runtime. Use a wide-angle scene camera feeding a vision-language model for environment understanding. Export your perception model from PyTorch to ONNX, optimize with TensorRT, and run inference via ONNX Runtime.

Build a simple voice or text interface that translates natural language commands into robot actions and benchmark latency at each stage. The latency numbers are the interesting part — document them honestly including the stages where you couldn't hit real time and what you tried.

Project 4 — Imitation Learning on a Robotic Arm

Skills covered: Imitation Learning, Reinforcement Learning, VLA Fine-tuning, LeRobot, PyTorch, Hugging Face

Mount one camera as a wrist-mounted eye-in-hand camera and a second wide-angle camera as an overhead scene camera. Record 50-100 teleoperated demonstrations using an open-source imitation learning framework with both camera streams as input. Fine-tune a VLA model in PyTorch on your dataset, evaluate on held-out tasks, and publish your model publicly.

Compare imitation learning versus RL policy performance and document the gap honestly. The failure modes are as interesting as the successes and most people never write them down.

Project 5 — Sim-to-Real Transfer

Skills covered: Gazebo, Isaac Sim, MuJoCo, URDF, Sim-to-Real

Model your rover and robotic arm in URDF with all cameras as sensor plugins. Simulate across at least two environments — a physics-based simulator and a GPU-accelerated sim. Train navigation and manipulation policies in sim and transfer to real hardware.

The sim-to-real gap is where most projects fall apart. Documenting how you dealt with it is more valuable than pretending it didn't exist. Anyone who has done real sim-to-real work will immediately recognize whether you have too.

Project 6 — Embedded Firmware Controller

Skills covered: C, C++, Zephyr, FreeRTOS, Low-Level Firmware, PID, SPI, I2C, UART, CAN Bus

Write bare-metal firmware for motor control and sensor reading on an ARM-based microcontroller. Implement SPI for IMU, I2C for encoders, UART for debug output, and CAN Bus for motor commands. Tune PID controllers for motor velocity and position control. Port the same implementation to both a real-time OS and a lightweight embedded OS and benchmark the latency difference. Bridge to ROS 2 via micro-ROS.

A lot of robotics engineers never go below the ROS 2 abstraction layer. This project is worth doing just to understand what's actually happening underneath — and it shows up immediately in how you talk about systems in technical conversations.

Project 7 — Latency Optimized Inference Pipeline

Skills covered: Latency Optimization, Linux Systems Programming, CUDA, TensorRT, ONNX Runtime

Build an end-to-end inference pipeline that processes stereo camera input and wide-angle scene input simultaneously on your edge compute module. Profile and optimize preprocessing, stereo matching, model inference, and postprocessing using Linux perf tools. Use CUDA kernels where bottlenecks require it. Document before-and-after benchmarks at each stage.

Real-time performance on constrained hardware is a fundamentally different problem than getting a model to run at all. This project is specifically about that difference and it's one of the most underrepresented skills in robotics portfolios.

Project 8 — Robot CI/CD Pipeline

Skills covered: CI/CD, GitHub Actions, Hardware-in-the-Loop, Regression Testing, Docker, BehaviorTree.CPP

Containerize your full ROS 2 stack including stereo vision and Nav2 with Docker. Set up a CI/CD pipeline for automated build and test on every commit. Implement Hardware-in-the-Loop regression tests that run on real hardware. Build a behavior tree task executor covering navigation, manipulation, and vision tasks.

Most robotics projects on GitHub are one-off demos that stopped working six months after they were posted. This project is about building something you can actually maintain, iterate on, and hand to someone else.

Project 9 — PCB and Power System Design

Skills covered: KiCad, Mobile Robot Power Systems, FreeCAD, OpenSCAD

Design a custom power distribution board for your rover using open-source EDA tools. Handle battery management and voltage regulation for your compute module, motors, servos, and cameras. Design a stereo camera mount with a fixed baseline and a wide-angle mount for scene coverage using open-source CAD tools.

Most software-focused robotics engineers never touch this layer. Even a basic custom board demonstrates a level of full-stack hardware ownership that is genuinely uncommon and immediately visible to anyone reviewing your work.

A Few Thoughts on How to Approach These

Prioritize real hardware over simulation — photos and videos of things actually running matter more than clean code on its own
Document your failures and tradeoffs, not just the wins — the reasoning behind decisions is what demonstrates real understanding
A clean reproducible README is worth as much as the code itself — if someone can't clone and run it, it may as well not exist
You don't need all nine — projects 1 through 4 cover the core of what most physical AI roles care about

Where to Start

If you're just getting into this space, start with Project 1. It's the foundation everything else builds on. Once your rover is navigating autonomously on real hardware, the path to the rest of these becomes much clearer.

If you're already comfortable with navigation and want to push into embodied AI, jump straight to Projects 3 and 4. That's where the field is moving and where the interesting problems are right now.

If you're working on any of these or something in the same space, drop a comment or reach out directly. Always happy to compare notes, give feedback, or collaborate on something interesting.

Building a Zero-Touch Resume Pipeline: Overleaf + GitHub Actions + Google Sites

Md Shaifur Rahman — Thu, 25 Jun 2026 00:49:26 +0000

As a developer, keeping your resume updated across multiple platforms is a classic friction point. You tweak a bullet point or add a new project in your LaTeX source file, and suddenly you have to recompile, download the PDF, log into your portfolio site, delete the old file, and upload the new one.

I wanted a single source of truth: Edit in Overleaf, click push, and have my personal Google Site portfolio instantly update with the newly compiled PDF in under 60 seconds.

Here is how I chained Overleaf, GitHub Actions, and a clever proxy trick to build a zero-maintenance, automated CV deployment pipeline.

The Architecture

The data flow is entirely hands-off once configured:
Overleaf (Editor) ➔ GitHub Repo (Trigger) ➔ GitHub Actions (Compile) ➔ Live Google Site (Embed)

Step 1: Syncing Overleaf with GitHub

Overleaf allows you to link a project directly to a GitHub repository.

I created a blank resume repository on GitHub.
Inside Overleaf, I selected Import from GitHub to link the two.

Now, whenever I make edits to my .tex files inside Overleaf, I can use the Overleaf Git menu to cleanly push those commits straight back to my GitHub main branch.

Step 2: Automating the LaTeX Compilation via GitHub Actions

Instead of manually compiling the PDF and tracking binary files in source control, I offloaded the compilation to a CI/CD runner.

I created a workflow file at .github/workflows/compile.yml that triggers on every push. It compiles the LaTeX files cleanly and pushes the fresh PDF right back into the repo directory.

name: Compile All Resume Versions
on:
  push:
    branches:
      - main
jobs:
  build_latex:
    runs-on: ubuntu-latest
    steps:
      - name: Set up Git repository
        uses: actions/checkout@v4

      # 1. Compile the SWE Resume
      - name: Compile SWE Resume
        uses: xu-cheng/latex-action@v3
        with:
          root_file: main.tex
          working_directory: generic/

      # 2. Compile the Robotics Resume
      - name: Compile Robotics Resume
        uses: xu-cheng/latex-action@v3
        with:
          root_file: main.tex
          working_directory: robotics/

      # 3. Commit and Push all generated PDFs
      - name: Commit and Push Compiled PDFs
        run: |
          git config --global user.name "github-actions[bot]"
          git config --global user.email "github-actions[bot]@users.noreply.github.com"

          git add generic/main.pdf
          git add robotics/main.pdf

          git commit -m "Automated Multi-PDF Compilation [skip ci]" || echo "No changes to commit"
          git push

Note on Edge Cases: Notice the [skip ci] tag in the commit message? This is critical. It ensures that when GitHub Actions pushes the compiled PDF back to the repo, it doesn't trigger an infinite workflow loop.

Step 3: Bypassing the Google Sites CORS Block

This is where things got interesting. Google Sites allows you to embed assets via URLs, but if you attempt to paste a raw GitHub URL (raw.githubusercontent.com), Google Sites strips the PDF rendering and displays a grumpy page preview or a broken GitHub header wrapper. This happens due to strict cross-origin security headers (CORS).

To solve this, I leveraged raw.githack.com—a proxy service that streams raw files directly from GitHub repos with the correct Content-Type: application/pdf parameters.

I took my raw asset path and mapped it like this:
https://raw.githack.com/shaifurcodes/resume/main/robotics/main.pdf

The Ultimate Fix for Mobile/Desktop Rendering

To guarantee that the document acts exactly like a native Google Doc PDF viewer across both desktop and mobile browsers, I wrapped the raw Git proxy link inside the official Google Docs viewer parameters:

https://docs.google.com/viewer?url=https://raw.githack.com/shaifurcodes/resume/main/robotics/main.pdf&embedded=true

Step 4: The Live Embed

Open the Google Sites editor dashboard.
Select Embed from the right side panel.
Paste the complete Google Docs viewer URL from Step 3 into the By URL input.
Hit Insert and stretch the bounding canvas boxes so the layout flows cleanly down the page.

The Result

Now, my resume maintenance stack is completely decoupled. I can optimize system-level descriptions, change formatting parameters, or update project statuses inside a high-end LaTeX environment on Overleaf. The moment I hit push, the automation takes over, hot-swapping the live PDF asset on my portfolio dynamically.

Have you automated your portfolio or documentation workflows? Let's talk about alternative CI/CD configurations or caching optimizations in the comments!

DEV Community: Md Shaifur Rahman

Fleet-Scale Robotics: Reliable USB Device Binding on NVIDIA Jetson Orin

The Core Concept: Vendor ID vs. Physical Port vs. Serials

Step 1: The Configuration-Driven File (devices.conf)

Step 2: The Automated Provisioning Script

Step 3: Integrating with ROS 2 Launch Files

Fleet Deployment & Ansible Automation

Squeezing Every Megabyte: Optimizing an 8GB NVIDIA Jetson Orin Nano for Headless ROS 2 and Edge-AI

Part 1: Headless Connection & Setup

Local Hostname Resolution

Part 2: Squeezing Memory for Headless Operations

Step 1: Deactivate the Graphical User Interface (GUI)

Step 2: Ruthlessly Pruning Background Services

The "Safe to Disable" List

What We MUST Keep Running

Step 3: Adjust Swappiness and Drop Caches

Part 3: Native ROS 2 Jazzy Installation

Step 1: Add ROS 2 Repositories

Step 2: Install ROS 2 Base

Step 3: Source the Environment Permanently

The Ultimate Payoff

50 Low-Level Primitives to Master Linux Systems & Kernel Engineering

🔬 Skill Evaluation & Value

🛠️ Building & Testing Framework

Prerequisites

📋 Problem Catalog (P01 - P50)

P01 - Kernel-style ring buffer (kfifo-like) [DS]

P02 - Simple inode cache (hash table + LRU eviction) [DS]

P03 - Fixed-size slab allocator (kernel kmem_cache style) [DS]

P04 - Wait-queue (simulated, no real threads) [DS]

P05 - kfifo bulk read/write (byte stream, not single byte) [DS]

P06 - Device registry (udev-style) [Driver]

P07 - GPIO interrupt mask register operations [Driver]

P08 - MMIO register read/write helpers [Driver]

P09 - sysfs attribute parser [Driver]

P10 - /proc/meminfo style parser [Driver]

P11 - Software timer wheel (simplified Linux hrtimer/timer_list) [DS]

P12 - Snap version string comparison [snapd]

P13 - Debian control file parser (subset) [snapd]

P14 - udev uevent filter [snapd]

P15 - cgroup resource counter (memory.usage_in_bytes style) [snapd]

P16 - Netlink message ring (variable-length messages) [FSM]

P17 - ioctl command dispatch table [Driver]

P18 - DMA scatter-gather list builder [Driver]

P19 - Device power state machine (Linux PM: D0/D1/D2/D3) [Driver]

P20 - Software watchdog timer [Driver]

P21 - mmap region tracker [Driver]

P22 - Device tree property parser [Driver]

P23 - Firmware image CRC32 verifier [Driver]

P24 - Linux kernel boot argument parser [snapd]

P25 - Kernel circular log buffer (dmesg-style) [snapd]

P26 - PID table (kernel pidmap-lite) [snapd]

P27 - /proc/mounts parser [snapd]

P28 - Signal set / bitmask (sigset_t-lite) [snapd]

P29 - sysctl node table (proc_dointvec style) [snapd]

P30 - OOM killer score calculator [snapd]

P31 - Packed sensor data frame (IoT protocol encoding) [Bits]

P32 - Endianness conversion (like Linux cpu_to_be32 / le32_to_cpu) [Bits]

P33 - CRC32 with incremental update (like Linux lib/crc32.c) [Bits]

P34 - Hardware register bitfield accessor (FIELD_GET/FIELD_PREP style) [Bits]

P35 - Run-length encoding for binary firmware patches [Bits]

P36 - Hex dump formatter (like kernel print_hex_dump) [Bits]

P37 - argv/getopt-style argument parser [Bits]

P38 - Environment variable store (snapd/systemd unit env parsing) [Bits]

P39 - Lock-free stack using GCC atomics (used in kernel-bypass paths) [DS]

P40 - Spinlock and ticket lock simulation [DS]

P41 - Work queue (kernel workqueue-lite) [DS]

P42 - Reference counting with saturation (like Linux kref / refcount_t) [DS]

P43 - UART framing FSM [DS]

P44 - USB device enumeration state machine [DS]

P45 - Memory pool with alignment support [DS]

P46 - Buddy allocator (simplified Linux page allocator) [DS]

P47 - Lightweight red-black tree (subset) [DS]

P48 - LRU cache with hash map (like Linux page cache / dcache) [DS]

P49 - CPU affinity map (cpumask_t-lite) [snapd]

P50 - Snap health check state tracker (snapd snap.health API) [snapd]