L’Arduino au coeur des systèmes de pilotage analogiques ou numériques

. Par : Dominique, Guillaume, Jean-Luc. URL : https://www.locoduino.org/spip.php?article58

L’Arduino a de multiples raisons de trouver sa place dans les systèmes de pilotage des modèles réduits ferroviaires, qu’ils soient numériques ou analogiques. Mais probablement plus encore pour les systèmes numériques, notamment parce que les accessoires ne sont pas numériques et un Arduino peut remplacer un décodeur du commerce.

Ce premier article va s’intéresser aux deux systèmes sans favoritisme, en révélant leurs différences, leurs similitudes, les ponts et points de passage de l’un à l’autre.

Vous possédez déjà un système, quelques modules Arduino vous permettront de le compléter.
Vous n’avez pas encore fait votre choix, c’est l’occasion rêvée de concevoir votre système sur mesure ! Et tout cela sans vous ruiner, ni vous épuiser dans la programmation. Locoduino vous proposera une solution qu’il vous faudra adapter à votre réseau.

Le but de cet article est de vous présenter toutes les opportunités d’introduire un ou plusieurs modules à base d’Arduino dans un système digital ou analogique. Mais il faut d’abord commencer par définir ce qu’est un système de pilotage ferroviaire.

Définitions

Les rails et la traction

Un réseau ferroviaire commence toujours par des rails, une locomotive (et éventuellement quelques voitures ou wagons) et une alimentation électrique.

Figure 1
Le système analogique minimum (inspiration : Source wikipedia).

Si le système est analogique, l’alimentation délivre une tension variable en fonction de la vitesse désirée, soit continue, avec un rhéostat, soit en impulsions modulées (PWM). Mais elle ne permet de piloter qu’un tronçon de rails auquel l’alimentation est raccordée, soit la et les locomotives présentes sur ce morceau sans aucune distinction.

Dans cette optique de piloter plusieurs trains avec une alimentation, 2 façons simples sont à notre disposition :

  • la première consiste en une seule alimentation et à la coupure du réseau en cantons commandés par des interrupteurs qui alimentent ou non en courant la voie.
  • soit nous avons la possibilité d’alimenter la voie avec plusieurs alimentations, de faire en fait un réseau composé de zones alimentées séparément.

Il est aussi évident que bon nombre de solutions existent encore. Nous avons pris deux cas élémentaires.

Déjà à ce point précis de l’article, on peut entrevoir le rôle d’un Arduino en charge de la production et de la coordination des alimentations d’un système analogique. Nous y reviendrons plus tard.

Le transformateur analogique fournit toujours sur une deuxième sortie une tension alternative destinée à commander les accessoires (aiguilles, passages à niveau, éclairages, etc..) à travers des boutons poussoirs ou inverseurs qu’on dispose sur un tableau de commande.

Rien n’empêche d’utiliser nos petits Arduinos pour assurer ces commandes avec élégance et sophistication !

Si le système est numérique (digital en anglais), la promesse (commerciale) d’une alimentation numérique est de permettre de piloter plusieurs trains et accessoires à partir de 2 fils seulement connectés aux rails. Ces 2 fils conduisent à la fois la puissance de traction ET des ordres de pilotage du matériel roulant (vitesses, fonctions des locos telles que lumière, sons, etc..). Cette simplification extrême est représentée sur la figure suivante qui met en oeuvre une centrale DCC (avec son amplificateur dit "Booster", ici intégré à la centrale) et des décodeurs dans chaque loco.
Le protocole DCC est le plus répandu, mais il existe cependant d’autres protocoles comme le MFX ou celui de MOTOROLA, plus anciens.

A ce stade, l’Arduino pourra être aussi impliqué dans la production du signal DCC et la commande des accessoires (comme en analogique). Des exemples sont décrits dans ce site.

Mais, même si un avantage du numérique apparaît déjà avec la possibilité de piloter plusieurs machines sur une même voie, la partie n’est pas gagnée car un réseau ferroviaire ne se résume pas à ces seuls éléments.

