At a glance

Aida Field Companion is a handheld maker tool for people who need to capture and recover project information while their hands or attention are occupied. Its signature workflow is capture–inspect–recall : record a voice note, deliberately photograph a component for explanation, and retrieve that recent project context later through the same interface.

The Arduino UNO Q is central to the design. Its Qualcomm/Linux side will handle connected voice, vision and bounded recent memory, while the STM32 side is planned to keep physical mute and stop controls, privacy status, haptics and display feedback responsive. The application-stage enclosure measures 115 × 75 × 28 mm , excluding the external power source. A commercial USB-C power source will remain external until measured power requirements determine the final production arrangement.

Evidence completed so far includes a native Autodesk Fusion .f3d dataset, STEP review copy, preliminary 16-line BOM, three Fusion screen captures and a reproducible Fusion generator. The UNO Q port, Fusion Electronics PCB, physical prototype, PCBWay enclosure and measured performance remain to be completed and validated.

`.f3d` Current status: this is an application-stage design proposal, not a finished prototype. CAD placeholders, candidate components and planned interfaces are identified as such below. Physical fit, electrical compatibility, manufacturability, thermal behaviour, runtime and interaction performance have not yet been verified.

Genuine Autodesk Fusion screen capture of the application-stage concept. It is CAD evidence, not a prototype photograph or proof of physical fit.

The signature workflow: capture–inspect–recall

The first complete demonstration will follow one coherent maker workflow:

• Capture: while working, the maker records a short voice note about a component, measurement or build decision.
• Inspect: the maker deliberately opens the mechanical camera shutter and asks Aida to capture and explain an image of the item.
• Associate: Aida stores the completed text exchange as bounded recent project context rather than retaining raw command audio in the conversation history.
• Recall: later, the maker asks what was recorded or discovered and receives a concise spoken and on-screen answer.
• Interrupt or erase: the maker can use the physical stop control, disconnect the microphone path or erase the recent conversation history.

This workflow is intended for benches, classrooms, site visits and events where unlocking a phone, finding several applications and changing context is disruptive. It combines the functions only where they support the same task rather than presenting Aida as an unlimited general-purpose assistant.

Why this is hardware, not only a phone application

A phone could run voice, camera and note-taking software, but it does not provide the same dedicated physical interaction or visible privacy state. Aida is being designed around hardware properties that software alone cannot provide:

• a physical microphone-signal disconnect;
• a mechanical camera shutter whose position can be seen without trusting an icon;
• a reachable action/back/stop control;
• microcontroller-owned privacy indicators;
• visible and haptic acknowledgement before a connected request begins; and
• a bounded recent-memory store with an owner-controlled erase action.

These are design goals until they have been tested on the assembled prototype. The final project will distinguish a switch state from the verified state of the underlying signal path and will not claim that a software indicator proves privacy.

Why the Arduino UNO Q

The 4 GB UNO Q combines a Debian-capable Qualcomm Dragonwing QRB2210 application processor with an STM32U585 real-time microcontroller. Aida has both connected application work and time-sensitive interface work, so the planned responsibility split is:

Responsibility: Voice, vision and network-provider calls

• Planned owner: Qualcomm/Linux
• Reason: Runs the Python application and connected services

Responsibility: Bounded recent-text memory

• Planned owner: Qualcomm/Linux
• Reason: Maintains up to 20 completed exchanges and supports owner-controlled erase

Responsibility: Camera workflow and local activation stage

• Planned owner: Qualcomm/Linux
• Reason: Uses the Linux multimedia and application environment

Responsibility: Buttons, mute-switch sensing and stop input

• Planned owner: STM32
• Reason: Keeps the physical interface independent of the main application loop

Responsibility: Privacy/status LEDs, haptics and compact display status

• Planned owner: STM32
• Reason: Keeps acknowledgement available while Linux is busy

Responsibility: Cross-processor commands and state

• Planned owner: Arduino Bridge
• Reason: Carries small, explicit messages between the two domains

