Binome2017-9 - Historique des versions

Rex le 16 juillet 2018 à 15:38

2018-07-16T15:38:38Z

Dtillaux le 23 mai 2018 à 09:38

2018-05-23T09:38:21Z

Rbonvale : /* Conclusion */

2018-05-07T08:46:04Z

‎Conclusion

Rbonvale : /* Réalisation du projet */

2018-05-06T10:12:00Z

‎Réalisation du projet

Dtillaux le 5 mai 2018 à 15:47

2018-05-05T15:47:22Z

Dtillaux : /* Nos erreurs lors du projet */

2018-05-05T15:40:45Z

‎Nos erreurs lors du projet

Dtillaux le 5 mai 2018 à 15:05

2018-05-05T15:05:48Z

Dtillaux : /* Les difficultés rencontrées */

2018-05-05T15:04:22Z

‎Les difficultés rencontrées

Dtillaux : /* Les difficultés rencontrées */

2018-05-05T15:03:03Z

‎Les difficultés rencontrées

Dtillaux : /* Réalisation du code Arduino */

2018-05-05T14:53:20Z

‎Réalisation du code Arduino

← Version précédente		Version du 16 juillet 2018 à 15:38
Ligne 1 :		Ligne 1 :
		+	<include nopre noesc src="/home/pedago/ppeip/include/video-Robot_Binome09_2017-iframe.html" />
		+	__TOC__
		+	<br style="clear: both;">
	Binôme 9 saison 8: Raphaël Bonvalet, Damien Tillaux.		Binôme 9 saison 8: Raphaël Bonvalet, Damien Tillaux.

← Version précédente		Version du 23 mai 2018 à 09:38
Ligne 23 :		Ligne 23 :

	Voici les différentes étapes par lesquels nous sommes passés lors de la création de Quireekoo.		Voici les différentes étapes par lesquels nous sommes passés lors de la création de Quireekoo.
		+
		+
		+	= Liste des objets récupérés =
		+
		+	- sonar
		+	- led infra-rouge
		+	- 2 servos-moteurs
		+	- boitier de pile
		+	- 6 piles
		+	- 1 bille
		+	- 1 tsop

← Version précédente		Version du 7 mai 2018 à 08:46
Ligne 571 :		Ligne 571 :

	Lorsque nous avons commencé à penser au projet, nous avons pensé à faire un robot le plus petit possible pour être le plus dur à attraper. Pour cela, nous avions décidé d'utiliser des servos-moteurs pour le déplacement. Nous pensions que la vitesse de rotation était suffisante pour avoir un robot plutôt rapide. La vitesse n'est alors pas si lente que ça mais nous nous attendions à mieux. Une question vient alors ce poser: aurait-il mieux fallut mettre des moteurs et non des servos-moteurs? Le défauts des moteurs est que ceci prennent alors plus de place et donc le robot n'est plus aussi petit que la taille voulut au départ. Nous avons alors conclut que les servos-moteurs restaient alors la meilleur solution pour le déplacement.		Lorsque nous avons commencé à penser au projet, nous avons pensé à faire un robot le plus petit possible pour être le plus dur à attraper. Pour cela, nous avions décidé d'utiliser des servos-moteurs pour le déplacement. Nous pensions que la vitesse de rotation était suffisante pour avoir un robot plutôt rapide. La vitesse n'est alors pas si lente que ça mais nous nous attendions à mieux. Une question vient alors ce poser: aurait-il mieux fallut mettre des moteurs et non des servos-moteurs? Le défauts des moteurs est que ceci prennent alors plus de place et donc le robot n'est plus aussi petit que la taille voulut au départ. Nous avons alors conclut que les servos-moteurs restaient alors la meilleur solution pour le déplacement.
−
−	~~= Conclusion =~~
−
−	~~Nous sommes très content d'avoir fait ce projet et de l'avoir fini dans les temps. Quireekoo fonctionne très bien et est comme nous voulions le concevoir à l'origine.~~