Il faut compter avec les décodeurs à installer dans les trains et accessoires. Et il faut aussi envisager d’intégrer la rétrosignalisation pour assurer quelques automatismes.

Figure 2
Un système DCC simple. Schéma inspiré de wikipedia.

Ce système DCC simple est en général constitué de deux parties : une manette de commande et un générateur de puissance. 

Les plus populaires sont la Multimaus de Roco/Fleischmann et la MS2 de Märklin (représentée ci-dessous). Mais l’offre est immense et le choix difficile car les combinaisons d’éléments de marques différentes sont peu nombreuses et onéreuses. D’où l’interêt de l’Arduino pour se passer de ces éléments onéreux et satisfaire exactement ses propres besoins, le propre du DIY

Figure 3
Un kit de démarrage extensible (Minitrix)

L’interface Homme-Machine

Que le réseau soit analogique ou numérique, il ne se résume pas à la commande de quelques convois. Pour permettre de belles manœuvres, il faudra commander des aiguillages, des barrières de passage à niveau, des feux de signalisation, des éclairages et probablement aussi des animations lumineuses et sonores (annonces en gare, bruits et lumières d’un garage, fête foraine, etc..).

Nous les pilotes humains avons besoin d’organes de commande ergonomiques , que ce soient des manettes (Throttle en anglais), des TCOs (tableau de contrôle opérationnel), voire sur nos smartphones, tablettes et ordinateurs (avec un logiciel de pilotage). En informatique, on appelle cela l’IHM (Interface Homme Machines - au pluriel bien sûr).

Voici deux exemples de TCO pour représenter le circuit, les positions des trains et des aiguilles et commander quelques trains et des aiguilles.

Figure 4
Exemples de TCO (source Forums)

Le premier est un TCO "classique" de réseau analogique et le second est celui de mon premier réseau digital (il est construit autour d’un Mega2560).

Dans tous les cas, l’Arduino se révélera très pratique et évolutif pour assurer les fonctions d’affichage (Leds, afficheurs, scrutation des boutons et clés, lecture de la position de potentiomètres, etc..).

A l’opposé, certains pourraient préférer un écran d’ordinateur avec un logiciel de pilotage (RocRail, JMRI, iTrain, TrainController, Windigipet, etc..), connecté à une centrale numérique en USB ou utiliser leur tablette via une liaison WiFi.

Figure 5
Un TCO sur écran d’ordinateur (TrainController)

La rétrosignalisation

La rétrosignalisation a pour but de remonter au poste de pilotage les événements de circulation (présence ou de passage des trains à certains endroits, détection d’occupation de cantons, état des aiguilles, et bien d’autres selon la sophistication souhaitée).

Elle doit mettre en œuvre des capteurs qui font "monter" chacun un signal au moment du passage d’un train, par exemple. Tous ces "signaux" sont envoyés au poste de pilotage (vous, un Arduino, une centrale simple ou sophistiquée, un logiciel PC, etc..) pour déclencher des actions telles que :

  • ralentissement ou arrêt d’un train en aval d’un canton occupé par un autre train (cantonnement, bloc système),
  • passage des feux de circulation au rouge, jaune ou vert
  • fermeture d’une barrière de passage à niveau
  • changement de sens d’une aiguille pour permettre à un train de suivre un itinéraire programmé
  • déclenchement d’une annonce sonore en gare
  • etc..

Nous allons d’abord nous pencher sur le cas du digital, conçu pour cela, pour montrer la complexité de la question et les opportunités qu’apportent les Arduino. Ensuite, il sera facile de transposer ces solutions vers l’analogique.

Pour fédérer ces capteurs et assurer la transmission des événements vers la centrale, les constructeurs ont inventé des bus et des protocoles de communications propriétaires qui détruisent en grande partie les bienfaits de la normalisation DCC. Sans aller jusqu’à dire que c’est la foire, cela complique notre projet.

Ces réseaux se nomment "Loconet" (Digitrax, Fleishmann, Uhlenbrock, Roco, Zimo), "S88" (Märklin, ESU, Fleishmann, Tams, Uhlenbrock, Viessmann) ou "RS-feedback" (Lenz).