Proposed architecture showing current software, planned UNO Q work, candidate hardware and optional external services. It has not yet been validated on assembled hardware.

The intended advantage is that the STM32 can continue to accept an interrupt or show state while the Linux application is occupied. That behaviour must be demonstrated under deliberate Linux load before it is treated as a verified result.

What exists today

Evidence: Native Fusion .f3d dataset

`.f3d`

• Current state: Complete for the application-stage concept
• What it does not prove: Physical fit, assembly, tolerances or manufacturability

Evidence: STEP review copy

In practice, Aida Field Companion: Voice-and-Vision Maker Tool works best when you follow a step-by-step contest validation workflow and keep a simple checklist for wiring, power stability, and expected output behavior. This makes debugging faster and creates a practical fusion troubleshooting path for repeatable results.

• Current state: Complete
• What it does not prove: Native Fusion design history or final geometry

Evidence: Three Fusion screen captures

• Current state: Complete
• What it does not prove: A manufactured or working prototype

Evidence: Reproducible Fusion generator and instructions

• Current state: Complete
• What it does not prove: That candidate components will fit when measured

Evidence: Preliminary 16-line BOM

• Current state: Complete as a planning document
• What it does not prove: Confirmed sourcing, final cost or electrical compatibility

Evidence: Existing Aida software structure

• Current state: Available as a Raspberry Pi/host starting point
• What it does not prove: UNO Q hardware compatibility or working UNO Q integration

Evidence: Fusion Electronics PCB

• Current state: Planned
• What it does not prove: Electrical or manufacturing readiness

Evidence: UNO Q physical build and test results

• Current state: Pending
• What it does not prove: No hardware performance claim is made yet

Evidence: PCBWay enclosure and assembled prototype

• Current state: Pending
• What it does not prove: No production-readiness claim is made yet

Application-stage design downloads:

• Native Autodesk Fusion `.f3d` dataset
• STEP review copy
• Fusion generator and reproduction instructions
• Preliminary BOM

The .f3d archive was produced by Autodesk Fusion rather than being a renamed neutral export. The STEP file is supplied as a convenient review copy and does not replace the native dataset.

`.f3d` Application-stage packaging arrangement. Peripheral bodies remain provisional placeholders.

Application-stage top view. Openings and feature positions remain provisional.

Contest MVP and stretch capabilities

The contest build will prioritise a small, testable product rather than attempting to complete every possible assistant feature.

Contest MVP: Local or physical activation

• Stretch capability after the MVP is stable: Short spoken translation

Contest MVP: Capture one voice note

• Stretch capability after the MVP is stable: Reminders and alarms

Contest MVP: Deliberate camera-assisted inspection

• Stretch capability after the MVP is stable: Additional provider integrations

Contest MVP: Recall bounded recent project context

• Stretch capability after the MVP is stable: Broader productivity workflows

Contest MVP: Store no more than 20 completed text exchanges

• Stretch capability after the MVP is stable: Additional assistant modes

Contest MVP: Owner-controlled memory erase

• Stretch capability after the MVP is stable: Longer-term project organisation

Contest MVP: Physical microphone disconnect and camera shutter

• Stretch capability after the MVP is stable: Expanded accessibility evaluation

Contest MVP: Physical stop under deliberate Linux load

• Stretch capability after the MVP is stable: Further enclosure and control variants

Contest MVP: Visible and haptic acknowledgement

• Stretch capability after the MVP is stable:

Contest MVP: Clear behaviour when the network is unavailable

• Stretch capability after the MVP is stable:

Translation, reminders and other stretch functions will not block the signature capture–inspect–recall demonstration or the required hardware documentation.

Prototype hardware and privacy controls

The preliminary prototype uses the following candidate modules:

A reliable implementation also benefits from modular structure: separate input handling, processing logic, and output control so each part can be tested independently. That pattern supports low-noise camera tuning, clearer application calibration decisions, and safer iteration when features evolve.

