Article technique

Concevoir EchoNav: une aide a la perception proche pour personnes malvoyantes

EchoNav explore une approche complementaire a la navigation classique: utiliser les capteurs de l'iPhone pour aider l'utilisateur a comprendre les obstacles proches, sans remplacer la canne blanche, le chien guide ou les outils d'assistance deja utilises.

EchoNav Conception produit et technique Juillet 2026

Beaucoup d'applications de navigation repondent a une question de trajet: quel itineraire prendre, ou tourner, combien de metres avant le prochain croisement. EchoNav se concentre sur une autre question, plus immediate: que se passe-t-il dans les quelques metres autour de l'utilisateur ?

Pour une personne aveugle ou malvoyante, cette couche de perception courte distance peut etre importante dans un environnement urbain changeant: poteaux, travaux, velos, trottinettes, pietons, vehicules ou obstacles temporaires. L'objectif d'EchoNav est de tester si un iPhone equipe de capteurs adaptes peut produire une information courte, localisee et exploitable.

Architecture generale

Le prototype est construit comme une chaine de traitement locale. Chaque couche a un role limite: percevoir, filtrer, prioriser, puis restituer une alerte simple.

1 Capteurs

LiDAR, camera et mouvement de l'iPhone.

2 Perception

Scene depth, detection d'objets et estimation de distance.

3 Decision

Selection du danger proche le plus pertinent.

4 Feedback

Son spatial, alerte vocale courte ou vibration.

Pourquoi une logique deterministe ?

Dans une application d'assistance, une alerte doit etre explicable. EchoNav evite donc de generer des phrases libres ou des recommandations longues. Le moteur de decision conserve un vocabulaire court et des regles defensibles: distance, direction, type d'objet, stabilite de la detection et pertinence du danger.

if obstacle.distance < safetyRange
  score = proximity + directionRisk + objectPriority
  keep highest score
  emit short feedback
else
  stay silent

Cette approche a une consequence importante: le silence est aussi une decision. Si l'information est trop incertaine, ou si elle risque de saturer l'utilisateur, l'application doit limiter l'alerte plutot que produire un flux permanent.

Perception courte distance

La beta se concentre sur une zone proche, typiquement quelques metres autour de l'utilisateur. Cette limite rend le probleme plus concret: il ne s'agit pas encore de remplacer un GPS longue distance, mais d'evaluer si le systeme peut signaler un obstacle ou une situation proche de maniere utile.

Le LiDAR aide a comprendre la profondeur de la scene. La camera et les modeles de detection completent cette information en identifiant certains objets urbains. L'enjeu n'est pas seulement de detecter, mais de choisir ce qui merite vraiment une alerte.

Feedback accessible

Une bonne detection n'est utile que si le retour utilisateur est comprehensible. EchoNav teste trois formes de feedback: un son spatial pour indiquer une direction, une phrase courte pour nommer un danger, et une vibration lorsque la proximite demande une attention plus forte.

La priorite est de reduire la charge cognitive. Le prototype privilegie donc des signaux courts et coherents plutot qu'une description complete de la scene.

Une beta responsable

EchoNav est pense comme un projet a tester avec la communaute, pas comme une promesse de securite absolue. Les premiers retours servent a comprendre les vrais cas d'usage, les limites acceptables et les situations ou l'application doit rester prudente.

Tests terrain

Observer la stabilite du pipeline et la coherence des alertes dans des scenes urbaines simples.

Mode debug

Afficher les objets detectes, la distance et la decision pour faciliter la revue technique.

Replay de scenes

Rejouer des situations deja capturees pour verifier une correction sans recreer le meme contexte.

Ce que nous cherchons a valider

Les objets proches les plus importants a signaler en priorite.
Le niveau de detail acceptable dans une alerte audio.
Les situations ou l'application doit rester silencieuse.
La facon dont les personnes malvoyantes veulent tester une beta.
Les partenariats utiles avec associations, experts accessibilite et beta testers.

La prochaine etape consiste a multiplier les retours externes: personnes concernees, experts accessibilite, associations, formateurs iOS/VoiceOver et partenaires techniques. Ces retours doivent permettre de distinguer ce qui est techniquement impressionnant de ce qui est vraiment utile.

Technical article

Designing EchoNav: short-range perception support for blind and low-vision users

EchoNav explores a complementary approach to navigation: using iPhone sensors to help users understand nearby obstacles without replacing a white cane, a guide dog, or the assistive tools they already rely on.

EchoNav Product and technical design July 2026

Most navigation apps answer route-level questions: which path to take, where to turn, or how many meters remain before the next crossing. EchoNav focuses on a more immediate question: what is happening within the few meters around the user?

For blind and low-vision people, this short-range perception layer can matter in a changing urban environment: poles, roadworks, bicycles, scooters, pedestrians, vehicles or temporary obstacles. EchoNav aims to test whether an iPhone equipped with suitable sensors can provide information that is short, localized and actionable.

General architecture

The prototype is built as a local processing pipeline. Each layer has a limited role: sense, filter, prioritize, then return a simple alert.

1 Sensors

LiDAR, camera and iPhone motion data.

2 Perception

Scene depth, object detection and distance estimation.

3 Decision

Select the most relevant nearby risk.

4 Feedback

Spatial sound, short voice alert or vibration.

Why a deterministic logic?

In an assistive application, an alert must be explainable. EchoNav therefore avoids generating open-ended text or long recommendations. The decision engine keeps a short vocabulary and defensible rules: distance, direction, object type, detection stability and risk relevance.

if obstacle.distance < safetyRange
  score = proximity + directionRisk + objectPriority
  keep highest score
  emit short feedback
else
  stay silent

This approach has an important consequence: silence is also a decision. If the information is too uncertain, or if it risks overwhelming the user, the application should limit alerts rather than produce a constant stream.

Short-range perception

The beta focuses on a nearby zone, typically a few meters around the user. This limit makes the problem more concrete: the goal is not yet to replace long-distance GPS, but to evaluate whether the system can report a nearby obstacle or situation in a useful way.

LiDAR helps understand scene depth. The camera and detection models complement this information by identifying certain urban objects. The challenge is not only to detect, but to choose what truly deserves an alert.

Accessible feedback

Good detection is only useful if the feedback is understandable. EchoNav tests three forms of feedback: spatial sound to indicate direction, a short phrase to name a risk, and vibration when proximity requires stronger attention.

The priority is to reduce cognitive load. The prototype therefore favors short, consistent signals over a full description of the scene.

A responsible beta

EchoNav is designed as a project to be tested with the community, not as a promise of absolute safety. Early feedback helps understand real use cases, acceptable limits and situations where the application should remain cautious.

Field tests

Observe pipeline stability and alert consistency in simple urban scenes.

Debug mode

Display detected objects, distance and the decision to make technical review easier.

Scene replay

Replay already captured situations to verify a correction without recreating the same context.

What we want to validate

The nearby objects that should be reported first.
The acceptable level of detail in an audio alert.
The situations where the application should remain silent.
How low-vision users want to test a beta.
Useful partnerships with associations, accessibility experts and beta testers.

The next step is to increase external feedback: people directly concerned, accessibility experts, associations, iOS/VoiceOver trainers and technical partners. These returns should help separate what is technically impressive from what is actually useful.