Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Sujets - Jean-Luc

Pages: 1 2 [3] 4
31
Bus CAN / Moniteur CAN
« le: avril 30, 2016, 07:29:57 pm »
Bonjour,

Pour permettre de développer plus facilement le logiciel des cartes avec du CAN, j'ai commencé un Moniteur CAN.

En substance c'est un sketch que l'on met sur une carte avec du CAN (la carte 8 servos par exemple) et qui va permettre d'afficher des messages CAN reçu sur le terminal mais également de changer la vitesse du CAN et d'envoyer des messages. Les messages entrant ne sont pas affichés en direct mais transitent dans un tampon circulaire de 16 emplacements et l'on peut activer ou désactiver l'affichage.

Pour l'instant c'est ce que ça fait.

Je vais ajouter l'envoi de messages périodiques mais également des commandes dédiées aux cartes Locoduino (la carte 8 servos mais également la carte pont tournant).

J'ai poussé la version initiale qui est fonctionnelle sur le gitlab de locoduino : https://git.framasoft.org/locoduino.org/MoniteurCAN

J'ai encore des plantages qui se traduisent par un reset

La ligne série est programmée à 115200. Il suffit de taper help pour avoir les commandes


32
Bonjour,

Je voudrais présenter un Design Pattern, ou patron de conception : le Proxy, appliqué à un système en contrôle commande décentralisé en réseau.

En POO, les patrons de conception sont des architectures logicielles réutilisables dans de nombreux cas.

Un Proxy est une « classe qui se substitue à une autre classe » ce qui hors contexte ne veut pas dire grand chose. Prenons un exemple concret : un système de commande de réseau en DCC formé d'un Arduino gestionnaire central, d'un Arduino jouant le rôle de centrale DCC et d'Arduino pilotant des actionneurs d'aiguillage, d'autres Arduino gérant la détection de présence, etc.

Le gestionnaire central doit donc :
  • envoyer des ordres aux trains (la locomotive qui le tracte) en communicant avec le calculateur DCC
  • envoyer des ordres aux actionneurs d'aiguillages en envoyant des messages CAN
  • recevoir la position des trains via des messages CAN
  • recevoir la position des aiguillages via des messages CAN (en effet, la position effective ne correspond pas à l'ordre donné, du moins pas tout de suite)

Idéalement le gestionnaire central devrait pouvoir manipuler un train ou un aiguillage sans se soucier de la manière d'interagir, c'est la que le Proxy entre en scène.

Supposons que nous ayons une classe Train avec les méthodes fixeVitesse (fixe la vitesse du train) et position (retourne le canton où se situe le train). Le gestionnaire interagit avec les objets de cette classe, donnant, pour chacun d'entre eux, la vitesse à intervalles régulier et récupérant la position.

Supposons également que nous ayons une classe Aiguillage avec les méthodes positionneDroit et positionneDevie pour commander la position et une méthode position pour retourner la position de l'Aiguillage. De même le gestionnaire interagit avec les objets de cette classe.

Train::fixeVitesse effectue la communication avec l'Arduino DCC
La position retournée par Train::position est possiblement actualisée au gré de l'arrivée des messages CAN indiquant l'occupation des canton

Aiguillage::positionneDroit et Aiguillage::positionneDevie effectuent l'envoi d'un message CAN correspondant
La position retournée par Aiguillage::positionne est actualisée au gré de l'arrivée des messages CAN indiquant l'état des aiguillages.

Ces objets sont des proxy, ils agissent pour le compte d'objets distants mais donnent l'impression au gestionnaire central que ce sont de simples objets en mémoire.

À noté qu'ils permettent également, via le polymorphisme, de concevoir un gestionnaire indépendamment de la technologie DCC/Analogique sous jacente et indépendamment du type de carte utilisées sur le réseau.

33
Bonjour,

Ma petite contribution à la modélisation.

Ayant travaillé sur l'approche objet pour la gestion d'un gare cachée, les articles sont en attente de publication, j'ai fait des classes pour chaque type de voie : aiguille, voie d'extrémité de la gare et voie en gare. Les classes en question sont instanciées et les objets sont connectés pour former un graphe. Une recherche de chemin est ensuite faite pour trouver une voie libre ou pour relier l'entrée à une voie ou bien une voie à la sortie. Le défaut est que le graphe est orienté ce qui fait qu'un aiguillage va connaître les voies en aval mais pas en amont. Donc partant de l'entrée, on trouve une voie en gare, idem partant de la sortie mais on ne trouve pas un chemin de l'entrée vers la sortie par exemple.

Titillé par DDEFF, j'ai généralisé l'idée à un graphe où chaque nœud (bout de voie) connaît ses voisins. Comme exemple, j'ai choisi la gare de DDEFF que j'ai re-dessinnée en PECO code 55 (gare dont on peut déduire deux choses d'ailleurs : 1) Ça va coûté un bras à DDEFF, rien qu'en appareils de voie, il y en a pour 1300€, 2) DDEFF a de la place, la gare fait 4,2m de long. Bref je suis jaloux !  ;D)

