Problem Statements Analysis

From what to build to how to build it — our platform helps you understand, plan, and solve SIH 2026 problem statements with complete insights into requirements, solution approaches, technology stacks, architecture, AI/ML, and implementation roadmaps.

Scroll down
01 / SIH 2026

PS: SIH26053

Adaptive Variable Resolution 2.5D Lidar Mapping for Dynamic Environment Perception

Description: • Background: Autonomous navigation depends on the ability of a vehicle to perceive its surroundings with high precision. While 3D Lidar point clouds provide rich spatial data, processing millions of points in real-time creates immense computational bottlenecks and memory latency. Conversely, standard 2D occupancy grids lose critical height information necessary for detecting curbs, potholes, or overhanging obstacles. To balance precision and performance, there is a need for a 'foveated' mapping approach-similar to human vision- where the immediate vicinity is rendered in high detail for safety, and distant areas are simplified to reduce the processing load. • Description: The goal is to build a deep learning pipeline that transforms raw Lidar point clouds into a variable resolution 2.5D grid (an elevation map with semantic layers). The system must perform three primary tasks: 1. Terrain Analysis: Distinguish between drivable surfaces and non-drivable terrain. 2. Object Detection: Identify and classify static obstacles (walls, poles) and dynamic objects (pedestrians, other vehicles). 3. Adaptive Spatial Representation: Implement a non-uniform grid where the cell size increases as the distance from the sensor increases. This requires a sophisticated data structure that can handle variable resolution without causing alignment errors or data loss during the projection from 3D to 2.5D. • Expected Solution: A software framework consisting of: • A Deep Learning Model: A network (e.g., PointNet++ or a Sparse Convolutional Neural Network) capable of semantic segmentation of point clouds into terrain, static obstacles, and moving objects. • Variable Resolution Grid Engine: An algorithm that projects classified 3D points into a 2.5D grid where the resolution is high (e.g., 5cm cells) within a 10m radius and decreases (e.g., 50cm cells) up to a 100m radius. • Real-time Visualization: A dashboard showing the 2.5D map with distinct color-coding for terrain and objects, demonstrating a significant reduction in memory usage compared to a uniform high-resolution 3D map. • Performance Metrics: Evidence of low latency (high FPS) and high accuracy in object classification across varying distances.
Organization: DRDO
Department: Department of Defence Production /IDEX
Category: Software
Theme: Smart Vehiclestd>
Youtube Link: Not provided
Dataset Link: Not provided
Contact info: Not provided

1. Executive Snapshot

This research and implementation dossier presents an end-to-end software framework designed for the Defence Research and Development Organisation (DRDO) under the iDEX / Smart Vehicles challenge (Problem ID: SIH26053). Autonomous ground vehicles (UGVs) and defense mobile platforms operating in dynamic, unstructured tactical terrain require hyper-accurate spatial perception without incurring massive compute and latency overheads [PS, INFERENCE]. Standard 3D LiDAR point cloud processing (handling $10^5$–$10^6$ points per frame at 10–20 Hz) imposes extreme memory bandwidth bottlenecks, while traditional 2D occupancy grids strip crucial height profile information needed for detecting curbs, overhanging obstacles, and negative terrain [PS, KNOWN]. To resolve this trade-off, we specify an Adaptive Variable-Resolution 2.5D LiDAR Mapping Pipeline inspired by biological foveated vision [PS]. The architecture pairs a high-speed Sparse 3D Convolutional Neural Network (Sparse CNN / SpConv) for 3D semantic segmentation with a non-uniform 2.5D concentric ring grid engine ($5\text{ cm}$ cell resolution within a $10\text{ m}$ safety radius, relaxing smoothly to $50\text{ cm}$ cell resolution at $100\text{ m}$) [PS, ASSUMPTION]. This system preserves sub-centimeter obstacle detail in the immediate vehicle envelope while reducing memory footprint by over 70% and sustaining execution at $>20\text{ FPS}$ on edge-compute hardware [INFERENCE].

Metadata Summary

Parameter Specification Confidence Tag
Problem Statement ID SIH26053 [PS]
Title Adaptive Variable Resolution 2.5D Lidar Mapping for Dynamic Environment Perception [PS]
Organization Defence Research and Development Organisation (DRDO) [PS]
Department Department of Defence Production / iDEX [PS]
Category Software [PS]
Theme Smart Vehicles [PS]
Submission Deadline 30 September 2026 [PS]
Ideas Counter 0 / 500 [PS]
Fundamental System Objective Deliver a real-time, foveated 2.5D semantic mapping engine that ingests raw 3D LiDAR point clouds, performs deep learning-based terrain and object classification, and projects points onto an adaptive spatial grid to minimize compute latency and memory overhead while maintaining high near-field navigation safety. [PS, INFERENCE]

2. Problem Deconstruction

The explicit problem statement provided by DRDO / iDEX contains three primary core tasks and four required solution deliverables [PS]. Below is the atomic deconstruction into formal requirement specifications:

Task Breakdown & Requirement Mapping

Req ID Source Text / Requirement Interpretation Technical & Implementation Implication Confidence
REQ-1 "Terrain Analysis: Distinguish between drivable surfaces and non-drivable terrain." The system must classify ground points into traversable road/flat ground vs non-traversable slope/rough terrain/vegetation. Semantic segmentation network must output a binary or multi-class drivability mask for every point or voxel; elevation map must compute surface normal ($\vec{n}$) and roughness variance ($\sigma_z^2$). [PS, INFERENCE]
REQ-2 "Object Detection: Identify and classify static obstacles (walls, poles) and dynamic objects (pedestrians, other vehicles)." The pipeline must perform multi-class segmentation separating stationary structures from dynamic moving entities. Network taxonomy must cover at least 5 key classes: Drivable Ground, Non-Drivable Ground, Static Obstacle (wall/pole/building), Dynamic Vehicle, Dynamic Pedestrian/VRU. [PS, INFERENCE]
REQ-3 "Adaptive Spatial Representation: Implement a non-uniform grid where the cell size increases as the distance from the sensor increases... without causing alignment errors or data loss during projection from 3D to 2.5D." The spatial data structure must discretize space radially or in concentric zones, maintaining precise sub-grid coordinates without aliasing at boundary transitions. Data structure must use a Concentric Multi-Resolution Ring Buffer or Radial Quadtree anchored to vehicle IMU/Odometry, using bilinear surface interpolation and temporal filtering across boundary cell transitions. [PS, INFERENCE]
REQ-4A "A Deep Learning Model: A network (e.g., PointNet++ or a Sparse Convolutional Neural Network) capable of semantic segmentation of point clouds..." 3D Deep Learning pipeline trained on point cloud benchmarks. Integrate SpConv / TorchSparse v2 sparse 3D UNet or PointNet++ optimized via TensorRT/ONNX Runtime for embedded inference. [PS, RESEARCHED]
REQ-4B "Variable Resolution Grid Engine: An algorithm that projects classified 3D points into a 2.5D grid where the resolution is high (e.g., 5cm cells) within a 10m radius and decreases (e.g., 50cm cells) up to a 100m radius." Projection algorithm mapping 3D segmented points $(x,y,z, \text{class})$ into multi-resolution 2.5D layers ($Z_{\max}, Z_{\min}, Z_{\text{mean}}$, class distribution vector). C++ grid projection engine operating on $O(N)$ point cloud scans; inner zone ($0\text{--}10\text{ m}$) at $0.05\text{ m}$, mid zone ($10\text{--}30\text{ m}$) at $0.15\text{ m}$, outer zone ($30\text{--}100\text{ m}$) at $0.50\text{ m}$. [PS, ASSUMPTION]
REQ-4C "Real-time Visualization: A dashboard showing the 2.5D map with distinct color-coding for terrain and objects, demonstrating a significant reduction in memory usage compared to a uniform high-resolution 3D map." GUI / RViz dashboard displaying live multi-layered grid, color coding by class/height, and displaying real-time RAM/VRAM comparison telemetry. Build a WebGL / RViz2 plugin displaying live 2.5D height-colored mesh and semantic overlays, with side-by-side memory metric telemetry ($M_{\text{adaptive}}$ vs $M_{\text{uniform}}$). [PS, INFERENCE]
REQ-4D "Performance Metrics: Evidence of low latency (high FPS) and high accuracy in object classification across varying distances." Quantitative evaluation proving inference speed $\ge 20\text{ FPS}$ ($<50\text{ ms}$ processing time per frame) and high Mean Intersection over Union ($\text{mIoU} \ge 65%$). Benchmark system latency on NVIDIA Jetson / RTX GPU; collect mIoU metrics categorized by range ($0\text{--}10\text{ m}$, $10\text{--}30\text{ m}$, $30\text{--}100\text{ m}$). [PS, ASSUMPTION]

3. Stakeholders & User Needs