@@ Ligne 22 : / Ligne 22 : @@
-Voici les différentes étapes par lesquels nous sommes passer lors de la création de Quireekoo.
+Voici les différentes étapes par lesquels nous sommes passés lors de la création de Quireekoo.
@@ Ligne 38 : / Ligne 38 : @@
 === Notre PCB ===
-Notre PCB a été réalisé sur Fritzing. Nous avons créer ce circuit imprimé à notre image pour notre véhicule. Nous avons enlevé le driver de moteur et les sorties moteurs car nous voulions un robot de petite taille. Donc le moyen de déplacement choisi a alors été le servo-moteur. Pour les réceptions infra-rouge nous n'avons prévu que deux sorties pour des Tsop pour pouvoir laisser un plus grande chance au chasseur de ne pas être repéré, pour une approche plus vrai que nature. Pour savoir si un chasseur nous a attrapé, nous utilisons une sonde de Hall.
+Notre PCB a été réalisé sur Fritzing. Nous avons créé ce circuit imprimé à notre image pour notre véhicule. Nous avons enlevé le driver de moteur et les sorties moteurs car nous voulions un robot de petite taille. Donc le moyen de déplacement choisi a alors été le servo-moteur. Pour les réceptions infra-rouge nous n'avons prévu que deux sorties pour des Tsop pour pouvoir laisser un plus grande chance au chasseur de ne pas être repéré, pour une approche plus vrai que nature. Pour savoir si un chasseur nous a attrapé, nous utilisons une sonde de Hall.
 De plus, en cas de problème nous avons créé toutes les sorties du microcontrôleur. Si un problème apparaît sur une des pins utilisées, nous pourrons la relocaliser sur une autre sortie.
@@ Ligne 350 : / Ligne 350 : @@
 ==== Fonction tsop()====
-Cette fonction a deux rôles. Le premier est de lire les entrées des tsop et de renvoyer si un prédateur a été détecter ou non. Le deuxième est d'émettre un signal infra-rouge permettant au prédateur de nous détecter.
+Cette fonction a deux rôles. Le premier est de lire les entrées des tsop et de renvoyer si un prédateur a été détecté ou non. Le deuxième est d'émettre un signal infra-rouge permettant au prédateur de nous détecter.
+{
@@ Ligne 384 : / Ligne 384 : @@
+}
-Les particularités de cette fonction sont que, premièrement pour facilité la programmation l'émission et la réception ont été mises dans la même fonction car elles demandent toutes les deux la même bibliothèque et les même timer, donc pour éviter tout conflit ceci fut une bonne solution. Deuxièmement, la fonction tsop() contient un pointeur en paramètre. Ce pointeur permet au robot de savoir s'il doit continuer à émettre ou non s'il est attrapé.
+Les particularités de cette fonction sont que, premièrement pour faciliter la programmation, l'émission et la réception ont été mise dans la même fonction car elles demandent toutes les deux la même bibliothèque et les même timer, donc pour éviter tout conflit ceci fut une bonne solution. Deuxièmement, la fonction tsop() contient un pointeur en paramètre. Ce pointeur permet au robot de savoir s'il doit continuer à émettre ou non s'il est attrapé.
-L'émission du signal infra-rouge ici ce fait toute les 0.5s. En effet si les émissions sont trop proche il y a conflit avec la réception.
+L'émission du signal infra-rouge ici se fait toute les 0.5s. En effet si les émissions sont trop proches il y a conflit avec la réception.
 ==== Fonction hall()====
