Forums LR PRESSE

Où il est question de trains, petits et grands

  • Advertisement

iChooChoo : Pilotage et automatisation de réseau

Toutes les discussions sur l'Arduino !

Modérateur: MOD

Re: iChooChoo : Pilotage et automatisation de réseau

Publié: Dim 24 Jan 2016, 01:41 
notix a écrit:Je gère mon réseau RS-485 avec Software Serial donc je garde le port série pour le debug.


Le débit doit être très faible du coup.

Y a-t-il un nombre limité d'éléments sur le réseau comme en RS-485 ?


Oui, le tranceiver CAN mpc2551 à un fan out d'une centaine de noeuds. Au delà il faut faire des passerelles.
Avatar de l’utilisateur
jlb
Fécond
 
Messages: 667
Inscrit le: Jeu 04 Oct 2012, 15:38
Echelle pratiquée: N
Prénom: Jean-Luc

Re: iChooChoo : Pilotage et automatisation de réseau

Publié: Dim 24 Jan 2016, 01:43 
Sierramike a écrit:Néanmoins merci pour le tuyau des modules CAN à bas prix, ça m'a convaincu, car à €7+ je serais directement parti sur une connexion Ethernet !


Indépendamment du prix, c'est un peu lourdingue un ethernet pour du contrôle-commande :)
Avatar de l’utilisateur
jlb
Fécond
 
Messages: 667
Inscrit le: Jeu 04 Oct 2012, 15:38
Echelle pratiquée: N
Prénom: Jean-Luc

Re: iChooChoo : Pilotage et automatisation de réseau

Publié: Dim 24 Jan 2016, 10:37 
Avec le bon composant il y a très peu de code pour faire marcher l'ethernet, par contre tu vas beeeeeeaaaauuuucoup plus loin en taille de trame, l'espace d'adressage devient immense, et tu as au moins du 10Mbit/s en vitesse de transmission... De plus, ton cerveau peut devenir n'importe quelle machine reliée au réseau, plus besoin de connexion "électronique" à un module (donc tu peux compiler ton cerveau dans une appli mobile ou sur un serveur Linux qui pourrait être une simple VM sur un serveur domestique, voir même un module sur un NAS synology avec un peu de connaissances...)
Sierramike
 
Messages: 12
Inscrit le: Mar 12 Jan 2016, 15:47
Echelle pratiquée: N
Prénom: Stéphane

Re: iChooChoo : Pilotage et automatisation de réseau

Publié: Dim 24 Jan 2016, 11:03 
Oui, sur le papier c'est mieux mais
- les 10Mbits ne sont pas atteints car le micro de l'Arduino ne peut pas débiter autant. En pratique ça plafonne à 3,34Mbits sans traitement côté Arduino.
- les grosses trames ne sont pas nécessaires car on transfère pas de gros paquets de données dans nos applications
- les temps de transmission ne sont pas bornés car ni ethernet ni TCP/IP n'offrent de garanties temps réel.
- il faut ajouter des switchs et câbler un reseau en étoile alors que la topologie de nos applications, grosso modo on suit la voie, est plus adaptée à un bus.

Enfin rien n'empêche d'ajouter un ethernet ou un module WiFi en bout de chaîne pour connecter un terminal quelconque mais pour ma part cette interaction sera pour la configuration et le pilotage manuel mais pas pour les automatismes.
Avatar de l’utilisateur
jlb
Fécond
 
Messages: 667
Inscrit le: Jeu 04 Oct 2012, 15:38
Echelle pratiquée: N
Prénom: Jean-Luc

Re: iChooChoo : Pilotage et automatisation de réseau

Publié: Dim 24 Jan 2016, 13:21 
Je suis d'accord avec ton analyse, et je vais en rajouter une couche (attention, je ne cherche à défendre ni une solution ni l'autre, juste à discuter de faits "scientifiques" :) ):
- Les 10 Mbits ne sont pas atteints entre deux Arduinos, mais un "cerveau" à base de Raspberry ou de PC par exemple, peut envoyer ses diverses trames à 100Mbit/s sur le réseau, et c'est le switch qui s'occupera d'envoyer les bonnes trames aux bons équipements sont sont les Arduinos, qui eux "indivituellement" répondront moins vite.
- Concernant la taille des trames, le bus CAN me pose déjà un soucis puisque j'ai défini qu'il me faudra des trames de 20 octets alors que le CAN ne supporte que 8 octets à la fois ...
- En effet, pas de garanties temps réel, mais vu ce qu'on commande, les délais seront suffisemment courts. D'ailleurs le CAN qui (ou alors j'ai mal compris), intègre un protocole de ré-émission de paquet s'il n'est pas reçu, introduira forcément un lag également !
- Effectivement côté câblage c'est moins pratique de se baser sur de l'ethernet ...
Sierramike
 
Messages: 12
Inscrit le: Mar 12 Jan 2016, 15:47
Echelle pratiquée: N
Prénom: Stéphane

Re: iChooChoo : Pilotage et automatisation de réseau

Publié: Dim 24 Jan 2016, 13:30 
Sierramike a écrit:Je suis d'accord avec ton analyse, et je vais en rajouter une couche (attention, je ne cherche à défendre ni une solution ni l'autre, juste à discuter de faits "scientifiques" :) ):


