Ce qu’un fabricant de robots de livraison peut vendre à une flotte de chantier

Un robot de livraison s’arrête quand une rampe temporaire modifie le passage qu’il attendait au bord du trottoir. Un engin de chantier s’arrête quand du gravier frais change le sol près d’une zone de travail balisée. Les machines ont des tâches différentes et une réaction sûre dans un cas peut être inutile dans l’autre. Leurs opérateurs ont un problème commun. Ils doivent savoir ce que la machine a vu, ce qu’elle a décidé et si ce moment fait partie des rares événements à transmettre à l’équipe d’ingénierie.

Serve Robotics, qui exploite des robots de livraison sur les trottoirs, a lancé Physical AI Services le 5 novembre 2026. L’offre comporte trois volets selon l’entreprise. Serve Link relie les machines à des systèmes externes. Serve Data Curator aide les équipes à repérer les événements utiles dans les données de flotte. Un catalogue de données d’entraînement provient des opérations de Serve sur les trottoirs. L’annonce cite Bedrock Robotics, qui développe l’autonomie pour des engins de chantier lourds, comme premier client de Serve Link. C’est un cas concret de connectivité dans le BTP. L’utilité des images de trottoir pour entraîner un modèle de chantier demande un essai distinct. Annonce de Serve

L’offre aide à voir ce qu’une flotte peut reprendre d’une autre. Le logiciel qui transporte les enregistrements, les filtres qui permettent de les retrouver et les données elles-mêmes ont des usages différents. Les distinguer facilite l’évaluation du produit.

Robot de livraison Serve Robotics à Los Angeles, mai 2026. Photo de The Squirrel Game, redimensionnée et placée sur un fond neutre, CC BY 4.0. Source de l’image · Licence.

La connexion peut se transférer avant les données d’entraînement

Selon Serve, Bedrock utilise Serve Link pour connecter ses machines via Wi-Fi, LTE, 5G et satellite. Un engin de chantier peut traverser des zones de couverture très différente pendant une même journée. La liste indique quelles liaisons font partie du déploiement annoncé. Un essai sur site doit encore établir ce qui se passe dans une zone blanche connue, quel débit reste lorsque plusieurs engins envoient des données à la fois et comment l’application se comporte lors d’un changement de réseau. Annonce de Serve

Distinguez d’abord trois flux. Une vérification d’état peut être courte et fréquente. Un extrait d’événement peut arriver plus tard s’il garde son horodatage d’origine. Une fonction de conduite des opérations en direct peut exiger un délai bien plus serré. Attribuez à chaque flux une priorité, un délai attendu et un comportement défini en cas de panne. Testez le passage d’une liaison intermittente à une liaison fonctionnelle. Un tableau de bord qui indique que l’engin est en ligne aide peu si les données nécessaires pour expliquer l’arrêt de la veille ne sont jamais arrivées.

La connexion permet aussi de demander quelles décisions restent à la machine. Pendant le pilote, l’équipe du site définit son comportement en cas de perte du service distant. Examinez la séquence avec les ingénieurs chargés de la sécurité, d’abord sur un enregistrement ou un montage isolé. Un envoi de données d’entraînement peut attendre le rétablissement de la liaison. Une contrainte de mouvement relève de la conception de sécurité de la machine. L’annonce établit l’existence du service et d’un client nommé. Chaque flotte doit établir le comportement de sa propre intégration. Serve Physical AI Services

Serve regroupe connexion, sélection d’événements et catalogue de données. L’exemple de chantier cité concerne un déploiement de Serve Link. Illustration originale de Telli.sh.

Un événement rare est utile lorsque l’équipe peut le retrouver

Les données deviennent coûteuses à examiner lorsque chaque machine enregistre des heures de travail ordinaire. Avec 30 machines et huit heures par jour chacune, on atteint 240 heures de vidéo avant d’ajouter une deuxième caméra ou un autre flux de capteur. Pour expliquer un arrêt inhabituel, il faut retrouver les bonnes secondes dans ce volume. Serve décrit Data Curator comme un outil qui fait ressortir les événements utiles à l’entraînement dans ces données de terrain. Annonce de Serve

