At the kerb, locating the crossing and understanding the pedestrian signal can involve several clues. Cyclope explores an additional source of information: using a camera to recognise these features and describe them aloud.
We have been developing Cyclope at Blind Systems since 2024. Here is where we stand, the limits we encountered with the early prototypes and the choices shaping the next version. The project remains experimental: a visual detection is not permission to cross.
Crossing the street when blind: bringing information together
The white cane, guide dogs, mobility techniques and navigation tools address different needs. They help people build up useful information throughout a journey.
At a crossing, that includes locating the crossing itself and interpreting the signals. Tactile paving and audible pedestrian signals already provide support, as described in Cerema’s work on pedestrian crossings (in French). Cyclope investigates what a camera-based description could add.
We have chosen to focus the tests on crosswalks and pedestrian traffic lights. This gives us specific situations to examine, detection errors to record and an opportunity to work on how to communicate uncertainty to the user.
What existing solutions already do
Existing aids give us useful points of comparison for size, controls and the information they provide. Their functions and conditions of use evolve; this article is not a ranking or a comparative product test.
OrCam MyEye was among the references we considered for an accessory worn on glasses. Our design question is practical: how can we add a camera without asking someone to change their frames?
Envision Glasses offer text reading, scene descriptions and calls to a companion, depending on the edition.
eSight takes a different approach: electronic eyewear intended for people with some remaining vision.
Aira offers remote visual assistance from professionals. Be My Eyes provides access to volunteers and AI description features. These services have their own uses and limitations.
These approaches address a range of needs. For Cyclope, we are working on a specific task: reporting what the system thinks it recognises around a crossing, including uncertainty. We need to assess how useful that feedback is with blind and visually impaired people and orientation and mobility professionals.
That is where we position ourselves.
Cyclope: three generations, and two failures we own
Testing changed the direction of the project, particularly around comfort and the delay between capturing an image and producing a voice announcement.
Generation 1: the computer in the backpack
Our first prototype worked. An ESP32-CAM mounted on 3D-printed glasses streamed images over wifi to a Raspberry Pi running the detection model.
The problem was not the code: it was that the user had to carry a computer and its battery in a bag, with a cable dangling down the side of their face. The setup was too bulky for the format we were aiming for.
It was built by five engineering students at Polytech Paris-Saclay — Naïl Boukerma, Nathan Carrée, Sébastien Joseph Guna Rajan, Esteban Pustoc’h and Mathieu Sogné — co-supervised by Professor Sylvie Le Hégarat-Mascle and by Amine Khettat, founder and president of Blind Systems. Two of them, Esteban Pustoc’h and Naïl Boukerma, present the project in this video, filmed at their school. It walks through the whole architecture, from the camera to the voice feedback. The video is in French, with English subtitles available.
The Cyclope project presented by the first-generation team at Polytech Paris-Saclay. Filmed by the video club of the Maison de l’Ingénieur, whom we thank.
Generation 2: the intelligence moved to the cloud
We got rid of the bag. Board and battery moved into a compartment built into the glasses, and image analysis moved to a remote AI service, reached through the user’s phone.
The device was lighter, but recognition now depended on a paid API and on the network, with several seconds of latency. We could describe a scene. We could not warn in time.
Generation 3: computation moves back into the pocket
The current design aims to run detection locally on the smartphone, without calling a remote API. Address lookup and route computation would remain separate services. Performance, power consumption and phone compatibility still need to be evaluated.
On the hardware side, we have stopped making glasses. Three runs of 3D-printed frames taught us that you do not replace the pair someone has chosen. Cyclope is now a small module that clips onto the temples of your own glasses.
The common thread is to move computation closer to the user and limit recurring costs. The hardware, phone, maintenance and any navigation services still have a cost.
How it works, concretely
The proposed architecture connects the camera to the phone over a local wifi network. A computer-vision model from the YOLO family analyses images for crosswalks and pedestrian lights. Voice feedback needs to distinguish a detection, uncertainty and no result. Recognising a colour alone cannot establish that it is safe to cross.
Another work package covers pedestrian navigation: receiving a spoken address, calculating a route and providing voice guidance. It uses OpenStreetMap data. Open data supports reuse, but it does not remove hosting and service-access requirements.
We are also exploring support for map contributions. A detection could suggest a crossing to check before a possible OpenStreetMap update. An accessible review process, position checks and duplicate detection still need to be designed in line with the project’s contribution rules.
Why we build it in the open
The project is public, under the Apache 2.0 licence. Everything lives in a single GitHub repository — the vision code, the mobile application, the camera firmware, the 3D design files and the documentation:
You will also find the complete history of all three generations there, including the code of the prototypes we abandoned. We did not erase it: knowing what did not work is part of what an open project should pass on.
Publishing the source lets others understand the design choices, fix defects and adapt the work to their needs. Testing and maintenance are still necessary, but open access makes the work easier to pick up.
It also means the project moves forward with whoever wants to contribute: embedded-systems students work on it every year as part of supervised projects, and each cohort picks up where the previous one left off.
Where we stand
Crossing the street when blind is a problem we have not finished solving. Cyclope is a project under development, not a product for sale. We promise no date: we publish what we build, generation after generation.
The current version covers four work packages — the electronics of the clip-on module, the embedded firmware, on-device detection, and pedestrian navigation. We will document each of them here as we go.
Want to know who we are? Our approach is described on the About Us page, and you can reach us through the contact page.
Crossing the street when blind: frequently asked questions
Is Cyclope for sale?
No. It is an ongoing research and development project. We will share its progress publicly, without announcing a commercial date until one is certain.
Does Cyclope replace the white cane?
No. The project aims to provide additional information; it does not replace a cane, a guide dog or mobility techniques. A prototype announcement must not be treated as a signal that it is safe to cross.
Is an internet connection required?
The design aims to run visual detection locally on the phone. The planned address lookup and route calculation require a data connection. These functions remain under development.
How is Cyclope different from other visual aids?
Cyclope focuses its tests on recognising crosswalks and pedestrian lights, then communicating that information. Its value and limitations need to be evaluated in practice; we do not claim that it outperforms existing tools.
Can I contribute?
Yes, and in several ways that do not all require writing code. See the section below.
How to contribute
Cyclope moves forward thanks to people who do not all share the same job. Here is what we actually need, from the most useful to the most technical.
Tell us whether it holds up. This is what we lack most. If you are visually impaired, an orientation and mobility instructor or an occupational therapist, your reading of our choices is worth more than any line of code. Is a module on the temple of your glasses acceptable day to day? At what point does a voice announcement at the kerb become a nuisance rather than a help?
Images. Our model learns to recognise crosswalks and pedestrian traffic lights. It needs photographs taken at pedestrian height, in varied conditions: rain, backlight, faded markings, a light half hidden by a pole. We are particularly interested in improving coverage of situations encountered in France.
Code. Four work packages are open: the electronics and its enclosure, the ESP32 firmware, on-device detection, and pedestrian navigation. They are independent of each other and documented in the repository.
Mapping. You can contribute to OpenStreetMap by checking crossings in your neighbourhood and following the community’s guidance. Cyclope’s integrated contribution feature is still to be developed.
To get started, open an issue on the repository, or write to us at contact@blindsystems.org. Field feedback matters to us as much as pull requests.
One honest caveat: Cyclope is a research project run with student cohorts, not full-time maintained software. We welcome contributions seriously, but we do not promise a response time.