Fabrication d’une monture de télescope avec un réducteur harmonique sur mesure et un ESP32

• L’auteur a fabriqué une monture de télescope sur mesure à l’aide d’un réducteur harmonique (harmonic drive) et d’un microcontrôleur ESP32
• Les montures de suivi commerciales étant très coûteuses, il a choisi de la concevoir et de la fabriquer lui-même en mode DIY
• Il décrit en détail l’ensemble du processus de conception, notamment la conception et la fabrication du PCB, la modélisation 3D avec FreeCAD et le choix des composants
• Le coût total de fabrication s’élève à environ 1 700 euros, ce qui rend le projet compétitif par rapport aux produits commerciaux même à l’unité
• Il partage les performances réelles en astrophotographie et les améliorations apportées grâce à l’intégration avec le firmware OnStepX

---

Un nouveau point de départ

Il y a quelques années, l’auteur s’est intéressé à l’astrophotographie après avoir été inspiré par une chaîne YouTube consacrée à l’astrophotographie. Il a essayé de photographier la nébuleuse d’Orion en prenant des centaines d’images avec un temps de pose court depuis un trépied, puis en les empilant avec le logiciel Siril. Mais il a rapidement ressenti le besoin d’un système de suivi. Il a alors acheté un tracker Move Shoot Move, avant de s’intéresser à la fabrication d’une monture de télescope plus sérieuse en raison des difficultés à trouver les objets célestes, à faire l’alignement polaire et des résultats encore insuffisants.

Approfondissement de l’expérience en fabrication de PCB

En 2024, il est tombé par hasard sur des vidéos YouTube sur la conception de PCB sur mesure, ce qui lui a permis d’apprendre à utiliser des PCB fabriqués proprement et à faible coût au lieu de montages approximatifs sur breadboard. Pour son premier projet, il a réalisé un thermostat intelligent avec un ESP32, un écran e-paper et un capteur BME680. Fort de cette expérience, il a décidé d’appliquer directement ses compétences de conception et de fabrication de PCB à sa monture de télescope.

Recherche approfondie et usage des ressources communautaires

Le projet s’est structuré autour de l’adoption d’un harmonic drive. Il a consacré beaucoup de temps à étudier le choix des composants et l’architecture mécanique en s’appuyant sur AliExpress et sur l’open source disponible dans diverses communautés DIY (HEMY, HrEM, DHEM, DIY EQ Mount V2, etc.). Il a également exploré de nombreuses implémentations open source et ressources communautaires autour des moteurs pas à pas, des servomoteurs, du contrôle FOC, de SimpleFOC, etc.

Choix de conception et architecture

• Axe RA (ascension droite) : servomoteur 42AIM15 + harmonic drive Type 17 (réduction 100:1)
• Axe DEC (déclinaison) : moteur pas à pas MKS Servo042D + harmonic drive Type 14 (réduction 100:1)
• Monture et boîtier : adoption d’une plaque Arca Swiss, compatible avec la wedge Move Shoot Move
• Modes de fonctionnement : GEM (équatorial) ou ALTAZ (alt-azimutal)
• Microcontrôleur : ESP32-S3
• Alimentation : USB-C PD jusqu’à 24V/4A
• Contrôle moteur : step/dir/en, ULN2003 + MODBUS, CANBUS
• Extensibilité : broches GPIO restantes exposées vers l’extérieur

Les caractéristiques de microstepping et de contrôle servo propres à chaque moteur ont permis de simplifier la conception tout en améliorant la précision du suivi. Grâce au changement dynamique du microstepping via CANBUS, il a obtenu un bon équilibre entre slew rapide (déplacement) et suivi de précision.

Conception du PCB et résolution des problèmes

• Conception d’un PCB en demi-cercle avec KiCad, parfaitement ajusté au boîtier
• Utilisation d’un module ESP32-S3 sans antenne pour plus de liberté d’implantation et adoption d’un circuit d’alimentation USB-C (jusqu’à 24V)
• Utilisation du circuit open source PicoPD et de l’IC AP33772. Le choix de connecteurs JST série PH a permis des connexions compactes et de forte capacité
• Lors du premier remplacement d’IC, il a connu une erreur de câblage I2C et des dysfonctionnements ; le problème a été résolu sur la seconde version grâce à des vérifications renforcées et à l’ajout de nombreux points de test

Intégration du firmware OnStepX