Mais nous verrons que l’Arduino peut être d’un grand secours dans ce domaine.

Les réseaux des manettes et accessoires

Et si cela ne suffisait pas, les constructeurs ont également inventé des bus et des protocoles de communication propriétaires (mais pas tous) pour raccorder plusieurs manettes et permettre le pilotage à plusieurs.

Figure 6
Un réseau pour les manettes (Throttle en anglais) Source dccwiki

Selon les constructeurs de centrales, ces réseaux propriétaires (échappants à la normalisation DCC) se nomment "Loconet", proche du protocole Ethernet (Digitrax, propriétaire de LocoNet, Uhlenbrock, Fleischmann) ou "Xpressnet", basé sur la norme RS485 (Lenz le créateur, Atlas, Roco, ZTC, CVP, ESU, Hornby), ou NCE Network (NCE). La partie droite de la figure 7 ci-après montre également un raccordement sans fil d’une manette, les constructeurs cités ci-dessus proposant souvent des liaisons sans fil.

Autant dire qu’il n’y a pas beaucoup de compatibilité entre les éléments d’un constructeur et ceux d’un autre, du coté des centrales et des IHM. Espérons que cette situation s’améliorera.

La norme DCC permet heureusement de libérer les choix des matériels roulants et des accessoires.

Il reste que cela impose de disposer d’autant de décodeurs que de matériels roulants et d’accessoires ou groupes d’accessoires (une commande DCC peut agir sur 8 actionneurs maximum).

Figure 7
Un système DCC perfectionné (Source wikipedia)

A noter sur cette figure, que le réseau d’alimentation et de commande est souvent scindé en deux parties : une partie pour l’alimentation des locos, via les rails (et souvent aussi via les détecteurs de consommation de courant nécessaires au cantonnement) et une partie pour la transmission des commandes aux accessoires (aiguilles, signaux, éclairages, animations sonores, etc..), afin d’éviter les parasites inévitables sur les rails.

Le casse-tête du modéliste ferroviaire

La promesse de compatibilité entre constructeurs est ainsi mise en échec et le coût d’un système de pilotage complet digital comme analogique, basé sur des modules du commerce, peut vite s’avérer très élevé. On peut aussi se sentir « prisonnier » d’un système !

En effet, à titre d’exemple, la liste des composants d’un système digital se compose :

  • d’une centrale chargée de produire le signal DCC de commande en fonction de la consigne des manettes, de la rétrosignalisation, des automatismes, etc..
  • d’une manette pour que l’utilisateur conduise des trains, et aussi plusieurs quand viennent les copains,
  • d’un booster pour fournir le signal DCC de puissance (ex : +/-15V 3 à 5A) à partir du signal de commande fourni par la centrale,
  • d’une alimentation pour alimenter le tout en courant électrique,
  • d’un décodeur dans chacune des locomotives,
  • de décodeurs pour la commande des aiguillages,
  • de décodeurs pour la commande de la signalisation (feux tricolores),
  • de capteurs pour la détection des trains,
  • de circuits de gestion des boucles de retournement s’il y en a,
  • d’une connexion à un ordinateur, tablette, smartphone, via un routeur, en wifi,
  • d’autres décodeurs de commande des feux de signalisation, d’éclairages, d’animations sonores, de plaques tournantes, de passages à niveau, etc..
  • d’un logiciel de conduite sur PC pour gérer tous ces éléments là.

Une rapide évaluation du coût d’une configuration moyenne dépasse largement les 1000€ sans compter les rails, les locos avec leur décodeur, voitures, wagons, et les éléments de décor. Rien que pour l’électronique ! (Free-DCC, page 11)

Pour l’analogique, dans l’hypothèse d’une circulation automatique, l’apport de l’électronique sera indispensable avec la nécessité de mettre en place un câblage important ainsi que des relais mécaniques ou électroniques (en restant basique).