• Arduino UNO Q 4 GB as the required compute and control platform.
• Arduino UNO Media Carrier as the intended route to documented MIPI-CSI and analogue-audio interfaces.
• IMX219 camera behind a manually operated mechanical shutter.
• Candidate 1.69-inch ST7789 SPI display for compact visual status; refresh performance, legibility and fit remain untested.
• Planned low-speed control/display PCB for the display, haptics, controls and status outputs.
• Microphone and speaker paths using the Media Carrier during first bring-up; levels, noise and gain remain to be measured.
• External commercial USB-C power bank selected only after input-power and runtime tests.

The custom PCB is deliberately limited to conventional 3.3 V SPI, I²C and GPIO. The first revision will not duplicate unvalidated high-speed MIPI camera routing or analogue-audio circuitry already provided by the Media Carrier.

The microphone path is planned to include a dual-pole control: one pole physically disconnects the microphone signal and the other reports the switch position to the STM32. Testing must confirm the actual signal-path behaviour. The camera shutter is mechanical and is intended to remain visibly closed without software.

Media Carrier Plan A and Plan B

The Media Carrier remains a supply risk because its official product page currently labels it Coming Soon . The project therefore has two distinct bring-up routes:

Trigger

• Plan A: compact carrier route: Media Carrier can be procured in time for hardware integration
• Plan B: software bring-up route: Media Carrier is unavailable when multimedia bring-up must begin

Camera and audio

• Plan A: compact carrier route: Media Carrier, IMX219 camera and analogue audio
• Plan B: software bring-up route: Arduino-documented powered USB-C dongle with USB camera, microphone and headphones/audio output

Purpose

• Plan A: compact carrier route: Target prototype architecture
• Plan B: software bring-up route: Validate software and interaction while the compact route is unresolved

Required validation

• Plan A: compact carrier route: Drivers, audio levels/noise, camera operation, current and thermal behaviour
• Plan B: software bring-up route: Debian drivers, hub power, latency and current behaviour

Enclosure consequence

• Plan A: compact carrier route: Continue with the compact enclosure stack after measured fit checks
• Plan B: software bring-up route: Do not present the USB arrangement as the final compact enclosure; revise packaging only after parts are proven

The fallback BOM will identify any powered hub, camera, microphone, audio device, cables and additional power allowance actually used. Neither route is considered compatible until it has been tested on the UNO Q.

PCBWay prototype and route towards approximately 750 units

After design-rule review and quotation, the first enclosure is planned as top, bottom and shutter parts produced by PCBWay in PA12 using SLS or MJF. The choice between those processes, material grade, finish, orientation and tolerance will follow the current manufacturer guidance and quotation rather than a CAD-only assumption.

The low-speed control/display PCB is also planned for PCBWay fabrication after schematic review, Fusion Electronics ERC and PCB DRC. The prototype will use test points and replaceable modules where that reduces bring-up risk.

Prototype work will document:

• selected process, material, finish and quoted tolerance;
• overall and critical dimensions;
• fastener and insert strategy;
• connector access and USB-C strain relief;
• antenna, speaker-magnet and thermal clearances;
• first-fit problems and the resulting Fusion revision; and
• the actual PCB and enclosure quotations.

The later review for approximately 750 units will compare printed PA12, urethane casting and injection moulding. It will consider consistent wall thickness, draft, undercuts, one-direction assembly, production connector strategy, PCB integration, incoming inspection, programming and functional test. No production process, unit cost or compliance claim will be made until the design and quotations support it.

Contest timeline and build sequence

Only dates published in the official contest rules are fixed here. Internal prototype dates will be added after hardware selection and shipping information are known.

Official date: 28 July 2026, 12:00 PM PT

• Contest event: Contest and project-submission period opened
• Aida checkpoint: Application-stage concept and evidence pack prepared during the submission period

Official date: 23 August 2026, 11:59 PM PT

• Contest event: Free-hardware application deadline
• Aida checkpoint: Hardware application submitted; keep the linked public evidence complete and accessible

Official date: 20 December 2026, 11:59 PM PT

• Contest event: Project submission deadline
• Aida checkpoint: Submit the documented working entry with the required UNO Q, PCBWay enclosure, Fusion dataset, BOM, instructions, code, photographs and video

