# Apollo ARGUS — Technical Project Report

Document ID: MF-2026-11-TPR-01  
Status: structured engineering draft; results not yet publication-approved  
Institution: MindforgeAI · Chatake Innoworks Private Limited

## Executive summary

Cognitive autonomous escort architecture using ROS 2 and dual-camera semantic perception. This report records the engineering problem, evidence, implementation decisions, verification work and limitations without converting a prototype into an unsupported production claim.

## 1. Problem definition

Primary engineering question: **How can perception, navigation and human-aware escort behaviour remain modular and testable?**

### Required completion evidence

- user and stakeholder definition;
- measurable functional and non-functional requirements;
- explicit scope and exclusions;
- responsible-use and safety boundary.

## 2. Domain research and requirements

Insert reviewed domain sources, competing methods, user workflow, constraints and acceptance criteria. Every source must be cited and retained in the project research register.

## 3. Dataset, preprocessing and features

Record dataset origin, licence, schema, data dictionary, missing-value policy, exploratory analysis, leakage controls, preprocessing pipeline, feature rationale and train/validation/test split. If no dataset is used, document the equivalent sensor, rule, simulation or document corpus.

## 4. System and model architecture

Add a traceable architecture diagram covering inputs, storage, processing, model or rule layer, API, interface, monitoring and human decision points. Record environment versions and reproducible run commands.

Observed technology surface: Python, C/C++, CMake, TypeScript, ROS-style workspace.

## 5. Implementation and verification

Verified at 17 August 2026: A ROS-style robotics workspace and multimodal implementation were observed.

Known limitation: ROS 2, CMake and Gazebo were unavailable on the audit host, so the robotics build was not proven.

Next gate: Reproduce with the team’s declared ROS/Gazebo versions and known-good run command.

Do not add accuracy, latency, scale, safety or deployment claims until the corresponding test artifact is linked in the evidence matrix.

## 6. Deployment and operations

Reserve evidence for environment configuration, secrets handling, infrastructure, health checks, logs, monitoring, rollback, privacy, accessibility and operating cost. A proposed Android application must remain a proposal until a reproducible build exists.

## 7. Results and discussion

Pending reproducible experiment outputs. Required table: metric, baseline, experiment configuration, result, uncertainty, artifact path and reviewer.

## 8. Limitations and future work

Current limitation: ROS 2, CMake and Gazebo were unavailable on the audit host, so the robotics build was not proven.

Capstone continuation remains open after repository reconciliation, reproducibility review and programme approval.

## 9. Conclusion

Complete only after the evidence matrix supports the project objective.

## References and appendices

Use a consistent citation style. Append dataset cards, model cards, API specification, test report, screenshots, diagram sources and change log.