@@ Ligne 489 : / Ligne 489 : @@
+}
-Cette fonction est divisée en deux partie. La première est la distribution des états du robot en fonction des entrées. Par la suite, la fonction va décidé quel déplacement faire en fonction des priorités des différents états. L'états le plus prioritaire est l'états etatHall. Celui ci indique si le robot est attrapé et une fois passé à 1 il ne peut plus changer et le déplacement associé est un sur-place pour le robot. Après il y a l'état associé au obstacle et si la distance devient inférieur à celle écrite, le robot tourne sur lui même dans une direction aléatoire jusqu'à ne plus percevoir d'obstacle. Le suivant est celui de la détection de prédateur. Ici si un prédateur est détectée, Quireekoo va aussi ce tourner dans une direction aléatoire. Mais la différence c'est que ici il va tourner pendant un certain intervalle de temps rentré dans le code. Le dernier déplacement n'est exécuter seulement si aucun des trois autres n'est fait. C'est le déplacement de base du robot. Ce déplacement est juste en zigzag.
+Cette fonction est divisée en deux partie. La première est la distribution des états du robot en fonction des entrées. Par la suite, la fonction va décider quel déplacement faire en fonction des priorités des différents états. L'état le plus prioritaire est l'état etatHall. Celui ci indique si le robot est attrapé et une fois passé à 1 il ne peut plus changer et le déplacement associé est un sur-place pour le robot. Après il y a l'état associé aux obstacles et si la distance devient inférieur à celle écrite, le robot tourne sur lui même dans une direction aléatoire jusqu'à ne plus percevoir d'obstacle. Le suivant est celui de la détection de prédateur. Ici si un prédateur est détecté, Quireekoo va aussi se tourner dans une direction aléatoire. Mais la différence c'est que ici il va tourner pendant un certain intervalle de temps rentré dans le code. Le dernier déplacement n'est exécuté seulement si aucun des trois autres n'est fait. C'est le déplacement de base du robot. Ce déplacement est juste en zigzag.
 === Les difficultés rencontrées ===