Official date: 29 January 2027, 5:00 PM PT

• Contest event: Contest winners scheduled to be announced
• Aida checkpoint: Preserve the submitted evidence and respond promptly to any organiser request

The working sequence before the final deadline is:

• Obtain the selected hardware and record exact part revisions.
• Bring up the UNO Q and a minimal Arduino Bridge button/indicator exchange.
• Validate the display, haptics and physical control inputs.
• Validate Plan A multimedia hardware or activate Plan B for software bring-up.
• Establish current, thermal and representative runtime baselines.
• Complete the Fusion Electronics schematic and PCB layout, then run ERC and DRC.
• Replace or revise provisional CAD geometry using official or measured components.
• Run section, interference, tolerance and design-for-manufacture reviews.
• Order the PCBWay PCB and enclosure, document the first fit and revise the design.
• Port the bounded capture–inspect–recall workflow and test failure behaviour.
• Publish assembly instructions, source files, measured results, prototype photographs and a working demonstration video.
• Review every contest requirement and submit before the official deadline.

Measurable acceptance plan

No result is reported until it has been measured on the assembled UNO Q prototype.

Test: Activation acknowledgement

• Provisional acceptance target: Visible and haptic acknowledgement recorded in every trial
• Method: Run and time 20 activation trials; publish latency distribution
• Result: Pending

Test: Physical stop under Linux load

For long-term maintainability, document baseline measurements such as response time, stability under transitions, and recovery after temporary faults. Using this measurement-driven physical optimization style gives you a scalable test upgrade path without turning the project into a fragile one-off demo.

• Provisional acceptance target: Stop input recognised in every trial without waiting for the busy Linux task to finish
• Method: Run 20 trials while deliberately loading Linux; record Bridge and MCU timestamps
• Result: Pending

Test: Physical microphone disconnect

• Provisional acceptance target: No usable microphone signal reaches the capture path while disconnected
• Method: Compare recorded levels in connected and disconnected states; document the test setup
• Result: Pending

Test: Camera shutter

• Provisional acceptance target: Lens is physically obscured in the closed position and camera use is presented as unavailable
• Method: Inspect the optical path and repeat capture attempts in open and closed positions
• Result: Pending

Test: Bounded recent memory

• Provisional acceptance target: No more than 20 completed text exchanges survive; the oldest is removed when the limit is exceeded
• Method: Store more than 20 exchanges, restart and inspect the persisted sequence
• Result: Pending

Test: Owner-controlled erase

• Provisional acceptance target: No stored conversation turns return through the application after erase and restart
• Method: Populate memory, erase it, restart and inspect the persisted store
• Result: Pending

Test: Offline behaviour

• Provisional acceptance target: Every tested connected action reports a clear unavailable state and does not fabricate a provider result
• Method: Disable networking and repeat voice, vision and recall-related cases
• Result: Pending

Test: Camera workflow

• Provisional acceptance target: One deliberate capture produces the expected state sequence and a documented response
• Method: Record timestamps, screen states and returned result for repeated trials
• Result: Pending

Test: Power

• Provisional acceptance target: Idle and peak input current are measured and published
• Method: Measure at the UNO Q input during defined idle, voice and camera workloads
• Result: Pending

Test: Thermal behaviour

• Provisional acceptance target: Surface temperatures under a documented workload are measured and published
• Method: Record ambient conditions, workload, run time and measurement locations
• Result: Pending

Test: Portable runtime

• Provisional acceptance target: Representative runtime is measured with the exact selected commercial power bank
• Method: Repeat a documented usage cycle until shutdown or the chosen endpoint
• Result: Pending

Test: Display and audio usability

• Provisional acceptance target: Results are published for defined workshop lighting, viewing and background-noise conditions
• Method: Record the conditions and test legibility, feedback recognition and speech intelligibility
• Result: Pending

Numerical performance thresholds that depend on the real hardware baseline will be added before final validation. Recording a value will not by itself make it acceptable; the final story will explain the threshold and whether each test passed.

