P15 Réseau de capteurs temps réel - Historique des versions

Elopes : /* Livrables */

2018-02-21T13:13:23Z

‎Livrables

Elopes : /* Calcul et utilisation de LQI et RSSI */

2018-02-21T10:46:25Z

‎Calcul et utilisation de LQI et RSSI

Elopes : /* Conclusion */

2018-02-21T00:03:39Z

‎Conclusion

Elopes : /* Bibliographie */

2018-02-20T23:57:51Z

‎Bibliographie

Elopes : /* Archive Git */

2018-02-20T23:57:35Z

‎Archive Git

Elopes : /* Conclusion */

2018-02-20T23:30:27Z

‎Conclusion

Elopes : /* Description du modèle NTP « client/serveur » implémenté */

2018-02-20T11:01:08Z

‎Description du modèle NTP « client/serveur » implémenté

Elopes : /* Description du modèle NTP « client/serveur » implémenté */

2018-02-20T11:00:23Z

‎Description du modèle NTP « client/serveur » implémenté

Elopes : /* Description du modèle NTP « client/serveur » implémenté */

2018-02-20T10:59:51Z

‎Description du modèle NTP « client/serveur » implémenté

Elopes : /* Description du modèle NTP « client/serveur » implémenté */

2018-02-20T10:58:23Z

‎Description du modèle NTP « client/serveur » implémenté

← Version précédente		Version du 21 février 2018 à 13:13
Ligne 500 :		Ligne 500 :

	[[Fichier:Rapport_mi_parcours.pdf ]]		[[Fichier:Rapport_mi_parcours.pdf ]]
		+
		+	'''Rapport final'''
		+
		+	[[Fichier:Rapport PFE15 LOPES.pdf]]

@@ Ligne 194 : / Ligne 194 : @@
 La fonction qui calcul le rang d'un nœud, en fonction des indicateurs et le RSSI:
-  //Avec base_rank=256, rssi <= 28 et <=255
+  //Avec base_rank=256, rssi <= 28 et lqi <=255
   add = 256 - (parent->mc.rssi + parent->mc.lqi)/10;
   my_rank = base_rank + add;

← Version précédente		Version du 21 février 2018 à 00:03
Ligne 479 :		Ligne 479 :
	L'application mise en place, est une application basée sur du temps réel grâce au système d'exploitation RIOT. En effet RIOT permet la programmation d'applications en langages C et C++ ainsi que le multithreading et le temps réel. La capacité en temps réel est possible grâce à une interruption de latence très faible (~ 50 cycles d'horloge) et à une programmation basée sur les priorités.		L'application mise en place, est une application basée sur du temps réel grâce au système d'exploitation RIOT. En effet RIOT permet la programmation d'applications en langages C et C++ ainsi que le multithreading et le temps réel. La capacité en temps réel est possible grâce à une interruption de latence très faible (~ 50 cycles d'horloge) et à une programmation basée sur les priorités.

−	Durant ce projet on a put mettre en place deux type de réseau: un réseau statique et l'autre dynamique (avec le protocole RPL). Le temps de latence du réseau statique est presque toujours le même ( vu que le taille du message ne change pas 32 bytes), sauf que celui augmente lorsque l'on ajoute un nœud dans le réseau. Dans le cas d'un réseau statique la latence varie en fonction du déplacement du robot; par exemple si le robot choisi le nœud racine comme sont parent lors des déplacements la latence sera plus petite contrairement si sont parent était un nœud qui se trouve à un saut du nœud racine.	+	Durant ce projet on a put mettre en place deux type de réseau: un réseau statique et l'autre dynamique (avec le protocole RPL). Le temps de latence du réseau statique est presque toujours le même ( vu que le taille du message ne change pas, 32 bytes), sauf que celui augmente lorsque l'on ajoute un nœud dans le réseau. Dans le cas d'un réseau statique la latence varie en fonction du déplacement du robot; par exemple si le robot choisi le nœud racine comme sont parent lors des déplacements la latence sera plus petite contrairement si sont parent était un nœud qui se trouve à un saut du nœud racine.

@@ Ligne 487 : / Ligne 487 : @@
 http://riot-os.org/files/RIOT-Seminar-2017/RIOT-Spring-Seminar-Song.pdf
 https://twatteyne.files.wordpress.com/2013/05/watteyne06intersense_pres.pdf
 https://riot-os.org/api/
 ==Archive Git==