L’auteur a adopté le firmware open source OnStepX pour le contrôle du télescope et la communication Wi‑Fi. Au départ, il a rencontré des problèmes de stabilité, l’ESP32 étant surchargé lors des mouvements de slew rapides, mais il les a résolus en réduisant la vitesse de slew et en passant le Wi‑Fi en mode client. En ajoutant simplement un fichier de disposition des broches adapté à OnStepX ainsi que du code de contrôle dynamique du microstepping, il a réussi à l’intégrer sans modifications majeures.

Fabrication et assemblage

La fabrication du PCB et l’usinage CNC du métal ont tous deux été réalisés chez JLCPCB. En faisant le choix audacieux de commander les pièces CNC directement à partir des plans CAD, sans test préalable en impression 3D, il a obtenu une précision des pièces très satisfaisante. Il y a bien eu une erreur de conception sur le capot de l’axe équatorial, mais elle a été corrigée simplement avec des entretoises. Toutes les pièces peuvent être assemblées uniquement avec du taraudage M3/M4 et des vis. Le taraudage manuel réalisé par l’auteur lui a permis de réduire les coûts de fabrication.

Retour d’expérience en conditions réelles

Après de nombreux tâtonnements liés à l’alignement polaire, à la mise en place et à la configuration des logiciels (INDI, KStars, Ekos, PHD2), il a progressivement accumulé de l’expérience en utilisation réelle. Lors des premiers essais, les échecs de prise de vue ont été fréquents à cause de divers petits et gros problèmes, mais au fil de la stabilisation il a atteint une précision de 1 à 2 secondes d’arc, suffisante pour obtenir de bons résultats avec des poses de 30 secondes à 600 mm de focale. Il utilise Siril pour l’empilement des images et poursuit déjà d’autres objectifs, comme l’empilement sur plusieurs nuits.

Coût de fabrication et intérêt économique

Le coût total s’élève à environ 1 700 euros (outillage, matériel et composants d’essai inclus). Rapporté à une seule unité, le coût revient à environ 800 euros. Face aux montures GOTO commerciales (1 200 à 4 000 euros), cela confirme un fort intérêt économique, même si l’auteur insiste davantage sur la valeur de l’expérience de fabrication elle-même.

Coût détaillé par élément (résumé des principaux postes)

• Harmonic drives (2) : 144 euros
• MKS et servomoteurs (2 de chaque) : 73 à 216 euros
• Pièces CNC : 215 euros
• PCB, connecteurs, vis, outils et autres

Conclusion et impressions

L’auteur souligne que l’expérience de fabrication, la résolution des problèmes et tout le cycle conception‑fabrication‑validation ont une valeur bien supérieure à l’achat d’un produit commercial. L’échec de la version 1 du PCB lui a appris l’importance d’une validation rigoureuse. Il en a tiré de nombreux enseignements sur FreeCAD, KiCad, l’usage de l’open source et l’ensemble du processus de développement hardware. Grâce au firmware OnStepX et aux ressources de la communauté, il montre qu’une monture de télescope DIY est aussi un projet accessible à un particulier.

Construire sa propre monture pour suivre les étoiles et la comprendre de bout en bout — voilà une satisfaction réellement précieuse.

[GN⁺]

Commentaires Hacker News

• Le câble provenant de l’alimentation USB-C finit par jouer le rôle d’une inductance, donc l’ensemble se comporte comme un filtre LC passe-bas, ce qui explique la nécessité de condensateurs embarqués. Quand le moteur appelle brutalement un fort courant, l’inductance empêche ce courant de circuler instantanément ; le condensateur le fournit alors à sa place, puis l’inductance prend progressivement le relais.

• Projet et explications vraiment superbes, avec un timing parfait. Je suis passionné d’astronomie amateur depuis mes 13 ans, j’ai possédé plusieurs télescopes et passé de longues soirées à observer le ciel avec ma famille. Récemment, j’ai ressorti un SCT de 10 pouces et un Newton de 4 pouces pour montrer la Lune et Saturne à mon fils de 7 ans. Le fait que mes parents aient aussi pu regarder a rendu ce moment particulièrement précieux. Le SCT de 10 pouces est monté sur une ancienne monture à fourche sans fonction GOTO. J’ai aussi étudié les avantages du GOTO, mais je n’ai toujours pas franchi le pas, car j’aime trop le plaisir de chercher les objets moi-même. J’ai quand même acheté une caméra de refroidissement dédiée, la ZWO 585MC. En même temps, j’ai aussi perdu énormément de temps à chercher des objets. Le Telrad seul ne suffit pas, donc avec une imprimante 3D et quelques connaissances en électronique, j’ai envisagé de fabriquer moi-même une monture tierce. J’ai aussi réfléchi à remplacer le moteur par un moteur pas à pas NEMA 17. En explorant tout ça, j’ai découvert le projet PiFinder. Ça me semble être l’équilibre parfait entre automatisation et guidage manuel https://www.pifinder.io/. Les progrès de l’impression 3D et de la fabrication de PCB me donnent la conviction qu’on pourra bientôt résoudre beaucoup de ces problèmes.

  • Lire que le GOTO n’est pas amusant me rappelle à quel point les goûts diffèrent. Personnellement, c’est justement la recherche des objets que je supporte le moins, donc je suis très reconnaissant envers les montures goto.
  • Si tu branches une caméra ZWO à Kstars/EKOS, tu peux utiliser le plate solving logiciel pour déterminer précisément où pointe le télescope et ajuster ensuite en conséquence.