-Une grand difficulté lors de la programmation de Quireekoo fut l’émission et la réception infra-rouge. En effet la première idée pour l'émission était de juste allumer et éteindre la led infra-rouge à un fréquence de 38 kHz avec les intervalles de temps précis comme utilisé ici pour d'autre fonction avec les currentMillis et lastMillis. Les tsop réagissaient bien à l'émission. Le problème est que si l'on rajoutais des fonctions comme le déplacement ou le sonar, le temps d'arriver jusqu'à l'émission l'intervalle de temps qui permettait une fréquence de 38 kHz était dépassé.
+Une grande difficulté lors de la programmation de Quireekoo fut l’émission et la réception infra-rouge. En effet la première idée pour l'émission était de juste allumer et éteindre la led infra-rouge à un fréquence de 38 kHz avec les intervalles de temps précis comme utilisé ici pour d'autre fonction avec les currentMillis et lastMillis. Les tsop réagissaient bien à l'émission. Le problème est que si l'on rajoutais des fonctions comme le déplacement ou le sonar, le temps d'arriver jusqu'à l'émission l'intervalle de temps qui permettait une fréquence de 38 kHz était dépassé.
+{
@@ Ligne 516 : / Ligne 516 : @@
+}
-Une solution fur de passer directement par les interruptions timer. Mais deux problèmes ce sont encore révélés. Le premier était que tout les timer étaient déjà utilisé par la bibliothèque servo.h, donc impossible de faire les interruptions. De plus avec cette façon de faire ou la précédente, il était impossible de faire passer un message à travers l'émission, donc impossible de différencier une proie d'un prédateur.
+Une solution fur de passer directement par les interruptions timer. Mais deux problèmes ce sont encore révélés. Le premier était que tous les timer étaient déjà utilisés par la bibliothèque servo.h, donc impossible de faire les interruptions. De plus avec cette façon de faire ou la précédente, il était impossible de faire passer un message à travers l'émission, donc impossible de différencier une proie d'un prédateur.
+{
@@ Ligne 539 : / Ligne 539 : @@
+}
-Nous en sommes arrivé à utiliser la bibliothèque IRremote.h. Avec cette bibliothèque, l'émission et la réception infra-rouge ce fait très simplement si elles sont séparées. Mais les applications utilisant les même timer, il y a alors conflit pour faire fonctionner les deux en même temps. Cela nous a pris du temps pour trouver une solution car aucune information n'a pu être trouvé sur le web. Le problème était que si nous faisions une émission, les timer de la réception était annulé. Il fallait alors les ré-allouer pour la réception après l'émission avec le ligne de code: reception_ir1.enableIRIn();.
+Nous en sommes arrivé à utiliser la bibliothèque IRremote.h. Avec cette bibliothèque, l'émission et la réception infra-rouge se fait très simplement si elles sont séparées. Mais les applications utilisant les même timer, il y a alors conflit pour faire fonctionner les deux en même temps. Cela nous a pris du temps pour trouver une solution car aucune information n'a pu être trouvé sur le web. Le problème était que si nous faisions une émission, les timer de la réception était annulé. Il fallait alors les ré-allouer pour la réception après l'émission avec le ligne de code: reception_ir1.enableIRIn();.
+{

← Version précédente		Version du 5 mai 2018 à 15:47
Ligne 571 :		Ligne 571 :

	Lorsque nous avons commencé à penser au projet, nous avons pensé à faire un robot le plus petit possible pour être le plus dur à attraper. Pour cela, nous avions décidé d'utiliser des servos-moteurs pour le déplacement. Nous pensions que la vitesse de rotation était suffisante pour avoir un robot plutôt rapide. La vitesse n'est alors pas si lente que ça mais nous nous attendions à mieux. Une question vient alors ce poser: aurait-il mieux fallut mettre des moteurs et non des servos-moteurs? Le défauts des moteurs est que ceci prennent alors plus de place et donc le robot n'est plus aussi petit que la taille voulut au départ. Nous avons alors conclut que les servos-moteurs restaient alors la meilleur solution pour le déplacement.		Lorsque nous avons commencé à penser au projet, nous avons pensé à faire un robot le plus petit possible pour être le plus dur à attraper. Pour cela, nous avions décidé d'utiliser des servos-moteurs pour le déplacement. Nous pensions que la vitesse de rotation était suffisante pour avoir un robot plutôt rapide. La vitesse n'est alors pas si lente que ça mais nous nous attendions à mieux. Une question vient alors ce poser: aurait-il mieux fallut mettre des moteurs et non des servos-moteurs? Le défauts des moteurs est que ceci prennent alors plus de place et donc le robot n'est plus aussi petit que la taille voulut au départ. Nous avons alors conclut que les servos-moteurs restaient alors la meilleur solution pour le déplacement.
		+
		+	= Conclusion =
		+
		+	Nous sommes très content d'avoir fait ce projet et de l'avoir fini dans les temps. Quireekoo fonctionne très bien et est comme nous voulions le concevoir à l'origine.

← Version précédente		Version du 5 mai 2018 à 15:40
Ligne 553 :		Ligne 553 :

	= Nos erreurs lors du projet =		= Nos erreurs lors du projet =
		+
		+	Au cours de ce projet nous avons fait quelque erreurs. Nous avons alors appris de ces erreurs et allons les décrire.
		+
		+	== Erreur lors de la création du circuit imprimé ==
		+
		+	Pour ce projet nous voulions faire tout le robot par nous même. Nous avons aussi refait le PCB en prenant comme exemple celui donner sur la page du projet qui est aussi celui affiché plus haut. Lorsque nous avions recopié le schéma, nous avons vu le leds de contrôle et avons décidé de les supprimer de notre circuit en pensant qu'elle ne servirait à rien. Ceci fut alors une grande erreur. Car lorsque nous avons reçu le circuit et que nous avons commencé à souder les composants, faire des tests pour savoir si les composant fonctionnaient comme il fallait ou de savoir si les soudures étaient bien faites devint très compliqué. Par chance aucun gros problème majeur n'a été trouvé. Nous savons maintenant que l'utilisation de led de contrôle est primordiale lors de la création de prototype.
		+
		+	== Erreur lors de la création de la structure ==
		+
		+	Quelques problèmes mineurs ont été rencontrés. Lors de la création des trous pour faire rentrer les tsop, le sonar et la sonde de hall, nous avions pris les mesures de la longueurs de pins mais la mesure précise. De ce fait, sans une petite marge de distance, les fils ne passaient pas. Nous avons alors juste limé un peu et le problème fut résolu.
		+
		+	De plus nous n'avions pas prévu de trous ou autres solutions pour maintenir la batterie avec les piles. Nous l'avons alors attachée avec des élastiques. Cela fonctionne mais rend la rend inaccessible.
		+
		+	Nous remercions aussi Vincent de nous avoir passé un des ces supports pour les servos-moteurs, car sans nous nous demandons comment nous aurions pu les attacher.
		+
		+	== Erreur de conception ==
		+
		+	Lorsque nous avons commencé à penser au projet, nous avons pensé à faire un robot le plus petit possible pour être le plus dur à attraper. Pour cela, nous avions décidé d'utiliser des servos-moteurs pour le déplacement. Nous pensions que la vitesse de rotation était suffisante pour avoir un robot plutôt rapide. La vitesse n'est alors pas si lente que ça mais nous nous attendions à mieux. Une question vient alors ce poser: aurait-il mieux fallut mettre des moteurs et non des servos-moteurs? Le défauts des moteurs est que ceci prennent alors plus de place et donc le robot n'est plus aussi petit que la taille voulut au départ. Nous avons alors conclut que les servos-moteurs restaient alors la meilleur solution pour le déplacement.

← Version précédente		Version du 5 mai 2018 à 15:05
Ligne 551 :		Ligne 551 :

	Cette solution a alors été partagée avec les autres groupes qui avaient besoin d'émettre et de réceptionner un signal.		Cette solution a alors été partagée avec les autres groupes qui avaient besoin d'émettre et de réceptionner un signal.
		+
		+	= Nos erreurs lors du projet =

← Version précédente		Version du 5 mai 2018 à 15:04
Ligne 549 :		Ligne 549 :
	}		}
	}		}
		+
		+	Cette solution a alors été partagée avec les autres groupes qui avaient besoin d'émettre et de réceptionner un signal.

