DISC 14 and ADITI 4.0 Outreach Session - Indian Army (Apr 17)

Challenge 1 (DISC 14) — Modular, Scalable Ammunition for UAVs/UAS

Problem intent (as briefed)

• Develop an “all-in-one modular and scalable” ammunition system compatible across multiple unmanned flying platforms, from UAVs/drones to larger UAS.
• Ammunition should be a detachable payload and support multiple role variants:
  • Anti-personnel
  • Anti-vehicle
  • Anti-tank
• Enable different models/weights through modular composition.

Key requirements & interpretations

Modularity approach

• Question raised: whether “modular” means the same form-factor weapon vs modular warhead/fuse.
• Clarification:
  • The expectation is modules with consistent form/fit factors.
  • Fuse handling is treated separately, since on-field integration is difficult.

Compatibility approach

• Start with plug-and-play at the payload level (a droppable payload concept).
• Integration and compatibility constraints (interfaces, arming safety, software protocols) are expected to be addressed later if needed, not necessarily solved upfront for every platform.

Safety & compliance

• Insensitive munitions compliance is expected/treated as compulsory due to storage and mobility constraints.
• Testing/certification standards are referenced (e.g., MIL-810).
• “EMIC” and certification gatekeeping were discussed; answer: acceptance is expected only after certification.

Other items noted

• Testing and certification and “1000+ simulated scenarios” are referenced.
  • A question asked about clarity given sensor types like laser/EO/IR; answers were deferred to specific parts of the brief or later responses.
• Lethality factors such as blast radius/penetration were acknowledged, with the method of measurement to be clarified later.

Business/process signals (stakeholder management)

Licensing expectation

• Startups are not required to hold ammunition production licenses at the project start.
• For prototype → procurement, startups should ensure access to licensed manufacturers:
  • JVs/support from existing ~16–17 license holders
  • Active production by about ~4 identified license holders

Queries intake

• Participants should submit technical questions via the IDEX/ADB web portal/forms for routing to officers.

Actionable recommendations implied by the Q&A

• Build a modular payload with:
  • Multiple module shapes/weights that compose into different payload variants.
  • Separate fuse handling aligned to safety constraints.
• Plan for:
  • Early certification/test planning (procurement acceptance depends on it)
  • A procurement pathway using licensed OEMs

Metrics / KPIs

• No explicit business KPIs (revenue/CAC/etc.) were stated.
• Technical items were discussed qualitatively (compatibility, safety certification, simulated scenarios, and later clarification of measurement methods).

Challenge 2 — AI-enabled Target Detection/Recognition/Identification Module for UAS (“Universal Compatibility” Edge Intelligence)

Problem intent

Build an AI-enabled edge module providing:

1. Target detection
2. Recognition
3. Precise identification + geo-tagging/location output

It must work across platform-agnostic UAS:

• Minimum expected sensors: EO (day/night) and IR (thermal)
• Future scalability: accept additional sensor inputs (IR/other advanced sensing)

Operational deployment architecture

Where it runs

• Primarily on the edge for the operator to reduce burden on the UAV and avoid modifying UAV integrity.
• Clarification: not on the UAV; integrated at the GCS/edge level.

Human in the loop

• Designed to assist the operator/last man at the GCS level.
• Targeting requires location/coordinates (geo-tag style output) for engagement decisions.

Universal compatibility constraints

• Must communicate with different UAS systems using available ICDs.
  • The team has interface documents for one system; availability of remaining OEM ICDs was to be clarified later.
• Must support different sensor feeds via standard/open interfaces where possible.

Performance priorities (explicit)

• Latency prioritized over accuracy at the edge.
• Throughput target discussed: ~30 fps
• Resource constraints:
  • Minimal power draw
  • Lightweight form factor (tablet/iPad-class or small laptop-class)
• Compute assumptions:
  • Edge deployment concept like Jetson Nano-class
  • Heavy GPU/server assumptions rejected

Training/data strategy

• Proof-of-concept:
  • Use open-source data