Je vous mets le lien vers le PDF : La gare de DDEFF en PDF

J'ai donc défini une classe abstraite de base, Voie :

class Voie
{
  private:
    byte mIdentifiant;
    byte mDirection;
 
  protected:
    void fixeDirection(byte dir);
   
  public:
    Voie(byte identifiant) { mIdentifiant = identifiant; mDirection = AUCUNE_DIRECTION; }
    byte idVoie() { return mIdentifiant; }
    byte direction() { return mDirection; }
    virtual void connecteDeVoie(Voie *voie, byte connecteur) = 0;
    virtual bool creeCheminVers(byte identifiant, byte dir, Voie *venantDe = NULL) = 0;
};

Une voie a : 1) un identifiant, 2) une direction. On l'instancie en lui donnant un identifiant et par défaut il n'y a pas de direction fixée. La direction est fixée plus tard lorsque le graphe est construit.

connecteDeVoie permet d'établir une connexion entre deux voies, j'explique ci-dessous. creeCheminVers permet de trouver un chemin entre deux nœuds du graphe (entre deux bout de voies) en suivant une direction.

Ensuite, j'ai 5 classes :

1) les voies de garage qui n'ont qu'un seul connecteur : SORTANT



2) les voies normales qui ont 2 connecteurs : ENTRANT et SORTANT



3) les aiguillages qui ont 3 connecteurs : ENTRANT, SORTANT_DROIT et SORTANT_DEVIE



4) les traversées de jonction double (on peut ajouter également les simples) qui ont 4 connecteurs : ENTRANT, SORTANT, ENTRANT_BIS et SORTANT_BIS
5) les croisement qui ont également 4 connecteurs



Un sens normal de parcours est également défini : de entrant vers sortant.

34
Shields et Modules / Carte Pont tournant
« le: février 13, 2016, 03:41:19 pm »
J'ai donc redessiné la carte pont tournant en format 10x10. La roue codeuse est marginalement plus petite car j'ai mis les capteurs sur la disgonale.

J'en ai profité pour ajouter le CAN et le DCC

Voici les schémas :

http://www.locoduino.org/pic/CartePontTournant/CartePontTournant.pdf

Et une partie des typons :






35
Shields et Modules / Carte Servomoteurs DCC + CAN
« le: janvier 14, 2016, 06:12:22 pm »
Bonsoir,

J'ai été hors course ces derniers temps mais je ne suis pas resté complètement inactif.

Voici donc une carte destinée à piloter 8 servomoteurs et raccordable au bus DCC et au bus CAN.

La carte comporte
- une alimentation pour les servos (un 7805, certains modèles délivrent 1,5A)
- un Arduino Nano
- un contrôleur CAN et un transceiver
- une interface DCC
- 2 connecteur RJ11 pour le CAN
- un bornier pour le DCC
- un bornier pour l'alim 9 à 12V
- 8 connecteurs pour les servos
- optionnellement un expandeur d'I/O pour lire des fins de course
- J'ai casé un détecteur de coupure d'alim pour la sauvegarde en EEPROM

J'ai réussi à tout faire tenir sur une carte 10x5 cm

Voici les schémas : http://www.locoduino.org/pic/carteServoCANDCC/schematique.pdf

Les typons :