Et en général, tous ces utilisateurs ennuyés se retrouvent sur les Forums pour poser des questions et espérer trouver des réponses autres que "revends ton matos et achète xxx .."

Mais quel plaisir que celui de voir évoluer plusieurs trains en même temps, certains automatiquement, avec un réalisme surprenant, tout en respectant les règles de sécurité.

Alors comment faire sans se ruiner ?

La solution : Do It Yourself avec Arduino

Notre approche vise à réduire considérablement ce coût en réalisant par nous-même une grande partie des équipements ci-dessus, à partir de modules Arduino et selon une architecture plus simple qui réduit le nombre des éléments matériels, à l’exception des éléments de base conformes à la norme DCC pour le digital.

Pour l’analogique, le choix est plus grand, avec différents degrés possibles d’automatisation.

En général, deux cas possibles se présentent :

  • Nous possédons déjà une centrale DCC du commerce ou un système analogique et il faut s’y adapter ;
  • Nous n’avons aucun système et nous sommes alors libres de concevoir un système complet.

Cette 2 ème approche n’est pas nouvelle : des centrales à monter soi-même (DIY : do it yourself) existent déjà telles que (liste non exhaustive) :

Ces réalisations permettent bien de "réduire la facture", mais ne concernent pas l’Arduino qui seul nous intéresse ici et ne permettent pas ou peu de personnaliser le logiciel.

Notre approche, à base de modules Arduino et de périphériques largement disponibles dans le commerce à très bas prix, nous parait plus souple et évolutive, parce que modulaire et programmable par tous (le succès de la plateforme Arduino en atteste), dont la plupart des logiciels nécessaires proviennent de l’Open Source (logiciel libre). Comme il existe des multitudes de modules Arduino, diffusés selon le mode du "matériel libre" et de multiples bibliothèques en "logiciel libre", nous verrons qu’il est assez facile de construire sa propre plateforme soi-même, "made in home" : DIY (do it yourself).

Cette plateforme ne nécessite la réalisation d’aucun circuit imprimé et limite l’usage du fer à souder (on ne peut malheureusement pas échapper à la réalisation des câbles de liaison mais l’utilisation de borniers à vis rend la tâche plus facile). Mais, quand on peut disposer de tels circuits imprimés, cela sera tout de même un plus pour celui voudra installer en dur son matériel. On en trouve certains sur le site Locoduino.

Son avantage est l’adaptation aux évolutions. Le faible prix d’un Arduino permet d’en installer plusieurs si l’architecture et l’évolution du réseau le nécessitent. Les différents modules communiquent entre eux pour se partager les événements et les fonctions à réaliser au moyen d’un BUS de communication.

Un autre avantage est la maîtrise du logiciel, donc des fonctionnalités, leur évolutivité, tout ceci s’appuyant sur des logiciels libres largement diffusés. L’évolutivité avec la possibilité de téléverser un nouveau code dans l’Arduino augmentera ses possibilités sans pour autant toucher au câblage.

Enfin, l’avantage du DIY est que ce modèle s’applique également à un réseau analogique puisqu’on pourra s’affranchir des bus et protocoles non standards du monde digital.

Quelle architecture matérielle ?

Deux parties principales sont au cœur de cette architecture :

  • le générateur de signaux de puissance DCC ou analogique (un dans le cadre du DCC ou plusieurs modules dans le cadre analogique) qui orchestre l’ensemble du matériel roulant du réseau,
  • le gestionnaire d’accessoires qui assure la commande des accessoires et assure la collecte des événements de la rétrosignalisation, en symbiose avec le générateur selon des protocoles inter-Arduino (SPI/CAN ou I2C), plutôt que ceux du DCC, pour que ces gestionnaires trouvent leur place aussi dans les systèmes analogiques.

Autour de ces deux parties gravitent un certain nombre d’autres d’organes :

  • les organes d’IHM (interface homme-machine) tels que manettes, TCO, tablettes, PC avec différents types de liaisons,
  • les interfaces d’accessoires qui assurent l’interface entre le monde numérique des Arduino et les éléments matériels du réseau, avec des éléments largement disponibles dans le commerce, y compris d’autres Arduino si la solution est plus pratique.