← Version précédente		Version du 20 février 2018 à 23:57
Ligne 483 :		Ligne 483 :

	Le nœud robot est piloté par des commandes provenant du nœud racine; Afin de s'assurer que la requête est bien arrivée à sa destination, une fois que le nœud racine envoie la commandes, il attend (25 ms max) un retour de la part du robot. S'il ne reçoit aucun retour, un message est affiché disant: <<mode auto>>. Côté robot on attend 5 seconds, s'il ne reçoit rien on passe en mode manu, ce mode dure 15 seconds si aucun message n'est toujours pas arrivé, ensuite il s’arrête.		Le nœud robot est piloté par des commandes provenant du nœud racine; Afin de s'assurer que la requête est bien arrivée à sa destination, une fois que le nœud racine envoie la commandes, il attend (25 ms max) un retour de la part du robot. S'il ne reçoit aucun retour, un message est affiché disant: <<mode auto>>. Côté robot on attend 5 seconds, s'il ne reçoit rien on passe en mode manu, ce mode dure 15 seconds si aucun message n'est toujours pas arrivé, ensuite il s’arrête.
		+
		+	==Bibliographie==
		+
		+	http://riot-os.org/files/RIOT-Seminar-2017/RIOT-Spring-Seminar-Song.pdf
		+	https://twatteyne.files.wordpress.com/2013/05/watteyne06intersense_pres.pdf
		+	https://riot-os.org/api/
		+
		+

	==Archive Git==		==Archive Git==

← Version précédente		Version du 20 février 2018 à 23:30
Ligne 476 :		Ligne 476 :

	==Conclusion==		==Conclusion==
		+
		+	L'application mise en place, est une application basée sur du temps réel grâce au système d'exploitation RIOT. En effet RIOT permet la programmation d'applications en langages C et C++ ainsi que le multithreading et le temps réel. La capacité en temps réel est possible grâce à une interruption de latence très faible (~ 50 cycles d'horloge) et à une programmation basée sur les priorités.
		+
		+	Durant ce projet on a put mettre en place deux type de réseau: un réseau statique et l'autre dynamique (avec le protocole RPL). Le temps de latence du réseau statique est presque toujours le même ( vu que le taille du message ne change pas 32 bytes), sauf que celui augmente lorsque l'on ajoute un nœud dans le réseau. Dans le cas d'un réseau statique la latence varie en fonction du déplacement du robot; par exemple si le robot choisi le nœud racine comme sont parent lors des déplacements la latence sera plus petite contrairement si sont parent était un nœud qui se trouve à un saut du nœud racine.
		+
		+
		+	Le nœud robot est piloté par des commandes provenant du nœud racine; Afin de s'assurer que la requête est bien arrivée à sa destination, une fois que le nœud racine envoie la commandes, il attend (25 ms max) un retour de la part du robot. S'il ne reçoit aucun retour, un message est affiché disant: <<mode auto>>. Côté robot on attend 5 seconds, s'il ne reçoit rien on passe en mode manu, ce mode dure 15 seconds si aucun message n'est toujours pas arrivé, ensuite il s’arrête.

	==Archive Git==		==Archive Git==

← Version précédente		Version du 20 février 2018 à 11:01
Ligne 471 :		Ligne 471 :


−	[[Fichier:Latency.png\|center\|~~400px~~\|thumb\| 2 nœuds: réseau statique]]	+	[[Fichier:Latency.png\|center\|700px\|thumb\| 2 nœuds: réseau statique]]

	Comme nous pouvions le voir, la longueur du paquet a une influence sur le temps de transmission. Globalement, cette évolution est linéaire.		Comme nous pouvions le voir, la longueur du paquet a une influence sur le temps de transmission. Globalement, cette évolution est linéaire.

← Version précédente		Version du 20 février 2018 à 11:00
Ligne 471 :		Ligne 471 :


−	[[Fichier:Latency.png\|center\|thumb\| 2 nœuds: réseau statique]]	+	[[Fichier:Latency.png\|center\|400px\|thumb\| 2 nœuds: réseau statique]]

	Comme nous pouvions le voir, la longueur du paquet a une influence sur le temps de transmission. Globalement, cette évolution est linéaire.		Comme nous pouvions le voir, la longueur du paquet a une influence sur le temps de transmission. Globalement, cette évolution est linéaire.

← Version précédente		Version du 20 février 2018 à 10:59
Ligne 471 :		Ligne 471 :


−	[[Fichier:Latency.png\|center]]	+	[[Fichier:Latency.png\|center\|thumb\| 2 nœuds: réseau statique]]

	Comme nous pouvions le voir, la longueur du paquet a une influence sur le temps de transmission. Globalement, cette évolution est linéaire.		Comme nous pouvions le voir, la longueur du paquet a une influence sur le temps de transmission. Globalement, cette évolution est linéaire.

← Version précédente		Version du 20 février 2018 à 10:58
Ligne 472 :		Ligne 472 :

	[[Fichier:Latency.png\|center]]		[[Fichier:Latency.png\|center]]
		+
		+	Comme nous pouvions le voir, la longueur du paquet a une influence sur le temps de transmission. Globalement, cette évolution est linéaire.

	==Conclusion==		==Conclusion==