Toddler Language Learning Device
Thought
Work done
- Updated the existing spec doc (project-specification) with requirements + a system block diagram.
- Added and wired all major subsystems in the schematic:
- Set initial PCB constraints: 4-layer stackup and 70 mm x 40 mm board size.
Success criteria review
- ✅ Major subsystems integrated and electrically connected in the schematic (compute, camera, audio, UI, power, optional mic).
- ❌ Cannot complete PCB routing/placement: DRC shows 131 airwires (unrouted nets). Routing requires the human to run Auto-Layout and/or perform placement.
- ❌ Cannot confirm charger/regulator programming component values from datasheets because the
@datasheettool errored (reported internally).
Next steps
Refine this doc
Ask about this doc
Project Specification
Version: 0.1.0
Date: 2026-02-27
Author: Flux AI
Status: Draft
Tags: toddler, handheld, camera, vision, tts, serbian
1. Executive Summary
This project is a toddler-friendly handheld device that captures live camera images, performs on-device object recognition, and speaks the recognized object name in Serbian (with support for additional selectable languages). The board integrates a camera interface, a compute module capable of running vision inference and text-to-speech (TTS) audio, a speaker amplifier, minimal user interface controls for language selection/status, and safe battery power management suitable for a child-safe enclosure.
2. Goals and Non-Goals
What must be true in this rev, and what is explicitly out of scope.
...
2.1 Goals
- Recognize common objects from live camera input and speak the name in Serbian.
- Support additional selectable languages via firmware assets (audio prompts/TTS models).
- Provide simple child-safe UI: a small number of buttons and status indication.
- Battery powered with safe charging and protection.
- Optional connectivity (BLE/Wi-Fi) for future expansion (updates/content).
2.2 Non-Goals
- Not a general-purpose phone/tablet replacement.
- Not intended to stream video to a cloud service (default assumption: offline operation).
- Not intended to be a high-resolution photography device.
3. System Overview
High-level description of the system and how the board fits into it.
...
3.1 Block Diagram
Diagram
4. Requirements
What the design must do (behaviorally and electrically), independent of implementation details.
...
4.1 Functional Requirements
- Live camera capture with sufficient frame rate for responsive interaction.
- Object recognition pipeline operates on-device.
- Audio output speaks recognized object name in Serbian.
- Language selection via UI (button-driven cycling) with clear status indication.
- Safe behavior on low battery: graceful shutdown and user feedback.
4.2 Electrical Requirements
- Battery: 1-cell Li-ion/LiPo with protection.
- USB input: 5 V for charging and optional operation.
- Primary logic rail: 3.3 V.
- Audio rail: sized for peak speaker current (implemented as a dedicated boosted rail or direct battery, depending on amplifier choice).
- Camera interface: DVP/parallel or MIPI CSI-2 (depends on compute choice).
- Audio interface: I2S/PCM preferred.
4.3 Environmental and Reliability Requirements
- Designed for handheld child use in an enclosed plastic housing.
- No external exposed conductive parts accessible to the child during normal use.
- Robust to frequent drops; prefer fewer external connectors.
5. Constraints
Hard limits that shape the design choices.
...
5.1 Mechanical Constraints
- Handheld device; board outline to be defined after enclosure constraints are known.
- Camera must align to an enclosure window.
- Speaker opening and acoustic path must align with enclosure features.
5.2 Power and Thermal Constraints
- Minimize surface temperature rise; avoid hot spots accessible to child.
- Prefer switching regulation for higher-load rails.
5.3 Layout / Implementation Constraints
- Place camera connector/module close to compute and keep high-speed routing short.
- Keep switching regulators away from camera and audio analog paths.
- Provide solid ground reference and adequate decoupling near compute and camera.
5.4 Cost and Sourcing Constraints
- Prefer widely available parts with active lifecycle.
- Allow substitutes for passives.
6. Assumptions and Dependencies
- Default assumption: offline recognition and offline speech (pre-recorded prompts or on-device TTS).
- Recognition model and vocabulary will be optimized for embedded inference.
- Optional connectivity kept modular to allow removal if not needed.
7. Validation Criteria
- Board powers from battery and USB safely and predictably.
- Live camera capture and inference runs on target compute.
- Spoken output in Serbian is intelligible and volume-limited.
- ERC clean (or only known-unfixable library pin-type warnings) and DRC clean after layout.
7.1 Acceptance Tests
- Power: charge battery from USB, run while charging, verify low-battery cutoff behavior.
- Camera: capture frames and validate exposure/white balance settings.
- Recognition: test a small target vocabulary and measure end-to-end latency.
- Audio: play prompts at target SPL without excessive distortion.
- UI: cycle languages and confirm the selected language changes the spoken output.
7.2 Review Checklist
- All subsystems present: compute, camera, audio, UI, power, optional connectivity.
- Adequate decoupling on each rail and near each IC.
- ESD protection on external connectors.
- Battery safety: protection + safe charge settings.
Appendix (Optional)
Any supporting urls, analysis, datasets, or taxonomy notes that informed this spec.
...
1. Executive Summary
2. Goals and Non-Goals
2.1 Goals
2.2 Non-Goals
3. System Overview
3.1 Block Diagram
4. Requirements
4.1 Functional Requirements
4.2 Electrical Requirements
4.3 Environmental and Reliability Requirements
5. Constraints
5.1 Mechanical Constraints
5.2 Power and Thermal Constraints
5.3 Layout / Implementation Constraints
5.4 Cost and Sourcing Constraints
6. Assumptions and Dependencies
7. Validation Criteria
7.1 Acceptance Tests
7.2 Review Checklist
Appendix (Optional)