Une première tâche consiste à trouver des arrêts inattendus près d’un changement de surface. L’opérateur peut utiliser un marqueur ou un signal simple, comme une vitesse qui tombe à zéro, puis l’associer à un extrait et à l’état de l’engin avant et après. Ces règles sont des exemples indépendants des filtres d’un produit précis. Gardez assez de contexte pour distinguer un arrêt prévu d’une perte d’adhérence, d’un obstacle ou d’une pause de protection.

Une deuxième tâche consiste à chercher des événements similaires qui ont abouti à des décisions différentes. Un sol irrégulier peut déclencher un arrêt sur un site et être franchi sur un autre parce que les charges ou les limites diffèrent. Deux images semblables ne suffisent pas. Conservez avec l’événement le type de véhicule, les conditions du site, la version des règles et les interventions humaines. Cela aide à décider s’il faut modifier un filtre, ajouter un exemple d’entraînement ou examiner un capteur.

Une troisième tâche consiste à garder des cas faciles et connus pour comparaison. Une file composée seulement d’arrêts inhabituels aide à enquêter sur les échecs. Elle peut induire en erreur une équipe qui cherche leur fréquence. Consignez la manière dont les exemples sont entrés dans la file et gardez un échantillon de référence séparé pour mesurer les taux. Si le modèle progresse sur les cas sélectionnés tout en interrompant davantage le travail ordinaire, la référence aide à repérer le compromis.

La sélection se prête à un essai concret. Donnez à deux personnes la même définition de l’événement pertinent et demandez-leur d’annoter séparément un petit ensemble représentatif d’enregistrements. Comparez les résultats de l’outil à cette référence. Comptez les événements pertinents trouvés, les cas non pertinents à ouvrir et ceux dont les preuves ne permettent pas de conclure. L’outil peut réduire le temps nécessaire pour obtenir un exemple exploitable avant même que l’équipe utilise un clip pour l’entraînement.

Les données de trottoir ont de la valeur lorsque leurs limites sont visibles

Le troisième produit est un catalogue provenant des opérations de Serve sur les trottoirs. L’annonce décrit des données de terrain et d’infrastructure réelles. Un acheteur qui développe un autre robot de trottoir peut s’intéresser aux formes de bordures et aux barrières temporaires. Pour les engins de chantier, les capteurs, la hauteur des caméras, les vitesses et les contraintes diffèrent. Un trottoir pavé donne des exemples d’objets et d’éclairage à une équipe de perception. Il renseigne peu sur le comportement d’un véhicule lourd en charge sur un sol meuble. Annonce de Serve

Demandez ce que contient réellement un échantillon. Un modèle peut se satisfaire d’images horodatées. Un autre projet peut avoir besoin de paramètres intrinsèques calibrés, de mouvements synchronisés ou d’une indication de la manière dont les annotations ont été vérifiées. Ces questions relèvent de l’essai de l’acheteur. L’annonce établit l’origine et le sujet général du catalogue. Chaque acheteur doit examiner si un échantillon contient les champs dont il a besoin.

Les données de terrain ont aussi une limite de droits. Les images de trottoir ou de chantier peuvent contenir des visages, enseignes, plaques et détails d’installations. L’acheteur doit vérifier les usages autorisés, les clauses géographiques, les règles de conservation et la procédure de suppression du produit. Les données de diagnostic peuvent avoir d’autres conditions que les données d’entraînement. Garder la source précise, les conditions de collecte et les droits contractuels facilite le traitement d’une demande de suppression ou d’un problème de qualité.

Comparer le même incident avant de connecter toute une flotte

Le pilote peut mesurer séparément récupération, examen et évaluation du modèle sur la même classe d’incidents. Illustration originale de Telli.sh.