+-----------------------------------------------------------------------------------+
|                                DRDO / iDEX STAKEHOLDERS                           |
+------------------------------------+----------------------------------------------+
| Tactical UGV / Autonomous Vehicle  | Commands sub-second path updates; requires   |
| Motion Planner (Nav2 / Autoware)   | zero-aliasing 2.5D height profiles.          |
+------------------------------------+----------------------------------------------+
| Defense Operations / Remote        | Monitors live vehicle telemetry & multi-layer |
| Operator (Tele-operation Console) | grid visualization under minimal bandwidth.  |
+------------------------------------+----------------------------------------------+
| Embedded Perception Engineer       | Demands peak FPS, bounded VRAM consumption,   |
| (Perception & AI Lead)             | and seamless C++/ROS 2 node integration.     |
+------------------------------------+----------------------------------------------+
Stakeholder Goal Current Pain System Need
Autonomous UGV Motion Planner [INFERENCE] Rapidly compute local paths and obstacle-avoidance trajectories in unstructured or off-road conditions. 3D point cloud processing is computationally prohibitive ($>100\text{ ms}$ latency); 2D flat occupancy grids miss overhanging branches, low curbs, and negative terrain. Fast 2.5D map publishing high-resolution elevation ($Z_{\max}, Z_{\min}$) and traversability scores at $>20\text{ Hz}$ in the immediate collision zone ($0\text{--}10\text{ m}$). [INFERENCE]
Remote Defense Tele-operator [INFERENCE] Maintain real-time situational awareness over tactical communications (low-bandwidth radio links). Raw 3D point cloud streaming requires $>50\text{ Mbps}$ bandwidth, causing frame drops and visual lag. Compressed 2.5D variable-resolution map streaming ($\le 2\text{ Mbps}$) with color-coded semantic overlays for terrain and static/moving threats. [INFERENCE]
Embedded System Developer / AI Architect [INFERENCE] Deploy deep perception pipelines on SWaP-constrained (Size, Weight, and Power) edge compute units (e.g., NVIDIA Jetson Orin AGX). Large dense 3D CNNs exhaust VRAM and trigger thermal throttling; uniform $5\text{ cm}$ grids across $100\text{ m}$ radius require $>1.6\times 10^7$ cells ($>500\text{ MB}$ RAM per frame). Sparse neural inference engine combined with memory-bounded concentric ring buffers, achieving $>20\text{ FPS}$ with $<50\text{ MB}$ dynamic memory usage. [INFERENCE]
DRDO Technical Evaluation Panel [PS, INFERENCE] Verify system performance, accuracy, memory reduction, and real-time execution capabilities. Lack of objective memory telemetry or clear distance-decay accuracy benchmarking in typical submissions. Integrated live dashboard displaying side-by-side memory benchmarking ($M_{\text{uniform}}$ vs $M_{\text{adaptive}}$), per-ring latency, and distance-stratified mIoU metrics. [PS, INFERENCE]

4. Requirements Traceability

The table below maps every architectural module and software component directly back to explicit DRDO problem statement specifications [PS].

Proposed Feature / Module Target Functionality Justifying Requirement ID Source Text Excerpt
Sparse 3D UNet (SpConv/TorchSparse Engine) Performs 3D point cloud semantic segmentation into terrain, static, and dynamic classes. REQ-4A, REQ-1, REQ-2 "A network (e.g. PointNet++ or a Sparse Convolutional Neural Network) capable of semantic segmentation of point clouds into terrain, static obstacles, and moving objects." [PS]
Concentric Multi-Ring 2.5D Grid Discretizer Discretizes space into $5\text{ cm}$ ($0\text{--}10\text{ m}$), $15\text{ cm}$ ($10\text{--}30\text{ m}$), and $50\text{ cm}$ ($30\text{--}100\text{ m}$) cell zones. REQ-3, REQ-4B "Implement a non-uniform grid where the cell size increases as the distance from the sensor increases... 5cm cells within 10m radius and 50cm cells up to 100m radius." [PS]
Bilinear Dynamic Alignment & Interpolation Module Prevents spatial aliasing and projection gaps when transforming 3D point coordinates into variable-resolution cells. REQ-3 "...without causing alignment errors or data loss during the projection from 3D to 2.5D." [PS]
Multi-Layer Cell Aggregator ($Z_{\max}, Z_{\min}, \text{Class}$) Converts segmented 3D points in each cell to elevation min/max/mean and semantic distribution vectors. REQ-1, REQ-2, REQ-4B "transforms raw Lidar point clouds into a variable resolution 2.5D grid (an elevation map with semantic layers)." [PS]
Side-by-Side Memory Telemetry Dashboard Computes and displays live RAM usage comparison between uniform grid vs adaptive grid. REQ-4C "demonstrating a significant reduction in memory usage compared to a uniform high-resolution 3D map." [PS]
ROS 2 C++ Grid Engine Node Publishes /grid_map/variable_elevation messages at $\ge 20\text{ FPS}$ for navigation motion planners. REQ-4D "Evidence of low latency (high FPS) and high accuracy in object classification across varying distances." [PS]

5. Constraints & Environment Realities

Defense UGVs operate in extreme operational environments [KNOWN]. Architectural design choices must reflect real field constraints rather than assuming idealized laboratory or cloud conditions [INFERENCE].

+-----------------------------------------------------------------------------------+
|                              FIELD ENVIRONMENT REALITIES                          |
+-----------------------+-----------------------+-----------------------------------+
| COMPUTATIONAL BOUND   | CONNECTIVITY AIR-GAP  | RUGGED MOBILITY                   |
| Embedded GPU (Orin)   | Zero Cloud / Internet | Sensor jitter & pitch/roll shocks |
| SWaP Bounded Thermal  | Pure Local Processing | High dust, rain, fog attenuation  |
+-----------------------+-----------------------+-----------------------------------+
  1. Hardware & Compute Constraints (SWaP): Tactical ground vehicles run on power-constrained edge platforms such as the NVIDIA Jetson AGX Orin (64GB) or Orin Nano (8GB/16GB) [KNOWN]. Cloud API offloading is impossible due to air-gapped security protocols and electronic warfare (EW) jamming risks [INFERENCE]. All neural inference and grid mapping must execute 100% locally on onboard GPU hardware [INFERENCE].
  2. Network & Connectivity Realities: Tactical environments lack cellular or broadband connectivity [KNOWN]. Inter-node communication between perception modules and motion planners must occur via high-speed intra-process zero-copy IPC (Shared Memory ROS 2 / CycloneDDS) [INFERENCE].
  3. LiDAR Sensor Characteristics & Dust/Rain Noise: Off-road terrain causes vehicle pitch/roll motion and sensor vibration [KNOWN]. Outdoor environments introduce backscatter noise from dust particles, rain, and ground spray [KNOWN]. The grid engine must integrate point cloud motion undistortion using IMU high-rate ego-motion data [INFERENCE].
  4. Distance Decay & Beam Divergence: Mechanical and solid-state LiDAR sensors (e.g., Velodyne HDL-64E, Ouster OS1-128) suffer from beam sparsity at long range ($100\text{ m}$) [KNOWN]. Angular resolution creates sparse point distributions ($<2\text{ points/m}^2$ at $100\text{ m}$ vs $>500\text{ points/m}^2$ at $5\text{ m}$) [KNOWN]. This physical phenomenon directly aligns with our variable-resolution strategy: spending $5\text{ cm}$ resolution at $100\text{ m}$ is physically wasteful due to point beam sparsity [INFERENCE].

6. Research Questions

To ensure rigorous system engineering, the student team must investigate the following six core technical questions:

  1. Alignment Error Mitigation: How do we continuously translate a multi-resolution concentric grid centered on a moving vehicle without introducing spatial aliasing or cell alignment jitter at ring boundaries ($10\text{ m}$ and $30\text{ m}$ transitions)? [INFERENCE]
  2. Model Optimization & Quantization: Can a 3D Sparse Convolutional Network (SpConv / TorchSparse) achieve $>25\text{ FPS}$ on an NVIDIA Jetson AGX Orin using FP16 / INT8 TensorRT quantization without dropping mIoU below 65% on small dynamic obstacles (e.g., pedestrians at $25\text{ m}$)? [RESEARCHED, INFERENCE]
  3. Data Loss During 3D to 2.5D Projection: When multiple 3D points with distinct elevation values land within a single $2.5\text{D}$ cell, what elevation metrics ($Z_{\max}, Z_{\min}, \Delta Z, \text{variance}$) must be preserved to guarantee that overhanging obstacles (bridges/branches) or negative obstacles (potholes/ditches) are not erased? [PS, INFERENCE]
  4. Dynamic vs Static Temporal Consistency: How can the pipeline handle temporarily stopped dynamic objects (e.g., a car waiting at an intersection) to prevent them from being permanently baked into the static terrain layer? [INFERENCE]
  5. Memory Footprint Scaling: What is the exact mathematical ratio of cell count and memory consumption between a uniform $5\text{ cm}$ grid over a $200\text{ m} \times 200\text{ m}$ bounding box ($1.6\times 10^7$ cells) versus a 3-tier concentric variable-resolution grid ($~4.8\times 10^5$ cells)? [INFERENCE]
  6. Robustness Under Sensor Drift: How does high-frequency IMU integration prevent local map blurring when the vehicle undergoes aggressive braking or angular rotation? [INFERENCE]

7. Data Requirements & Sources

Training and evaluating a deep learning 3D semantic segmentation model for variable-resolution 2.5D mapping requires point cloud datasets annotated with point-wise semantic labels [PS, RESEARCHED].

Data Taxonomy & Requirements Table

Data Type Purpose Ideal Real-World Source Hackathon Substitute Access Method Availability Privacy / Security Sensitivity Confidence Tag
3D LiDAR Point Clouds with Point-Wise Semantic Labels Train and evaluate 3D semantic segmentation deep learning network (Terrain, Static, Dynamic). Real DRDO UGV sensor sweeps (Velodyne HDL-64E / Ouster OS1-128). [INFERENCE] SemanticKITTI (22 sequences, 43,000+ sweeps) [1.3, 1.4] & nuScenes-lidarseg (1000 scenes, 40k keyframes) [2.1, 2.2]. Public HTTP download via dataset portals [1.3, 2.2]. Open Academic License (Non-commercial) [1.3, 2.2]. Low (Publicly scrubbed automotive data) [KNOWN]. [RESEARCHED]
High-Rate Vehicle Ego-Motion / IMU & Odometry Perform motion undistortion and dynamic map transform updates. Tactical Grade Fiber Optic Gyro (FOG) IMU + Wheel Encoders [INFERENCE]. SemanticKITTI Pose files (poses.txt) / ROS 2 Odometry messages in Bags. [1.8] Downloaded with SemanticKITTI odometry benchmark [1.8]. Fully Available [1.8]. None [KNOWN]. [RESEARCHED]
Synthetic Off-Road & Tactical Terrain Point Clouds Validate performance on military off-road conditions (ditches, ruts, foliage). Custom CARLA / Gazebo Off-Road Simulator Sweeps. [INFERENCE] Gazebo Fortress / Ignition Simulation with Velodyne ROS Plugin on custom off-road heightmap. Self-generated via ROS 2 Gazebo simulation environment [INFERENCE]. Self-generated during build window [INFERENCE]. None [KNOWN]. [ASSUMPTION]

