Dans les coulisses d’EchoNav
La proximité, traduite en informations utiles.
Comment EchoNav associe les capteurs de l’iPhone Pro à un moteur de décision déterministe pour signaler des dangers proches aux personnes aveugles ou malvoyantes.
Une information complémentaire, à courte distance
EchoNav se concentre sur les obstacles proches en ville : personnes, véhicules, vélos ou trottinettes, poteaux et surfaces pouvant former un obstacle. Le moteur travaille sur la zone observée par la caméra, avec des directions simples : devant, avant-gauche et avant-droite.
Il ne décrit pas toute la scène et ne garantit pas la détection de chaque obstacle. L’application complète la canne blanche, le chien-guide ou l’accompagnement habituel. Une absence d’alerte ne signifie jamais que le passage est libre.
Quatre étapes, une information courte
Le traitement de proximité s’effectue sur l’appareil. Le modèle Paris V1 est conservé pendant le Sprint 2 pour faire évoluer l’interface sans remplacer le moteur de perception de référence.
ARKit et le LiDAR fournissent la profondeur ; la caméra et CoreMotion complètent le contexte.
Vision et Core ML proposent une catégorie d’objet. Le moteur lui associe une profondeur lorsqu’elle est exploitable.
Des règles déterministes comparent la proximité, la direction et les informations disponibles.
Une phrase courte, un son directionnel et des vibrations apportent une information complémentaire.
Des décisions que l’on peut examiner
EchoNav n’utilise pas de modèle de langage dans la boucle critique. Les alertes reposent sur un vocabulaire fixe et une logique que l’équipe peut tester sur les mêmes entrées. Lorsque la catégorie d’un objet n’est pas exploitable, la profondeur peut alimenter une alerte d’obstacle générique.
Une mémoire spatiale limite la répétition des annonces vocales. Elle conserve des exceptions pour une aggravation du danger et des rappels. Cette réduction des répétitions porte sur la parole ; elle ne supprime pas, à elle seule, les autres retours de danger.
Le modèle reconnaît aussi des feux et des panneaux à des fins de contexte et de diagnostic. Ces détections ne donnent aucune autorisation de traverser.
Une interface centrée sur l’assistance
Le Sprint 2 ajoute un mode produit qui s’ouvre avec l’assistance arrêtée. L’utilisateur choisit de démarrer et peut arrêter la session. L’état courant reste explicite, tandis que le maillage, les boîtes de détection et la télémétrie sont masqués par défaut.
Si une dépendance critique manque, l’application ne présente pas l’assistance comme active. L’arrêt, la fermeture de la vue ou la perte des données nécessaires neutralisent les retours et réinitialisent les informations concernées. La reprise attend des données fraîches.
Des destinations conservées localement
Le parcours développé permet de créer, modifier et supprimer une destination, avec saisie au clavier et dictée optionnelle. Le clavier reste disponible si les permissions vocales sont refusées ; le nom et l’adresse sont conservés après relance.
Enregistrer une destination ne déclenche pas un guidage d’itinéraire. L’intégration MapKit et la navigation longue portée restent hors du périmètre du Sprint 2.
Développer, vérifier, puis éprouver l’usage
Les jalons 0 à 5 du Sprint 2 sont documentés comme validés techniquement. Ce statut porte sur le code et les contrôles associés ; il ne constitue ni un verdict de recette indépendant ni la publication du candidat Sprint 2 sur TestFlight.
Les contrôles couvrent notamment l’authentification locale, les états de session, le mode produit et les destinations.
Les mêmes scènes enregistrées permettent de comparer les décisions et de détecter une régression du moteur.
Les essais finaux sur l’iPhone LiDAR de référence et le candidat TestFlight restent à consigner dans la recette.
Les limites qui guident la suite
La lumière, le mouvement, les surfaces transparentes ou réfléchissantes et l’occlusion peuvent dégrader la profondeur ou l’identification d’un objet. Les preuves de relecture établissent une cohérence sur les scènes testées ; elles ne démontrent pas un taux de détection en toutes conditions.
- Finaliser les réglages, les parcours en français et en anglais et leur accessibilité.
- Vérifier l’usage réel avec VoiceOver et la compréhension des retours.
- Préparer le socle backend et le candidat TestFlight du Sprint 2.
- Documenter les résultats des essais physiques et du plan de recette indépendant.
La disponibilité d’un build Sprint 1 sur TestFlight ne signifie pas que ces évolutions du Sprint 2 y sont déjà publiées.
Comprendre le projet, suivre son évolution.
Découvrez l’approche d’EchoNav et les possibilités de prendre contact avec l’équipe.