Projet CanSat : Différence entre versions

De Wiki de Projets IMA
(→‎Présentation du projet)
 
(121 révisions intermédiaires par 3 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
 +
<include nopre noesc src="/home/pedago/pimasc/include/video-CanSat-iframe.html" />
 +
__TOC__
 +
<br style="clear: both;">
 +
=Présentation du projet =
  
−
=Présentation du projet =
+
==== Concours CanSat ====
−
=== Encadrants ===
+
[[File:Logo2013.jpg|thumb|[http://www.cansatcompetition.com/Main.html logo CanSAt]]]
−
Alexandre Boé / Nicolas Defrance / Thomas Vantroys
+
L'idée du concours CanSat a vu le jour aux États Unis, en novembre 1998, lors d'un meeting à Hawaï. Ce concours
−
=== Binôme ===
+
destiné aux étudiants a eu un fort succès dès son lancement. Depuis, l'évènement a dépassé les frontières
−
Céline Burtaire / Robin Gouenard
+
américaines pour conquérir entre autres le Japon, l'Argentine, puis l'Europe et notamment l'Espagne, les Pays‐
−
=== Objectif===
+
Bas, et maintenant la France.
 +
Le principe du CanSat repose sur l'idée de réaliser un satellite contenu dans un volume très réduit (33cl). Un CanSat est un dispositif autonome, capable de réaliser une ou plusieurs missions concrètes. Celui‐ci est largué
 +
à une certaine altitude et son but est d'exécuter une expérience technique ou scientifique. Toutes les fonctions de
 +
base  d’un  satellite  (alimentation,  communications…)  sont  introduites  à  l’intérieur  d’une  canette,  ce  qui
 +
représente une plateforme d’apprentissage exceptionnelle pour tous les jeunes intéressés par la conception et la
 +
fabrication de satellites.
 +
 +
==== Objectif : ====
 
'''Réaliser un prototype permettant de participer à la compétition CanSat
 
'''Réaliser un prototype permettant de participer à la compétition CanSat
  
Ligne 14 : Ligne 25 :
 
* competion cansat : [http://www.cansatcompetition.com/Main.html cansat]
 
* competion cansat : [http://www.cansatcompetition.com/Main.html cansat]
  
−
= Liste du matériel =
+
<br>
 +
 
 +
== Liste du matériel ==
  
−
== Présent ==
 
 
<ul>
 
<ul>
 
  <li>Carte Arduino Uno</li>
 
  <li>Carte Arduino Uno</li>
−
  <li>Montre TI eZ430 chronos</li>
+
  <li><s>Montre TI eZ430 chronos</s></li>
 +
<li>Capteur de température : [http://www.analog.com/en/mems-sensors/digital-temperature-sensors/tmp36/products/product.html TMP36]</li>
 +
<li>Capteur de pression [http://www.freescale.com/files/sensors/doc/data_sheet/MPXHZ6400A.pdf MPXHZ6400A]</li>
 +
<li>Accéléromètre [https://www.sparkfun.com/products/9836 ADXL345]</li>
 +
<li>Module RF [http://www.picaxe.com/docs/xbe001.pdf ZigBee Pro] </li>
 +
<li>Micro-controleur [http://www.atmel.com/Images/doc8161.pdf ATMEGA328p]</li>
 
</ul>
 
</ul>
  
−
== A acheter ==
 
−
<ul>
 
−
<li>à définir</li>
 
−
</ul>
 
  
−
= Le projet =
+
<br>
 +
 
 +
= Avancement du projet =
 
== Introduction ==
 
== Introduction ==
 +
Le CanSat est une sonde embarquée dans un volume équivalent à une canette de soda.
 +
Cette sonde est lancée en fusée pour atteindre jusqu'à 800 mètres d'altitude ou en ballon pour atteindre une altitude de 150 mètres.
 +
Différentes informations doivent être transmises en temps réel:
 +
* Températures
 +
* Altitudes
 +
* coordonnées GPS
 +
* ...
 +
 +
Nous avons choisis ce projet car il permet une grande liberté. En effet, les fonctionnalités du "satellite" doivent être définies au début du projet.
 +
De plus, il est pluridisciplinaire puisqu'il faut des connaissances en informatique, électronique mais aussi en physique et mécanique.
 +
 
== Séances après séances ==
 
== Séances après séances ==
 +
 +
==== Analyse du problème ====
 +
''(Jusqu'au 25 Février 2013)''
 +
 +
 +
Nous avons pris du temps pour analyser nos problèmes et les solutions plausibles.
 +
Nous avions décider de tester la montre TI eZ430 chronos car elle possède déjà un altimètre et un capteur de température, ainsi qu'un système de transmission. Cependant, après avoir fait quelques tests, la distance de transmission n'est pas assez grande (on souhaite un minimum de 150m).
 +
 +
Nous avions donc le choix entre commander des capteurs et les programmer via arduino, ou récupérer les informations de la montre. Nous avons choisis la première option car elle semble plus accessible.
 +
<br>
 +
<br>
 +
 +
==== Choix des composants====
 +
''( 25 Février)''
 +
 +
* Capteur de température : [http://www.analog.com/en/mems-sensors/digital-temperature-sensors/tmp36/products/product.html TMP36]
 +
 +
* Capteur de pression [http://www.freescale.com/files/sensors/doc/data_sheet/MPXHZ6400A.pdf MPXHZ6400A]
 +
 +
* Accéléromètre [https://www.sparkfun.com/products/10121? ADXL345]
 +
 +
* Module Zigbee Pro
 +
<br>
 +
 +
==== 27 Février ====
 +
 +
Le capteur de température a été testé avec l'arduino et nous avons commencé à configuré le XBee Pro par liaison USB.
 +
 +
Nous avons réfléchis à la mise en place du module XBee sur notre montage. Afin de procéder aux premiers tests nous utilisons un shield arduino, cependant, nous devons commander / construire deux connecteurs femelles avec le bon pas pour ensuite le monter sur notre carte.
 +
<br>
 +
<br>
 +
 +
==== 28 Février ====
 +
[[File:Prototype d'architecture du CanSat.jpg|thumb|Architecture]]
 +
<br>
 +
<br>
 +
Début de la configuration des Zigbee.
 +
<br>
 +
<br>
 +
L'architecture du Cansat sera idéalement réalisée en 3 cartes rondes. Les capteurs et l'antenne sont aux extrémités pour avoir un accès plus direct avec l’extérieur.
 +
Ce modèle n'est cependant pas fixé mais nous aide à structuré nos tests. Nous attendrons de réaliser les tests sur un montage complet avant de corriger les erreurs de placements éventuelles ou de voir si tout pourrait tenir sur une seule carte.
 +
<br>
 +
<br>
 +
<br>
 +
<br>
 +
<br>
 +
<br>
 +
<br>
 +
<br>
 +
 +
==== 4-6 Mars ====
 +
 +
Nous avons testé une utilisation simple des modules Zigbee afin de simuler la transmission de données du CanSat vers un ordinateur distant. La transmission s'effectue de la façon suivante : un arduino envoi un message en boucle sur son port série (broches RX/TX). Deux Zigbee XB24 sont configurés à l'aide de commandes AT avec un PC et le logiciel X-CTU, l'un des Xbee est relié au RX/TX de l'arduino et l'autre au PC. On visualise alors sur l'ordinateur les données reçues.
 +
 +
Nous avons alors eu un problème. En effet, les données arrivaient de manière aléatoire, quelques fois reçues, quelquefois non, et ce sans changer le programme ou la configuration. Nous avons d'abord pensé à un dysfonctionnement matériel (shield Zigbee, arduino, ...) et nous avons donc essayer de changer un par un ces éléments. Le problème persistait et ce malgré le fait que les deux Xbee communiquaient bien entre eux (réponse positive à la commande ATND). Nous avons tenté de remplacer la communication arduino-PC par une communication arduino-arduino, changé le protocole de communication, mis à jour les firmwares des XB24,  mais la transmission était toujours aléatoire.
 +
Finalement nous sommes parvenu à régler ce problème en laissant de coté l'émission série à l'aide des broches RX/TX au profit d'un port série virtuel (librairie Software Serial).
 +
 +
 +
Durant la semaine 10, nous avons testé l’accéléromètre ADXL345 ([https://www.sparkfun.com/products/10121? carte sparkfun]). Cette carte communique avec le protocole I2C.
 +
N'ayant jamais utilisé un tel capteur, nous avons tout d'abord téléchargé et testé le programme fournit sur le site du fabricant ([http://bildr.org/2012/03/stable-orientation-digital-imu-6dof-arduino/ bildr Tutorial - Stable Orientation]). Ce programme nous servira de base pour avoir un exemple de communication avec le bus I2C et savoir où chercher les données souhaitées.
 +
 +
 +
==== 7 Mars ====
 +
[[File:Montage test.jpg|thumb|Test avec capteur de t°]]
 +
La communication entre les ZigBees fonctionne. Nous l'avons testée en réalisant un montage avec le capteur de température (voir photo).
 +
 +
 +
<u>Code de test</u>:<pre>
 +
#include <SoftwareSerial.h>
 +
const int rxpin = 10;            // Software Serial RX
 +
const int txpin = 11;                  // Software Serial TX
 +
SoftwareSerial mySerial(rxpin, txpin); // RX, TX
 +
int temperaturePin = 0; // Relevé de température sur la broche analogique 0
 +
 +
void setup() 
 +
{
 +
  mySerial.begin(9600); // initialisation du Software Serial
 +
  mySerial.println("Debut du programme");
 +
}
 +
 +
float getVoltage(int pin) // convertit la valeur de la tension du capteur en température
 +
{
 +
return (analogRead(pin) * .004882814);
 +
}
 +
 +
void loop()
 +
{
 +
float temperature = getVoltage(temperaturePin);
 +
temperature = (temperature - 0.5) * 100;
 +
mySerial.println(temperature);         
 +
delay(1000);
 +
}
 +
</pre>
 +
<br>
 +
 +
==== semaine 11 ====
 +
 +
[[File:Trames I2C.png|thumb|Trames I2C]]
 +
 +
Nous avons commencé par récupérer un accéléromètre ADXL345 présent sur une carte sparkfun Digital 6DOF. C'était le dernier accéléromètre disponible. Il a la particularité de n'avoir que les broches SDA et SCL de disponibles. Nous avons donc dû récupérer les données du capteur par l'intermédiaire du protocole I2C.
 +
Après avoir analysé le fonctionnement du protocole, nous avons coder un programme test. Ayant des difficultés à utiliser ce protocole, nous avons visualisé les données à l'aide d'un analyseur de trames. Les trames d'envoi semblaient correctes mais aucune réponse ne parvenait du capteur.
 +
 +
==== semaine 12 ====
 +
 +
Nous avons finalement réussi à faire fonctionner le capteur en I2C, il s'agissait d'un problème d'adressage du capteur (il faillait utiliser l'adresse auxiliaire plutôt que la principale). Cependant, nous avons échangé notre capteur avec celui d'un autre groupe. Ils avaient en effet besoin d'une fonction gyroscope que nous n'utilisions pas et qui était présente dans notre Digital 6DOF. Lors de l’intégration de notre programme avec le nouveau capteur, nous avons à nouveau rencontré quelques soucis. Ayant la possibilité d'utiliser notre nouveau capteur en SPI, nous avons retranscris notre programme. De plus le protocole I2C étant peu approprié à notre application (un seul maître et un seul esclave), le passage en SPI était plutôt cohérent.
 +
 +
==== 25 Mars ====
 +
Les capteurs ont été reçus et testés, il est temps de faire la carte et son programme.
 +
 +
Afin de préciser les prochaines étapes de conception, nous avons besoin d'étudier le [http://www.planete-sciences.org/espace/IMG/pdf/reglement_Cansat_2013.pdf règlement du projet CanSat] (concours national).
 +
Nous nous occupons cette année du ''sondage atmosphérique'', la mission d'atterrissage et la mission libre seront étudiées si le sujet est poursuivi l’année prochaine puisqu'elles peuvent changées chaque année.
 +
 +
*Le programme
 +
Pour le sondage atmosphérique, il est demandé de relever la température et l'altitude toutes les 5secondes au moins et de transmettre ces mesures vers une station au sol.
 +
Le programme tiendra donc compte de cette contrainte.
 +
 +
*La carte
 +
La carte sera réalisée seulement pour cette mission. Cela nous permettra d'estimer la place de l’électronique dans la "canette" par la suite. Nous pourrons aussi réfléchir à la possibilité de faire une carte utilisant un arduino nano en fonction des missions annexes.
 +
 +
De plus, il est nécessaire que la cansat ne dépasse pas 66mm de diamètre, 115mm de hauteur, et 350g en poids. La batterie doit tenir au minimum 45minutes.
 +
 +
==== 27 Mars ====
 +
[[Fichier:Assemblage test.jpg|thumb|montage de test]]
 +
Un montage de test a été réalisé. Le capteur de pression, l'accéléromètre et le ZigBee ont été assemblés autour d'un même arduino. Cela nous a permit de tester un programme plus complet et de visualiser les besoins matériels pour la confection de la carte.
 +
1 port analogique est utilisé pour la capteur de température (1 autre sera utilisé par el capteur de pression), 2 ports digitals sont utilisés pour le Xbee et 4 pour l'accéléromètre. 
 +
L'atmega fournissant à la fois du 3.3V et du 5V nous utilisons directement ces 2 sources pour les différents capteurs.
 +
 +
En réception, nous visualisons les données x,y,z de l'accéléromètre (à coder correctement) et la température à des intervalles réguliés.
 +
<br>
 +
<br>
 +
<br>
 +
<br>
 +
<br>
 +
 +
==== 8 Avril ====
 +
Nous avons essayer de programmer l'atmega sans le module arduino, à l'aide du programmateur ARV isp mkII.
 +
Pour l'instant nous n'obtenons pas de résultat concluant, il y a des soucis avec la bibliothèque arvdude.
 +
 +
 +
==== 10 Avril ====
 +
Après avoir plusieurs essais peu concluants nous décidons d'abandonner la programmation par programmateur externe faute de temps. Nous inclurons la connectique ips sur la carte affin de pouvoir reprendre cet initiative par la suite.
 +
Nous avons ensuite travaillé sur l'exploitation des données de l’accéléromètre. Nous souhaitions en effet utiliser l'accéléromètre pour relever différentes informations sur la chute. Nous avons pour cela convertit les valeurs retournées par le capteur puis tenté de calculer via les valeurs de l'accélération une valeur approchée de la vitesse. Le calcul, bien qu’imprécis, devrait être suffisant pour obtenir une évolution de vitesse au cours d'une chute (supposée de courte durée).
 +
 +
 +
==== 17 avril ====
 +
[[Fichier:Lib.jpg|thumb|schematic et pcb du Xbee]]
 +
 +
La bibliothèque de composants est terminée. Elle sera réutilisable pour de prochaines cartes puisque la bibliothèque comporte des composants tels que le Xbee. Cette bibliothèque a été faites à l'aide du logiciel Altium Designer pour être plus facilement modifiable par d'autres personnes.
 +
<br>
 +
<br>
 +
<br>
 +
<br>
 +
<br>
 +
==== 2 mai ====
 +
 +
Il faut terminer le projet.
 +
La machine pour faire la carte est en panne. Nous n'avons donc pas cherché à terminé le typon bien que les principaux branchements ont été établit sur un schematic. La nouvelle idée d'architecture proposée est composée de 2 cartes : La carte principale avec le microprocesseur, ses sorties et le Xbee. C'est une carte qui changera très peu puisqu'elle regroupe les éléments essentiels au CanSat, à savoir transmission et traitement des données. La seconde quant à elle regroupe l'ensemble des capteurs.
 +
 +
 +
 +
== Fin du projet ==
 +
 +
==== Conclusion ====
 +
 +
Finalement, nous n'avons malheureusement as pu testé de carte réelle mais seulement un assemblage sur plaque de test.
 +
Cependant, les problèmes que nous avons rencontrés nous ont permis d'écarter plusieurs problèmes et le sujet peut facilement être repris pour participer à la compétition.
 +
Le plus gros de nos soucis a été la partie concernant l'accéléromètre. En effet, entre les problèmes de protocoles au départ et le traitement des données ensuite, nous pensons que ce n'est pas le choix le plus adéquat.
 +
 +
Concrètement, la liaison entre les Xbee fonctionne, plusieurs capteurs peuvent être reliés à l'ATMEGA et donc de nombreuses missions sont faisables. Nos bibliothèques et codes restent disponible si d'autres élèves souhaitent poursuivre le projet et notre rapport contient les informations essentielles à la compréhension de nos composants.
 +
 +
==== Rapport ====
 +
 +
[[Média:CanSat.pdf]]
 +
 +
==== Fichiers partagés ====
 +
 +
[[Média:CANSAT_Plil.zip]]
 +
 +
Archive contenant :
 +
 +
- la bibliothèque de composants (réalisée sous Altium Designer)
 +
 +
- Le programme de test en Arduino 'CANSAT.ino'
 +
 +
- Le rapport de notre projet avec les liens vers les datasheet et les schemas de branchement

Version actuelle datée du 23 mai 2013 à 07:50


Vidéo HD


Présentation du projet

Concours CanSat

logo CanSAt

L'idée du concours CanSat a vu le jour aux États Unis, en novembre 1998, lors d'un meeting à Hawaï. Ce concours destiné aux étudiants a eu un fort succès dès son lancement. Depuis, l'évènement a dépassé les frontières américaines pour conquérir entre autres le Japon, l'Argentine, puis l'Europe et notamment l'Espagne, les Pays‐ Bas, et maintenant la France. Le principe du CanSat repose sur l'idée de réaliser un satellite contenu dans un volume très réduit (33cl). Un CanSat est un dispositif autonome, capable de réaliser une ou plusieurs missions concrètes. Celui‐ci est largué à une certaine altitude et son but est d'exécuter une expérience technique ou scientifique. Toutes les fonctions de base d’un satellite (alimentation, communications…) sont introduites à l’intérieur d’une canette, ce qui représente une plateforme d’apprentissage exceptionnelle pour tous les jeunes intéressés par la conception et la fabrication de satellites.

Objectif :

Réaliser un prototype permettant de participer à la compétition CanSat

Les dates d'inscriptions pour participer à la compétition 2013 étant antérieures au début du projet, cette année nous nous concentrerons sur les fonctions récurrentes (vitesse, altitude...).

Plus d'informations sur la compétition :


Liste du matériel



Avancement du projet

Introduction

Le CanSat est une sonde embarquée dans un volume équivalent à une canette de soda. Cette sonde est lancée en fusée pour atteindre jusqu'à 800 mètres d'altitude ou en ballon pour atteindre une altitude de 150 mètres. Différentes informations doivent être transmises en temps réel:

  • Températures
  • Altitudes
  • coordonnées GPS
  • ...

Nous avons choisis ce projet car il permet une grande liberté. En effet, les fonctionnalités du "satellite" doivent être définies au début du projet. De plus, il est pluridisciplinaire puisqu'il faut des connaissances en informatique, électronique mais aussi en physique et mécanique.

Séances après séances

Analyse du problème

(Jusqu'au 25 Février 2013)


Nous avons pris du temps pour analyser nos problèmes et les solutions plausibles. Nous avions décider de tester la montre TI eZ430 chronos car elle possède déjà un altimètre et un capteur de température, ainsi qu'un système de transmission. Cependant, après avoir fait quelques tests, la distance de transmission n'est pas assez grande (on souhaite un minimum de 150m).

Nous avions donc le choix entre commander des capteurs et les programmer via arduino, ou récupérer les informations de la montre. Nous avons choisis la première option car elle semble plus accessible.

Choix des composants

( 25 Février)

  • Capteur de température : TMP36
  • Module Zigbee Pro


27 Février

Le capteur de température a été testé avec l'arduino et nous avons commencé à configuré le XBee Pro par liaison USB.

Nous avons réfléchis à la mise en place du module XBee sur notre montage. Afin de procéder aux premiers tests nous utilisons un shield arduino, cependant, nous devons commander / construire deux connecteurs femelles avec le bon pas pour ensuite le monter sur notre carte.

28 Février

Architecture



Début de la configuration des Zigbee.

L'architecture du Cansat sera idéalement réalisée en 3 cartes rondes. Les capteurs et l'antenne sont aux extrémités pour avoir un accès plus direct avec l’extérieur. Ce modèle n'est cependant pas fixé mais nous aide à structuré nos tests. Nous attendrons de réaliser les tests sur un montage complet avant de corriger les erreurs de placements éventuelles ou de voir si tout pourrait tenir sur une seule carte.







4-6 Mars

Nous avons testé une utilisation simple des modules Zigbee afin de simuler la transmission de données du CanSat vers un ordinateur distant. La transmission s'effectue de la façon suivante : un arduino envoi un message en boucle sur son port série (broches RX/TX). Deux Zigbee XB24 sont configurés à l'aide de commandes AT avec un PC et le logiciel X-CTU, l'un des Xbee est relié au RX/TX de l'arduino et l'autre au PC. On visualise alors sur l'ordinateur les données reçues.

Nous avons alors eu un problème. En effet, les données arrivaient de manière aléatoire, quelques fois reçues, quelquefois non, et ce sans changer le programme ou la configuration. Nous avons d'abord pensé à un dysfonctionnement matériel (shield Zigbee, arduino, ...) et nous avons donc essayer de changer un par un ces éléments. Le problème persistait et ce malgré le fait que les deux Xbee communiquaient bien entre eux (réponse positive à la commande ATND). Nous avons tenté de remplacer la communication arduino-PC par une communication arduino-arduino, changé le protocole de communication, mis à jour les firmwares des XB24, mais la transmission était toujours aléatoire. Finalement nous sommes parvenu à régler ce problème en laissant de coté l'émission série à l'aide des broches RX/TX au profit d'un port série virtuel (librairie Software Serial).


Durant la semaine 10, nous avons testé l’accéléromètre ADXL345 (carte sparkfun). Cette carte communique avec le protocole I2C. N'ayant jamais utilisé un tel capteur, nous avons tout d'abord téléchargé et testé le programme fournit sur le site du fabricant (bildr Tutorial - Stable Orientation). Ce programme nous servira de base pour avoir un exemple de communication avec le bus I2C et savoir où chercher les données souhaitées.


7 Mars

Test avec capteur de t°

La communication entre les ZigBees fonctionne. Nous l'avons testée en réalisant un montage avec le capteur de température (voir photo).


Code de test:
#include <SoftwareSerial.h>
const int rxpin = 10;            // Software Serial RX
const int txpin = 11;                  // Software Serial TX
SoftwareSerial mySerial(rxpin, txpin); // RX, TX
int temperaturePin = 0; // Relevé de température sur la broche analogique 0 

void setup()  
{
  mySerial.begin(9600); // initialisation du Software Serial
  mySerial.println("Debut du programme");
}

float getVoltage(int pin) // convertit la valeur de la tension du capteur en température
{
 return (analogRead(pin) * .004882814);
}

void loop()
{
float temperature = getVoltage(temperaturePin);
temperature = (temperature - 0.5) * 100;
mySerial.println(temperature);           
delay(1000);
}


semaine 11

Trames I2C

Nous avons commencé par récupérer un accéléromètre ADXL345 présent sur une carte sparkfun Digital 6DOF. C'était le dernier accéléromètre disponible. Il a la particularité de n'avoir que les broches SDA et SCL de disponibles. Nous avons donc dû récupérer les données du capteur par l'intermédiaire du protocole I2C. Après avoir analysé le fonctionnement du protocole, nous avons coder un programme test. Ayant des difficultés à utiliser ce protocole, nous avons visualisé les données à l'aide d'un analyseur de trames. Les trames d'envoi semblaient correctes mais aucune réponse ne parvenait du capteur.

semaine 12

Nous avons finalement réussi à faire fonctionner le capteur en I2C, il s'agissait d'un problème d'adressage du capteur (il faillait utiliser l'adresse auxiliaire plutôt que la principale). Cependant, nous avons échangé notre capteur avec celui d'un autre groupe. Ils avaient en effet besoin d'une fonction gyroscope que nous n'utilisions pas et qui était présente dans notre Digital 6DOF. Lors de l’intégration de notre programme avec le nouveau capteur, nous avons à nouveau rencontré quelques soucis. Ayant la possibilité d'utiliser notre nouveau capteur en SPI, nous avons retranscris notre programme. De plus le protocole I2C étant peu approprié à notre application (un seul maître et un seul esclave), le passage en SPI était plutôt cohérent.

25 Mars

Les capteurs ont été reçus et testés, il est temps de faire la carte et son programme.

Afin de préciser les prochaines étapes de conception, nous avons besoin d'étudier le règlement du projet CanSat (concours national). Nous nous occupons cette année du sondage atmosphérique, la mission d'atterrissage et la mission libre seront étudiées si le sujet est poursuivi l’année prochaine puisqu'elles peuvent changées chaque année.

  • Le programme

Pour le sondage atmosphérique, il est demandé de relever la température et l'altitude toutes les 5secondes au moins et de transmettre ces mesures vers une station au sol. Le programme tiendra donc compte de cette contrainte.

  • La carte

La carte sera réalisée seulement pour cette mission. Cela nous permettra d'estimer la place de l’électronique dans la "canette" par la suite. Nous pourrons aussi réfléchir à la possibilité de faire une carte utilisant un arduino nano en fonction des missions annexes.

De plus, il est nécessaire que la cansat ne dépasse pas 66mm de diamètre, 115mm de hauteur, et 350g en poids. La batterie doit tenir au minimum 45minutes.

27 Mars

montage de test

Un montage de test a été réalisé. Le capteur de pression, l'accéléromètre et le ZigBee ont été assemblés autour d'un même arduino. Cela nous a permit de tester un programme plus complet et de visualiser les besoins matériels pour la confection de la carte. 1 port analogique est utilisé pour la capteur de température (1 autre sera utilisé par el capteur de pression), 2 ports digitals sont utilisés pour le Xbee et 4 pour l'accéléromètre. L'atmega fournissant à la fois du 3.3V et du 5V nous utilisons directement ces 2 sources pour les différents capteurs.

En réception, nous visualisons les données x,y,z de l'accéléromètre (à coder correctement) et la température à des intervalles réguliés.




8 Avril

Nous avons essayer de programmer l'atmega sans le module arduino, à l'aide du programmateur ARV isp mkII. Pour l'instant nous n'obtenons pas de résultat concluant, il y a des soucis avec la bibliothèque arvdude.


10 Avril

Après avoir plusieurs essais peu concluants nous décidons d'abandonner la programmation par programmateur externe faute de temps. Nous inclurons la connectique ips sur la carte affin de pouvoir reprendre cet initiative par la suite. Nous avons ensuite travaillé sur l'exploitation des données de l’accéléromètre. Nous souhaitions en effet utiliser l'accéléromètre pour relever différentes informations sur la chute. Nous avons pour cela convertit les valeurs retournées par le capteur puis tenté de calculer via les valeurs de l'accélération une valeur approchée de la vitesse. Le calcul, bien qu’imprécis, devrait être suffisant pour obtenir une évolution de vitesse au cours d'une chute (supposée de courte durée).


17 avril

schematic et pcb du Xbee

La bibliothèque de composants est terminée. Elle sera réutilisable pour de prochaines cartes puisque la bibliothèque comporte des composants tels que le Xbee. Cette bibliothèque a été faites à l'aide du logiciel Altium Designer pour être plus facilement modifiable par d'autres personnes.




2 mai

Il faut terminer le projet. La machine pour faire la carte est en panne. Nous n'avons donc pas cherché à terminé le typon bien que les principaux branchements ont été établit sur un schematic. La nouvelle idée d'architecture proposée est composée de 2 cartes : La carte principale avec le microprocesseur, ses sorties et le Xbee. C'est une carte qui changera très peu puisqu'elle regroupe les éléments essentiels au CanSat, à savoir transmission et traitement des données. La seconde quant à elle regroupe l'ensemble des capteurs.


Fin du projet

Conclusion

Finalement, nous n'avons malheureusement as pu testé de carte réelle mais seulement un assemblage sur plaque de test. Cependant, les problèmes que nous avons rencontrés nous ont permis d'écarter plusieurs problèmes et le sujet peut facilement être repris pour participer à la compétition. Le plus gros de nos soucis a été la partie concernant l'accéléromètre. En effet, entre les problèmes de protocoles au départ et le traitement des données ensuite, nous pensons que ce n'est pas le choix le plus adéquat.

Concrètement, la liaison entre les Xbee fonctionne, plusieurs capteurs peuvent être reliés à l'ATMEGA et donc de nombreuses missions sont faisables. Nos bibliothèques et codes restent disponible si d'autres élèves souhaitent poursuivre le projet et notre rapport contient les informations essentielles à la compréhension de nos composants.

Rapport

Média:CanSat.pdf

Fichiers partagés

Média:CANSAT_Plil.zip

Archive contenant :

- la bibliothèque de composants (réalisée sous Altium Designer)

- Le programme de test en Arduino 'CANSAT.ino'

- Le rapport de notre projet avec les liens vers les datasheet et les schemas de branchement

Récupérée de « https://projets-ima.plil.fr/mediawiki/index.php?title=Projet_CanSat&oldid=6391 »