Recto





Verso





Le logiciel reste à faire. Il se basera sur SlowMotionServo

36
Bibliothèques / Bibliothèque LcdUI
« le: mai 04, 2015, 11:51:50 am »
Viendra ensuite LcdUI qui permet de réaliser -assez- facilement une interface utilisateur un peu évoluée (Splash Screen, écrans de saisie entier, chaine, booléen, choix multiples, enchaînements d'écrans et messages d'interruption...).

J'ai vu que tu as comité ce projet hier sur framasoft. Ça m'intéresse :) Je cherchais justement ce type de bibliothèque et je veux bien utiliser/tester ;)

37
Shields et Modules / Carte « Cerveau du réseau »
« le: avril 22, 2015, 05:07:23 pm »
Bonjour à tous,

j'ouvre ce fil pour déterminer les fonctions et composants à intégrer sur une carte destinée à piloter un réseau, que ce soit en analogique ou DCC.

Dans le pilotage, j'inclus le dialogue avec les Arduino en charge de :
  • la détection de présence
  • la commande des aiguillages
  • la commande des ponts tournants
  • la commande de la signalisation
  • ...

Mais aussi l'anticollision, les itinéraires, la circulation automatique, la connaissance et la gestion des trains, ...

En DCC, cette carte servirait de centrale.
En analogique, elle piloterait également les cartes Traction.
Elle remplacerait le PC pour le pilotage du réseau.

L'Arduino ciblé pour cela est l'Arduino Due pour les raisons suivants :
  • 512ko de Flash permettant de mettre de très gros programme et quantité de constantes de configuration du réseau.
  • 96ko de RAM permettant de stocker beaucoup de données (12 fois plus que sur un Mega, 48 fois plus que sur un Uno)
  • Processeur 32 bits à 84 MHz ce qui permet d'en avoir sous le pied
  • 2 interfaces CAN natives

Le prix n'est pas un problème puisque le Due serait en exemplaire unique et on trouve des compatibles Due à 15€.

Le Due serait épaulé par un Nano pour générer des signaux précis temporellement sans être embêtés par les interruptions (comptage de temps, Interruption I2C, interruptions CAN, etc). Il s'agit de générer précisément le signal DCC en DCC et les signaux de synchro pour les cartes traction en analogique. Il effectuerait également la surveillance du booster DCC. La communication entre Due et Nano se ferait par le bus SPI.

Sur cette carte 10x10cm, le Due et le Nano viendrait s'enficher par dessous. Par dessus on aurait un emplacement pour mettre un LCD 20x4. On aurait également :
  • Deux transceivers CAN 2551 pour les deux CAN du due
  • Des prises RJ11/RJ45 pour le CAN/CAN avec synchro analogique
  • Un emplacement pour mettre une UART Bluetooth
  • Un connecteur pour branche le booster (LMD18200)
  • Un connecteur I2C pour déporter un LCD
  • Des boutons et switches pour interagir sans PC.
  • Un régulateur 9v (7809) avec radiateur pour pouvoir accepter des tensions d'alimentation plus élevées que 12v

N'hésitez pas à mettre votre grain de sel !

38
Shields et Modules / Alimentation traction de canton (analogique)
« le: avril 17, 2015, 02:44:55 pm »
Bonjour,

Il y a une dizaine de jours, j'ai reçu le PCB de la carte traction à base d'Arduino Nano. Le voici :



Après quelques heures, les composants sont montés sauf le CAN :



Je vous tiens au courant des avancées ;-)

39
Bibliothèques / Bibliothèque CommandInterpreter
« le: avril 14, 2015, 10:20:05 am »
Bonjour,

Je ne sais pas si vous êtes comme moi mais lors de la mise au point de programmes un peu plus compliqués que le basique, je reflashe pas mal l'Arduino. Par ailleurs, pour configurer une application, valeurs par défaut de variables, configuration en EEPROM, ... c'est assez pénible.

Il m'est donc venu à l'idée d'utiliser une interface ligne de commande qui tournerait sur l'Arduino. Il y en a qui existent mais pas forcément comme je veux. J'ai donc fait la mienne.