1. Nommer la décision à améliorer. Choisissez un type de véhicule, un site et une classe d’événements. Une équipe peut vouloir un relevé fiable lorsqu’une machine s’arrête près d’un changement de surface. Définissez les éléments qui rendent le relevé exploitable.
2. Établir la référence avec des enregistrements connus. Comptez les événements exploitables, le volume examiné et le temps de recherche. Distinguez un enregistrement indisponible d’un enregistrement que l’opérateur aurait pu trouver.
3. Tester la connexion sur un rejeu limité. Utilisez un appareil de test ou un environnement isolé. Consignez la complétude et les délais avec une liaison normale ou interrompue. Vérifiez les envois répétés, la stabilité de l’identité et les horodatages.
4. Comparer une file sélectionnée à l’échantillon de référence. Donnez les mêmes règles aux personnes chargées d’examiner les cas et notez ce que chaque file manque. Mesurez le temps par événement utile et la possibilité de remonter à l’engin et à la version du logiciel.
5. Évaluer le modèle séparément. Si les données externes paraissent pertinentes, comparez des entraînements équivalents avec et sans elles. Évaluez sur des scénarios mis de côté dans l’environnement prévu de l’acheteur. Fixez les seuils de régression avant de voir les résultats.

Examinez le coût en plus de l’exactitude. Garder plus d’images augmente les coûts de réseau, de stockage et de relecture même lorsque la machine envoie correctement. Comparez-les à la valeur de l’exemple. Une flotte peut envoyer d’abord un court relevé et récupérer le clip complet à la demande. Pour une autre, perdre les images coûte plus cher que les garder. Cela dépend du délai d’envoi, du contrat et de la fréquence d’usage des extraits longs.

Le déploiement a besoin d’une personne responsable. Définissez qui traite les enregistrements manquants, comment l’ingénierie découvre un problème de liaison persistant et quelles données le support peut récupérer sans exposer davantage le site. Donnez à cette personne un exemple rejouable dont la réponse est connue. Lorsque le système change, la prochaine vérification dépend moins des souvenirs du pilote initial.

Le même rejeu aide lorsqu’une flotte change de prestataire, ajoute une caméra ou modifie sa durée de conservation. Gardez l’identifiant d’événement attendu et les champs utiles à son explication. Comparez-les après le changement et notez les parties qui nécessitaient un accès du fournisseur. Une équipe peut découvrir que déplacer un clip est facile, alors que ses annotations et son historique de relecture demandent un effort supplémentaire. Demandez assez tôt un exemple d’export pour vérifier que les éléments circulent ensemble. Cela comptera si un nouvel outil doit lire un incident ancien ou si l’entreprise modifie ses règles de stockage.

L’export doit pouvoir être ouvert par une deuxième équipe. Demandez à l’opérateur de choisir un événement avec une correction humaine et à une autre personne de le reconstituer depuis l’export seul. Elle doit pouvoir retrouver les heures de capture et de réception, l’horloge et les unités de chaque flux, et savoir si l’annotation décrit l’événement brut ou une interprétation ultérieure. Si l’export contient un lien plutôt que la vidéo, vérifiez qu’il reste utilisable après un changement d’accès. Ajoutez un cas où une caméra manque. Un schéma qui indique une lacune connue permet d’arrêter le rejeu de façon visible au lieu de confondre l’absence de preuve avec un parcours sans incident. Cette transmission montre aussi quelles notes de l’opérateur appartiennent au rejeu et lesquelles doivent rester dans un cercle plus restreint.

Le service fait ses preuves dans les événements que l’équipe peut expliquer

Le lancement de Serve montre comment un exploitant de robots peut vendre une partie de l’infrastructure qu’il a construite pour lui-même. Un client du BTP nommé fournit un exemple concret pour la connectivité. La sélection et les données d’entraînement demandent des preuves supplémentaires qu’un petit examen d’incidents peut réunir. Vérifiez que le même événement arrive avec assez de contexte, apparaît dans la bonne file et aide les responsables à décider de la suite pour la flotte.

Sources

• Lancement des Physical AI Services de Serve Robotics et exemple Bedrock, 5 novembre 2026
• Page produit Serve Robotics Physical AI Services
• Photo du robot de livraison à Los Angeles par The Squirrel Game

---

Pour retrouver les conversations et décisions qui ont guidé votre travail, créez un compte Telli.sh.