• Army-specific improvement path:
  • Army collects data for ~46 classified object classes, forming a classified data lake
  • Selected developers receive collaborative access to train models for required accuracy

Certification & video standards

• Multiple certifications referenced; discussion can occur during/after proposal.
• No single locked video-resolution spec in the dialogue:
  • Developers asked to send queries in writing to receive minimums/requirements.

Denial/EW environment

• UAS expected to operate in degraded/denied environments per developer requirements.
• Edge module should remain functional under such conditions (details not fully specified).

Metrics / KPIs explicitly mentioned

• Throughput/latency: ~30 fps target; latency more critical than accuracy
• No explicit accuracy targets (mAP/precision) or error thresholds provided in the transcript.

Actionable “how-to” from Q&A

• Start with a lightweight model that works with:
  • EO/IR feeds, extensible to new sensors
• Design around:
  • Edge compute constraints and minimal power consumption
• Use the Army classified dataset pipeline:
  • Demonstrate basics with open data first, then integrate classified training

Challenge 3 — AI-enabled Terrain (“Raki”) Planning Module for Gun Area Selection

Problem intent

• Make raki (reconnaissance for gun deployment areas) intelligent and faster, especially at night in hostile conditions.
• Current manual workflow:
  • Humans select general areas using maps/satellite/images
  • Then conduct step-by-step physical raki to verify:
    • obstacles, access tracks, spacing for deployment
    • enemy presence, cover
    • terrain undulations/trafficability
  • Night operations are time-consuming and hazardous:
    • ~60 minutes per km-scale raki (ballpark)

Proposed approach

Use AI + UAS reconnaissance to:

• Analyze terrain and threats
• Validate/refine deployment suitability
• Output recommended:
  • gun/ammo/command-post placements
  • within suggested grid blocks

Key operational parameters (explicit)

• Deployment area example/ballpark: 1 km × 1 km (for deployment of six guns)
• Time targets (baseline and goal direction):
  • Daytime: deployment + completion in ~30 minutes
  • Nighttime: ~60 minutes baseline (manual); automation should drastically reduce (exact new target not quantified)
• Terrain range profile:
  • deserts → semi-deserts → obstacle-laden areas with canals → plains/fields → mountainous terrain → high-altitude areas up to ~18,000 ft

What the AI must evaluate (explicit factors)

• Space availability (grid/area adequacy)
• Undulation and trafficability
• Ground nature/soil stability (stones hardness/bogginess)
• Enemy presence / unidentified humans
• Obstacles:
  • big trees, slopes, mountains/ridges affecting line-of-fire and safe siting
• Cover/concealment considerations (as “value-add”)
• Undergrowth and feasibility of trenches/digging
• Maintain spacing requirements for platforms:
  • 15–20 m minimum distance between guns/platforms (mentioned)

Output format (explicit)

• A report including:
  • Threat/obstacle detection outputs
  • Suitability recommendation such as:
    • “In a 400 m × 400 m area, you can place 1/2/3/… guns here…”
  • Coordinates/grid-style placement suggestions

Edge processing preference

• Prefer processing on the edge for “last man” utility (small tablet/laptop class).
• Offloading allowed only if the aircraft returns to a nearby vehicle/command post, but the design should not rely on heavy compute carried far behind.

UAS platform assumptions

• Birds for raki reconnaissance:
  • Fixed-wing UAS already being procured
  • Endurance ~4–5 hours, range ~10–15 km
  • FPV not included in scheme (not baseline)
• Baseline sensing:
  • Multi-camera EO-based sensing (day + night)
  • Lidar/SAR discussed as not baseline (lidar complicates; SAR likely out-of-scope but may be confirmed)

Use of imagery

• Broad-area planning from open-source satellite/GIS/maps
• Explicitly avoiding requirements like sub-3m resolution pinpoint targets

Time sensitivity / library vs dynamic

• Terrain is somewhat stable, but systems must support dynamic updates due to:
  • enemy movement
  • flash floods/landslides/avalanche events

Metrics / KPIs explicitly mentioned

• Area/time baselines:
  • 1 km × 1 km
  • ~30 min day, ~60 min night