Pareil :)

- Les 10 Mbits ne sont pas atteints entre deux Arduinos, mais un "cerveau" à base de Raspberry ou de PC par exemple, peut envoyer ses diverses trames à 100Mbit/s sur le réseau, et c'est le switch qui s'occupera d'envoyer les bonnes trames aux bons équipements sont sont les Arduinos, qui eux "indivituellement" répondront moins vite.


Je suis d'accord

- Concernant la taille des trames, le bus CAN me pose déjà un soucis puisque j'ai défini qu'il me faudra des trames de 20 octets alors que le CAN ne supporte que 8 octets à la fois ...


Ah, explique ce que tu veux faire

- En effet, pas de garanties temps réel, mais vu ce qu'on commande, les délais seront suffisemment courts. D'ailleurs le CAN qui (ou alors j'ai mal compris), intègre un protocole de ré-émission de paquet s'il n'est pas reçu, introduira forcément un lag également !


en cas d'erreur de transmission, c'est extrêmement rare. Sinon c'est déterministe avec une priorité fixe, la trame la plus prioritaire passe sans collision.
Avatar de l’utilisateur
jlb
Fécond
 
Messages: 667
Inscrit le: Jeu 04 Oct 2012, 15:38
Echelle pratiquée: N
Prénom: Jean-Luc

Re: iChooChoo : Pilotage et automatisation de réseau

Publié: Lun 25 Jan 2016, 10:21 
Pour la longueur des trames, il faudrait terriblement jongler pour rentrer dans 8 octets, en tous cas ce serait moins propre. Par exemple pour ma commande de lancement de circulation
Octet 1 : Groupe de commande (1 = Config, 2 = Traction, 3 = ...)
Octet 2 : Commande (1 = GetStatus, 2 = Démarrage circulation, 3 = Allumage lumières, 4 = ...)
Octet 3 : Numéro du circuit d'alimentation
Octet 4 : Sens de circulation (polarité)
Octet 5 : Vitesse de démarrage (0 à 255)
Octet 6 : Vitesse cible (0 à 255)
Octet 7 : Vitesse d'arrêt (0 à 255)
Octets 8 et 9 : durée d'accélération en millisecondes (entier 16 bits)
Octets 10 et 11 : durée de décélération en millisecondes (entier 16 bits)
Octet 12 : condition d'arrêt (ID du capteur)

et j'utilise les deux derniers octets comme CRC16 pour valider l'intégrité de la transmission.

Alors ok, je pourrais grouper les octets 3 et 4 en un seul, je pourrais diminuer les durées en entier 8 bits en utilisant des multiples de 50ms, et plus gênant, n'utiliser qu'un seul octet pour identifier la commande, mais je risque d'être short avec 255 commandes, là je tiens sur 8 octets pour ce cas précis, sans CRC.

Est-ce que le bus CAN intègre la gestion de l'intégrité de la transmission ?
Sierramike
 
Messages: 12
Inscrit le: Mar 12 Jan 2016, 15:47
Echelle pratiquée: N
Prénom: Stéphane

Re: iChooChoo : Pilotage et automatisation de réseau

Publié: Lun 25 Jan 2016, 14:03 
Il y a pas mal d'infos dans tes trames de données qui dans une messagerie CAN serait géré via les identifiants de message. J'ai lu la page de ton site consacré au protocole

Je distinguerais 2 types de message : les messages de commandes, utilisés en fonctionnement normal et les messages de services destinés à configurer les carte. J'imagine dans ce cas que la carte est seule sur le bus.

<Les messages de commandes pourraient utiliser les trame standard (identifiants de 11 bits) et les messages de de service les trames étendues (identifiants de 29 bits)

Sierramike a écrit:Pour la longueur des trames, il faudrait terriblement jongler pour rentrer dans 8 octets, en tous cas ce serait moins propre. Par exemple pour ma commande de lancement de circulation
Octet 1 : Groupe de commande (1 = Config, 2 = Traction, 3 = ...)
Octet 2 : Commande (1 = GetStatus, 2 = Démarrage circulation, 3 = Allumage lumières, 4 = ...)
Octet 3 : Numéro du circuit d'alimentation


Tout ou partie de ces infos passe dans l'identifiant

Octet 4 : Sens de circulation (polarité)


1 bit donc 1 octets si on ne cherche pas à optimiser

Octet 5 : Vitesse de démarrage (0 à 255)
Octet 6 : Vitesse cible (0 à 255)
Octet 7 : Vitesse d'arrêt (0 à 255)


Ok

Octets 8 et 9 : durée d'accélération en millisecondes (entier 16 bits)
Octets 10 et 11 : durée de décélération en millisecondes (entier 16 bits)


Comme tu le dis en prenant des multiples de 50ms, on arrive à 255 x 0,05 = 12,75 secondes

2 octets

Octet 12 : condition d'arrêt (ID du capteur)


Là je ne sais pas donc 1 octet

On est à 7 octets


et j'utilise les deux derniers octets comme CRC16 pour valider l'intégrité de la transmission.


Inutile pour le CAN c'est intégré et géré par le matériel

Sinon, j'ai pas vraiment compris l'usage des modules traction
Avatar de l’utilisateur
jlb
Fécond
 
Messages: 667
Inscrit le: Jeu 04 Oct 2012, 15:38
Echelle pratiquée: N
Prénom: Jean-Luc

Re: iChooChoo : Pilotage et automatisation de réseau

Publié: Lun 25 Jan 2016, 17:44 
Il faudra alors que j'approfondisse cette histoire d'identifiants de messages sur le bus CAN, de toute manière j'ai commandé 5 modules CAN donc je ferai ces expérimentations, histoire de choisir le protocole le plus adapté.

Intéressante ta dernière remarque sur mes modules traction, ça signifie que mes explications ne sont probablement pas très claires et qu'il faudra que je ré-écrive une partie. En fait, un module traction S (small) par exemple, va gérer 2 tractions, comprendre l'alimentation de deux portions de voies pour faire circuler un train, il gère aussi la détection de passage/présence de train pour garantir la coupure de l'alimentation à l'arrivée du train.

Grosso modo un ordre à un module traction est une "action" :
Sur ta sortie 1, fais circuler un train dans le sens A en faisant une accélération de 60 à 168 en 2000ms, jusqu'à détection sur le capteur C3 puis décélération de 168 à 50 en 2000ms.

L'idée c'est de laisser un Arduino maîtriser sa chaîne de traction, y compris la condition d'arrêt, car si c'est un autre Arduino qui gère les capteurs, si ce dernier est en panne, il n'enverra pas la trame d'arrêt et le train ne s'arrêtera pas.
Mais c'est aussi que chaque Arduino puisse exécuter des actions maîtrisées individuellement mais sans jamais avoir besoin de savoir où il se situe dans la chaîne de commandement. C'est le cerveau qui s'en occupe, en l'occurence dans mon archi un Raspberry Pi, sur lequel je n'ai pas de contrainte de taille de code, et qui pourra gérer la connectivité Ethernet de façon stable, qui pourra servir de vrai serveur Web etc. pour la partie commande manuelle, tout en étant capable de jouer des scénarii automatiques.

Du coup, pour aller jusqu'au bout dans la description, comment je vois le raccordement d'un nouvel Arduino, contrairement à ce que tu penses, pas un module "seul sur la ligne" pour lui injecter la conf et après on le positionne, et le jour où on doit le modifier ou le remplacer car grillé, on doit rechercher la conf à lui injecter.

On prend un "module" neuf (un Arduino Nano neuf par exemple), on lui injecte un programme universel, et on le raccorde au bus (I2C pour l'instant). Au démarrage, l'Arduino trouve une EEPROM vide, il se met donc en adresse 0x77 (la valeur max), à l'écoute des ordres du groupe 0x01 qui servent à la conf.
Le cerveau détecte un module en adresse 0x77 et me propose de le configurer. Je lui dis alors de le mettre en adresse 0x56 (par exemple) et que ce sera un module "Traction S". Le cerveau envoie donc l'ordre de config vers l'adresse 0x77, l'Arduino stocke cette conf dans son EEPROM, puis le cerveau envoie un ordre de "Reset", et l'Arduino redémarre et se comporte maintenant en module "Traction S" à l'adresse 0x56. Fini, terminé.
Le reste c'est le cerveau qui, en fonction du paramétrage global du circuit que j'établirai sur ce même cerveau, enverra les ordres d'actions citées plus haut.

Je peux même faire envoyer un ordre "Hard reset" à l'adresse 0x56, et l'Arduino à cette adresse effacera son EEPROM et fera un reset, et se retrouvera comme un module "neuf", prêt à être configuré.

De cette manière, si je veux changer le moindre comportement, je fais tout sur un fichier de configuration sur le Raspberry Pi, je n'ai rien à toucher aux modules Arduino. Du côté des modules Arduino, c'est "industrialisé", ils contiennent tous le même programme et se configurent via la ligne une fois connectés. N'importe quel Arduino est donc remplaçable à souhait, pas besoin de maintenir plusieurs programmes pour les flasher, ils sont tous identiques.
Sierramike
 
Messages: 12
Inscrit le: Mar 12 Jan 2016, 15:47
Echelle pratiquée: N
Prénom: Stéphane

Re: iChooChoo : Pilotage et automatisation de réseau

Publié: Lun 25 Jan 2016, 20:54 
Ce que je n'ai pas compris concernant les modules traction c'est leur fonction exacte. La description parle de gestion de l'accélération, de la décélération et de la vitesse. Il y a également la détection des trains.

Mais ça manque de précision.

Je suppose que tu es en analogique.

As tu un module d'alimentation par canton ? Comment alimentes tu les locomotives exactement ? Quelle est l'électronique ? As tu un asservissement de vitesse ou bien es tu en boucle ouverte ? Si tu as plusieurs modules d'alimentation, comment les synchronises tu ? Comment est géré le passage d'une alimentation à l'autre ? Si une loco passe d'une alimentation à l'autre en phase de décélération ou d'accélération, comment garanties tu que la vitesse est identique sur les deux modules d'alimentation ? Pourquoi t'embêtes tu avec des détecteurs infra-rouge ou des ILS qui ont le défaut d'être des dispositifs de détection évènementiels alors que les modules d'alimentation peuvent savoir si une locomotive est présente dans la portion de rails alimentés ?

Ok pour le module générique que tu peux reconfigurer même si le logiciel risque d'être un peu complexe. Ceci dit les pannes dues à un matériel grillé ne sont pas fréquentes. Est ce que ceci nécessite un logiciel plus complexe ?
Avatar de l’utilisateur
jlb
Fécond
 
Messages: 667
Inscrit le: Jeu 04 Oct 2012, 15:38
Echelle pratiquée: N
Prénom: Jean-Luc

Re: iChooChoo : Pilotage et automatisation de réseau

Publié: Mar 26 Jan 2016, 10:58 
jlb a écrit:Ce que je n'ai pas compris concernant les modules traction c'est leur fonction exacte. La description parle de gestion de l'accélération, de la décélération et de la vitesse. Il y a également la détection des trains.

Mais ça manque de précision.

Je suppose que tu es en analogique.

As tu un module d'alimentation par canton ? Comment alimentes tu les locomotives exactement ? Quelle est l'électronique ? As tu un asservissement de vitesse ou bien es tu en boucle ouverte ? Si tu as plusieurs modules d'alimentation, comment les synchronises tu ? Comment est géré le passage d'une alimentation à l'autre ? Si une loco passe d'une alimentation à l'autre en phase de décélération ou d'accélération, comment garanties tu que la vitesse est identique sur les deux modules d'alimentation ? Pourquoi t'embêtes tu avec des détecteurs infra-rouge ou des ILS qui ont le défaut d'être des dispositifs de détection évènementiels alors que les modules d'alimentation peuvent savoir si une locomotive est présente dans la portion de rails alimentés ?


Ah en fait tu n'as pas lu la première page du site, où j'explique le but du projet :

Les objectifs de la première version sont :

- Piloter les trains en mode analogique sur un réseau simple
- Commander les éclairages et accessoires
- Utilisable depuis un Smartphone et/ou une tablette

La première version pourra être facilement utilisée sur un petit réseau à vocation automatique, où les trains ont des déplacements simples d’un point A à un point B. Sur des réseaux plus conséquents aux manœuvres plus compliquées, le système pourra néanmoins être utilisé en complément, pour la gestion de l’éclairage, des accessoires etc., et également de diverses navettes ferroviaires.

Ce système n’aura jamais la vocation de remplacer une centrale de commande DCC.


Donc pour l'instant, il n'y a aucune gestion de cantons, de manoeuvres etc. Mon but premier c'est de pouvoir lancer des circulations d'un quai d'une gare à un quai d'une autre gare. Pour avoir une accélération identique je lance l'accélération simultanément sur les deux (ou plus, deux maximum en l'occurence sur mon réseau en construction) sections de voie sur lesquelles la circulation a lieu. Et si j'ai une rampe (en l'occurence j'en ai une), j'augmente la tension (la valeur PWM en l'occurence) sur la rampe, et je définis mes valeurs par tâtonnement dans un premier temps.
Par exemple, si la section A est à plat, et la section B est une rampe à 4%, je vais lancer simultanément :
Circulation A, sens 1, accélération de 60 à 150 en 2000ms, décélération de 150 à 50 en 2000ms sur détection C3.
Circulation B, sens 1, accélération de 70 à 180 en 2000ms, décélération de 180 à 60 en 2000ms sur détection c3.

Ca, c'est la première version. Evidemment je pense à l'asservissement de vitesse, mais ce sont des technos à découvrir pour moi, et je compose avec le temps libre que j'ai. Et mon but, c'est d'avoir aussitôt que possible un réseau "jouable", plutôt que de développer pendant 5 ans une liste de fonctionnalités longue comme mon bras et me lasser entre temps ... Donc, version 1 : ça fonctionne, les trains circulent. Après il sera temps d'améliorer pour la version 2 !
Le projet a vu le jour à partir de mon besoin et de celui de mon frère (qui prévoit un grand circuit tour de pièce, mais dont les circulations sont toutes gérées par une centrale DCC). J'ai choisi de rendre le projet public et OpenSource pour qu'il puisse servir à tous ceux que ça intéresse, et puisse même être complété/amélioré par ceux qui le souhaitent, il n'a pas vocation à devenir l'ultime système de commande adapté à 100% des situations ;)
Ceci explique que la gestion des cantons et des circulations plus complexes ne fait pas partie du cahier des charges de la version 1, tout simplement ;)