← Version précédente		Version du 5 mai 2018 à 15:03
Ligne 539 :		Ligne 539 :
	}		}

−	Nous en sommes arrivé à utiliser la bibliothèque ~~IRemote~~.h	+	Nous en sommes arrivé à utiliser la bibliothèque IRremote.h. Avec cette bibliothèque, l'émission et la réception infra-rouge ce fait très simplement si elles sont séparées. Mais les applications utilisant les même timer, il y a alors conflit pour faire fonctionner les deux en même temps. Cela nous a pris du temps pour trouver une solution car aucune information n'a pu être trouvé sur le web. Le problème était que si nous faisions une émission, les timer de la réception était annulé. Il fallait alors les ré-allouer pour la réception après l'émission avec le ligne de code: reception_ir1.enableIRIn();.
		+
		+	{
		+	if ((current_millis - last_millis >= interval)&&(*attraper == 0)){
		+	emission_ir.sendNEC(1, 32);
		+	last_millis = current_millis;
		+	reception_ir1.enableIRIn();
		+	reception_ir2.enableIRIn();
		+	}
		+	}

← Version précédente		Version du 5 mai 2018 à 14:53
Ligne 490 :		Ligne 490 :

	Cette fonction est divisée en deux partie. La première est la distribution des états du robot en fonction des entrées. Par la suite, la fonction va décidé quel déplacement faire en fonction des priorités des différents états. L'états le plus prioritaire est l'états etatHall. Celui ci indique si le robot est attrapé et une fois passé à 1 il ne peut plus changer et le déplacement associé est un sur-place pour le robot. Après il y a l'état associé au obstacle et si la distance devient inférieur à celle écrite, le robot tourne sur lui même dans une direction aléatoire jusqu'à ne plus percevoir d'obstacle. Le suivant est celui de la détection de prédateur. Ici si un prédateur est détectée, Quireekoo va aussi ce tourner dans une direction aléatoire. Mais la différence c'est que ici il va tourner pendant un certain intervalle de temps rentré dans le code. Le dernier déplacement n'est exécuter seulement si aucun des trois autres n'est fait. C'est le déplacement de base du robot. Ce déplacement est juste en zigzag.		Cette fonction est divisée en deux partie. La première est la distribution des états du robot en fonction des entrées. Par la suite, la fonction va décidé quel déplacement faire en fonction des priorités des différents états. L'états le plus prioritaire est l'états etatHall. Celui ci indique si le robot est attrapé et une fois passé à 1 il ne peut plus changer et le déplacement associé est un sur-place pour le robot. Après il y a l'état associé au obstacle et si la distance devient inférieur à celle écrite, le robot tourne sur lui même dans une direction aléatoire jusqu'à ne plus percevoir d'obstacle. Le suivant est celui de la détection de prédateur. Ici si un prédateur est détectée, Quireekoo va aussi ce tourner dans une direction aléatoire. Mais la différence c'est que ici il va tourner pendant un certain intervalle de temps rentré dans le code. Le dernier déplacement n'est exécuter seulement si aucun des trois autres n'est fait. C'est le déplacement de base du robot. Ce déplacement est juste en zigzag.
		+
		+	=== Les difficultés rencontrées ===
		+
		+	Une grand difficulté lors de la programmation de Quireekoo fut l’émission et la réception infra-rouge. En effet la première idée pour l'émission était de juste allumer et éteindre la led infra-rouge à un fréquence de 38 kHz avec les intervalles de temps précis comme utilisé ici pour d'autre fonction avec les currentMillis et lastMillis. Les tsop réagissaient bien à l'émission. Le problème est que si l'on rajoutais des fonctions comme le déplacement ou le sonar, le temps d'arriver jusqu'à l'émission l'intervalle de temps qui permettait une fréquence de 38 kHz était dépassé.
		+
		+	{
		+	void allumer()
		+	{
		+	// check to see if it's time to change the state of the LED
		+	unsigned long currentMicros = micros();
		+
		+	if((ledState == HIGH) && (currentMicros - previousMicros >= OnTime))
		+	{
		+	ledState = LOW; // Turn it off
		+	previousMicros = currentMicros; // Remember the time
		+	digitalWrite(ledPin, ledState); // Update the actual LED
		+	}
		+	else if ((ledState == LOW) && (currentMicros - previousMicros >= OffTime))
		+	{
		+	ledState = HIGH; // turn it on
		+	previousMicros = currentMicros; // Remember the time
		+	digitalWrite(ledPin, ledState); // Update the actual LED
		+	}
		+	}
		+	}
		+
		+	Une solution fur de passer directement par les interruptions timer. Mais deux problèmes ce sont encore révélés. Le premier était que tout les timer étaient déjà utilisé par la bibliothèque servo.h, donc impossible de faire les interruptions. De plus avec cette façon de faire ou la précédente, il était impossible de faire passer un message à travers l'émission, donc impossible de différencier une proie d'un prédateur.
		+
		+	{
		+	// initialize timer1
		+	noInterrupts(); // disable all interrupts
		+	TCCR5A = 0;
		+	TCCR5B = 0;
		+	TCNT5 = 0;
		+
		+	OCR5A = 421; // compare match register 16MHz/256/2Hz
		+	TCCR5B \|= (1 << WGM52); // CTC mode
		+	TCCR5B \|= (1 << CS50); // 256 prescaler
		+	TIMSK5 \|= (1 << OCIE5A); // enable timer compare interrupt
		+	interrupts(); // enable all interrupts
		+	}
		+
		+	ISR(TIMER5_COMPA_vect) // timer compare interrupt service routine
		+	{
		+	digitalWrite(ledPin, digitalRead(ledPin) ^ 1); // toggle LED pin
		+	}
		+
		+	}
		+
		+	Nous en sommes arrivé à utiliser la bibliothèque IRemote.h