Ce que nous avons livré — et la suite pour R+D

Salut tout le monde,

Je suis resté assez discret ces derniers temps, mais ce n’est pas parce qu’il ne se passait rien. J’ai consacré la majeure partie des deux derniers mois à reconstruire certains des aspects les moins glamour — et les plus importants — de R+D : la documentation, les outils de navigateur, les versions de firmware, la récupération après mise à jour et la couche de communication partagée par nos appareils.

La direction devient de plus en plus claire. Je veux que nos produits restent ouverts et hackables tout en devenant nettement plus faciles et plus fiables pour les personnes qui veulent simplement les utiliser. Ces objectifs ne sont pas incompatibles. De meilleures fondations communes nous permettent de prendre en charge les deux.

Voici ce qui est disponible maintenant, ce qui est encore en cours de test et pourquoi je pense que cela compte.

Disponible maintenant

Une documentation que nous pouvons garder gratuite et améliorer

Nos guides utilisateur, notre documentation pour développeurs et nos guides d’assemblage OHAI sont désormais hébergés sur une stack Fumadocs que nous contrôlons.

L’ancienne plateforme de documentation était devenue beaucoup trop coûteuse et rendait les modifications ordinaires plus difficiles qu’elles ne devaient l’être. La nouvelle configuration est plus rapide, garde la documentation accessible gratuitement et stocke la véritable source dans Git au lieu de l’enfouir dans un éditeur propriétaire. Elle nous laisse aussi la place pour des guides écrits par des humains, des corrections directes de la communauté, des outils interactifs et un contenu d’assemblage plus riche.

Les guides OHAI ont retrouvé leur mise en page centrée sur l’assemblage, avec des photos, des nomenclatures, des légendes et des vues interactives des cartes KiCad. Ce n’est pas seulement une migration visuelle : c’est une meilleure base pour documenter la manière dont les machines sont réellement construites, réparées et modifiées.

Vous pouvez maintenant consulter les guides utilisateur, la documentation pour développeurs et le guide d’assemblage OSSM.

Les outils de navigateur OSSM sont de retour

Le contrôleur BLE OSSM est à nouveau disponible pour contrôler directement l’appareil depuis un navigateur de bureau compatible.

Le lecteur Funscript OSSM est également de retour en tant qu’outil expérimental. Il peut lire une vidéo locale et un Funscript ensemble via Web Bluetooth sans téléverser aucun des deux fichiers ; ils restent dans votre navigateur.

Les outils de firmware dans le navigateur sont à nouveau disponibles pour OSSM, DTT, Lockbox et RADR. Ils servent à installer ou à restaurer le firmware officiel depuis un navigateur de bureau lorsque le guide concerné ou le parcours d’assistance vous le demande.

Un travail discret sur la fiabilité de chaque appareil

Une grande partie du travail récent est volontairement peu spectaculaire. La publication du firmware pour OSSM, RADR, DTT et Lockbox bénéficie désormais d’une validation plus stricte, d’artefacts de version immuables, d’une attribution des versions plus prévisible et d’un comportement de récupération plus sûr. Cela réduit le risque qu’un appareil se voie proposer la mauvaise version ou tente sans cesse d’installer la même mise à jour.

Il y a également eu de plus petites corrections propres à chaque produit. OSSM a reçu des corrections pour la dérive et les déclenchements répétés de la butée arrière lors des sessions BLE. DTT peut conserver les résultats d’entraînement terminés lorsqu’un téléversement échoue et dispose maintenant d’un chemin de migration plus sûr pour les anciennes cartes de contrôle. Lockbox a reçu des corrections de stabilité de l’affichage et de gestion des pauses. RADR dispose d’une chaîne de versions plus fiable, ainsi que de fichiers CAO publics pour son couvercle de batterie.

Ces changements ne produisent pas de vidéos de démonstration spectaculaires, mais ils rendent moins fragile tout ce qui en dépend.

rad-ble est public

J’ai publié rad-ble v1.0.0 comme bibliothèque ESP32 publique et versionnée, ainsi que comme protocole public et versionné.