Concernant capteurs IR / ILS, mon but est de détecter la position d'un train pour l'arrêter. D'ailleurs je ne pense pas utiliser d'ILS mais pour d'autres raisons (j'ai fait une tentative il y a longtemps, pour allumer/éteindre un passage à niveau sur le réseau de mon père, mais en N, pas facile de trouver la place pour positionner l'aimant au même endroit sous chaque train, de plus le train est si léger que le wagon porteur d'aimant faisait une "oscillation" à chaque fois que l'aimant s'aimantait à une vis de vixation des rails, autremant dit tous les 6 à 8 cm ...).
Effectivement une alimentation peut détecter si la locomotive passe sur une section de voie, mais si j'ai une gare terminus avec une voie de 40cm sur laquelle vont devoir s'arrêter des trains de 30 à 35cm, il va me falloir être précis sur l'arrêt. Et si un train est un autorail qui capte le courant sur l'avant, et l'autre train est un petit train touristique de 3 petits wagons poussés par une loco vapeur (comme je l'ai vu plusieurs fois en réel en montagne), là la captation de courant se fait par l'arrière, pas évident de détecter précisément la position du train via l'alimentation ! Du coup je vais tester la barrière IR et le détecteur de distance à ultra-sons, mais ce dernier est volumineux et difficile à cacher.