• Une remarque sur les pistes de circuit dans cet excellent projet : il est dit qu’elles ont été faites trop larges pour supporter 24V, mais en réalité, plus la tension est élevée, plus le courant est faible, donc des pistes plus étroites suffisent généralement. La largeur des pistes dépend du courant, tandis que l’espacement entre pistes est le point à surveiller en fonction de la tension.

  • Pour la largeur des pistes, la spécification standard IPC-2221A est utile : https://www-eng.lbl.gov/~shuman/NEXT/CURRENT_DESIGN/TP/MATERIALS/IPC-2221A(L).pdf
  • Tout à fait d’accord avec cette bonne remarque et cette explication.

• Citation du blog : « quand on déplace le télescope vers une cible, le nombre d’impulsions envoyées au moteur augmente et cela surcharge le petit ESP32 ». Je travaille moi aussi sur le pilotage précis de moteurs pas à pas à haute vitesse, où la moindre impulsion ratée ou le moindre glitch est inacceptable. Les cœurs MCU atteignent vite leurs limites, donc je pilote via timer + DMA. Au final, j’exploite la fonction ACT (Advanced Control Timer) d’un MCU STM32G4. Comme la génération de formes d’onde arbitraires via DMA est facile, le timer reste insensible au fait que le cœur soit surchargé ou en veille. En ce moment, j’envisage aussi le PIO du RP2350. L’ESP32 a bien le MCPWM, mais pour implémenter des profils complexes d’accélération et de décélération en mode 100 % sans intervention du cœur, il faut utiliser des timers en cascade ou des interruptions ; on redevient donc dépendant du cœur, avec un risque de glitch. Chez ST, l’ACT fournit un timer indépendant par moteur, donc l’implémentation reste simple à condition de bien lire la datasheet. Les IC de pilotage spécialisés (Trimanic, etc.) sont aussi une option, mais la complexité logicielle finit par être plus élevée que dans mon approche.

  • À ma connaissance, OnStepX fonctionne par impulsions ; je n’ai pas encore vu d’approche exploitant le DMA. Dans les deux cas, je pense qu’il serait possible de passer par un mode à commandes de position sur CANBUS au lieu de piloter par impulsions. J’ai vu cette possibilité dans le code d’OnStepX aussi, mais le mode impulsions est tellement plus simple pour démarrer que je l’ai choisi.
  • J’avais aussi envisagé le PIO sur rp2040 pour contrôler un moteur pas à pas, mais la limite du compteur sur 5 bits et des 32 instructions rendait l’usage difficile. À la place, j’ai dédié le second cœur au contrôle de mouvement et généré les signaux step/dir en bit banging, ce qui était largement suffisant pour un profil trapézoïdal sur un seul axe.
  • Si tu veux voir jusqu’où on peut pousser le pilotage de moteurs pas à pas avec un MCU, je recommande de regarder le firmware d’imprimante 3D Merlin. Il arrive à gérer des calculs complexes pour imprimante delta avec de petits MCU AVR 8 bits.
  • Il me semble que l’ESP32 a aussi le RMT ; je me demande si cette piste a été envisagée.