Categorized Data Summary

  • A. Data Explicitly Mentioned in PS: Raw 3D LiDAR point clouds, 2.5D variable-resolution grid elevation layers, semantic class tags (Terrain, Static Obstacle, Moving Object) [PS].
  • B. Data Required by Inference: Vehicle pose matrix $T_{\text{world}}^{\text{sensor}} \in SE(3)$, IMU angular velocity $\vec{\omega}$ and acceleration $\vec{a}$ for motion undistortion, per-cell elevation statistics ($Z_{\max}, Z_{\min}, Z_{\text{mean}}, \sigma_z^2, \vec{n}$) [INFERENCE].
  • C. Data That Must Be Collected: Real-time evaluation telemetry logs (FPS, CPU/GPU utilisation, VRAM allocated in MB, mIoU per ring distance) [INFERENCE].
  • D. Data That Can Be Synthetically Generated: CARLA / Gazebo ROS 2 simulated bag files containing synthesized 64-beam LiDAR scans driving through dynamic off-road environments [INFERENCE].
  • E. Data Needing Validation: Real-time raw sensor feeds from military-grade solid-state LiDAR sensors (e.g., Ouster OS2-128 or Hesai Pandar128) operating under heavy atmospheric dust [NEEDS VALIDATION].

8. Existing Solutions & Gap Analysis

To substantiate the novelty of our approach, we analyze four major open-source and state-of-the-art robotic mapping systems [RESEARCHED].

+-----------------------------------------------------------------------------------+
|                            EXISTING MAPPING FRAMEWORKS                            |
+-------------------+--------------------+--------------------+---------------------+
| ANYbotics         | ETHZ ASL           | Autoware / Nav2    | OctoMap / Wavemap   |
| elevation_mapping | grid_map           | Costmap2D          | Volumetric Octrees  |
| (Uniform Grid)    | (Uniform 2.5D)     | (Flat 2D Grid)     | (3D Voxel Trees)    |
+-------------------+--------------------+--------------------+---------------------+

Comprehensive Systems Analysis

System Name Functional Overview Core Strengths Key Weaknesses Relevance to SIH26053 Identified Gap & Strategic Advantage Source & Confidence
ETHZ ANYbotics elevation_mapping / elevation_mapping_cupy GPU-accelerated robot-centric 2.5D elevation map using CuPy and ROS 2 [4.1, 4.7]. Fast height map updating ($>30\text{ Hz}$), handles localization noise and sensor drift [4.1, 4.7]. Restricted to fixed uniform grid cell sizes across the entire bounding box; lacks deep learning dynamic semantic segmentation [4.1, 4.7]. Direct foundation for elevation mapping concepts [4.1]. GAP: Cannot vary resolution dynamically as distance increases. Our engine implements a multi-resolution ring buffer structure with deep learning semantic layers [INFERENCE]. [4.1, 4.7] [RESEARCHED]
ETHZ ASL grid_map C++ library with ROS 2 interface managing multi-layer 2.5D circular buffer grids [4.2, 4.8]. Multi-layer support (elevation, surface normal, traversability), non-destructive circular buffer re-positioning [4.2, 4.8]. Single uniform resolution per map instance; high memory cost when extended to $100\text{ m}$ range [4.2, 4.8]. Standard interface for ROS 2 robotic costmaps [4.2]. GAP: Storing $100\text{ m}$ range at $5\text{ cm}$ cell size in grid_map requires $>1.6\times 10^7$ cells ($>500\text{ MB}$). Our nested concentric multi-grid wrapper reduces cells to $<5\times 10^5$ ($<30\text{ MB}$) [INFERENCE]. [4.2, 4.8] [RESEARCHED]
Nav2 costmap_2d / Autoware Obstacle Map Standard ROS 2 navigation costmap projecting LiDAR points onto a 2D occupancy grid [4.10]. Highly optimized, direct interface to Nav2 path planners (DWB, TEB, MPPI) [4.10]. Completely flattens 3D space into 2D; loses all height information ($Z_{\max}, Z_{\min}$), failing to detect overhanging obstacles or curbs [PS, 4.10]. Baseline 2D navigation reference [4.10]. GAP: Strips height profile completely [PS]. Our solution delivers full 2.5D elevation structures ($Z_{\max}, Z_{\min}, \text{roughness}$) in variable resolution format [INFERENCE]. [PS, 4.10] [RESEARCHED]
OctoMap / Wavemap (ETHZ) Hierarchical 3D octree mapping supporting variable voxel sizes via tree depth [4.4, 4.9]. True 3D representation; memory efficient for large sparse volumetric scenes [4.4, 4.9]. High computational overhead for ray-casting insert ($<10\text{ FPS}$); slow conversion into 2.5D terrain surface for real-time UGV motion planning [4.4, 4.9]. Reference for multi-resolution data structures [4.9]. GAP: Ray-casting 3D octrees is compute-intensive for high-speed navigation. Our Concentric 2.5D Ring Buffer projects points directly into planar rings without 3D tree traversal overhead [INFERENCE]. [4.4, 4.9] [RESEARCHED]

9. Candidate Solution Approaches

We generate and evaluate three distinct architectural approaches to solve the DRDO challenge [PS].

+-----------------------------------------------------------------------------------+
|                           THREE CANDIDATE ARCHITECTURES                           |
+-----------------------+----------------------------------+------------------------+
| APPROACH 1            | APPROACH 2 (RECOMMENDED)         | APPROACH 3             |
| PointNet++ + Polar    | Sparse 3D CNN (SpConv/TorchSparse) | Range-Image 2D UNet +  |
| Radial Ring Grid      | + Concentric Multi-Ring Buffer   | Quadtree Downsampling  |
+-----------------------+----------------------------------+------------------------+

Comparative Evaluation Matrix

Architectural Criteria Approach 1: PointNet++ + Polar Radial Ring Grid Approach 2: Sparse 3D CNN + Concentric Multi-Ring Buffer (RECOMMENDED) Approach 3: Range Image 2D UNet + Quadtree Downsampling
Core Mechanism Raw point sampling with PointNet++ set abstraction layers; polar grid projection $(\rho, \theta, z)$. Submanifold Sparse 3D Convolution (SpConv/TorchSparse v2) on voxelized points; projection into 3-tier concentric square ring buffers. Spherical range image projection $(u,v) = f(x,y,z)$; 2D UNet segmentation (SalsaNext); quadtree rasterization.
Semantic Segmentation mIoU Moderate (~58–62% mIoU) on large scenes due to point downsampling limits [RESEARCHED]. High (~68–74% mIoU) across fine structures and dynamic obstacles [3.2, 3.5]. High (~65–70% mIoU), but degrades at severe grazing angles [RESEARCHED].
Processing Latency (AGX Orin) Slow (~80–120 ms per frame) due to $k$-NN neighbor search overhead [RESEARCHED]. Fast (<25 ms per frame) via FP16 TensorRT sparse GPU kernels [3.2, 3.4]. Very Fast (<15 ms per frame), but 2D projection induces spatial distortion [RESEARCHED].
Data Structure Complexity High: Non-uniform polar wedges ($\Delta \rho, \Delta \theta$) cause varying physical cell area ($A = \rho \Delta \rho \Delta \theta$). Medium: Concentric square ring buffers with fixed cell sizes per ring ($5\text{ cm}, 15\text{ cm}, 50\text{ cm}$). High: Quadtree pointer traversal induces dynamic memory allocation bottlenecks.
Spatial Aliasing & Boundary Errors Significant distortion at distance due to expanding wedge widths ($\Delta s = \rho \Delta \theta$). Minimal: Anchor-snapped square grids prevent spatial aliasing during translation [INFERENCE]. High edge artifacting along quadtree multi-resolution cell boundaries.
Memory Footprint (100m Range) ~35 MB (Polar Grid) ~24 MB (3-Tier Ring Buffer) ~40 MB (Dynamic Quadtree)
Hackathon Feasibility Hard: Complex $k$-NN compute CUDA kernels difficult to write in build window. High: Pre-built SpConv/TorchSparse v2 libraries integrated with ROS 2 C++ node [3.5, 4.8]. Medium: Range image spherical unrolling requires precise calibration setup.
Production Defense Readiness Low: PointNet++ fails to scale to 128-beam high-density LiDARs. High: Standard architecture for military and commercial autonomous driving perception [3.2, 3.5]. Moderate: Susceptible to vertical bloom and range image occlusion artifacts.

10. Recommended Approach & Why

Selection: Approach 2 — Sparse 3D CNN (SpConv / TorchSparse) + Concentric Multi-Ring Buffer Engine

We select Approach 2 as the winning architecture for the DRDO challenge [PS, ASSUMPTION].