jlb a écrit:Ok pour le module générique que tu peux reconfigurer même si le logiciel risque d'être un peu complexe. Ceci dit les pannes dues à un matériel grillé ne sont pas fréquentes. Est ce que ceci nécessite un logiciel plus complexe ?


Le logiciel n'est pas forcément beaucoup plus complexe, en revanche je ne vois pas que l'avantage sur les modules grillés, mais aussi sur les modifications de réseau dans le temps, et aussi pour faciliter la configuration. Je sais par expérience (pour travailler dans l'informatique), que partout où c'est possible, on cherche à centraliser la gestion d'un parc et la configuration d'un système, parce qu'il est plus simple quand on souhaite faire un changement, de le faire sur le "serveur", plutôt que de parcourir les "clients" l'un après l'autre pour aller appliquer les modifications. C'est le principe même de l'Active Directory (et en l'occurence des GPO), pour ne citer que le plus connu.

Ici, en l'occurence, le jour où j'ai envie de modifier un fonctionnement sur un recoin d'un réseau de 12 mètres de long (un tour de pièce quoi), je n'ai pas envie d'avoir à me pencher sous la planche, repérer un numéro que j'aurais écrit sur l'Arduino, puis fouiller dans un dossier avec une cinquantaine de codes sources pour chercher à comprendre ce que j'avais fait pour celui-là, le modifier, chercher l'Arduino pour le brancher au PC, le reprogrammer, le remettre en place etc. Je préfère aller ouvrir un fichier de conf sur le serveur et le modifier, et hop c'est parti.
Et si vraiment cela nécessite une évolution dans le code de gestion des Arduinos, j'ai un code source standard à ouvrir et à modifier, et je sais que je peux le flasher indifféremment ensuite sur mes Arduinos sans me poser de question. Je ferai passer mon code source par exemple de la version 1.0.1 à la version 1.0.2, et à une requête d'identification sur mon bus (I2C ou CAN), le module répondra sa version qui me permettra d'un seul coup d'oeil de savoir si mes modules sont à jour ou pas ...