L'idée est d'avoir sur l'Arduino une interface en ligne de commande qui gère la communication sur la ligne série, attend des commandes et les exécute. Les commandes sont à coder sous forme de fonction et peuvent avoir des arguments. La bibliothèque gère également un historique de 8 commandes pour ne pas avoir à les retaper et deux commandes internes : hist qui permet d'afficher l'historique des commandes et help qui affiche l'aide. Le tampon d'entrée est de 20 caractères et la saisie au delà de ce tampon est gérée.

Côté logiciel sur le PC/Mac, il faut un logiciel de terminal plus sérieux que celui inclus dans l'IDE Arduino, j'aime beaucoup CoolTerm qui est multiplateforme : http://freeware.the-meiers.org mais, Guillaume va râler, il n'est pas libre. Sinon il y a minicom et un tas d'autres.
Les paramètres de connexion sont la vitesse qui dépend du Serial.begin() de votre appli, 8 bits de données, pas de parité, 1 bit de stop, pas de contrôle de flot. Comme ceci :



Il faut également ne pas avoir d'écho local et prendre en charge le backspace



La bibliothèque est ici : https://git.framasoft.org/Koryphon/CommandInterpreter/repository/archive.zip. Une fois décompressée, on obtient un dossier CommandInterpreter.git. Enlever le .git et placer le dossier dans libraries.

J'ai inclus deux exemples : un interpréteur avec 3 commandes pour lire, écrire et avoir la taille de l'EEPROM, un interpréteur pour changer et afficher l'état de la led 13.

En résumé, il faut :

  • Instancier un objet de type CommandInterpreter avec comme argument de constructeur la ligne série utilisée
  • Instancier un objet de type Command pour chaque commande avec 3 arguments : le nom de la commande, la fonction à appeler, une chaîne d'aide
  • écrire pour chaque commande une fonction à appeler. Ces fonctions prennent 2 arguments : une référence vers un CommandInterpreter (ce qui permet de récupérer la ligne série employée et chaque argument), un byte qui est le nombre d'arguments
  • dans setup, ajouter les commandes à l'interpréteur via la méthode addCommand
  • dans loop, appeler CommandInterpreter::update() pour que l'interaction avec l'utilisateur se fasse

On a alors un moniteur qui fonctionne en « tâche de fond » pourvu qu'il n'y ait aucun appel à des delay longs dans le programme.

Avec les flèches haut / bas, on peut se balader dans l'historique, une fois une entrée de l'historique sélectionnée elle peut bien entendu être éditée. L'historique ne stocke pas une nouvelle commande si la précédente est identique.

40
Bibliothèques / Bibliothèque SlowMotionServo
« le: mars 26, 2015, 06:16:57 pm »
Bonjour à tous,

En me replongeant dans le travail que j'avais effectué pour piloter 8 servo-moteurs, voir la série d'articles sur mon blog, j'ai voulu remettre les choses à plat.

En effet, quand on pilote un servo-moteur pour bouger les aiguilles d'un aiguillage, on se moque un peu de la manière dont le mouvement est effectué, du moment qu'il est lent. J'avais donc fait un mouvement linéaire sans phase d'accélération ou de décélération. Donc le plus basique possible.

Voulant maintenant manœuvrer des portes de remise, je voulais un mouvement réglable en vitesse, mais aussi que la position angulaire suive une trajectoire qui ne soit pas forcément une droite. Je veux par exemple que la porte vienne en butée puis rebondisse et s'arrête progressivement.

je me suis demandé si il n'existait pas une bibliothèque pour effectuer des mouvements lents sur les servo-moteurs et je n'ai absolument rien trouvé.

J'en ai donc fait une.

On peut donc pour chaque servo :

  • définir les positions minimum et maximum ;
  • régler la vitesse indépendamment dans chaque sens de déplacement ;
  • définir une trajectoire quelconque sous la forme d'une courbe mathématique ;

3 trajectoires sont disponibles toutes faites :
- linéaire
- accélération puis décélération en sinus
- accélération en sinus, rebond sur la butée et décélération en 1/temps