+-----------------------------------------------------------------------------------+
|                        WHY APPROACH 2 WINS THE EVALUATION                         |
+-----------------------------------------------------------------------------------+
|  1. Sparse 3D Convolutions exploit point cloud sparsity (95%+ empty space),       |
|     delivering <25ms latency on edge GPUs (NVIDIA Jetson AGX Orin).              |
|  2. Concentric Square Ring Buffers eliminate polar wedge area distortion          |
|     (A = dx * dy is constant within each ring zone).                              |
|  3. Multi-layer grid maps integrate directly with ROS 2 Nav2 and RViz2.           |
+-----------------------------------------------------------------------------------+

Strategic Reasons for Selection

  1. Computational Efficiency via Sparsity: Raw 3D point cloud space is $>95%$ empty space [3.6]. Standard dense 3D convolutions waste trillions of FLOPs computing over empty air [3.6]. Submanifold Sparse Convolutions (SpConv v2 / TorchSparse v2) only execute matrix multiplications on non-empty voxels, achieving sub-25 ms inference per scan on edge GPUs [3.2, 3.4].
  2. Elimination of Polar Wedge Area Distortion: Polar grids $(\rho, \theta)$ suffer from the "expanding cell area" problem where cell physical width grows linearly with distance ($\Delta s = \rho \cdot \Delta \theta$). At $\rho = 100\text{ m}$, a single polar wedge spans several meters wide, destroying spatial fidelity [INFERENCE]. Our Concentric Multi-Ring Buffer Engine maintains fixed square grid cells ($5\text{ cm}$ in Zone 1, $15\text{ cm}$ in Zone 2, $50\text{ cm}$ in Zone 3), ensuring consistent spatial geometry across all directions [INFERENCE].
  3. Zero Spatial Aliasing via Snapped Shift Buffers: Moving the vehicle causes cell position jitter if grid anchors shift continuously [INFERENCE]. By snapping ring coordinate origins to integer multiples of each ring's cell size ($\Delta x_1 = k \cdot 0.05\text{ m}$, $\Delta x_3 = k \cdot 0.50\text{ m}$), we enable non-destructive circular buffer shifting without data copying or spatial aliasing [4.2, INFERENCE].

Justification for Rejecting Alternatives

  • Why PointNet++ (Approach 1) was rejected: PointNet++ relies on Furthest Point Sampling (FPS) and $k$-Nearest Neighbors ($k$-NN) search [RESEARCHED]. On large outdoor scans ($>100,000$ points), $k$-NN search creates severe GPU memory bandwidth bottlenecks, dropping frame rates below $10\text{ FPS}$ on embedded Jetson platforms [RESEARCHED, INFERENCE].
  • Why Range Image UNet (Approach 2D) was rejected: Projecting 3D point clouds onto a 2D range image spherical canvas $(u,v)$ introduces severe spatial compression near the zenith and horizon, leading to boundary bleeding where distant dynamic vehicles blend into background ground terrain [RESEARCHED, INFERENCE].

11. Technical Architecture

Layered System Architecture Diagram

+-----------------------------------------------------------------------------------+
|                             SYSTEM ARCHITECTURE LAYERS                            |
+-----------------------------------------------------------------------------------+
| LAYER 1: SENSOR INGESTION & PREPROCESSING                                         |
| Raw LiDAR Point Cloud (ROS 2 / PointCloud2) + FOG IMU High-Rate Ego-Motion        |
| [Motion Undistortion Kernel] -> Synchronized & Undistorted Point Sweeps           |
+-----------------------------------------------------------------------------------+
                                         |
                                         v
+-----------------------------------------------------------------------------------+
| LAYER 2: DEEP LEARNING SPARSE SEGMENTATION PIPELINE (GPU Engine)                 |
| Voxelization (5cm Voxel Grid) -> Sparse 3D UNet (SpConv v2 / TensorRT FP16)       |
| Output: Point-wise Semantic Class Tags (Terrain, Static Wall/Pole, Dynamic Agent) |
+-----------------------------------------------------------------------------------+
                                         |
                                         v
+-----------------------------------------------------------------------------------+
| LAYER 3: ADAPTIVE VARIABLE-RESOLUTION CONCENTRIC GRID ENGINE (C++ Node)          |
| Spatial Zone Discretization:                                                      |
|   - Ring 1 (0m to 10m Radius):   High-Res Grid (Cell Size = 0.05m / 5cm)         |
|   - Ring 2 (10m to 30m Radius):  Mid-Res Grid  (Cell Size = 0.15m / 15cm)        |
|   - Ring 3 (30m to 100m Radius): Coarse Grid   (Cell Size = 0.50m / 50cm)        |
| Projection & Layer Aggregation: Z_max, Z_min, Z_mean, Roughness, Semantic Vector  |
+-----------------------------------------------------------------------------------+
                                         |
                                         v
+-----------------------------------------------------------------------------------+
| LAYER 4: ROS 2 MIDDLEWARE & INTER-PROCESS COMMUNICATION                           |
| ROS 2 CycloneDDS / Shared Memory Transport                                        |
| Topic: /grid_map/variable_elevation (Multi-Layer GridMap Msg)                   |
+-----------------------------------------------------------------------------------+
                                         |
                                         +----------------------------------+
                                         |                                  |
                                         v                                  v
+--------------------------------------------------+ +------------------------------+
| LAYER 5A: NAVIGATION & MOTION PLANNING           | | LAYER 5B: REAL-TIME DASHBOARD|
| ROS 2 Nav2 MPPI Planner / Local Costmap Plugin   | | WebGL / RViz2 Visualizer    |
| Receives 2.5D Elevation & Traversability Maps    | | Side-by-Side Memory Telemetry|
+--------------------------------------------------+ +------------------------------+

Step-by-Step Data-Flow Narrative

  1. Ingestion & Motion Undistortion: The raw LiDAR driver publishes sensor_msgs/msg/PointCloud2 at $10\text{--}20\text{ Hz}$ [INFERENCE]. A C++ motion undistortion kernel fetches high-frequency ($200\text{ Hz}$) IMU angular velocities $\vec{\omega}$ and linear accelerations $\vec{a}$, applying a per-point spherical linear interpolation (Slerp) to compensate for UGV motion distortion during beam scanning [4.9, INFERENCE].
  2. Voxelization & Sparse Neural Inference: The undistorted point cloud is voxelized into a sparse coordinate tensor with a spatial resolution of $0.05\text{ m}$ [3.6, INFERENCE]. The sparse tensor is processed by a TensorRT-optimized Sparse 3D UNet (SpConv v2) [3.2, 3.10]. The deep neural network assigns a semantic category probability vector to every non-empty voxel, identifying:
    • Class 0: Drivable Ground Surface [PS]
    • Class 1: Non-Drivable Ground / Rough Terrain [PS]
    • Class 2: Static Obstacles (Walls, Buildings, Poles) [PS]
    • Class 3: Dynamic Pedestrians / VRUs [PS]
    • Class 4: Dynamic Vehicles [PS]
  3. Adaptive Concentric Grid Projection: Classified 3D points $(x, y, z, c)$ are passed to the C++ Concentric Multi-Ring Engine [INFERENCE]. The engine computes the radial planar distance $r = \sqrt{x^2 + y^2}$ for each point [INFERENCE]:
    • If $r \le 10\text{ m}$, project into Ring 1 Grid (Resolution: $\Delta x = 0.05\text{ m}$, Grid Dimensions: $400 \times 400$ cells) [PS, ASSUMPTION].
    • If $10\text{ m} < r \le 30\text{ m}$, project into Ring 2 Grid (Resolution: $\Delta x = 0.15\text{ m}$, Grid Dimensions: $266 \times 266$ cells) [PS, ASSUMPTION].
    • If $30\text{ m} < r \le 100\text{ m}$, project into Ring 3 Grid (Resolution: $\Delta x = 0.50\text{ m}$, Grid Dimensions: $280 \times 280$ cells) [PS, ASSUMPTION].
  4. Layer Aggregation: Within each target cell $(i, j)$ of the corresponding ring, the engine updates multi-layer attributes:
    • $Z_{\max} = \max(z_1, z_2, \dots, z_k)$
    • $Z_{\min} = \min(z_1, z_2, \dots, z_k)$
    • $Z_{\text{mean}} = \frac{1}{k} \sum z_k$
    • $\text{Roughness } \sigma_z^2 = \frac{1}{k} \sum (z_k - Z_{\text{mean}})^2$
    • $\text{Semantic Dominance } C^* = \arg\max_c (\sum \mathbf{1}(c_k = c))$
  5. Publishing & Telemetry Streaming: The accumulated multi-ring data structure is formatted into a ROS 2 /grid_map/variable_elevation topic [4.8, INFERENCE]. Concurrently, the engine logs dynamic memory usage ($M_{\text{adaptive}}$) and compares it against a hypothetical uniform $5\text{ cm}$ grid over a $200\text{ m} \times 200\text{ m}$ area ($M_{\text{uniform}}$), transmitting telemetry to the visualization dashboard [PS, INFERENCE].

12. Technology Stack

+-----------------------------------------------------------------------------------+
|                              RECOMMENDED TECH STACK                               |
+-----------------------------------------------------------------------------------+
| LANGUAGE & CORE FRAMEWORK  : C++17 (Grid Engine) / Python 3.10 (DL Training)       |
| ROS 2 MIDDLEWARE           : ROS 2 Humble / Jazzy (CycloneDDS / Shared Memory IPC) |
| DEEP LEARNING INFERENCE    : PyTorch -> SpConv v2 / TorchSparse++ -> TensorRT FP16  |
| GRID DATA STRUCTURE        : ETHZ grid_map C++ Library / Eigen3 Vector Matrix       |
| REAL-TIME VISUALIZATION    : RViz2 Custom Plugin + Three.js / WebGL React Dashboard |
| EMBEDDED HARDARE TARGET    : NVIDIA Jetson AGX Orin 64GB (CUDA 12.2 / TensorRT 8.6) |
+-----------------------------------------------------------------------------------+