• J’utilise freeCAD depuis trois ans, et je suis vraiment admiratif du résultat produit dans ce projet. J’aime freeCAD, mais je n’ai pas souvent rencontré un outil aussi obstinément inconfortable et agaçant.

  • Merci à FreeCAD, mais à mesure que la complexité des projets augmente, les crashs aléatoires deviennent vraiment pénibles. Cela dit, la plupart des fonctions dont j’ai besoin restent faisables dans FreeCAD dès lors qu’on sait comment s’y prendre. Le fait de ne pas avoir utilisé d’autres logiciels de CAO m’a paradoxalement aidé à m’installer sur freeCAD.
  • Cela fait sept ans que je fais de la modélisation de loisir avec FreeCAD, mais dès qu’il s’agit d’une fonction que j’utilise pour la première fois, l’expérience reste frustrante. Je suis développeur front-end, donc je connais les critères de QA, et FreeCAD a souvent une UX qui ne les atteint pas. En cherchant sur le forum à comprendre la différence entre erreurs et avertissements d’overconstraint, je suis surtout tombé sur des messages défendant cette politique au nom des performances, avec une vraie ambiance de gatekeeping chez les power users. Il manque cruellement de vrais spécialistes UX et d’un community manager.
  • J’alterne entre OnShape et FreeCAD, et je suis impressionné par la finition soignée d’OnShape. En revanche, à cause de modèles achetés, je ne peux pas les mettre sur le tier gratuit d’OnShape. C’est faisable avec FreeCAD, mais quand on se dit « ça sera plié en une heure », on finit généralement par y passer la nuit.
  • L’existence même de FreeCAD est formidable, et j’attends avec intérêt qu’il mûrisse encore. Cela dit, si l’objectif est d’obtenir vite un résultat, je recommande le tier gratuit d’Autodesk Fusion. Ça ne conviendra peut-être pas à ceux qui veulent n’utiliser que de l’OSS par principe, mais pour un usage hobbyiste, la qualité est excellente et les limitations sont dans les faits très faibles. J’ai l’impression que ce rejet vient surtout du fait que ce n’est pas OSS, mais j’aimerais qu’on élargisse le choix des logiciels sur la base des fonctionnalités.
  • ChatGPT et Claude sont d’une grande aide pour ce genre de travail. Avec un logiciel correctement documenté, l’IA peut expliquer gentiment un workflow étape par étape. Il y a bien sûr des limites dans les domaines très spécialisés ou mal référencés, mais c’est bien plus rapide que de cliquer à l’aveugle ou de parcourir des vidéos YouTube en accéléré. On peut aussi lui demander un guide d’étude pour acquérir les bases. En revanche, il faut absolument demander des liens et références, car l’IA hallucine et se trompe aussi.

• Je suis très intéressé par des projets où l’on réalise soi-même des mesures de précision avec une monture de télescope, par exemple de l’astrométrie planétaire en autonomie. Reconstituer les orbites des planètes à partir de ses propres mesures donne un peu l’impression de refaire le chemin des anciens astronomes comme Kepler.

  • Sujet vraiment passionnant. Au-delà de la photo « jolie », j’ai réfléchi à un système permettant d’utiliser les données d’observation amateurs pour la recherche. Si l’on partage les images brutes d’une seule prise ainsi que les métadonnées (heure, coordonnées, images de calibration, etc.), on pourrait collectivement produire soit de la science, soit des images encore plus belles. Le Vera C. Rubin Observatory peut couvrir tout l’hémisphère sud en quelques jours. Si ce type de logiciel évoluait vers une sorte de réseau astronomique mondial participatif, ce serait vraiment formidable.
  • En réalité, pour connaître précisément la position d’une planète, il est bien plus exact de prendre une photo en la centrant puis de calculer sa position en la comparant aux coordonnées fixes des étoiles environnantes, plutôt que de se fier à la correction de position de la monture. Calibrer parfaitement la monture elle-même est quasiment impossible ; l’approche par coordonnées relatives aux étoiles est incroyablement précise.
  • Autre projet intéressant : mesurer la courbe de lumière d’un transit d’exoplanète. Certaines exoplanètes proches sont observables depuis un jardin avec un simple objectif photo. Exemple d’observation amateur avec une ASI178MM-c et un Canon FD 300mm : https://astropolis.pl/topic/60163-wasp-10-b-w-pegazie-1270-mag-00340-mag/
  • Même si ce n’est pas totalement du first principles, certaines personnes utilisent aussi un Seestar S50 roboscope et un réseau de diffraction pour mesurer le spectre d’émission des étoiles.
  • À noter que Kepler travaillait à partir des observations à l’œil nu de Tycho, sans télescope.