Et du coup je me permets de mettre un lien sur un autre forum (j'espère que ce n'est pas contre les règles), où je présente mon projet de réseau, ça aidera peut être à comprendre mon cahier des charges initial :
http://le-forum-du-n.forumotions.net/t24041-projet-de-reseau-hivernal-en-table-basse
Sierramike
 
Messages: 12
Inscrit le: Mar 12 Jan 2016, 15:47
Echelle pratiquée: N
Prénom: Stéphane

Re: iChooChoo : Pilotage et automatisation de réseau

Publié: Mar 26 Jan 2016, 18:43 
Bonjour Stéphane,

Cela fait un moment que je suis cette passionnante discussion d'experts entre Jean-Luc et toi. Alors, CAN, I2C ? Je me garderais bien de donner une opinion vu que je ne suis pas très fort dans ce domaine. Mais Jean-Luc est un "pointu" donc je ne doute pas qu'il pourra te donner de bons conseils.

D'un autre côté, j'ai pu me rendre compte que tu as déjà bien prévu ton projet et souvent avec beaucoup de bon sens.


Sierramike a écrit:
Les objectifs de la première version sont :

- Piloter les trains en mode analogique sur un réseau simple
- Commander les éclairages et accessoires
- Utilisable depuis un Smartphone et/ou une tablette