Justified Technology Choices Table

Layer Selected Technology Strategic Justification Alternative Considered Rejection Justification
LiDAR Processing Engine C++17 with OpenMP / Eigen3 Sub-millisecond mathematical cell aggregation and zero-copy memory execution [4.8]. Python / NumPy Python Global Interpreter Lock (GIL) and memory allocation overheads introduce $>30\text{ ms}$ latency per frame [INFERENCE].
Deep Learning Inference TensorRT FP16 via SpConv v2 / TorchSparse++ Ultra-fast sparse CUDA kernels optimized for NVIDIA Tensor Cores [3.2, 3.4, 3.10]. Native PyTorch Python Execution PyTorch eager execution incurs high CPU-GPU synchronization overhead ($>60\text{ ms}$) [INFERENCE].
Robotic Middleware ROS 2 Humble / Jazzy (CycloneDDS) Industry standard for defense UGVs; built-in zero-copy shared memory transport [4.8, 4.10]. ROS 1 Noetic / Custom Sockets ROS 1 lacks native real-time QoS guarantees and multi-threading capabilities [KNOWN].
Grid Data Representation ETHZ grid_map C++ Extensions Circular buffer support enables $O(1)$ grid shift during vehicle movement without data copying [4.2, 4.8]. Standard 2D std::vector arrays Hand-written vector re-allocation during vehicle translation causes frame stuttering [INFERENCE].
GUI & Dashboard Frontend WebGL / Three.js + React Dashboard High-performance 60 FPS 3D rendering in browser; decoupling display from ROS 2 core [INFERENCE]. Pure RViz2 RViz2 lacks customizable side-by-side dynamic memory telemetry panels [INFERENCE].

13. AI/ML Justification

+-----------------------------------------------------------------------------------+
|                           AI vs NON-AI DOMAIN BOUNDARIES                          |
+-----------------------------------------------------------------------------------+
| USE DEEP LEARNING FOR:                            DO NOT USE AI FOR:              |
| - Complex 3D Geometry & Semantic Context          - Deterministic Grid Projection |
| - Distinguishing Static vs Dynamic Objects        - Height Aggregation (Zmax/Zmin)|
| - Classifying Subtle Road Boundaries & Foliage    - Spatial Zone Radius Truncation|
+-----------------------------------------------------------------------------------+

Deep Learning Model Breakdown

Requirement Criteria System Parameter Specification
1. Purpose Classify raw, unorganized 3D LiDAR point clouds into 5 semantic categories: Drivable Surface, Rough Terrain, Static Obstacle, Dynamic Pedestrian, Dynamic Vehicle [PS].
2. Model Type Sparse 3D Convolutional Neural Network (Submanifold Sparse UNet Architecture using SpConv v2 / TorchSparse++) [3.2, 3.10].
3. Model Input Synchronized 3D LiDAR point tensor $\mathbf{P} \in \mathbb{R}^{N \times 4}$ where each row contains $(x, y, z, I)$ [PS, INFERENCE].
4. Model Output Point-wise logit matrix $\mathbf{Y} \in \mathbb{R}^{N \times 5}$ representing class probabilities for each 3D point [PS, INFERENCE].
5. Why Simpler Rules Fail Rule-based heuristics (e.g., ground plane RANSAC or height thresholding) fail in off-road environments with vegetation, steep slopes, overhanging structures, or moving vehicles [1.1, 1.12]. Rule-based systems cannot infer object semantics or distinguish between a parked car (static) and a moving car (dynamic) based on geometry alone [1.14].
6. Training & Fine-Tuning Pre-trained on SemanticKITTI / nuScenes-lidarseg; fine-tuned on custom off-road Gazebo simulated sweeps [1.3, 2.1].
7. Evaluation Metrics Mean Intersection over Union ($\text{mIoU}$), Class-wise IoU, and Per-Frame Inference Latency (ms) [PS, 2.1].
8. Failure Modes & Oversight Failure Mode: Misclassifying a tall bush as a solid static obstacle, or under-segmenting a thin wire fence [1.1]. Human Oversight: High-uncertainty cells (entropy $H > 0.8$) are flagged with a "Yellow Caution" status in the local costmap, forcing UGV path planners to reduce velocity [INFERENCE].

Explicit Non-AI Boundary

  • Where AI MUST NOT Be Used: AI must NOT be used for projecting classified points into the 2.5D grid, computing ring cell coordinates, or calculating elevation $Z_{\max} / Z_{\min}$ statistics [INFERENCE]. These operations are purely deterministic coordinate transformations ($x,y \to \text{cell } i,j$). Using neural network regression for spatial grid projection introduces unpredictable spatial distortion and violates deterministic defense safety guarantees [INFERENCE].

14. Data Architecture & Offline/Low-Network Design

Concentric Ring Buffer Memory Layout

+-----------------------------------------------------------------------------------+
|                    CONCENTRIC RING BUFFER SPATIAL DISCRETIZATION                  |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|      +---------------------------------------------------------------------+      |
|      | RING 3 (30m to 100m Radius) -- Cell Size: 0.50m (50cm)               |      |
|      | Dimensions: 280 x 280 cells (78.4k cells)                           |      |
|      |                                                                     |      |
|      |        +---------------------------------------------------+        |      |
|      |        | RING 2 (10m to 30m Radius) -- Cell Size: 0.15m    |        |      |
|      |        | Dimensions: 266 x 266 cells (70.7k cells)         |        |      |
|      |        |                                                   |        |      |
|      |        |        +---------------------------------+        |        |      |
|      |        |        | RING 1 (0m to 10m Radius)       |        |        |      |
|      |        |        | Cell Size: 0.05m (5cm)          |        |        |      |
|      |        |        | Dimensions: 400 x 400 cells     |        |        |      |
|      |        |        | (160k cells)                    |        |        |      |
|      |        |        |             (EGO UGV)           |        |        |      |
|      |        |        +---------------------------------+        |        |      |
|      |        |                                                   |        |      |
|      |        +---------------------------------------------------+        |      |
|      |                                                                     |      |
|      +---------------------------------------------------------------------+      |
|                                                                                   |
+-----------------------------------------------------------------------------------+

Mathematical Memory Proof & Reduction Telemetry

To satisfy REQ-4C ("demonstrating a significant reduction in memory usage compared to a uniform high-resolution 3D map"), we formulate the exact mathematical memory footprint comparison [PS, INFERENCE]:

  1. Uniform High-Resolution Grid ($5\text{ cm}$ cell size across $100\text{ m}$ radius):
    • Bounding Box: $200\text{ m} \times 200\text{ m}$.
    • Grid Cells: $\left(\frac{200}{0.05}\right) \times \left(\frac{200}{0.05}\right) = 4,000 \times 4,000 = 16,000,000\text{ cells}$.
    • Memory per cell (32 bytes: $Z_{\max}, Z_{\min}, Z_{\text{mean}}, \sigma_z^2, \text{Class}, \text{Variance}$):
    • $M_{\text{uniform}} = 16,000,000 \times 32\text{ bytes} = 512,000,000\text{ bytes} \approx \mathbf{512\text{ MB}}$.
  2. Adaptive Variable-Resolution Concentric Grid:
    • Ring 1 ($0\text{--}10\text{ m}$, $5\text{ cm}$ cell): $20\text{ m} \times 20\text{ m} \to 400 \times 400 = 160,000\text{ cells}$.
    • Ring 2 ($10\text{--}30\text{ m}$, $15\text{ cm}$ cell): $(60\text{ m} \times 60\text{ m}) - (20\text{ m} \times 20\text{ m}) \to (400 \times 400) - (133 \times 133) = 160,000 - 17,689 = 142,311\text{ cells}$.
    • Ring 3 ($30\text{--}100\text{ m}$, $50\text{ cm}$ cell): $(200\text{ m} \times 200\text{ m}) - (60\text{ m} \times 60\text{ m}) \to (400 \times 400) - (120 \times 120) = 160,000 - 14,400 = 145,600\text{ cells}$.
    • Total Adaptive Cells: $160,000 + 142,311 + 145,600 = \mathbf{447,911\text{ cells}}$.
    • $M_{\text{adaptive}} = 447,911 \times 32\text{ bytes} \approx \mathbf{14.33\text{ MB}}$.
    • Net Memory Footprint Reduction: $\mathbf{97.2%}$ memory reduction ($14.33\text{ MB}$ vs $512\text{ MB}$) [INFERENCE].

Alignment & Spatial Aliasing Protection

When the vehicle translates by $(\Delta x, \Delta y)$, updating grid cell coordinates without spatial aliasing requires anchoring each ring to an integer grid snap function [INFERENCE]:

$$\text{Anchor}k = \text{floor}\left( \frac{\mathbf{P}{\text{UGV}}}{\text{CellSize}_k} \right) \times \text{CellSize}_k$$

This guarantees that as the vehicle moves, cells in Ring 1 ($5\text{ cm}$), Ring 2 ($15\text{ cm}$), and Ring 3 ($50\text{ cm}$) shift in discrete integer cell increments, eliminating cell interpolation artifacts during point cloud rasterization [INFERENCE].

15. Security, Privacy & Governance

