Messages

1321

Vos projets / Re : Re : Commande d'itinéraires par arduino

« le: mars 13, 2015, 04:24:34 pm »

Par contre, on ne choisit pas le plus court. C'est souvent celui qui génère le plus d'incompatibilités avec les autres.
On décide de prendre celui qui va le plus à gauche.

C'est peut être vrai sur le réseau que tu as mis en pièce jointe mais dans le cas général, plus l'itinéraire est court et moins de nœuds du graphes sont indisponibles et plus tu as de chances de pouvoir établir un autre itinéraire.

Une fois qu'un itinéraire est construit, on ne peut plus utiliser ses aiguilles tant que le train ne les a pas "effacées" en roulant dessus.
Quand le train parcoure l'itinéraire, il en efface les aiguilles une à une.
C'est cette notion qu'on appelle "souplesse".
Une fois une aiguille effacée, elle devient immédiatement disponible pour un autre itinéraire.

Ok mais tu peux faire la même chose avec les cantons. Le seul cas où je vois une aiguille seule dans un canton c'est le cas d'une TDJ qui permet à deux cantons différents de se croiser.

Si on va jusqu'au bout du raisonnement, l'itinéraire est accroché non pas à sa voie d'origine, mais à sa voie d'extrémité.

Disons que tu le réactualises au fur et à mesure que les cantons sont libérés. Le canton occupé devenant le canton d'origine et définissant un itinéraire plus court et strictement inclus dans l'itinéraire précédent.

PS : j'ai essayé de mettre une image, mais je n'ai pas compris comment faire.

Il semble que tu aies réussi

1322

Vos projets / Re : Commande d'itinéraires par arduino

« le: mars 13, 2015, 01:38:55 pm »

Le PRS ne me semble pas si compliqué à réaliser. Effectivement il ne permet pas de calculer tous les itinéraires hors ligne pour ensuite les sélectionner car le nombre de combinaisons donnerait un volume de données trop important pour loger dans la mémoire de l'Arduino. Il faut calculer les itinéraires au vol.

Et je ne vois pas pourquoi chaque aiguille doit être gérée comme un canton.

Un réseau est un graphe dont les nœuds sont les cantons. C'est un graphe orienté par le sens de circulation. Chaque nœud à des successeurs. Calculer un itinéraire consiste à partir d'un nœud initial à le marquer puis à prendre tous les successeurs, à en faire le nœud initial etc et à parcourir récursivement le graphe jusqu'à trouver le nœud destination ou bien un nœud marqué (ce qui évite de boucler à l'infini). Si plusieurs itinéraires sont trouvés on peut choisir le plus court.

Pour calculer un nouvel itinéraire alors que d'autres sont en cours d'utilisation, il suffit de priver le graphe des nœuds utilisés par les itinéraires en cours et d'appliquer le même algorithme.

On prive également le graphe des nœuds occupés par une rame.

Evidemment l'itinéraire est réservé et un canton ne peut être emprunté par deux itinéraires.

On peut également imaginer que les itinéraires sont parcourus concurremment avec des cantons en commun et que le cantonnement empêche les collisions. Toutefois, il est probable qu'il puisse y avoir des deadlocks ou des livelocks.

1323

Vos projets / Re : Re : Micro-module en HOe

« le: mars 13, 2015, 08:48:30 am »

Je continue d'avancer pas grand chose est montrable pour le moment.

Tu as tout de même un plan ou un croquis de ce que tu veux faire

Je me posais donc la question de la distance entre un arduino et on va dire son composant commandé par exemple  une DEL.
Quelle est la distance maximale  entre les deux ?

Pas de soucis de ce côté. Tu peux avoir plusieurs mètres.

1324

Vos projets / Re : Commande d'itinéraires par arduino

« le: mars 05, 2015, 11:20:12 am »

Concernant les Tortoises :

- ils disposent de 2 paires de contact de fin de course. Une paire peut être utilisée pour renseigner l'Arduino sur la position du moteur et donc adopter cette position de départ. Pas besoin de mémoriser la position dans l'EEPROM. La mémorisation de l'itinéraire est faite par la position des moteurs et remontée à l'Arduino qui s'occupe de la commutation des itinéraires.
- ils peuvent être pilotés par un pont en H. Il en existe de très petits et très bon marché comme celui-ci : http://www.electrodragon.com/product/l9110-stepper-motor-driver-controller-board-for-arduino/ qui permettrait de piloter 2 Tortoises.

1325

Vos projets / Re : Re : Un Arduino par canton

« le: mars 03, 2015, 08:43:27 pm »

Je trouve le principe très bien pensé. Félicitations!!!