Autodesk Fusion and manufacturing work

The application-stage .f3d contains a two-piece shell, provisional shutter plate, UNO Q datum envelope, candidate peripheral placeholders, openings, fastener towers, lid rim and a reserved 15 × 20 mm side-bay envelope for the planned control/display PCB. The 115 × 75 × 28 mm body is a packaging target, not a verified final fit.

`.f3d` The current dataset has not yet passed a documented section, interference, tolerance or design-for-manufacture review. Before the enclosure is ordered, the Fusion work will add or verify:

• official UNO Q and, if used, Media Carrier reference geometry;
• measured or manufacturer geometry for the selected display, camera, speaker, controls and connectors;
• a section through the electronics stack and USB-C access;
• interference results and a critical-clearance register;
• an exploded assembly view and service path;
• shutter open and closed states, retention and lens coverage;
• dimensioned drawings, process call-outs and revision identifiers;
• antenna, speaker-magnet and thermal keep-out geometry; and
• a Rev-A-to-Rev-B record showing how physical fit evidence changed the design.

Fusion Electronics will be used for the original low-speed control/display PCB. Planned schematic sheets cover connectors and power, display and backlight, buttons and privacy, haptics and status, and test points. The final project will publish the schematic, board layout, manufacturing outputs, ERC/DRC status and any approved exceptions.

AI-generated design inspiration only. This is not a Fusion render or prototype photograph. Screen size, component placement, dimensions, ports and enclosure details are illustrative; the verified Fusion design and manufactured prototype will take precedence.

Software boundary and connected services

An existing Aida codebase separates conversational memory, voice notes, translation, reminders, camera actions and service adapters. It currently targets a Raspberry Pi Zero 2 W with a PiSugar Whisplay HAT. That code provides a starting structure, but its GPIO, display, audio, camera and power integrations are not assumed to work on the UNO Q.

The contest implementation will add a separate UNO Q hardware layer and an Arduino sketch. Shared feature logic will be reused only where tests show that it is platform-independent; the Pi/Whisplay build remains a separate target.

The intended service boundary is:

• local or physical activation begins the interaction;
• the STM32 owns physical control sensing, acknowledgement and status outputs;
• the Linux application owns the bounded text store and orchestration;
• advanced speech recognition, translation, vision explanation and reasoning may use connected providers; and
• the interface identifies when a requested action needs a network connection.

The device is not being presented as a fully offline assistant. The final documentation will list each external service, configuration requirement, operating cost and data path actually used. Raw command audio will not be included in the bounded conversation-history store; any temporary or provider-side handling will be documented according to the implemented service path.

Privacy, accessibility and evidence limits

The interface is intended to work through more than speech alone. A high-contrast display, vibration patterns and physical controls provide alternative ways to acknowledge or interrupt an interaction. Accessibility claims will be limited to the behaviours actually tested and documented; a control being present does not prove that it is accessible to every user.

Project photographs and video will distinguish clearly between CAD, AI-generated inspiration, bench prototypes and the final assembled build. Measurements will state their equipment, conditions and sample count. Candidate parts will remain labelled as candidates until their electrical, software and mechanical compatibility is demonstrated.

The source release and overall project licence have not yet been selected. Before final submission, every third-party code, image, model and dataset used in the entry will be checked for permission, licence and required attribution. No licence is implied by the public availability of these application-stage files.

References

• Build the Autodesk University 2027 Product — contest overview
• Official contest rules, requirements and dates
• Contest FAQ and judging criteria
• Arduino UNO Q hardware documentation and CAD resources
• Arduino UNO Q 4 GB product page
• Arduino UNO Media Carrier documentation
• Arduino UNO Media Carrier product page
• Raspberry Pi Camera Module 2 specification
• Adafruit 1.69-inch ST7789 display, product 5206
• Adafruit DRV2605L haptic controller, product 2305

These sources describe contest requirements and component capabilities. They do not prove that the proposed assembly works. All project-specific compatibility and performance remain to be demonstrated on the completed hardware.