Nous répétons bien que les interfaces d’accessoires ne seront pas nécessairement conformes à la norme DCC, pour décharger le bus DCC en digital et pour s’adapter aux réseaux analogiques.

Il en va de même pour les connexions des organes d’IHM tant que l’on n’utilise pas des produits du commerce.

Mais l’intégration de produits du commerce n’est pas exclue pour ceux qui en possèdent, car des circuits d’interface existent parfois et/ou seront envisagés, mais dans un second temps. Vous trouverez sur le site d’autres articles relatant ces possibilités comme Un TCO xpressnet

Que commander avec l’IHM ?

Que commande t-on à partir d’un poste de pilotage ?

  • les trains (locos et wagons), en DCC ou analogique,
  • les aiguilles avec, de préférence, des servos (solutions moins chères) ou des relais pour commander les moteurs d’aiguille du commerce,
  • les itinéraires (avec mode automatique ou manuel)
  • les feux de circulation ferroviaire, les barrières
  • les animations lumineuses : lampadaires, bâtiments, boutiques, enseignes, feux routiers, panneaux, etc..
  • les animations sonores : annonces en gare, etc..
  • la configuration des paramètres de l’ensemble
  • la programmation des décodeurs (en DCC)

S’il s’agit d’une manette (manette réelle ou smartphone/tablette faisant tourner une application de type "manette"), les commandes se limiteront au pilotage des trains (moteur et fonctions).

S’il s’agit d’un TCO, les commandes agiront sur les aiguilles et les animations avec un retour par la rétrosignalisation.

S’il s’agit d’un ordinateur personnel, toutes les commandes ainsi que la rétrosignalisation seront possibles. Mais le but de Locoduino n’étant pas le développement de logiciels pour PC, tablette ou smartphone, nous verrons s’il est quand même possible d’utiliser certains logiciels existants, mais dans un second temps.

On pourra même envisager le développement d’un gestionnaire de réseau complet sur Arduino !

Quelle interfaces et moyens de communication ?

Entre modules, il faut bien s’entendre. Les connexions à réaliser pourront être tout ou partie de cette liste :

  • l’interface avec un PC sera en USB ou sans fil en Bluetooth ou WiFi (pour la configuration et pour offrir un écran TCO, la compatibilité avec un logiciel du marché n’étant pas recherchée dans une première étape)
  • l’interface avec un TCO réel (optionnel, ou plusieurs) avec l’affichage de l’état du réseau (positions des aiguilles et des trains), indicateurs lumineux, boutons de commande manuelle des aiguilles, etc.. Un tel TCO sera avantageusement construit autour d’un Arduino et relié au système par I2C ou par bus CAN de préférence car plus rapide et moins sensible aux perturbations.
  • l’interface avec une ou plusieurs manettes de commande de train (avec ou sans fil, simple ou sophistiquée - à base de smartphone ou de tablette ou faite sur mesure / DIY)
  • l’interface de rétrosignalisation (détection de passage/présence des trains, reconnaissance des N°s de trains)
  • l’interface de commande d’aiguilles
  • l’interface de commande d’animations lumineuses
  • l’interface de commande d’animations sonores

Bien sûr cette liste n’est pas exhaustive... Tout dépend de la sophistication qui sera voulue. Pour ces dernières interfaces, le moyen de communication va découler de l’architecture qui est décrite.

Mais on sait d’ores et déjà que les moyens d’interconnexion entre Arduino (SPI/Can ou I2C principalement) sont intégrés au micro-contrôleur et sont extensibles à loisir, du fait de leur présence native et d’une documentation bien fournie.

Schémas d’architecture

La Figure 8 représente un exemple (parmi plein d’autres) de système composé de deux parties qui coopèrent pour assurer l’ensemble des animations d’un réseau :

  • à gauche la génération du DCC digital ou du PWM analogique, donc le pilotage des trains et l’IHM sous forme de TCO et de curseurs de commande de vitesse ;
  • et à droite le contrôle du réseau, donc les accessoires, les capteurs, la rétrosignalisation, les animations.