Pour l'instant j'ai un prototype qui tourne mais il faut que je finisse de monter une remise pour montrer le mouvement des portes :) Il faut également que je vérifie que l'Arduino arrive à calculer des fonctions complexes pour 8 servos sans que le mouvement en pâtisse.

Je me servirai de cette bibliothèque pour mettre à jour le logiciel pour piloter 8 servo-moteurs.

Elle disponible via le gestionnaire de bibliothèques de l’IDE

41
Bus CAN / Le bus CAN
« le: février 03, 2015, 04:16:53 pm »
Nous avions démarré en interne une discussion sur le bus CAN qui a débouché sur la réalisation d'un module permettant d'expérimenter le bus sur un Arduino. La carte réalisée est visible sur le fil voisin : BreakoutBoard CAN. Ce développement a été entrepris car les shields CAN sont mystérieusement hors de prix (20€ et plus). 

Le bus CAN est déjà utilisé dans notre hobby. Il y a tout d'abord le MERG (Model Electronic Railway Group). Organisation anglaise qui a choisi le CAN pour interconnecter les modules qu'elle développe. L'explication est donnée ici : http://www.merg.org.uk/merg_resources/cbus.php

Ensuite il y a Zimo qui a choisi le bus CAN comme bus de rétro signalisation : http://www.zimo.at/web2010/aboutus/highlights_EN.htm

Enfin il y a CAN Digital Bahn : http://www.can-digital-bahn.com/news.php

J'utilise moi même le CAN sur mon réseau (2 bus en fait, l'un à 125kb et l'autre à 700kb+)

Des informations concrètes suivront sur le site éditorial.

42
Infos et bonnes affaires / ElectroDragon rime avec service client
« le: janvier 30, 2015, 05:51:51 pm »
Bonsoir,

Lors de ma dernière commande chez ElectroDragon, j'ai pris un Visduino pour voir comment ça marchait. La carte compatible Uno coûte $4.90. http://www.electrodragon.com/product/arduino-compatible-visduino-uno-r3/



J'ai eu un petit problème de qualité dessus. Après deux branchements du câble sur le connecteur USB, le connecteur s'est dessoudé. Les pattes de fixation du connecteur étaient mal soudées. J'ai ressoudé avec quelques difficultés pour les broches du connecteurs car elles sont proches et on est gêné par le quartz. Finalement tout marchait bien.

J'ai ensuite contacté ElectroDragon pour signaler le problème tout en leur disant que j'avais réparé la carte. Le contact m'a proposé un remboursement ou un bon d'achat (sans préciser la somme). J'ai choisi le bon d'achat qui s'est avéré être de $9  ;D presque 2 fois le prix de la carte :)

43
Vos projets / Un Arduino par canton
« le: janvier 15, 2015, 06:36:28 pm »
Bonjour,

Il s'agit ici de faire du cantonnement sur un réseau analogique. L'idée est de pouvoir piloter un réseau « comme en numérique » avec une grosse différence : les « décodeurs » sont associés aux cantons et non aux locomotives.

Ce n'est pas une idée nouvelle, feu Driving Railways faisait cela. Mais il s'agit d'aller un peu plus loin en ayant une régulation de vitesse (compensation de charge dans le jargon).

Une première solution est de faire un arbre de relais qui permet d'associer une alimentation à un ou plusieurs cantons.

Une autre solution consiste à associer une alimentation pilotée par un Arduino à chaque canton. En plus de l'alimentation du canton, il assure la détection de présence et, idéalement, la mesure de vitesse de la locomotive qui occupe le canton.

C'est cette seconde solution qui est choisie.

Une première chose à faire est de synchroniser les PWM de tous les cantons. En effet, si les PWM ne sont pas synchrones, une locomotive à cheval sur 2 cantons recevra une impulsion plus longue et verra sa vitesse modifiée tant qu'elle est à cheval. Elle fera donc potentiellement un petit bond à chaque passage d'un canton au suivant.

Voici donc une bibliothèque qui assure la synchronisation des PWM de plusieurs Arduino. Elle utilise le timer2 dans un mode de PWM particulier qui permet d'ajuster finement la fréquence.

Un Arduino maître diffuse un signal de synchronisation aux autres Arduino, le code exemple est dans MasterClock. Le signal de synchro sort sur la broche 3.