+-----------------------------------------------------------------------------------+
|                         GOVERNANCE & DEFENSE COMPLIANCE                           |
+-----------------------------------------------------------------------------------+
| - AIR-GAPPED DEPLOYMENT : Zero external network dependencies / zero cloud calls.   |
| - AES-256 MEMORY ENCRYPTION : Local log encryption for defense operational logs.  |
| - TACTICAL FAIL-SAFE : Deterministic fallback costmap if AI inference stalls.    |
+-----------------------------------------------------------------------------------+
  1. Air-Gapped Operational Compliance: In alignment with DRDO defense operational requirements, the software stack operates 100% offline [PS, INFERENCE]. Zero telemetry, models, or raw sensor sweeps are transmitted over public networks [INFERENCE].
  2. LiDAR Point Cloud Data Ownership & Privacy: Autonomous UGV sensor logs captured during testing may contain restricted defense facility geography [INFERENCE]. Local disk logging uses AES-256 encrypted ROS 2 bag storage [INFERENCE].
  3. Safety Critical Fail-Safe Protocols: If the deep learning inference node experiences GPU driver failure or frame drop ($>100\text{ ms}$ timeout), the C++ Grid Engine defaults to a deterministic geometrical ground filter (RANSAC Ground Plane Fitting + Elevation Gap Thresholding) to ensure uninterrupted collision avoidance [INFERENCE].

16. MVP Scope (Hackathon Build)

To ensure high execution quality within the SIH hackathon timeline, the scope is divided into explicit build tiers [PS, ASSUMPTION].

+-----------------------------------------------------------------------------------+
|                                 HACKATHON MVP SCOPE                               |
+-----------------------------------------------------------------------------------+
| MUST BUILD (CORE)            | SHOULD BUILD (ENHANCED)     | OUT OF SCOOP / FUTURE|
| - ROS 2 SpConv UNet Node    | - WebGL React Dashboard     | - Custom ASIC Hardware|
| - 3-Tier Concentric Grid     | - Side-by-Side RAM Telemetry| - Multi-UGV Swarm Map|
| - SemanticKITTI Playback    | - Gazebo Off-Road Simulation| - Hardware FOG IMU    |
+-----------------------------------------------------------------------------------+

In Scope vs Out of Scope Breakdown

Tier Component / Feature Specification Implementation Focus
MUST BUILD (Core MVP) Sparse 3D UNet Model Trained on SemanticKITTI / nuScenes to segment point clouds into Terrain, Static, Dynamic classes [1.3, 2.1].
MUST BUILD (Core MVP) 3-Tier Concentric Grid Engine C++ ROS 2 node executing $5\text{ cm}$ ($0\text{--}10\text{ m}$), $15\text{ cm}$ ($10\text{--}30\text{ m}$), and $50\text{ cm}$ ($30\text{--}100\text{ m}$) projection [PS].
MUST BUILD (Core MVP) Live Telemetry Benchmarking Real-time logging displaying FPS, inference latency (ms), and side-by-side memory reduction metrics [PS].
SHOULD BUILD (Enhanced) WebGL / RViz2 Custom Panel Live interactive 3D color-coded rendering of elevation mesh and semantic class overlays [PS].
SHOULD BUILD (Enhanced) Gazebo Off-Road Simulation Bag Synthetic defense vehicle simulation running through dynamic obstacle courses [INFERENCE].
NICE TO HAVE TensorRT FP16 Acceleration Full INT8/FP16 quantization pipeline targeting NVIDIA Jetson edge execution [3.2].
DO NOT BUILD (Out of Scope) Real Military Hardware Integration Physical mounting on DRDO defense tactical vehicles (simulated via standard Rosbags) [INFERENCE].
DO NOT BUILD (Out of Scope) Multi-UGV Swarm Map Fusion Swarm map aggregation across multiple vehicles (out of scope for single-vehicle PS) [PS].

17. Live Demo Simulation Plan

To present a compelling, evidence-based demonstration for the SIH judging panel without requiring physical UGV hardware, the team will implement a live simulation pipeline [PS, ASSUMPTION].

+-----------------------------------------------------------------------------------+
|                              LIVE DEMO SIMULATION FLOW                            |
+-----------------------------------------------------------------------------------+
| [SemanticKITTI / Gazebo Rosbag] --(ROS 2 Topic)--> [SpConv Inference Node]        |
|                                                                |                  |
|                                                                v                  |
| [Side-by-Side Dashboard] <--(Telemetry/Grid)--- [Concentric Grid Engine C++]      |
|  ├─ Panel 1: Live 2.5D Color-Coded Map (Terrain/Static/Dynamic)                    |
|  ├─ Panel 2: Memory Footprint Counter (Adaptive: 14.3MB vs Uniform: 512MB)        |
|  └─ Panel 3: FPS & Distance-Stratified IoU Metrics Panel                          |
+-----------------------------------------------------------------------------------+

Demonstration Execution Sequence

  1. Dataset Playback & Undistortion: Replay pre-recorded SemanticKITTI (Sequence 00/08) and custom Gazebo off-road ROS 2 bag files at $1.0\times$ real-time speed, streaming raw 64-beam LiDAR point clouds [1.3, INFERENCE].
  2. Real-Time Inference Telemetry: Display live terminal and dashboard metrics demonstrating the SpConv 3D UNet executing at $>25\text{ FPS}$ ($<35\text{ ms}$ latency per frame) on an NVIDIA RTX/Jetson GPU [3.2, PS].
  3. Interactive 2.5D Variable-Resolution Visualization:
    • Open the custom WebGL/RViz2 dashboard showing the concentric ring boundaries ($10\text{ m}$ and $30\text{ m}$).
    • Show dynamic color-coding: Green = Drivable Surface, Brown = Rough Terrain, Red = Static Walls/Poles, Yellow = Dynamic Pedestrians/Vehicles [PS].
  4. Side-by-Side Memory Telemetry Proof: Live display of dynamic RAM allocation counters:
    • Uniform High-Res Grid Allocation: $512.0\text{ MB}$ [INFERENCE].
    • Adaptive Variable-Res Grid Allocation: $14.3\text{ MB}$ [INFERENCE].
    • Live Memory Savings Counter: $\mathbf{97.2%}$ reduction [INFERENCE].
  5. Interactive Stress Test: Inject synthetic range noise and dynamic point occlusions live during the demo to prove grid boundary stability and zero alignment jitter [INFERENCE].

18. Implementation Roadmap

The development schedule is sized against the official deadline: 30 September 2026 [PS].

+-----------------------------------------------------------------------------------+
|                               IMPLEMENTATION ROADMAP                              |
+-----------------------------------------------------------------------------------+
| PHASE 1: DATASET PREP & MODEL TRAINING     [Oct 2025 - Jan 2026]                  |
|   - Setup SemanticKITTI & nuScenes pipelines                                      |
|   - Train SpConv 3D UNet baseline (mIoU > 68%)                                    |
+-----------------------------------------------------------------------------------+
| PHASE 2: C++ CONCENTRIC GRID ENGINE        [Feb 2026 - Apr 2026]                  |
|   - Implement 3-tier concentric ring buffer math                                  |
|   - Implement snap anchor shift to prevent aliasing                               |
+-----------------------------------------------------------------------------------+
| PHASE 3: ROS 2 INTEGRATION & TENSORRT      [May 2026 - Jul 2026]                  |
|   - Quantize model to TensorRT FP16 (<25ms latency)                              |
|   - Build C++ ROS 2 Node with zero-copy transport                                 |
+-----------------------------------------------------------------------------------+
| PHASE 4: DASHBOARD, TESTING & BENCHMARKING [Aug 2026 - Sep 2026]                  |
|   - Develop WebGL / RViz2 telemetry dashboard                                     |
|   - Final testing & SIH presentation preparation                                  |
+-----------------------------------------------------------------------------------+

Detailed Milestone Timelines

  • Phase 1: Research, Dataset Pipeline & Deep Learning Training (Oct 2025 – Jan 2026)
    • Milestone 1.1: Download and convert SemanticKITTI and nuScenes-lidarseg datasets into unified sparse coordinate tensors [1.3, 2.1].
    • Milestone 1.2: Train SpConv v2 3D UNet segmentation network; achieve $\text{mIoU} \ge 68%$ across terrain, static, and dynamic classes [3.2].
  • Phase 2: Concentric Grid Engine & C++ Core Math (Feb 2026 – Apr 2026)
    • Milestone 2.1: Develop C++ Multi-Ring Discretization Engine; implement $0.05\text{ m}, 0.15\text{ m}, 0.50\text{ m}$ spatial ring assignment routines [PS].
    • Milestone 2.2: Implement bilinear coordinate snapping to prevent spatial aliasing during UGV motion [INFERENCE].
  • Phase 3: ROS 2 Integration & Embedded Optimization (May 2026 – Jul 2026)
    • Milestone 3.1: Export PyTorch SpConv model to ONNX / TensorRT FP16; achieve $<25\text{ ms}$ inference per scan on NVIDIA Jetson AGX Orin [3.2, 3.4].
    • Milestone 3.2: Encapsulate perception engine into ROS 2 Humble/Jazzy C++ Node publishing multi-layer /grid_map messages [4.8].
  • Phase 4: Dashboard Telemetry, System Validation & Final Dossier (Aug 2026 – Sep 2026)
    • Milestone 4.1: Build React + Three.js WebGL real-time telemetry dashboard; connect live memory side-by-side comparison panel [PS].
    • Milestone 4.2: Conduct full latency, memory, and false-positive field tests on pre-recorded off-road Gazebo simulation bags [INFERENCE].
    • Milestone 4.3: Lock build, complete video demonstration, and submit final SIH project deliverables prior to 30 September 2026 [PS].

19. Testing & Validation Plan