La première version pourra être facilement utilisée sur un petit réseau à vocation automatique, où les trains ont des déplacements simples d’un point A à un point B. Sur des réseaux plus conséquents aux manœuvres plus compliquées, le système pourra néanmoins être utilisé en complément, pour la gestion de l’éclairage, des accessoires etc., et également de diverses navettes ferroviaires.

Ce système n’aura jamais la vocation de remplacer une centrale de commande DCC.


.....
Ca, c'est la première version. Evidemment je pense à l'asservissement de vitesse, mais ce sont des technos à découvrir pour moi, et je compose avec le temps libre que j'ai. Et mon but, c'est d'avoir aussitôt que possible un réseau "jouable", plutôt que de développer pendant 5 ans une liste de fonctionnalités longue comme mon bras et me lasser entre temps ... Donc, version 1 : ça fonctionne, les trains circulent. Après il sera temps d'améliorer pour la version 2 !


C'est toujours ce que j'ai conseillé, commencer par une version simplifiée de ce qu'on veut faire, puis compliquer cette version petit à petit. Ta démarche me parait donc très seine et te garantira de bons résultats assez rapidement. Je constate trop souvent des gens qui veulent se lancer dans une usine à gaz trop vite.

Sierramike a écrit:Le projet a vu le jour à partir de mon besoin et de celui de mon frère (qui prévoit un grand circuit tour de pièce, mais dont les circulations sont toutes gérées par une centrale DCC). J'ai choisi de rendre le projet public et OpenSource pour qu'il puisse servir à tous ceux que ça intéresse, et puisse même être complété/amélioré par ceux qui le souhaitent, il n'a pas vocation à devenir l'ultime système de commande adapté à 100% des situations ;)
Ceci explique que la gestion des cantons et des circulations plus complexes ne fait pas partie du cahier des charges de la version 1, tout simplement ;)


L'OpenSource est l'esprit même d'Arduino : faire en sorte que le travail réalisé serve à tous. Nous y adhérons tous à locoduino et notre but est bien de mettre l'expérience de tous au service de tous.