Avec l'exemple SyncPWM, chaque Arduino affecté à un canton génère une PWM synchronisée sur la broche 3 et reçoit le signal de synchro sur la broche 8.

La fréquence de la PWM est d'un peu moins d'1kHz. l'erreur maxi entre 2 PWM, du moins ce que j'ai pu mesurer à l'oscillo, est d'environ 8µs. Les valeurs possibles pour la PWM vont de 0 à 254.

À 1kHz, le signal de synchro devrait pouvoir voyager sur une certaine distance (combien ? faut voir). Au delà, il faut passer en différentiel.

Si vous avez des questions, n'hésitez pas.

La bibliothèque :

https://dl.dropboxusercontent.com/u/67740546/SyncPWM.zip

44
Infos et bonnes affaires / Bonne Année
« le: janvier 01, 2015, 10:01:42 am »
Meilleurs vœux a tous pour 2015  ;)

Que vos projets, et bien entendu vos projets ferroviaires et arduinesques soient couronnés de succès.   :)

45
Débuter / Comment perdre son temps :)
« le: décembre 26, 2014, 07:15:37 pm »
Bonjour.

Petite mésaventure cet après-midi qui peut servir à d'autres. J'ai un encodeur en quadrature sur un de mes projets. C'était une occasion de faire un article et de montrer l'emploi des interruptions. Un encodeur se présente comme un potentiomètre mais il est généralement cranté et, correctement connecté avec des résistances de pullup de 10kΩ, chaque passage de cran génère une impulsion sur les deux sorties. Selon le sens de rotation, l'impulsion de la première sortie est en avance ou en retard sur la seconde. Ce qui fait que sur le front descendant de l'impulsion d'une des sorties, une lecture de la seconde permet de déterminer le sens de rotation. Pour utiliser un encodeur on branche donc une sortie sur une entrée interruption de l'Arduino et on lit l'état de la seconde dans l'ISR. Voir Les interruptions.

Comme j'ai prêté un de mes 2 Uno et que le second était sur mon TCO, j'ai attrapé un compatible Léonardo que j'ai acheté sur eBay il y a peu et un LCD Keypad shield. Je branche l'encodeur, la broche commune sur la masse, une des sorties en quadrature sur l'entrée INT0, aka D2, et l'autre sur D3.

Rien ne marchait correctement le comportement était erratique ou bien aucune interruption ne pétait. Quand je manipulais la carte, mes gros doigts pleins de charges électrique déclenchaient pourtant des interruptions. Je commence par accuser les cartes chinoises d'eBay, le LCD keypad shield d'abord. J'enlève le LCD, passe sur la ligne série. Toujours rien de cohérent. J'accuse le Leonardo. Finalement je constate une erreur dans le programme. Comme premier argument de attachInterrupt, j'avais mis la constante que j'avais initialisé avec le numéro de broche, c'est à dire 2 au lieu de 0. Je rectifie. Fonctionnement toujours étrange, quelque soit le sens de rotation, le compteur que j'incrémente ou décrémente selon le sens de rotation ne fait que s'incrémenter  :o

Je finis par chercher le brochage du Leonardo. Bingo ! alors que je pensais qu'il avait des entrées/sorties identiques à celle du Uno, ce n'est pas du tout le cas. INT0 et INT1 sont inversées ! et sur les broches 0 et 1 on a deux entrées supplémentaires d'interruption : INT2 et INT3.

Dans un premier temps, en appelant attachInterrupt avec 2 comme 1er argument, j'activais les interruptions sur INT2, broche qui était en l'air. En manipulant la carte, la broche attrapait mes charges électrique et les interruptions pétaient.

Dans un second temps, comme INT1 et INT0 sont inversés, la broche sensible aux interruptions étaient également celle où je lisais la valeur pour déterminer le sens de rotation. Comme l'interruption pétait sur le front descendant, la valeur était toujours 0  :P

Moralité : quand on utilise une nouvelle carte, on regarde la doc avant de se lancer. Ça évite de perdre du temps  ;D
Moralité 2 : quand on écrit un article sur les interruptions, on s'y conforme soi-même !

Pages: 1 2 [3] 4