+-----------------------------------------------------------------------------------+
|                             TESTING & VALIDATION MATRIX                           |
+-------------------+--------------------+--------------------+---------------------+
| FUNCTIONAL TESTS  | PERFORMANCE TESTS  | AI ACCURACY TESTS  | FALSE POSITIVE TEST |
| Verify grid ring  | Frame rate >20 FPS | mIoU > 68% overall | Validate ground     |
| projection math   | Memory < 20 MB     | mIoU > 60% @ 80m   | over-segmentation   |
+-------------------+--------------------+--------------------+---------------------+

Comprehensive Testing Matrix

Test Domain Test Objective Target Benchmark / Pass Criteria Test Methodology
Functional Verification Verify 3D point projection into correct concentric ring cells ($0\text{--}10\text{ m}, 10\text{--}30\text{ m}, 30\text{--}100\text{ m}$). Zero cell index out-of-bounds errors; correct resolution assignment [PS]. Inject synthetic test points with known coordinates $(x,y,z)$; assert target ring index and cell cell resolution.
Performance & Latency Measure end-to-end perception latency and processing frame rate [PS]. Frame Rate $\ge 20\text{ FPS}$ (Total latency $< 50\text{ ms}$ per scan on NVIDIA Jetson/RTX) [PS]. Timestamp logging across Ingestion, SpConv Inference, Grid Projection, and ROS 2 Publishing.
Memory Footprint Verify dynamic memory savings compared to uniform high-res grid [PS]. Memory Reduction $\ge 70%$ ($< 25\text{ MB}$ vs $512\text{ MB}$) [PS, INFERENCE]. valgrind / sysinfo VRAM and RAM allocation tracking logged continuously during full-sequence playback.
AI Accuracy Evaluate semantic segmentation accuracy across distances [PS]. Overall $\text{mIoU} \ge 68%$; Near-field ($0\text{--}10\text{ m}$) $\text{mIoU} \ge 75%$; Far-field ($30\text{--}100\text{ m}$) $\text{mIoU} \ge 60%$ [PS, ASSUMPTION]. Benchmark against official SemanticKITTI and nuScenes validation splits [1.3, 2.1].
False-Positive Robustness Ensure ground points are not misclassified as obstacles on steep slopes. False Obstacle Rate $< 1.0%$ on $15^\circ$ ramps [INFERENCE]. Replay Gazebo off-road vehicle driving over inclined slopes and rough terrain [INFERENCE].
Spatial Aliasing Test Verify zero cell alignment jitter during high-speed UGV translation [PS]. Zero phantom obstacle flicker at ring transition boundaries ($10\text{ m}$ and $30\text{ m}$) [PS]. Execute rapid linear translation ($5\text{ m/s}$) in simulation; inspect cell height variance at ring boundaries [INFERENCE].

20. Risk Register

+-----------------------------------------------------------------------------------+
|                                  RISK REGISTER MATRIX                             |
+-----------------------------------------------------------------------------------+
| [HIGH SEVERITY]  R-01: Sparse Convolution Memory Overhead on Edge GPUs            |
|                  Mitigation: Apply TensorRT FP16 Quantization & Voxel Pruning     |
| --------------------------------------------------------------------------------- |
| [MED SEVERITY]   R-02: Spatial Aliasing at Concentric Ring Boundaries             |
|                  Mitigation: Implement Anchor-Snapped Coordinate Shifting         |
| --------------------------------------------------------------------------------- |
| [MED SEVERITY]   R-03: Sparse Far-Field LiDAR Points Miss Small Obstacles         |
|                  Mitigation: Temporal Multi-Sweep Voxel Aggregation               |
+-----------------------------------------------------------------------------------+

Risk Severity & Mitigation Table

Risk ID Risk Description Likelihood Impact Severity Mitigation Strategy
R-01 Sparse Convolution Memory Overhead: Unoptimized SpConv kernels exhaust VRAM on 8GB Jetson platforms during dense sweeps. Medium High High Apply FP16 TensorRT quantization; constrain maximum active non-zero voxels via spatial voxel pruning [3.2, 3.4].
R-02 Boundary Spatial Aliasing: Ring transition boundaries ($10\text{ m}, 30\text{ m}$) cause cell alignment jitter during vehicle translation [PS]. High Medium Medium Implement anchor-snapped coordinate translation math, forcing ring coordinate origins to shift in integer cell multiples [INFERENCE].
R-03 Far-Field Point Sparsity: Low point density at $100\text{ m}$ causes thin static obstacles (poles) to be missed in $50\text{ cm}$ cells [PS]. High Medium Medium Accumulate $K=3$ consecutive past LiDAR sweeps using IMU motion compensation prior to far-field cell projection [1.3, INFERENCE].
R-04 Dynamic Object Ghosting: Moving vehicles leave lingering obstacle trails in the static elevation map. Medium Medium Medium Use model dynamic class predictions (Class 3 & 4) to bypass permanent static height map updating for moving cells [1.6, INFERENCE].
R-05 ROS 2 Topic Serialization Overhead: Large multi-layer grid map message copying causes CPU frame drops. Low High Medium Utilize ROS 2 intra-process zero-copy transport via rclcpp::allocator::AllocatedMemoryStrategy [4.8, INFERENCE].

21. Cost & Scalability

+-----------------------------------------------------------------------------------+
|                              COST & SCALABILITY ANALYSIS                          |
+-----------------------------------------------------------------------------------+
| HACKATHON MVP STAGE (Zero Hardware Cost)                                          |
| - Pre-existing Student Laptops / RTX GPUs                                         |
| - Open-Source Datasets (SemanticKITTI, nuScenes) & ROS 2 Tooling                 |
| - Net Hackathon Direct Expense: $0 / ₹0                                           |
+-----------------------------------------------------------------------------------+
| PRODUCTION DEFENSE DEPLOYMENT (Per UGV Unit Estimate)                             |
| - NVIDIA Jetson AGX Orin 64GB Industrial Module   : [NEEDS VALIDATION]            |
| - Tactical FOG IMU + Solid-State 128-Beam LiDAR   : [NEEDS VALIDATION]            |
| - Software Stack Licensing (Open Source Apache 2) : $0 / Free                     |
+-----------------------------------------------------------------------------------+

Hackathon vs Production Cost Profile

  1. Hackathon Stage (Student Team Scope):
    • Hardware: Existing student development laptops equipped with NVIDIA RTX 3060/4060 GPUs [INFERENCE].
    • Datasets & Libraries: 100% open-source software (ROS 2 Humble, SpConv v2, ETHZ grid_map, SemanticKITTI, nuScenes) [1.3, 2.1, 3.10, 4.8].
    • Total Hackathon Cost: ₹0 (Zero direct software development cost) [INFERENCE].
  2. Production Defense Deployment (Per Vehicle Unit):
    • Compute Unit: NVIDIA Jetson AGX Orin Industrial Grade (64GB) [NEEDS VALIDATION for military hardware pricing].
    • Sensors: Tactical 3D Solid-State LiDAR (128-beam) + Fiber Optic Gyro IMU [NEEDS VALIDATION for defense procurement].
    • Software Scalability: The variable-resolution architecture scales linearly $O(N_{\text{active_voxels}})$, enabling a single edge compute node to manage up to 4 synchronized LiDAR sensors simultaneously without exceeding thermal limits [INFERENCE].

22. Differentiation

+-----------------------------------------------------------------------------------+
|                            KEY TECHNICAL DIFFERENTIATORS                          |
+-----------------------------------------------------------------------------------+
| 1. CONCENTRIC SQUARE RING BUFFERS : Eliminates polar distortion while maintaining |
|                                     fixed square cells per ring zone.             |
| 2. SPARSITY-AWARE NEURAL INFERENCE: 25ms execution on edge GPUs via SpConv v2.    |
| 3. MATHEMATICAL MEMORY REDUCTION  : Proven 97.2% RAM savings over uniform grids.  |
| 4. ZERO-ALIASING ANCHOR SNAPPING  : Eliminates boundary jitter during translation.|
+-----------------------------------------------------------------------------------+

Differentiator Feature Mapping

Differentiator Module Standard Generic Submission Our DRDO Solution Framework Architectural Advantage
Spatial Grid Discretization Standard 2D flat occupancy grid or uniform high-res 3D grid [4.10]. 3-Tier Concentric Square Ring Engine ($5\text{ cm}, 15\text{ cm}, 50\text{ cm}$) [PS]. Preserves $5\text{ cm}$ near-field safety detail while reducing RAM usage by $97.2%$ [INFERENCE].
Neural Backbone Heavy dense 2D image networks or unquantized PointNet++ [RESEARCHED]. TensorRT FP16 Submanifold Sparse 3D UNet (SpConv v2) [3.2, 3.10]. Achieves $>25\text{ FPS}$ execution on edge GPUs by skipping empty spatial voxels [3.2, 3.6].
Boundary Alignment Naive coordinate truncation causing boundary cell jitter and ghosting [INFERENCE]. Anchor-Snapped Integer Grid Translation [INFERENCE]. Prevents spatial aliasing and projection gaps during rapid UGV maneuvers [INFERENCE].
Evaluation Telemetry Qualitative visual screenshots without objective memory benchmarking [INFERENCE]. Side-by-Side Dynamic RAM Telemetry Dashboard [PS]. Provides direct proof of low latency and memory reduction to SIH judges [PS].

23. Future Scope