Merci 

Petites questions :
1) Comment se fait la détection? Uniquement via la mesure de la FCEM ou y a t-il autre chose qui permet de détecter la machine?

Non car quand la machine est à l'arrêt la FCEM est nulle. La détection se fait via le système classique : une serie de diodes (ici 4 pour avoir une bonne sensibilité)  quand un courant circule, on a une tension, qui est la somme des tensions de seuil des diodes en série, qui sert à saturer un transistor. Quand le courant ne circule pas, le transistor est bloqué. Ça permet de détecter une résistance de plus de 68kΩ ce qui correspond à des essieux de wagons pas très bien graphités.

2) Si je comprends bien, tu mesures la FCEM pour en déduire la vitesse de la locomotive. Cela marche ben avec des locomotives analogiques, mais cela marche t-il aussi avec des locomotives équipées de décodeurs?

Probablement pas. Le décodeur étant intercalé entre la voie et le moteur, la FCEM ne doit pas être visible. 

3) Quel logiciel utilises tu pour faire tes typons?

Canari (Mac OS X), développé par un collègue.

4) qu'appelles tu une alimentation "one step beyond"? Je ne trouve pas d'article sur le net expliquant ce que c'est...

C'était juste pour dire que ça va au delà de ce qui se fait habituellement. Ce n'est pas un terme consacré 

1326

Vos projets / Re : Commande d'itinéraires par arduino

« le: mars 03, 2015, 08:22:06 pm »

Bonsoir Sergio et bienvenue sur LOCODUINO.

200 aiguillages c'est plus que conséquent. On est dans la catégorie des très grands réseaux.

Avant de continuer, quelle est la taille en terme de distance entre les deux extrémités les plus éloignées ?

1327

Vos projets / Re : Un Arduino par canton

« le: mars 03, 2015, 05:46:49 pm »

Bonjour,

J'ai avancé sur la carte d'alimentation de canton version Arduino. Les composants tiennent sur une carte 10x10 avec un Arduino Nano aux commandes. J'ai testé sur breadboard la mesure de vitesse, l'asservissement de vitesse et la détection. Le CAN a été testé par ailleurs. Le reste attendra la carte car ça devient compliqué sur breadboard 

J'ai disposé un certains nombre de pastilles sur les signaux entre l'électronique et l'Arduino pour mettre des sondes et voir ce qui se passe.

Voici l'implantation des composants :



Le cuivre côté composants :



Le cuivre côté cuivre :



C'est compliqué mais ça fait également la détection et ça gère un canton double sens avec zone d'arrêt. C'est également une alimentation « One step beyond » car, à ma connaissance, il n'existe pas d'alimentation avec asservissement et synchronisation entre les cantons (L'alimentation avec asservissement de l'AMFN semble être monolithique). Les systèmes comme Driving Railways, LadyBug ou UTS utilisent de la tension hachée basse fréquence sans asservissement.

1328

Présentez vous ! / Re : presentation TF53

« le: mars 02, 2015, 11:24:55 pm »

Bonsoir,

J'avais pas vu ton âge Bonne école l'INSA de Rennes.

1329

Présentez vous ! / Re : Présentation de jeff

« le: mars 02, 2015, 09:45:05 am »

Bonjour et bienvenue parmi nous.

Pourrais-tu nous en dire plus sur tes projet ?

1330

Présentez vous ! / Re : presentation TF53

« le: mars 02, 2015, 09:44:25 am »

Bonjour Thimoté,

Bienvenue sur le forum de LOCODUINO. Pourrais-tu nous dire dans quelle domaine tu étudies ? info ? génie électrique ?

1331

Vos projets / Re : Un Arduino par module....ou pas.

« le: février 26, 2015, 02:46:16 pm »

Bonjour,

Une petite modif, la mise à jour des schedule tables se fait via une méthode de classe. Donc il suffit d'un appel pour tout mettre à jour :

Code: [Sélectionner]

  ScheduleTable::update();

Le github est ici : https://github.com/Koryphon/ScheduleTable

J'ai mis 3 exemples. Voici un exemple simple de feux tricolores utilisant les schedule table (j'ai écrit les commentaires en anglais, désolé)

Code: [Sélectionner]

/*
 * More complex example of the use of the ScheduleTable library
 *
 * This example uses 2 ScheduleTable with 3 actions each.
 * Each schedule table manages a traffic light.
 *
 * Each traffic light has a 30s period.
 * - Green light lasts for 13s
 * - Yellow light lasts for 2s
 * - Red light lasts for 15s
 * Schedule tables are shifted so that one light switches from
 * red to green when the other one shift from yellow to red.
 */