Ces 2 parties coopèrent grâce à une liaison série rapide (ici I2C).

Figure 8
Un exemple d’architecture globale Locoduino

Le pilotage des trains requiert la génération du signal de traction. Le comportement des trains sera la résultante des actions du ou des pilotes (manettes) et des retours de signalisation (cantons ou aiguilles libres ou occupés), signaux de ralentissement, etc..

Le pilotage d’un train nécessitant, en digital, la connaissance de son adresse DCC, il est indispensable de connaitre sa position et les contraintes liées à cette position (occupation du canton suivant, sémaphore, carré ou contrainte d’itinéraire).

L’Arduino Générateur DCC recevra donc les commandes des pilotes directement et les informations de positionnement et de cantonnement par l’intermédiaire de l’Arduino Contrôleur de réseau.

Ce dernier devra s’occuper des différents capteurs (capteurs de présence, d’occupation, d’identification, d’incidents, etc..) et des différents actionneurs (aiguilles, signaux, éclairages, sons, etc..).

Tous les deux maintiendront des tableaux de variables communes qui représentent l’état du réseau et du trafic et permettent au Générateur DCC de piloter directement les trains. Le pilotage de chaque train est la résultante de plusieurs volontés : celle du pilote (moi, mes enfants, mes amis) et celles du système (sécurité, automatismes). Cela n’enlève rien au plaisir de piloter : tout au plus, nos trains ralentissent et s’arrêtent parfois, puis redémarrent, sans accident.

Figure 9
Répartition des fonctions entre les deux Arduino

L’Arduino contrôleur du circuit, à gauche, n’a pas d’interface homme-machine. Il est chargé des détections et des actions :

  • détections d’occupation (détection de consommation, barrières infrarouges, détecteurs à effet Hall, etc..) pour les zones de ralentissement et les zones d’arrêt de chaque canton. Ces détections servent à suivre la position des trains ;
  • identification des trains (capteur RFID, code barre, etc..) pour connaître les numéros de trains, grâce à laquelle le système pourra piloter les trains par leur adresse DCC ;
  • autres capteurs (photosensibles, par exemple, pour commander des animations de jour ou de nuit)
  • commandes d’aiguilles pour positionner les aiguilles en mode droit ou dévié ;
  • commandes des signaux (feux tricolores ou feux complexes) ;
  • animations sonores correspondant aux passages des trains (annonces en gare, bruits divers) ;
  • commandes d’éclairage (éclairage public, éclairage des bâtiments et boutiques, animations lumineuses) ;
  • commandes de rotondes et passages à niveau ;
  • autres commandes selon les contextes.

Toutes les détections et l’état des dispositifs commandés seront consignés dans une table d’états qui est mise à jour à chaque détection et chaque ordre reçu de l’Arduino générateur de traction et d’IHM.

Ce dernier dispose d’une table similaire qui sert à alimenter le générateur DCC ou de traction (ralentir un train entrant dans une zone de ralentissement, changer l’état d’une aiguille pour le passage d’un train selon un itinéraire donné, etc..) et à afficher l’état du réseau sur un TCO et/ou sur un écran informatique.
Des manettes et des boutons manipulés par les pilotes transmettent des ordres qui sont acheminés vers l’Arduino contrôleur du circuit qui les exécutera en mettant sa table à jour.

Les deux tables sont synchronisées par un protocole de communication rapide tel que l’I2C ou plutôt le CAN.

Rien n’empêche de réaliser l’Arduino contrôleur du circuit et l’Arduino générateur de traction sur des bases Arduino Mega ou DUE qui offrent un grand nombre d’entrées-sorties (70). Si ce nombre n’est pas suffisant (cas d’un grand réseau), plusieurs Arduino peuvent être connectés sur le bus. Des circuits d’extension d’entrées/sorties peuvent aussi être utilisés (registres à décalages 74HC595 pour ajouter 8 sorties par boitier ou MCP23017 pour ajouter 16 entrées/sorties par boitier - 8 maximum - via I2C).

