[WIP] Update RAM allocation strategy for task management

[Copilot]

Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.

Original prompt

Context

This is the JEEVA companion robot project — an AI elder-care robot powered by NVIDIA Jetson Orin Nano Super (8GB shared RAM, 67 TOPS) + ESP32-S3. The project plan document (JEEVA_FUNDED_PROJECT_PLAN.md) needs two critical technical sections added/updated based on real-world engineering analysis, NOT hallucinated numbers.

Problem 1: RAM Allocation — Prevent Task Interference

The Jetson Orin Nano Super has 8GB shared LPDDR5 RAM (shared between CPU and GPU). The plan currently claims "Q4_K_M ~2GB" for Llama 3.2 3B but doesn't provide a real-world tested RAM budget or any strategy to prevent one AI task from starving another.

Requirements:

1. Research and document actual real-world RAM usage from community benchmarks and user-reported data for each component running on Jetson Orin Nano Super:
   • JetPack 6 OS + desktop environment baseline
   • Llama 3.2 3B Q4_K_M via llama.cpp with CUDA (actual VRAM + RAM from user tests)
   • Whisper small/medium via faster-whisper with CUDA
   • OpenCV with CUDA for face detection + ArUco
   • PyGame/rendering for eye animations on 4.3" HDMI display
   • Flask/FastAPI web server + SQLite
   • System overhead, buffers, etc.
2. Calculate whether all tasks fit simultaneously in 8GB, or if model swapping is required.
3. Propose a practical RAM allocation strategy:
   • Can we use systemd cgroups or NVIDIA's jetson_clocks / power modes to reserve RAM?
   • Should we use mlock() or mlockall() for critical AI models to prevent swapping?
   • Should Whisper be loaded/unloaded on demand (only when wake word triggers) to save RAM?
   • What is the actual peak RAM when Llama + Whisper + OpenCV all run simultaneously?
4. Use data from real Jetson Orin Nano Super users on NVIDIA Developer Forums, GitHub issues for llama.cpp, and faster-whisper benchmarks. Cite sources where possible. Do NOT make up numbers.

Problem 2: Microphone Architecture — The Hardest Problem

The founder explicitly says: "mic is the biggest confusion and headache for me in this project." The robot must:

• Detect voice from every direction (omnidirectional pickup)
• Work at 20-30 human steps distance (~15-22 meters is unrealistic for MEMS mics; realistically this means 3-5 meters in a room, which is already very challenging)
• Block internal noise from: 40mm blower fan (structure-borne vibration + acoustic), speaker echo (3W at high volume for elderly), motor noise from JGA25-370 track motors
• Work in Indian elder-care environments: ceiling fans, TV noise, other residents talking, tile/cement room acoustics (high reverb)
• Fit in a ~25cm tall, ~140mm wide robot body

Current plan has:

• 1× INMP441 I2S MEMS mic on ESP32-S3 (for wake word detection via openWakeWord/ESP-SR WakeNet)
• 1× USB mic on Jetson (for Whisper ASR during development, planned upgrade to dual I2S MEMS in Month 7)

The founder's core questions:

1. Is 2 mics enough? If not, how many do we need and where do they physically go in a 25cm robot?
2. How do we block internal fan/motor/speaker noise from contaminating the mic signal?
3. What specific mic hardware should be used? (INMP441 vs SPH0645 vs ICS-43434 vs PDM mics vs USB mic arrays)
4. Do we need hardware AEC (like ES8388 codec) or can software AEC on Jetson handle it?
5. What is the practical maximum pickup distance for a MEMS mic in a noisy Indian room? Be honest — don't claim 10m if it's really 2-3m.
6. Should we just use a commercial USB mic array (like ReSpeaker 2-Mic HAT at ~₹1,500-2,000) instead of hand-wiring MEMS mics?

Requirements for the solution:

• Provide a specific, actionable mic architecture recommendation with:
  • Exact mic model(s), quantity, and placement diagram
  • Wiring to ESP32-S3 and/or Jetson
  • Software pipeline: wake word (ESP32) → ASR (Jetson Whisper) → how audio flows
  • AEC strategy (hardware vs software, specific library/tool)
  • Vibration isolation approach for internal noise
  • Honest maximum working distance in a typical Indian room
  • India cost (₹) with source
• Address the physical space constraint: where do mics go in a 140mm-wide, 25cm-tall robot?
• Address the "blocking internal sound" problem specifically — structure-borne vibration from fan/motors transmitted through the rigid PETG chassis to co-located MEMS mics

Deliverable

Create or update a technical document (e.g., docs/RAM_AND_MIC_ARCHITECTURE.md) in the repository that covers both problems with:

1. A real-world RAM budget table with cited sources
2. A RAM allocation strategy with specific Linux/Jetson commands
3. A complete mic architecture recommendation with placement, wiring, software pipeline, and cost
4. Honest limitations and trade-offs
5. A decision matrix for mic options (cost vs quality vs complexity vs space)

This document should be engineering-grade — the founder will use it to make purchasing decisions and design the physical robot body in FreeCAD. No hand-waving, no "it should work" — ...

This pull request was created from Copilot chat.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[Copilot]

Copilot wasn't able to review any files in this pull request.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.