• Projet vraiment impressionnant. J’ai l’impression que, lors de la conception du PCB, les bons condensateurs, résistances, etc. n’ont pas été correctement ajoutés, ce qui nuit à la stabilité du microcontrôleur. Je me demande comment chacun détermine les composants nécessaires, par exemple les condensateurs de découplage. Est-ce qu’il suffit de lire la datasheet et d’appliquer tout ce qui y figure ?

  • Vérifier la datasheet est indispensable. Elle contient souvent un schéma minimal ou un exemple de circuit qu’il faut absolument consulter. Parmi les bonnes habitudes, il y a aussi placer les condensateurs de découplage près des broches du circuit, stabiliser la masse et suivre le layout de référence. Les explications détaillées d’ingénieurs expérimentés sur leur processus de décision (par ex. : https://www.youtube.com/watch?v=aVUqaB0IMh4) sont aussi très utiles.
  • Presque toutes les datasheets de composants contiennent un circuit minimal et une conception de référence. L’usage d’un plan de masse, la longueur des lignes de signal, etc. sont souvent détaillés séparément dans des notes d’application.
  • Pour concevoir un circuit autour d’un microcontrôleur, partir de cartes de développement open hardware dont le schéma est public est un bon point de départ.
  • En plus de consulter la datasheet, placer des condensateurs de découplage aussi près que possible de chaque broche d’alimentation et consacrer une face du PCB à un plan de masse permet de résoudre la plupart des problèmes.

• J’ai été particulièrement impressionné par le fait d’avoir fait fabriquer des pièces métalliques CNC sur commande. Moi aussi je débute en CAO et j’aimerais apprendre.

  • Je me suis inscrit dans un makerspace local pour utiliser leur atelier d’usinage. J’ai suivi la formation et obtenu l’autorisation d’utiliser la machine CNC, puis j’ai conçu en CAO de simples plaques métalliques pour du matériel de tournage. Il y avait un générateur de G-code simple et j’ai pu vérifier les collisions avec un simulateur. À chaque fois que je voulais vraiment usiner une pièce, quelqu’un avait endommagé la tête et la machine était hors service. J’ai donc fini par tout fabriquer à la main, avec des dimensions pas parfaitement exactes. Si j’avais su qu’il existait des services CNC, j’aurais préféré leur confier directement la fabrication.
  • En réalité, c’est très simple : il suffit d’uploader un fichier step pour obtenir immédiatement un devis et vérifier la faisabilité de fabrication https://jlccnc.com/cnc-machining-quote

• Très beau projet. Je me demande si le coût de fabrication du PCB vient surtout de l’assemblage. Avec JLCPCB, une carte 2 couches de moins de 100 mm avec finition HASL et options de base reste bon marché ; est-ce que la fente de la plaque USB connector ajoute des frais ? Combien d’exemplaires ont été commandés en assemblage à chaque fois ? Quelle proportion relevait de la bibliothèque standard ou étendue ? Quelle différence de coût y aurait-il eu en soudant uniquement les connecteurs à la main ? Et si la présence d’un seul composant de la bibliothèque étendue fait grimper les coûts de picking pour tous les composants, est-ce que réduire au maximum le nombre de références reste la clé pour faire baisser le prix ?

  • En pratique, la principale source de coût est bien l’assemblage. La carte est une JLCPCB 2 couches avec options de base, et seul le passage au noir augmente légèrement le prix. J’en commandais cinq à la fois, car c’est la quantité minimale. J’ai essayé autant que possible de rester dans la bibliothèque standard, mais en dehors des composants passifs c’est difficile. Pour le traversant, je n’ai pas mesuré précisément l’écart si je soudais moi-même, mais il n’était pas assez important pour que je m’en soucie. Oui, réduire le nombre de références est la bonne stratégie. Par exemple, s’il faut des résistances de 4k et de 6k, il peut être plus avantageux d’assembler cinq résistances de 2k.

• Projet vraiment impressionnant. J’avais moi aussi envisagé d’acheter une grande monture à harmonic drive pour mon instrument, mais la barrière de prix est énorme. Même avec les outils EKOS/Kstars/INDI, j’ai beaucoup tâtonné. J’ai d’ailleurs écrit du code pour piloter des appareils indi depuis Python : https://github.com/dahlend/contindi

  • Je suis curieux de savoir quelle motivation t’a poussé à écrire ce code, car EKOS semble déjà avoir de bonnes fonctions de planification. De mon côté aussi, j’ai fait tourner un serveur INDI sur un mini-PC MeLE 4C et écrit une interface terminal (TUI) https://www.svendewaerhert.com/content/blog/telescope-mount/inditui.png. À cause des problèmes de stabilité de GNOME Remote Desktop, je suis passé à un serveur INDI headless/distants, et je compte bientôt nettoyer le code de mon TUI pour le publier sur GitHub.