Summary of "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:
- Target detection
- Recognition
- 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)
Category
Business
Share this summary
Is the summary off?
If you think the summary is inaccurate, you can reprocess it with the latest model.
Preparing reprocess...