• No explicit ML accuracy metrics stated.

Actionable recommendations implied

• Build modular edge intelligence that ingests:
  • EO/RGB + thermal feeds (day/night) plus GIS overlays
• Provide grid-based suitability outputs and threat-aware placement suggestions
• Support dynamic updates rather than static-only terrain libraries

Challenge 4 — AI-enabled Multi-agent Module for UAS “Surveillance + Strike” Mission Autonomy (Human-in-the-loop)

Problem intent

Create an AI-enabled multi-agent autonomy module inspired by a “HiveMind” concept (Shield AI reference), but with a locally developed “totally ours” solution.

Example mission behavior:

• Mission planning for a combined surveillance/strike package:
  • e.g., 2 surveillance UAS + 3 strike UAS
• Surveillance agents:
  • takeoff/navigation to assigned blocks
  • search and perform detection/recognition/identification
  • redistribute tasks if a surveillance asset is lost
  • share target info with strike agents
• Strike agents:
  • perform mission planning with man-in-the-loop approval
  • re-detect/re-home if the target moved before striking

Core autonomy level

• Not full autonomy (explicitly not Level 5).
• Positioned between Level 3 and Level 4, with:
  • human always involved for strike decisions
  • surveillance functions under supervision

Architecture constraints

• No modification to UAV flight controllers
  • Keep onboard UAV hardware unchanged
  • Changes primarily at GCS/ground-side control via modules integrated on edge
• Multi-agent composition clarified as acceptable in either form:
  • multiple agents collaborating on one UAV, and/or
  • each UAV acting as an agent communicating with others
• Sensor-to-shooter scope:
  • airborne systems only (no ground robots/vehicles in this challenge)
• Telemetry and update/upgrade:
  • expect modularity and ability to update the module
  • key bottleneck: access to ICDs/telemetry/video feeds from OEMs
    • plan to be selective to avoid needing “entire codes” access

Communication/networking

• Mesh networking:
  • may need to be created as part of the model/module, since birds may not provide native mesh capability.

Band/communication details

• Exact frequencies/protocols not provided in-session.
• Bands are being harmonized broadly; developers should query officers.

Metrics / KPIs

• No explicit quantitative KPIs given (e.g., completion time, success rate, autonomy percentage).

Actionable recommendations implied

• Implement a lightweight onboard/edge autonomy stack that can:
  • generate mission plans (waypoints, search patterns)
  • manage tasking across agents
  • coordinate info handoff from surveillance to strike
• Ensure upgradeability and modular integration across different OEM platforms via ICDs

Frameworks / Playbooks / Structured Processes Referenced

• Open-then-classified training pipeline:
  • start with open data for proof-of-concept
  • then improve using classified dataset access
• Human-in-the-loop workflow for strike authorization (explicit in Challenge 4)
• End-to-end operational loop:
  • ingest sensors → infer detections/terrain suitability → output actionable placements/locations → operator confirmation
• Edge-first deployment constraint:
  • minimize compute, power draw, and form factor requirements

Key presenters / sources (as mentioned in subtitles)

• Linkal Vijay G1 RT14 (Army presenter/chair; initial DISC 14 problem framing)
• Gagen (Trigger Labs)
• Kashab (Hyderabad)
• Abhishek Jan (Zos)
• Pender (AMY Design Bureau / licensing guidance)
• Anul / Nathan / RT8/RT9/RT14/RT8 (challenge coordination; identity varied in transcript)
• Rahul (AI) (Optimize/AI participant)
• Arun (Optimize) (participant)
• ProtOMindi Technologies (participant; name not clearly stated)
• Sah / Gupendra / Var defense (participant; name varied)
• Manish Shaki (participant)
• Manish (question about where to mail; later portal guidance)
• Vikramya (participant; referenced Shield AI)
• ABD/ADB / DIIO (Innovation for Defence Excellence; general session presenter)
• Secretary/DP (mentioned in outreach framing)
• IDEX / DIIO outreach presenter (delivered general framework, grants, timelines; name not captured in subtitles)