L’objectif est de donner à nos appareils un langage commun pour les contrôles, la télémétrie, les ressources, les entrées diffusées en continu, les sorties et les mises à jour du firmware. Les développeurs ne devraient pas avoir à redécouvrir un ensemble de conventions complètement différent pour chaque produit R+D.

La bibliothèque elle-même est disponible dès maintenant. Ses intégrations firmware passent par la phase de staging pour OSSM, RADR, DTT et Lockbox ; je ne veux donc pas encore décrire toute la famille de produits comme migrée.

Ce sur quoi je travaille ensuite

Un streaming OSSM plus fluide et plus sûr

Le principal chantier actif est une mise à jour majeure du streaming BLE d’OSSM.

Aujourd’hui, un flux de positions entrantes peut présenter un timing irrégulier, des sauts soudains, des paquets retardés ou un arriéré qui n’est plus pertinent. Une machine ne devrait pas reproduire aveuglément ces entrées.

Le nouveau planificateur traite le flux comme une trajectoire temporisée. Il limite les à-coups et l’accélération, abandonne l’arriéré obsolète, améliore la mise en tampon et le timing de connexion, et maintient les cibles dans des limites de déplacement protégées. Il peut appliquer un retour progressif vers la zone sûre lorsque l’entrée disparaît, puis réinitialiser proprement son état de mouvement lorsque la lecture s’arrête. La branche ajoute également des métriques de charge et des outils de validation matérielle afin que le comportement puisse être mesuré plutôt que deviné.

Cette fonctionnalité est encore en cours d’examen et de test sur matériel. C’est le principal sujet sur lequel j’aimerais que les propriétaires d’OSSM et les développeurs techniquement curieux nous aident à mettre le système à l’épreuve.

Une couche de contrôle ouverte pour toute la famille de produits

Le même contrat BLE v1 est également intégré à RADR, DTT et Lockbox. Cela ne signifie pas qu’il faut imposer une interface identique à chaque produit. Cela signifie utiliser des conventions communes pour la découverte, l’identité, la télémétrie et les mises à jour, tandis que chaque appareil expose les capacités qui ont du sens pour lui.

RADR est particulièrement utile ici : c’est à la fois un produit et un contrôleur ouvert et configurable, qui bénéficie donc directement de ressources plus claires et de contrôles en direct plus riches.

Un firmware vérifiable sans exclure les utilisateurs

J’ajoute également une provenance signée du firmware. Les versions officielles contiendront une preuve cryptographique de leur origine, et les outils pourront afficher cette preuve.

Il ne s’agit ni de Secure Boot, ni de chiffrement de la mémoire flash, ni d’un projet visant à bloquer le firmware de la communauté. Les propriétaires et les makers pourront toujours compiler et flasher leur propre code. La provenance sert à rendre l’origine visible, pas à transformer le matériel ouvert en appareil verrouillé.

Du côté développeur, je nettoie également les API de planification et de session de DTT, j’ajoute des webhooks de fin d’exécution et je corrige le comportement de durée de l’API Lockbox afin que les ajustements gagnés soient conservés. Ces changements sont encore en cours d’examen.

La direction générale

La version utile de l’« ouverture » ne consiste pas simplement à mettre le code source sur GitHub. Il s’agit de fournir aux utilisateurs des protocoles compréhensibles, des outils fonctionnels, du matériel réparable, une documentation qui peut être corrigée et une manière sûre d’expérimenter.

En même temps, l’ouverture ne peut pas servir d’excuse à des versions peu fiables ou à des mouvements dangereux. Je veux que l’expérience normale devienne plus calme et plus prévisible, tandis que les possibilités avancées deviennent plus configurables.

Cela signifie davantage de fondations open source partagées, davantage d’outils dans le navigateur lorsque c’est pertinent, de meilleurs tests par étapes et une documentation traitée comme une partie du produit plutôt que comme un ajout secondaire.

Si vous voulez aider, essayez les outils OSSM, examinez rad-ble ou passez en revue le travail sur le streaming OSSM. Les bugs, les cas limites étranges, les corrections de documentation et les désaccords réfléchis sont tous utiles.

Merci de continuer à construire tout cela avec moi.

— AJ