+-----------------------------------------------------------------------------------+
|                                FUTURE ROADMAP SCOPE                               |
+-----------------------------------------------------------------------------------+
| POST-HACKATHON DEPLOYMENT ROADMAP:                                                |
| - MULTI-SENSOR FUSION      : Integrate Radar + Thermal Infrared Point Clouds      |
| - NEGATIVE TERRAIN DETECTION: Specialised elevation variance filters for ditches   |
| - SWARM MAP SHARING        : Mesh-network compressed 2.5D delta grid updates      |
+-----------------------------------------------------------------------------------+
  1. Multi-Modal Thermal-LiDAR Fusion: Extend the 3D Sparse UNet to ingest synchronized far-infrared (LWIR) camera projections, enabling semantic terrain segmentation through heavy smoke, fog, and nighttime conditions [INFERENCE].
  2. Negative Obstacle Detection Filters: Integrate dedicated Rayleigh-distribution height-variance kernels into the 2.5D elevation layers to detect concealed trenches, ditches, and negative terrain hazard zones [1.1, INFERENCE].
  3. Multi-UGV Tactical Swarm Synchronization: Leverage the lightweight $14.3\text{ MB}$ map footprint to broadcast differential 2.5D delta map updates across tactical mesh radios (MNET) between cooperating autonomous ground vehicles [INFERENCE].

24. Assumptions & Open Items Log

Consolidated Evidence & Validation Index

  • [PS] SIH26053 Explicit Requirements:
    • DRDO / iDEX organisation, software category, Smart Vehicles theme, deadline 30 September 2026 [PS].
    • Variable-resolution 2.5D grid engine ($5\text{ cm}$ inside $10\text{ m}$, $50\text{ cm}$ up to $100\text{ m}$) [PS].
    • Tasks: Terrain analysis, Object detection (static/moving), Adaptive spatial representation [PS].
    • Model: PointNet++ or Sparse CNN for 3D semantic segmentation [PS].
    • Deliverables: Deep learning model, Variable-resolution engine, Real-time color-coded visualization dashboard, Low latency (high FPS) performance evidence [PS].
  • [KNOWN] Established Facts:
    • NVIDIA Jetson AGX Orin SWaP edge compute parameters [KNOWN].
    • LiDAR point beam density decay over distance [KNOWN].
    • Air-gapped defense operational constraints [KNOWN].
  • [RESEARCHED] External Findings:
    • SemanticKITTI dataset (22 sequences, 28 classes, Velodyne HDL-64E) [1.3, 1.4].
    • nuScenes-lidarseg benchmark (1000 scenes, 32/16 classes) [2.1, 2.2].
    • SpConv v2 / TorchSparse++ sparse 3D convolution frameworks [3.2, 3.5, 3.10].
    • ETHZ grid_map and elevation_mapping_cupy ROS 2 packages [4.1, 4.2, 4.7, 4.8].
  • [INFERENCE] Derived Logical Implications:
    • Mathematical memory reduction proof ($512\text{ MB} \to 14.33\text{ MB} = 97.2%$ savings) [INFERENCE].
    • Anchor-snapped coordinate shift to eliminate concentric ring boundary aliasing [INFERENCE].
    • Fallback geometric ground filter protocol if AI inference times out [INFERENCE].
  • [ASSUMPTION] Concrete Design Choices:
    • 3-tier ring buffer dimensions ($0\text{--}10\text{ m}$ @ $5\text{ cm}$; $10\text{--}30\text{ m}$ @ $15\text{ cm}$; $30\text{--}100\text{ m}$ @ $50\text{ cm}$) [ASSUMPTION].
    • Target inference benchmark: $\ge 20\text{ FPS}$ ($<50\text{ ms}$ total scan latency) [ASSUMPTION].
  • [NEEDS VALIDATION] Unverified Operational Details:
    • Real-time performance of solid-state 128-beam LiDAR sensors under heavy dust atmospheric backscatter [NEEDS VALIDATION].
    • Military procurement pricing for defense-grade Jetson Orin AGX industrial enclosures [NEEDS VALIDATION].

Final Decision Summary

Final Recommendation

Build Approach 2: A software framework coupling a Submanifold Sparse 3D UNet (SpConv v2 / TensorRT FP16) for semantic segmentation with a C++ Concentric Multi-Ring 2.5D Grid Engine ($5\text{ cm}, 15\text{ cm}, 50\text{ cm}$) published as multi-layer ROS 2 /grid_map messages to a custom WebGL React dashboard [PS, ASSUMPTION].

Recommended Stack

  • Language/Core: C++17 (Grid Engine), Python 3.10 (PyTorch Model Training)
  • AI/Inference: SpConv v2 / TorchSparse++ export to TensorRT FP16
  • Middleware: ROS 2 Humble / Jazzy (CycloneDDS Shared Memory IPC)
  • Grid Engine: ETHZ grid_map C++ circular buffer library
  • Dashboard: Three.js / WebGL + React side-by-side telemetry panel
  • Target Hardware: NVIDIA Jetson AGX Orin 64GB / RTX Edge GPU

Biggest Dependency

Availability of point-wise annotated LiDAR training datasets (SemanticKITTI and nuScenes-lidarseg) properly re-mapped into DRDO's target taxonomy (Terrain, Static Obstacle, Moving Agent) [1.3, 2.1, ASSUMPTION].

Biggest Risk

Potential spatial aliasing or cell height jitter along concentric ring boundary transitions ($10\text{ m}$ and $30\text{ m}$) during high-speed UGV translation [PS, R-02].

Biggest Technical Challenge

Achieving real-time execution ($>20\text{ FPS}$, $<50\text{ ms}$ latency) for 3D sparse convolution neural inference on embedded GPU hardware without losing classification mIoU on distant or small dynamic obstacles [PS, 3.2].

First 5 Actions

  1. Download SemanticKITTI and nuScenes-lidarseg datasets; set up unified sparse coordinate tensor pre-processing scripts [1.3, 2.1].
  2. Train baseline SpConv v2 3D UNet model on GPU; achieve $>68\text{ mIoU}$ across drivable, static, and dynamic classes [3.2].
  3. Implement core C++ Concentric 3-Ring Buffer math engine with anchor-snapped coordinate shifting [INFERENCE].
  4. Export SpConv PyTorch model to ONNX / TensorRT FP16; benchmark latency on target NVIDIA GPU [3.2, 3.4].
  5. Develop ROS 2 Humble C++ wrapper node and React WebGL telemetry dashboard for live demonstration [PS].

Validation Before Coding

  • Verify that SpConv v2 CUDA extensions build cleanly on local development GPU environment with CUDA 12.2 [3.10].
  • Confirm that SemanticKITTI scan poses correctly align multi-sweep point clouds without pose drift [1.3, 1.8].

Buildability Score /100

92 / 100: The problem statement is computationally well-defined. High-quality open-source 3D sparse convolution libraries (SpConv v2, TorchSparse) and C++ grid libraries (grid_map) exist, enabling a capable 4–6 student team to build and demonstrate a complete working prototype within the hackathon timeframe [3.2, 3.5, 4.8, INFERENCE].

Confidence

High (95%): The mathematical formulation, deep learning choices, memory reduction proofs, and ROS 2 architectural components directly fulfill all DRDO problem requirements [PS, INFERENCE].

Research Sources

  1. SemanticKITTI Dataset Benchmark
    • Title: Towards 3D LiDAR-based Semantic Scene Understanding: The SemanticKITTI Dataset
    • URL: http://www.semantic-kitti.org
    • Source Type: Academic Publication / Benchmark Dataset Portal
    • Supported Claim: Serves as the primary 3D point cloud semantic segmentation training source (22 sequences, Velodyne HDL-64E) [1.3, 1.4].
    • Reliability: High (Peer-reviewed IEEE/CVF ICCV publication).
  2. nuScenes-lidarseg Dataset
    • Title: nuScenes: A Multimodal Dataset for Autonomous Driving
    • URL: https://www.nuscenes.org
    • Source Type: Official Dataset Documentation
    • Supported Claim: Provides 1,000 driving scenes with 40,000 keyframes of point-wise LiDAR semantic annotations [2.1, 2.2].
    • Reliability: High (Industry-standard benchmark by Motional).
  3. TorchSparse / SpConv High-Performance Sparse GPU Engine
    • Title: TorchSparse++: Efficient Training and Inference Framework for Sparse Convolution on GPUs
    • URL: https://github.com/mit-han-lab/torchsparse
    • Source Type: Open-Source Technology Documentation & Research Paper
    • Supported Claim: Submanifold sparse convolutions achieve 2.9x inference speedup over standard point cloud backends on NVIDIA GPUs [3.2, 3.4, 3.5].
    • Reliability: High (MIT HAN Lab, MLSys/CVPR Workshops).
  4. ETHZ ASL Grid Map Library
    • Title: ANYbotics / ETHZ ASL Universal Grid Map Library for Mobile Robotic Mapping
    • URL: https://github.com/anybotics/grid_map
    • Source Type: Official Open-Source Repository
    • Supported Claim: Multi-layered 2.5D C++ grid map library supporting non-destructive circular buffer re-positioning and ROS 2 interfaces [4.2, 4.8].
    • Reliability: High (Maintained by ANYbotics / ETH Zurich Autonomous Systems Lab).
02 / What our

DEVELOPERS SAY

" 30M+ Google Gemini tokens went into researching, analyzing, and understanding all 233 SIH problem statements to make them easier to explore and solve. "
Satyam Kumar
Satyam Kumar
CEO , Full Stack Developer
" The platform makes SIH problem statements much easier to understand. Having everything from the problem details to the procedure in one place. "
Rishabh Ranjan
Rishabh Ranjan
COO , Content Writer
" Oh, you got ads? Well, we need to make money too! But, you can use our platform to help you win SIH and take home the prize money. "
Himanshu Kumar
Himanshu Kumar
CMO , Product Reviewer
03 / Are You

READY TO
BUILD?

Get in touch if you need help bringing your ideas to life, or simply have an interesting idea you'd like to talk through. I'm always open to a conversation and exploring new possibilities together.