#include <ScheduleTable.h>
 
/* Both light cycle has 3 actions, lasts 30 time unit and has a 1000ms time base */
ScheduleTable firstLightCycle(3,30,1000);
ScheduleTable secondLightCycle(3,30,1000);

struct trafficLight {
  byte greenPin;
  byte yellowPin;
  byte redPin;
};

const struct trafficLight firstLight  = { 3, 4, 5 };
const struct trafficLight secondLight = { 6, 7, 8 };

enum { GREEN, YELLOW, RED };

void setLightState(const struct trafficLight& light, const byte state)
{
  digitalWrite(light.greenPin, LOW);
  digitalWrite(light.yellowPin, LOW);
  digitalWrite(light.redPin, LOW);
  switch (state) {
    case GREEN:  digitalWrite(light.greenPin, HIGH);  break;
    case YELLOW: digitalWrite(light.yellowPin, HIGH); break;
    case RED:    digitalWrite(light.redPin, HIGH);    break;
  }
}

void firstLightGreen()   { setLightState(firstLight, GREEN);   }
void firstLightYellow()  { setLightState(firstLight, YELLOW);  }
void firstLightRed()     { setLightState(firstLight, RED);     }
void secondLightGreen()  { setLightState(secondLight, GREEN);  }
void secondLightYellow() { setLightState(secondLight, YELLOW); }
void secondLightRed()    { setLightState(secondLight, RED);    }

void setup()
{
  pinMode(firstLight.greenPin,   OUTPUT);
  pinMode(firstLight.yellowPin,  OUTPUT);
  pinMode(firstLight.redPin,     OUTPUT);
  pinMode(secondLight.greenPin,  OUTPUT);
  pinMode(secondLight.yellowPin, OUTPUT);
  pinMode(secondLight.redPin,    OUTPUT);
 
  /* Green at start for first light */
  firstLightGreen();
  /* at 13s first light switches to yellow */
  firstLightCycle.at(13,firstLightYellow);
  /* at 15s, it switches to red */
  firstLightCycle.at(15,firstLightRed);
  /* at 30s, it switches back to green */
  firstLightCycle.at(30,firstLightGreen);

   /* Red at start for second light  */
  secondLightRed();
  /* at 15s, it switches to green */
  secondLightCycle.at(15,secondLightGreen);
  /* at 28s, it switches to yellow */
  secondLightCycle.at(28,secondLightYellow);
  /* at 30s, it switches to red */
  secondLightCycle.at(30,secondLightRed);
 
  /* starts both light forever */
  firstLightCycle.start();
  secondLightCycle.start();
}

void loop()
{
  /* update all the schedule tables at once */
  ScheduleTable::update();
}

Et l'exemple de la DEL verte de petitrain

Code: [Sélectionner]


/*
 * A third complex example of the use of the ScheduleTable library
 *
 * This example uses 3 ScheduleTable with 4 actions for the first one
 * and 1 action of the other two.
 *
 * The first schedule table manages the whole cyle with:
 * - a first action to start led dimming from 0 to 255
 * - a second action to start led dimming from 255 to 0
 * - a third action identical to the first one to start led dimming from 0 to 255
 * - a fourth action to start led dimming from 255 to 0 at faster pace
 *
 * The sketch is supposed to do the cycle in 24h but the execution is sped 1000 times
 * To change the speed, change the time base of each schedule table.
 */

#include <ScheduleTable.h>

/*
 * The Green LED cycles.
 */

/* 4 actions, period duration in seconds = 24h */
ScheduleTable greenLEDCycle(4,86400);
/* 1 action, period duration = 7200 / 255 = 28 */
ScheduleTable greenLEDPWMIncreaseCycle(1,28);
/* 1 action, period duration = 10800 / 255 = 42 */
ScheduleTable greenLEDPWMDecreaseCycle(1,42);

byte pwmGreenLED = 0;
byte pinGreenLED = 3;

/*
 * This function is called to start the increase of the PWM
 */
void startPWMIncrease()
{
  /* start the schedule table for 255 periods */
  greenLEDPWMIncreaseCycle.start(255);
}

/*
 * This function is called to start the decrease of the PWM
 */
void startPWMDecreaseFast()
{
  /* start the schedule table for 255 periods of 28s */
  greenLEDPWMDecreaseCycle.setPeriod(28);
  greenLEDPWMDecreaseCycle.start(255);
}

/*
 * This function is called to start the decrease of the PWM
 */
void startPWMDecreaseSlow()
{
  /* start the schedule table for 255 periods of 42s */
  greenLEDPWMDecreaseCycle.setPeriod(42);
  greenLEDPWMDecreaseCycle.start(255);
}