Sierramike a écrit:Concernant capteurs IR / ILS, mon but est de détecter la position d'un train pour l'arrêter. D'ailleurs je ne pense pas utiliser d'ILS mais pour d'autres raisons (j'ai fait une tentative il y a longtemps, pour allumer/éteindre un passage à niveau sur le réseau de mon père, mais en N, pas facile de trouver la place pour positionner l'aimant au même endroit sous chaque train, de plus le train est si léger que le wagon porteur d'aimant faisait une "oscillation" à chaque fois que l'aimant s'aimantait à une vis de vixation des rails, autremant dit tous les 6 à 8 cm ...).
Effectivement une alimentation peut détecter si la locomotive passe sur une section de voie, mais si j'ai une gare terminus avec une voie de 40cm sur laquelle vont devoir s'arrêter des trains de 30 à 35cm, il va me falloir être précis sur l'arrêt. Et si un train est un autorail qui capte le courant sur l'avant, et l'autre train est un petit train touristique de 3 petits wagons poussés par une loco vapeur (comme je l'ai vu plusieurs fois en réel en montagne), là la captation de courant se fait par l'arrière, pas évident de détecter précisément la position du train via l'alimentation ! Du coup je vais tester la barrière IR et le détecteur de distance à ultra-sons, mais ce dernier est volumineux et difficile à cacher.


C'est vrai que les ILS n'ont pas que des qualités, surtout à l'échelle N. Comme les réseaux sont éclairés depuis le haut, je pense qu'il est possible de remplacer l'ILS par une photorésistance qui envoie un signal quand le train la plonge dans l'ombre. De plus, pas besoin d'équiper les trains et cela fonctionne même en pousse.

Je pense qu'un détecteur à ultrasons est difficile à mettre en oeuvre et très gros pour le camoufler sur un réseau N.

Sierramike a écrit: ...

Et du coup je me permets de mettre un lien sur un autre forum (j'espère que ce n'est pas contre les règles), où je présente mon projet de réseau, ça aidera peut être à comprendre mon cahier des charges initial :
http://le-forum-du-n.forumotions.net/t24041-projet-de-reseau-hivernal-en-table-basse


Tant que ce lien n'est pas commercial, je ne pense pas que la modération dira quelque chose. D'ailleurs, nous ne nous gênons pas pour mettre des liens vers le site locoduino car les deux sites se complémentent. Locoduino a l'avantage de proposer des articles de fond dans lesquelles le modéliste peut puiser, ici, il s'agit plutôt de discussions à bâtons rompus mais dès qu'un fil n'est plus alimenté, il risque d'être oublié (je l'ai souvent constaté).

En tout cas, j'applaudis des deux mains :applause: cette discussion ; elle te permettra d'avancer dans de bonnes conditions ton projet et donnera des idées concrètes à ceux qui sont confrontés à des problèmes similaires. Maintenant, je me retire sur la pointe des pieds car, comme je l'ai dit, je ne suis pas un spécialiste dans ce domaine. :wink:
Avatar de l’utilisateur
Arduino
Prolixe
 
Messages: 1630
Inscrit le: Mer 25 Sep 2013, 16:14

Re: iChooChoo : Pilotage et automatisation de réseau

Publié: Mer 27 Jan 2016, 15:45 
Entre temps, un nouvel article qui explique comment développer et expérimenter sur le Raspberry Pi et sur l'Arduino à distance (Arduino connecté en USB au Raspberry Pi), pour le laisser tranquillement branché dans le bureau ou à la cave, et faire ses expérimentations depuis le canapé, le train ou la chambre d’hôtel en déplacement !

http://ichoochoo.ztb.fr/arduino/avrdude-lautonomie-du-raspberry/

C'est très technique, mais ça peut vous servir, et j'ai essayé d'être le plus exhaustif possible dans les explications et les étapes à suivre pour tout installer, paramétrer et exécuter.
Sierramike
 
Messages: 12
Inscrit le: Mar 12 Jan 2016, 15:47
Echelle pratiquée: N
Prénom: Stéphane

Re: iChooChoo : Pilotage et automatisation de réseau

Publié: Mer 27 Jan 2016, 16:05 
Arduino a écrit:Bonjour Stéphane,

Cela fait un moment que je suis cette passionnante discussion d'experts entre Jean-Luc et toi. Alors, CAN, I2C ? Je me garderais bien de donner une opinion vu que je ne suis pas très fort dans ce domaine. Mais Jean-Luc est un "pointu" donc je ne doute pas qu'il pourra te donner de bons conseils.

D'un autre côté, j'ai pu me rendre compte que tu as déjà bien prévu ton projet et souvent avec beaucoup de bon sens.


Merci pour ces quelques mots ! Sur le choix de techno, j'ai passé l'âge d'essayer de convaincre que mon choix est le meilleur de la terre, je prends les infos de tous et j'expérimente pour me faire mon propre avis, puis je fais un choix qui me convient, en sachant que si plusieurs technologies existent, c'est qu'elles répondent à divers besoins !

J'ai effectivement déjà beaucoup réfléchi à ce projet, et comme j'ai un passif important en tant que développeur et architecte en informatique, forcément ça déteint sur mes choix et mes implémentations ...

