Designing Atari Eyes for Non-Visual Navigation
Navigation tools for blind and low-vision people should not assume that the answer is simply to reproduce vision.
Atari Eyes begins with a different question:
Can information about nearby space be translated into signals a person can understand and choose to use without depending on a visual display?
The project explores non-visual navigation using sensing, controlled feedback and careful human testing. It remains an early research and prototype program, not a finished mobility aid.
Non-visual information, not artificial sight
Atari Eyes is not presented as a cure for blindness or a replacement for human vision.
The intended research direction is narrower: detect selected environmental conditions and translate them into understandable non-visual cues.
Possible inputs may include:
- Distance and relative movement
- Direction of a nearby obstacle
- Surface or pathway changes
- Temperature differences
- Motion around the user
- Known location markers in a controlled setting
Possible outputs may include:
- Directional vibration
- Distinct vibration patterns
- Simple tones
- Spoken descriptions
- Other feedback selected through user research
The system should communicate only what its sensors and tested logic can support.
Why feedback design matters
More signals do not automatically create better navigation.
A device that constantly vibrates, speaks or changes patterns may overload the user and compete with environmental sound, a cane, a guide dog or another mobility strategy.
Atari Eyes therefore needs to test:
- Which information is actually useful
- How quickly a signal can be understood
- Whether signals are distinguishable under stress
- Whether repeated feedback becomes tiring
- Whether warnings arrive early enough to support a decision
- Whether the user can silence or change the feedback
- Whether the system communicates uncertainty clearly
The user must remain in control of the device.
A separate safety case
Atari Eyes is related to the wider Mahlis mission, but it remains separate from the Vitalis healthcare core.
It requires its own:
- Intended-use statement
- User and environment definitions
- Hazard analysis
- Prototype versions
- Verification tests
- Usability studies
- Failure-response rules
- Release decisions
It must not be quietly merged into another product merely because the technical components can communicate.
The role of human testing
An assistive-navigation system cannot be designed responsibly from engineering assumptions alone.
Blind and low-vision participants must help determine whether the problem definition, physical design, signals and testing methods reflect real experience. Participation must use clear study information, appropriate consent, minimal data collection and a meaningful withdrawal process.
The research should ask participants what is useful rather than measuring success only by whether the prototype behaves as its builders expected.
Building the first prototype carefully
An early controlled prototype can focus on a small number of measurable tasks.
For example, a prototype may test whether a person can distinguish:
- An object approaching from the left or right
- A near obstacle from a distant obstacle
- A normal signal from a device-fault signal
- A confirmed reading from an uncertain reading
Initial tests should occur in controlled environments with supervision, defined stopping rules and no claim that the prototype is ready for independent navigation.
Failure must be understandable
Sensors can be obstructed, misaligned or affected by the environment. Batteries can become low. Software can stop responding. A signal can be delayed or misunderstood.
The system must therefore communicate its own state, including:
- Starting and ready
- Sensor unavailable
- Reading uncertain
- Battery low
- Feedback muted
- Device fault
- Safe shutdown
Silence must not be allowed to mean both “nothing is nearby” and “the system has failed.”
Privacy and dignity
A navigation device may observe information about the user and surrounding people. That creates privacy responsibilities even when the system is not storing health records.
The project should minimize collection, prefer local processing where practical and avoid retaining raw environmental data without a defined reason.
The physical design should also respect dignity. A user should be able to understand what the device is doing, control its feedback and stop its operation.
What Atari Eyes does not currently claim
Atari Eyes is not currently approved as a medical device or independent mobility aid.
It does not currently claim to:
- Replace a white cane or guide dog
- Guarantee obstacle detection
- Support unsupervised street navigation
- Diagnose an eye condition
- Restore sight
- Eliminate the need for orientation and mobility training
Public progress will distinguish a concept, bench prototype, controlled human study and production-ready product.
Measuring progress with evidence
Useful progress measures may include:
- Signal-recognition accuracy
- Time required to understand a cue
- Missed or false obstacle indications
- Device-fault detection
- Battery and sensor reliability
- User-reported comfort and cognitive load
- Successful completion of controlled tasks
- Identified hazards and completed corrective actions
The purpose of measurement is not to force a positive result. It is to learn whether the proposed system is useful enough and safe enough to justify another development stage.
A human-centred research direction
Atari Eyes explores how sensing technology might communicate spatial information without demanding visual attention. Its success will depend less on how many sensors can be added and more on whether the resulting signals are understandable, controllable and genuinely useful.
Explore the Atari Eyes research plan or follow its evidence-gated roadmap.