/*
 * This function is called to increase the PWM of the green LED
 */
void increaseGreenLEDPWM()
{
  pwmGreenLED++;
  analogWrite(pinGreenLED, pwmGreenLED);
}

/*
 * This function is called to decrease the PWM of the green LED
 */
void decreaseGreenLEDPWM()
{
  pwmGreenLED--;
  analogWrite(pinGreenLED, pwmGreenLED);
}

void setup() {
  pinMode(pinGreenLED,OUTPUT);
  pwmGreenLED = 0;
  analogWrite(pinGreenLED,pwmGreenLED);

 
  greenLEDCycle.at(27000,startPWMIncrease);     /* at 7:30 */
  greenLEDCycle.at(34200,startPWMDecreaseSlow); /* at 9:30 */
  greenLEDCycle.at(63000,startPWMIncrease);     /* at 17:30 */
  greenLEDCycle.at(75600,startPWMDecreaseFast); /* at 21:00 */
 
  greenLEDPWMIncreaseCycle.at(0,increaseGreenLEDPWM);
  greenLEDPWMDecreaseCycle.at(0,decreaseGreenLEDPWM);
 
  greenLEDCycle.start();
}

void loop() {
  // put your main code here, to run repeatedly:
  ScheduleTable::update();
}


1332

Vos projets / Re : Un Arduino par canton

« le: février 26, 2015, 08:30:40 am »

Bonjour,

Le github pour SyncPWM qui remplace la version postée ici en pièce jointe :

https://github.com/Koryphon/SyncPWM

1333

Vos projets / Re : Un Arduino par module....ou pas.

« le: février 25, 2015, 06:00:13 pm »

Bonjour,

Voilà, la bibliothèque est implémentée. Il s'agit d'un implémentation des tables d'ordonnancement.

J'explique la philosophie.

Il s'agit d'ordonnancer des actions dans le temps. À cet effet on définit une période qui a une durée avec un instant initial qui est l'instant de démarrage et un instant final qui est l'instant initial + la durée. Entre cet instant initial et cet instant final, on place des actions. Une action est l'appel d'une fonction que l'utilisateur fournit. La période peut ensuite être répétée entre 1 et 65535 fois ou bien infiniment.

La bibliothèque offre une classe ScheduleTable que l'on peut instancier pour créer ces périodes où des actions sont ordonnancées. Pour déclarer une ScheduleTable, on écrit par exemple :

Code: [Sélectionner]

ScheduleTable myTable(3, 200);

Le premier argument est le nombre d'actions que peut contenir la table, ici 3. Le 2e est sa durée, ici 200. Par défaut, il s'agit de millisecondes. On peut fournir un 3e argument qui donne la base de temps. Par exemple :

Code: [Sélectionner]

ScheduleTable myTable(3, 200, 100);

précise une base de temps de 100 ms. Par conséquent 200 représente 200 x 100 ms de durée. Toutes les durées relative à myTable seront exprimées en centaines de millisecondes.

Ensuite dans setup(), on place des actions à des dates relative par rapport au début de la période. Par exemple si sur notre période de 200 unités de temps on veut placer une action à 50, 60, 120, on écrira dans setup :

Code: [Sélectionner]

myTable.at(50, action1);
myTable.at(60, action2);
myTable.at(120, action3);

action1, action2 et action3 sont des fonctions définies comme suit :

Code: [Sélectionner]

void action1()
{
    Serial.print(millis());
    Serial.println(" : action 1");
}


Code: [Sélectionner]

void action2()
{
    Serial.print(millis());
    Serial.println(" : action 2");
}


Code: [Sélectionner]

void action3()
{
    Serial.print(millis());
    Serial.println(" : action 3");
}

Il faut ensuite lancer la table on peut faire ça dans setup pour que ça soit en route pour toute l'application :

Code: [Sélectionner]

myTable.start()

Ensuite, il n'y a pas de miracle, il faut appeler répétitivement la méthode update() dans loop pour que la schedule table fonctionne :

Code: [Sélectionner]

myTable.update()

On peut également stopper une schedule table :

Code: [Sélectionner]

myTable.stop();

Je poste la bibliothèque et du code exemple plus tard

1334

Vos projets / Re : Un Arduino par module....ou pas.

« le: février 22, 2015, 12:09:50 pm »

Le problème est surtout de gérer plusieurs « timelines » simultanément pas tellement d'avoir une base de temps

1335

Vos projets / Re : Un Arduino par module....ou pas.

« le: février 22, 2015, 09:22:46 am »

Ok, je m'occupe de ça