Arduino a écrit:C'est toujours ce que j'ai conseillé, commencer par une version simplifiée de ce qu'on veut faire, puis compliquer cette version petit à petit. Ta démarche me parait donc très seine et te garantira de bons résultats assez rapidement. Je constate trop souvent des gens qui veulent se lancer dans une usine à gaz trop vite.


C'est aussi ce qui fait que l'informatique est ce qu'elle est aujourd'hui, si on avait attendu d'avoir la version parfaite de Windows qui fait tout et ne plante jamais, nous en serions encore à la calculette et à la machine à écrire ;)

Arduino a écrit:L'OpenSource est l'esprit même d'Arduino : faire en sorte que le travail réalisé serve à tous. Nous y adhérons tous à locoduino et notre but est bien de mettre l'expérience de tous au service de tous.


Absolument et la démarche est excellente, d'ailleurs dès que j'ai le temps je vous rédige un article pour apporter une petite pierre à votre bel édifice !

Arduino a écrit:C'est vrai que les ILS n'ont pas que des qualités, surtout à l'échelle N. Comme les réseaux sont éclairés depuis le haut, je pense qu'il est possible de remplacer l'ILS par une photorésistance qui envoie un signal quand le train la plonge dans l'ombre. De plus, pas besoin d'équiper les trains et cela fonctionne même en pousse.

Je pense qu'un détecteur à ultrasons est difficile à mettre en oeuvre et très gros pour le camoufler sur un réseau N.


Ah pas bête l'idée de la photorésistance, à creuser aussi, merci !
Le détecteur à Ultrasons me semble aussi peu pertinent, mais je veux quand même le tester, d'une part pour la culture, et d'autre part parce que dans une gare cachée, peut-être qu'il peut répondre à un besoin !

Arduino a écrit:Tant que ce lien n'est pas commercial, je ne pense pas que la modération dira quelque chose. D'ailleurs, nous ne nous gênons pas pour mettre des liens vers le site locoduino car les deux sites se complémentent. Locoduino a l'avantage de proposer des articles de fond dans lesquelles le modéliste peut puiser, ici, il s'agit plutôt de discussions à bâtons rompus mais dès qu'un fil n'est plus alimenté, il risque d'être oublié (je l'ai souvent constaté).


Disons que je ne veux froisser personne dans la "concurrence entre les forums", sur d'autres thèmes je suis déjà tombé sur ce genre de couacs, alors je ne veux pas commettre d'impairs !
En effet la discussion semble à bâtons rompus avec jlb mais j'adore ça, ma maxime c'est que même une discussion où personne n'est d'accord, et d'où on sort sans être tombés d'accord, a tout de même fait avancer le Schmilblick pour tout le monde !
Alors surtout Jlb, j'espère ne pas te vexer dans mes réponses et n'hésite pas à continuer à me répondre pour alimenter le débat :)

Arduino a écrit:En tout cas, j'applaudis des deux mains :applause: cette discussion ; elle te permettra d'avancer dans de bonnes conditions ton projet et donnera des idées concrètes à ceux qui sont confrontés à des problèmes similaires. Maintenant, je me retire sur la pointe des pieds car, comme je l'ai dit, je ne suis pas un spécialiste dans ce domaine. :wink:


Aucun soucis, au contraire, tu as probablement des milliers de choses à m'apprendre toi aussi ;)
Sierramike
 
Messages: 12
Inscrit le: Mar 12 Jan 2016, 15:47
Echelle pratiquée: N
Prénom: Stéphane

Re: iChooChoo : Pilotage et automatisation de réseau

Publié: Mar 09 Fév 2016, 01:22 
Ca avance sur iChooChoo, comme j'ai réussi à faire transmettre des trames de 20 octets dans chaque sens entre le Raspberry Pi et l'Arduino, j'ai peaufiné mon code source et j'ai ajouté les fonctions permettant de configurer et gérer les modules depuis la ligne de commande.

Ca donne la première pré-version de iChooChoo v0.10, désormais librement téléchargeable sur GitHub. Bien sûr on ne fait pas encore bouger de train, mais le socle commun de communication via le bus i2c est complet.

http://ichoochoo.ztb.fr/ichoochoo/premiere-pre-version-disponible-0-10/
Sierramike
 
Messages: 12
Inscrit le: Mar 12 Jan 2016, 15:47
Echelle pratiquée: N
Prénom: Stéphane

PrécédentSuivant

Retour vers Arduino

Qui est en ligne ?

Utilisateur(s) parcourant actuellement ce forum : Petitrain et 3 invité(s)