Comme indiqué au début de ce paragraphe, la répartition des fonctions dans cet exemple n’est pas la seule possible. Il serait plus évident par exemple d’associer la fonction TCO avec la connaissance de la topologie du réseau et l’état des occupations. Mais il ne faut pas oublier qu’un Arduino n’a qu’un nombre limité de ports et le découpage fonctionnel doit tenir compte des choix matériels de chacun. L’exemple plus loin éclate beaucoup plus l’architecture en modules interconnectés via un bus CAN.

Flexibilité, évolutivité

On tendra vers un système polyvalent. Petit ou grand réseau, il s’agit d’avoir la même architecture pour pouvoir l’agrandir sans changer ce qui a été fait précédemment. Dans cette optique de système polyvalent, si le réseau même petit contient bon nombre de choses, un Arduino seul ne sera pas forcément suffisant.

On notera en particulier que la transmission et la traction ne sont utilisées QUE pour commander les matériels roulants mais pas les accessoires, ce qui permet de se passer des décodeurs d’accessoires.

La technologie de communication (SPI/CAN, I2C) permettra aux Arduino de coopérer, entre eux d’une part et avec un certain nombre de périphériques d’autre part.

Figure 10
Autre répartition des fonctions entre plusieurs Arduino

Mais d’autres technologies de communication seront supportées notamment pour l’interface avec un ordinateur personnel qui supporte principalement l’USB en communication série asynchrone, le Bluetooth ou le Wifi pour le sans fil.

Compatibilité avec des modules existants

La possibilité de réaliser un système de pilotage 100% à base d’Arduino existe bien réellement et nous espérons que Locoduino vous y conduira progressivement. Mais, dans la pratique, beaucoup de modélistes voudront réutiliser certains dispositifs qu’ils possèdent déjà.

L’Arduino contrôleur du circuit pourrait, par exemple, générer le signal de rétrosignalisation du protocole S88 pour s’interfacer avec une centrale existante.

Un décodeur d’accessoires à base d’Arduino peut aussi trouver sa place dans un système comprenant un logiciel de pilotage sur PC et une centrale DCC.

Le générateur DCC pourrait être remplacé par un système de pilotage analogique.

D’autres combinaisons seront décrites dans d’autres articles.

De ces généralités découleront des projets spécifiques que vous aurez loisir de découvrir prochainement sur Locoduino !

Quelques exemples de choix d’implémentation grâce aux bibliothèques existantes et fiables

  • L’Arduino est relié aux rails via un booster et commande les trains par la librairie CmrdArduino.
  • Les aiguilles sont commandées via des servos par la librairie servo, mais aussi via des relais pour les moteurs d’aiguillage à impulsion.
  • Les Leds des feux de signalisation et des éclairages sont commandées via un étage de puissance puisque l’Arduino ne sera pas à même de fournir l’ampérage nécessaire en général.

Visitez le Forum Locoduino pour participer aux échanges sur nos expériences personnelles

Modélisation, Architectures logicielles et matérielles

On y parle des tables qui décrivent la structure du réseau (cantons, aiguilles), les itinéraires, les trains, les animations. On y parle aussi d’architecture matérielle.

Vers une gestion logicielle complète de notre réseau sans logiciel PC ? Oui tout peut-être dans les Arduino !

Mais il est bon d’y penser dès le départ.

Il y aura donc des suites à cet article...

Avertissement et conclusions

De ces concepts découleront des programmes qui ne correspondront pas forcément au réseau que vous possédez, mais ce site vous aidera à les adapter. Les différents articles qui suivront expliqueront la marche à suivre, mais une connaissance minimum de l’environnement de programmation (IDE) et du langage seront nécessaires. Comprendre vous permettra aussi de vous sortir d’un bug intempestif ou récalcitrant. Ces connaissances, Locoduino peut vous aider à les acquérir grâce aux nombreux articles sur la programmation ou le matériel.