Un capteur LiDAR matriciel pour donner la vue en relief à un petit robot
Le LiDAR, c'est cette techno qui mesure des distances en envoyant des impulsions laser et en chronométrant leur retour, un peu comme un sonar, mais avec de la lumière. On en entend parler surtout pour les voitures autonomes ou les robots aspirateurs.
Mellow Labs , une chaîne qui bidouille du hardware, s'est procuré un capteur LiDAR un peu particulier : un modèle matriciel. C'est-à-dire un capteur qui ne mesure pas une seule distance droit devant lui, mais toute une grille de points d'un coup.
Concrètement, ce capteur fonctionne comme une grille de 64 capteurs (8 sur 8) qui sort une carte des distances comprises entre 2 cm et 3,5 m. Au lieu de savoir juste "il y a un obstacle à un mètre", le robot récupère une vraie image en relief de ce qu'il a devant lui.
La différence est énorme : un capteur classique vous dit qu'il y a quelque chose, un capteur matriciel vous dit quoi, où, et à quelle hauteur. C'est tout de suite plus exploitable pour un engin qui doit se débrouiller seul, parce qu'il peut distinguer un mur d'une marche, ou un obstacle au sol d'un truc suspendu.
Mellow Labs a greffé ce capteur sur Zippy, son petit robot à chenilles imprimé en 3D et piloté par un ESP32, la puce bon marché qu'on retrouve dans la moitié des projets de bricolage électronique de la planète. L'objectif : faire passer Zippy du mode télécommandé à un vrai mode autonome. Avec sa grille de points, le robot peut enfin voir le sol devant lui et décider tout seul où aller. Enfin, en théorie.
Sauf que voilà, ça ne s'est pas fait en claquant des doigts. Premier souci, la moitié des données du capteur ne servait à rien, parce que la grille captait aussi le sol juste sous le robot. Du coup il a fallu trier, ne garder que la partie utile, et réduire encore le volume de données à traiter.
Mellow Labs a fait plusieurs allers-retours, avec, comme souvent désormais, un coup de main d'un modèle d'IA pour générer le code, avant que l'ensemble tourne enfin correctement !
Source : Hackaday
Ces fléchettes incendiaires géantes du XVIe siècle viennent enfin d'être testées
La Mary Rose, c'était le navire de guerre préféré d'Henri VIII. Il a coulé en 1545 au large de Portsmouth, son épave a été retrouvée en 1971 puis remontée en 1982, et depuis, tout ce qu'elle contenait fascine les historiens.
Parmi les objets sortis de la coque, il y avait des armes assez mystérieuses : d'énormes fléchettes qui semblaient conçues pour transporter une charge incendiaire. Personne ne savait vraiment comment elles fonctionnaient. Tod's Workshop, une chaîne YouTube spécialisée dans la reconstitution historique « testée pour de vrai », vient de s'attaquer à la question avec d'autres passionnés.
Le principe de ces fléchettes, une fois reconstituées à partir des fragments d'époque, est plutôt vicieux. À l'intérieur d'un revêtement en tissu enduit de poix, on trouvait un mélange incendiaire. Des mèches en bois mettaient le feu au contenu après un délai, et le résultat donnait des flammes quasiment impossibles à éteindre. Sur un navire en bois bourré de cordages et de voiles, vous imaginez les dégâts. Un cauchemar.
Restait à comprendre comment on envoyait ce truc sur le bateau ennemi. L'équipe a testé trois pistes. Le lancer à la main, d'abord, depuis le nid de pie (en haut du mat), ce qui semblait jouable pour atteindre un navire collé au vôtre. Ensuite un canon retrouvé juste à côté des fléchettes sur l'épave, un canon mal coulé et pointé vers le haut, ce qui n'est sûrement pas un hasard. Et faute de canon à poudre noire grandeur nature, ils ont reproduit un modèle réduit propulsé à l'air comprimé pour mesurer ce qui se passait vraiment.
Et c'est là que ça se complique. À pleine charge, la fléchette ne survit pas : l'accélération brutale la fait carrément se désintégrer avant même de partir. Par contre, avec une charge réduite, elle tient le coup et peut frapper une cible proche.
Une fois plantée dans la structure du navire adverse, les tests montrent qu'elle fait de gros dégâts. Donc l'arme n'était pas faite pour tirer loin, mais pour cramer le bateau d'en face dans un combat rapproché. Ce qui colle plutôt bien, d'ailleurs, avec la façon dont on se battait en mer à l'époque : on s'approchait, on s'accrochait, et on essayait de mettre le feu avant l'abordage.
Bref, une arme de 1545 qu'on ne comprenait pas, élucidée avec un peu d'air comprimé et beaucoup de patience, c'est improbable mais passionnant.
Source : Hackaday
Saracroche - L'app qui bloque le démarchage téléphonique
J'sais pas vous, mais en ce moment, moi ça n'arrête pas ! De quoi je parle ? Hé bien des putains d'appels commerciaux / arnaques que je reçois sur mon téléphone. C'est simple, je ne décroche plus aucun numéro que je ne connais pas.
Je crois qu'on peut tous dire collectivement qu'on en peut plus. Et c'est aussi le cas de Camille Bouvat, un développeur toulousain qui en a eu tellement marre qu'il a pondu Saracroche , une app gratuite et open source qui bloque environ 90% du démarchage téléphonique. Y'a déjà 1 million de Français qui l'ont adoptée donc y'a des chances que vous connaissiez déjà, mais dans le doute, je repartage ! Je sais, on est à quelques mois de l'arrivée de la loi anti-démarchage qui devrait normalement nous sauver même si j'y crois moyen... Ça va peut-être empêcher des sociétés françaises qui ont pignon sur rue de nous casser les couilles mais pour les arnaqueurs de tout poil, je ne suis pas sûr que cette loi suffise.
Alors comment ça marche Saracroche ? Hé bien vous installez l'app sur iOS (App Store) ou Android (Google Play, et un build F-Droid annoncé), vous activez les permissions de blocage d'appels, et hop, l'app fait correspondre chaque appel entrant grâce à une base locale de plus de 15 millions de numéros préchargés. Hé oui c'est 100% en local !
La base s'appuie sur les préfixes ARCEP (l'autorité des télécoms qu'on ne présente plus) réservés au démarchage téléphonique (les fameux 01 62, 04 24 et compagnie) ce qui permet de bloquer ces préfixes en bloc. Ça permet de se couper mécaniquement d'une grosse partie du démarchage légal en un seul coup
Et pour les arnaques qui usurpent des numéros mobiles ou ordinaires (faux colis, fausses banques, ping calls surtaxés), Saracroche complète ça avec les signalements communautaires, que vous pouvez nourrir vous-même depuis l'app.
Après j'sais pas si vous savez, mais à partir du 11 août prochain, le démarchage téléphonique sans consentement préalable sera légalement interdit en France, et Bloctel va prendre sa retraite. Mais ce ne sera pas suffisant...
J'avais déjà parlé de WinCalls y'a quelques mois ici mais c'était uniquement pour Android alors que Saracroche, pousse l'idée aussi jusqu'à iOS. Par contre, ça ne bloque que les appels entrants, et pas les arnaques par SMS ni par mail. Mais pour le démarchage classique, c'est probablement ce qu'il y a de plus efficace sur le marché français aujourd'hui.
Après côté business model, c'est comme d'hab en France... Camille Bouvat confiait à France Info que seulement 0,5% de ses utilisateurs sont donateurs. Donc sur 1 million de personnes ça fait peut-être 5 000 mecs qui mettent la main au portefeuille, soit à peine de quoi en vivre pour Camille ! Nous sommes vraiment un pays de crevards ^^ .
Bref, n'oubliez pas, si vous trouvez l'app utile, c'est le moment de cliquer sur le bouton "Soutenir" !!
Unitree lance son robot mecha à 500 000 dollars
500 000 dollars. C'est le prix d'entrée annoncé pour le GD01 d'Unitree, un robot mecha de 2,7 mètres de haut que vous pouvez littéralement piloter depuis son torse, façon Pacific Rim version chinoise. Unitree, le fabricant chinois déjà connu pour ses chiens-robots quadrupèdes, passe au stade de la production en série pour son engin transformable.
Le robot pèse 500 kilos avec son pilote à bord, soit clairement plus qu'un quad de loisir. Sa particularité, et c'est là qu'on bascule dans le délire science-fiction, c'est qu'il peut passer de la marche bipède à un mode quadrupède pour les terrains plus accidentés.
La vidéo de démonstration montre le patron Wang Xingxing en train de piloter l'engin, qui défonce un mur de briques d'un coup de poing métallique. Voilà voilà.
Côté chinois, ce n'est pas vraiment une surprise. Les fabricants locaux pèsent déjà environ 90% des ventes mondiales de robots humanoïdes en 2025, et Unitree fait partie des leaders du secteur. La boîte a même déposé son dossier d'introduction en bourse à Shanghai en mars dernier, avec 4,2 milliards de yuans à lever (environ 530 millions d'euros), dont 85% fléchés vers la recherche et développement. Le business des robots commence à devenir sérieux.
Au passage, ça marque une vraie différence d'approche avec les humanoïdes plus classiques, type Optimus chez Tesla ou Atlas chez Boston Dynamics (le fabricant américain de robots quadrupèdes et humanoïdes).
Eux visent un robot de taille humaine, autonome, destiné à assister ou remplacer des tâches du quotidien. Unitree, à l'inverse, propose un engin que vous habitez de l'intérieur, plus proche d'un exosquelette géant que d'un assistant compagnon. Pas le même produit, pas le même marché.
Unitree positionne le GD01 sur des usages assez spécifiques : parcs d'attractions, tournages de films, opérations de sauvetage en milieu hostile, expériences immersives. Pas franchement le genre de robot que vous garez dans le garage en rentrant du boulot. Le constructeur prévient d'ailleurs que le prix est "préliminaire" et qu'il bougera selon les optimisations à venir.
Bon, avant de rêver à votre propre mecha, quelques bémols quand même. Les experts pointent des soucis assez basiques : c'est galère d'entrer et de sortir du cockpit, l'autonomie batterie est limitée, le confort est minimal, et personne ne sait encore comment encadrer ce genre d'engin côté réglementation. Sans parler de la maintenance d'une bête mécanique de 500 kilos. Alors, vous sortez la carte bleue ?
Source : Gagadget
Valve a planqué un Wilhelm Scream dans le nouveau Steam Controller
Un utilisateur de Reddit a découvert cette semaine que le nouveau Steam Controller de Valve, vendu 100 euros en pré-commande sur le site de Steam, contient un easter egg complètement absurde : si vous lâchez la manette en mode Big Picture (l'interface plein écran de Steam, pensée pour être affichée sur une télé), elle pousse un Wilhelm Scream.
Pour ceux qui n'auraient jamais entendu ce nom, le Wilhelm Scream est un cri d'agonie enregistré en 1951 pour le film Distant Drums, et samplé depuis dans plus de 400 films d'Hollywood (Star Wars, Indiana Jones, Toy Story, et à peu près tout ce que Spielberg ou Lucas ont touché). C'est devenu une blague d'initiés de l'industrie du son.
Le truc, c'est que la manette ne contient pas de haut-parleur. C'est l'un de ses moteurs haptiques (les petits vibreurs qui font la vibration immersive sous les doigts) qui joue le son. Un moteur de vibration peut en effet être piloté avec un signal très fin pour reproduire à peu près n'importe quel son audible, comme un petit haut-parleur planqué dans le boîtier. C'est le même principe que sur la Switch ou la DualSense de la PS5, juste poussé à l'extrême pour cracher un cri reconnaissable.
Pour le déclencher, branchez la manette, lancez Steam en Big Picture, et lâchez le bidule sur quelque chose de mou. Coussin, canapé, oreiller. Ne jetez pas votre Steam Controller à 100 euros contre un mur pour tester, ce serait quand même un peu balot. Et ça n'arrive pas systématiquement : le Redditor qui a déterré l'easter egg a relevé une attented'environ une minute entre deux cris, histoire d'éviter que les gens en fassent une boucle audio en saccageant leur manette.
Au-delà de la blague, le nouveau Steam Controller affiche une bonne fiche technique. Deux trackpads pour un contrôle souris au pad, gyroscope complet pour la visée fine dans les FPS, et de nouveaux sticks magnétiques censés résister au stick drift (ce phénomène pénible où le stick croit qu'on le pousse alors que personne ne le touche). La manette est pensée pour fonctionner avec le PC, la Steam Deck, et la prochaine Steam Machine, la console salon de Valve qui doit débarquer plus tard cette année.
C'est typiquement le genre de détail qui montre qu'il y a encore des gens chez Valve qui font les choses pour le plaisir. Un easter egg sonore caché dans un accessoire à 100 euros, ça n'apporte rien commercialement, mais c'est franchement chouette.
Bref, ne lâchez pas votre Steam Controller pour le plaisir. Ou si.
Source : PC Gamer
OpenZFS 2.4.2 sort avec le support du noyau Linux 7.0
OpenZFS 2.4.2 est sortie ce 12 mai, et c'est une mise à jour qu'attendaient pas mal de gens qui font tourner du Linux 7.0 (le tout dernier noyau Linux stable). OpenZFS, pour ceux qui ne suivent pas, c'est le portage libre du célèbre système de fichiers ZFS originellement développé par Sun Microsystems, et désormais maintenu par une communauté autour de FreeBSD et Linux.
ZFS, en gros, c'est ce qui permet de gérer des pools de disques de plusieurs téraoctets avec snapshots, compression, déduplication et auto-réparation des données. Le genre d'outil qu'on retrouve dans les NAS sérieux et les serveurs de stockage.
La grosse nouveauté de cette 2.4.2, c'est le support du noyau Linux 7.0 stable. La version précédente 2.4.1 plafonnait à Linux 6.19, et beaucoup d'admins qui ont mis à jour leur distribution se retrouvaient avec un système qui refusait de charger le module ZFS.
C'est résolu. La compatibilité historique est aussi maintenue jusqu'à Linux 4.18, ce qui permet aux serveurs un peu anciens de continuer à profiter des dernières corrections. Côté BSD, FreeBSD 13.3 et plus restent supportés.
Dans le détail des changements, on trouve des corrections sur initramfs (le système qui charge le noyau au démarrage), le support de l'appel système POSIX_FADV_DONTNEED qui permet à une application de dire au noyau qu'elle n'a plus besoin d'un fichier en cache (ce qui libère de la RAM), les premiers patchs préparatoires pour Linux 7.1, et un durcissement des en-têtes SPDX (les balises de licence en tête de chaque fichier). Rien de spectaculaire, mais c'est ce genre de maintenance discrète qui fait tenir un projet sur la durée.
Pour ceux qui ne veulent pas passer sur la branche 2.4, l'équipe a aussi publié OpenZFS 2.3.7 en parallèle. Mêmes corrections de stabilité, kernels supportés un peu plus anciens. Ça permet aux infrastructures conservatrices de rester sur leur branche sans rater les fixes importants.
Si vous tournez sur Proxmox, TrueNAS, ou un Linux avec ZFS en racine, allez donc vérifier la version dispo dans vos dépôts. La 2.4.2 va probablement arriver sous quelques jours.
Source : Phoronix
Il essaye de réparer une GoPro Hero 10, et c'est l'enfer
Hugh Jeffreys , le YouTuber australien qui démonte tout ce qu'il trouve, s'est attaqué cette fois à une GoPro Hero 10 achetée 100 dollars avec un message d'erreur "no camera input".
Traduction : la caméra ne reçoit plus l'image du capteur. Sur Hackaday , le récit complet est savoureux pour qui aime la réparation board-level (la réparation au niveau de la carte, avec fer à souder et microscope, plutôt que le simple swap de pièces).
Pour ne pas y aller à l'aveugle, il achète une seconde GoPro Hero 10 HS à 40 dollars, censée donner ses pièces. Premier souci : le démontage.
La GoPro Hero 10 a un écran tactile collé au châssis avec une telle quantité d'adhésif que le retirer sans le briser tient du miracle. Hugh y arrive après plusieurs essais avec un sèche-cheveux et beaucoup de patience, mais c'est clair que GoPro n'a pas pensé à la réparabilité une seconde.
Vient ensuite le swap du module caméra, l'élément suspecté sur la première unité. Démontage, montage, reset usine, mise à jour firmware, rien n'y fait. Le message d'erreur revient. Hugh teste plusieurs combinaisons, sans plus de succès, et finit par admettre qu'il manque cruellement de schémas électroniques pour aller plus loin.
Sans la documentation interne que GoPro garde évidemment fermée, impossible de tracer le signal du capteur jusqu'à la puce de traitement.
Twist final : la seconde GoPro, présentée comme HS pour dégât des eaux, s'avère réparable après un bon nettoyage à l'isopropanol et un séchage soigneux.
Elle redémarre, capture des images, et fonctionne comme neuve. Hugh termine donc avec une GoPro qui marche pour 40 dollars, et une autre qui finit en boîte à pièces de rechange.
La leçon est simple. Sans schémas et sans accès au programmateur officiel de GoPro, la réparation board-level d'une caméra moderne tient parfois plus de la loterie que du diagnostic, surtout quand le constructeur fait tout pour décourager l'ouverture.
Et pendant que les marques serrent la vis sur la documentation technique, des gens comme Hugh tentent encore de prouver que ces appareils peuvent vivre une seconde vie.
Franchement, GoPro pourrait offrir un peu plus de prise aux réparateurs indépendants. On peut toujours rêver.
Source : Hackaday
Magic Pointer, le pointeur de souris pensé par Google DeepMind
Du côté de Google DeepMind, on s'amuse à réinventer le pointeur de souris. Le projet s'appelle Magic Pointer, c'est un pointeur piloté par Gemini (le modèle d'IA maison de Google) qui comprend ce que vous désignez à l'écran.
L'idée est simple. Vous survolez un élément (un tableau, une image, un PDF, une recette), vous tapez ou dites ce que vous voulez en faire, et Gemini exécute en tenant compte du contexte visuel précis.
Les démos publiées font effectivement leur petit effet. Vous survolez un tableau de chiffres et vous demandez un camembert ? Le graphique apparaît directement dans la zone visée. Vous pointez une recette en ligne et vous dites "double les ingrédients" ? La liste se réécrit avec les nouvelles quantités.
Vous pointez un PDF de 30 pages et vous demandez un résumé en bullet points ? Gemini sort un résumé qui colle aux pages effectivement visées, pas au document entier. C'est exactement le genre d'interaction qu'on attendait d'une IA depuis des années, et qui jusqu'ici se faisait toujours en mode "copier la zone puis coller dans une fenêtre de chat".
Côté disponibilité, Magic Pointer est dispo en démo dans Google AI Studio (l'interface dev de Google pour jouer avec Gemini), avec un déploiement progressif annoncé dans Gemini pour Chrome et dans les Googlebook, ces ordinateurs récemment annoncés par Google. Pas de date pour une arrivée sur d'autres navigateurs, ni en français au passage, mais on peut imaginer que Chrome reste prioritaire pour Google.
Côté technique, DeepMind reste un peu flou sur le pipeline exact. Gemini reçoit visiblement une capture autour du pointeur (un rectangle de quelques centaines de pixels), plus le texte demandé, et renvoie l'action à exécuter. C'est bluffant.
Maintenant on verra bien comment ça tient en conditions réelles avec des documents complexes, des sites mal formatés ou des PDF mal scannés où la reconnaissance de texte galère déjà. La vraie question, c'est aussi la latence. Aussi malin que soit le système, si ça met cinq secondes à comprendre, on ira plus vite en copier-collant.
Source : Google
Des utilisateurs Google Cloud facturés des milliers de dollars par erreur
Un truc franchement rageant remonte du côté de chez Google Cloud, et c'est The Register qui a mené l'enquête. Plusieurs développeurs ont vu leur facture Google Cloud exploser entre 3000 et 10000 dollars en quelques minutes, pour des services qu'ils n'ont jamais utilisés : génération vidéo Veo 3, tokens du modèle Gemini, le tout via leurs clés API Maps. Et le pire, c'est qu'ils avaient suivi à la lettre les recommandations officielles de Google.
La doc Google vous dit en effet de mettre votre clé Maps en clair côté client (dans le JavaScript de votre site, par exemple), parce qu'elle sert à afficher une carte dans un navigateur. Sauf que voilà, si vous activez sur votre projet Google Cloud d'autres APIs (comme Gemini ou Veo, l'outil de génération vidéo de Google), la même clé peut être utilisée pour appeler ces services.
Un bot malveillant trouve la clé sur n'importe quel site (le code source d'une page web est lisible par tout le monde), s'en sert pour générer des milliers de vidéos IA, et c'est le proprio du projet qui paie l'addition.
Le plus pénible, ce sont les spending caps, ces plafonds de dépenses que Google met en avant comme garde-fou. En pratique, ils ne déclenchent qu'une alerte par mail, pas une coupure réelle des services.
Vous recevez l'alerte alors que la facture grimpe déjà depuis dix minutes, et le temps de réagir, c'est déjà fini. Plusieurs devs disent avoir vu leur compte passer de quelques euros à plusieurs milliers en moins d'une heure. Ça pique.
Et Google ? La firme refuse les remboursements en parlant d'un problème "industrie-wide", autrement dit "tout le monde a ce souci, c'est pas notre faute". Pratique pour eux, moins pour les développeurs qui se retrouvent avec une note salée pour des services qu'ils n'ont jamais demandés.
Le vrai sujet, c'est le mélange clé Maps publique par design + accès Gemini activé par défaut sur le même projet. Ce n'est pas une faille au sens technique du terme, c'est une configuration que Google a choisie et qui transforme chaque clé Maps en bombe potentielle pour le portefeuille de celui qui l'utilise.
Si vous bossez sur Google Cloud, allez donc vérifier que Gemini et Veo ne sont pas activés sur les projets qui n'en ont pas besoin, et restreignez vos clés Maps à des domaines précis dans la console. C'est moche, mais visiblement c'est à vous de le faire.
Source : The Register