ELECINF344/381

Partie interactive du site pédagogique ELECINF344/ELECINF381 de Télécom ParisTech (occurrence 2011).

Catégories

Copterix : on passe entièrement sur la Gumstix !

Aujourd’hui, avec Bertrand, puis rejoins par Samuel et Axel, nous nous sommes concentrés sur la communication Gumstix/STM32. Nous avons enfin réussi à connecter comme nous le voulions les deux cartes.

Nous avons d’abord dû activer le GPIO 10, le pin correspondant n’étant pas configuré par défaut en tant que GPIO. Nous avons donc choisi de le configurer à chaque démarrage par l’intermédiaire d’un script shell, exécuté automatiquement, réalisant l’accès en mémoire nécessaire à la configuration, à l’aide de l’utilitaire memdev2.

Après avoir débugué notre carte à l’oscilloscope, et résolu un problème de soudure, nous avons donc enfin pu communiquer entre nos deux cartes. Les premiers essais ne furent malheureusement pas très fructueux : alors que les échanges de paquets se faisaient sans soucis entre PC et carte de TP STM32, avec le même protocole, nous avons à présent plus de 10% de perte de paquets (parfois 25%), et surtout, de longs moments (se décomptant en secondes) qui s’écoulent avec presqu’aucun paquet de valide. Les cartes sont donc inutilisables dans ces conditions.

Après analyse des données échangées, il semblerait que de nombreux octets ne sont pas reçus par la Gumstix, ceux-ci se perdant, à un niveau qu’il nous reste encore à déterminer. Exemple : sur des paquets qui devraient être de 21 octets, nous avons parfois observé plus de la moitié des octets perdus. Et ce, malgré le fait que nous avons redescendu la vitesse de l’UART à 115200 bps.

Les différentes pistes que nous avons à explorer demain, pour essayer de résoudre ce problème, sont les suivantes:

- Alexis nous a suggéré d’essayer de modifier le préscalaire de l’horloge concernée. Les quartzs n’étant pas forcément très fiables, il se peut que le souci vienne d’une vitesse de communication approximative, qu’on pourrait essayer de compenser de cette manière.
- Axel m’a suggéré de modifier légèrement le protocole. En effet, si on perd un octet, on perd au minimum deux paquets. Je rappelle le protocole :
On envoie un octet de start : 0xfe. Puis un octet identifiant le paquet : 0x4b. Ensuite on lit le nombre d’octets correspondant. Si on perd un octet, on va déborder sur le paquet suivant dans la lecture, et on ne le lira donc pas non plus. La solution proposée par Axel serait d’enregistrer la position de tout octet 0xfe croisé dans le contenu d’un paquet, et si le paquet est invalide, revenir à cette position pour « récupérer » ce paquet. Toutefois cela ne résoudra pas le problème, il s’agit juste de perdre moins de données à cause du protocole.

 

D’autre part, nous allons abandonner l’altimètre. Il semblerait que celui-ci soit trop peu précis, et trop complexe à utiliser. Nous allons donc plutôt faire des tests avec un détecteur à ultrasons ou un sharp, pour voir si nous obtenons quelque chose de plus satisfaisant.

Nous avons également été chercher l’hélicoptère, afin de pouvoir tester les commandes des moteurs très bientôt.

TSV Safe Express: à partir de carte TP à la carte réelle

Pendant le week-end, nous avons essayé de stabiliser le protocol de NMRAnet (CAN bus) avec trois cartes. Nous avons réussi avec 3 cartes mail il y avait beaucoup de problèmes quand on utilise plus que un carte pour le nœud. Les plus importants sont:-
Pour rappel, nous avons 3 cartes – Un carte central station, 2 qui sont nœuds.
1. Premier nœud se timed out lorsque le deuxième nœud entre dans le réseau –
Raison- Il y avait trop des paquets à partir de le nouvelle carte parce que Il se fait programmé. Alors, le « network manager » supprime le premier nœud s’il ne reçoit pas le paquet état ​​dans un délai prédéterminé.
Solution- Utilise le CAN Filter qui lui permet de recevoir que les paquets qui le concernent. ça va dire , une fois le filtre statique est installé, les nœuds ne recevraient pas de paquets qui sont envoyés par d’autres nœuds soit le gestionnaire du réseau (« Network Manager »)ou de l’outil de configuration(« Configuration Tool »).
Futur Développement possible – Actuellement, pour les évènements de carte feux(« Consumer ») il n’y a pas de filtres qui signifie que chaque noeud reçoit les événements qui sont générés par d’autres. Pour cela, nous avons besoin d’installer des filtres CAN dynamiquement en fonction du nombre d’événements qui lui sont donnés par le gestionnaire du réseau. Nous le ferons en fonction de comment ça se passe avec les 12 attendus plus de cartes.

2. Redémarre de le nœud ne marche pas –
Raison – Si le redémarrage est très rapide, le nœud n’a pas reprogrammé par l’outil de configuration. C’est parce que le gestionnaire de réseau n’a pas assez de temps pour lui de supprimer de sa table nœud.
Solution – Après le redémarrage, le nœud inactif pendant 3 secondes qui donne la gare centrale de suffisamment de temps pour lui supprimer.
Futur Développement possible – Au lieu de dormir aveugle de 3 secondes, l’introduction de l’Etat en fonction le contrôle opérationnel au niveau du « Network Manager ».

3. Redémarre de le station central –
Raison – Depuis le nœud est déjà programmée, ainsi qu’il ne devient pas programmé encore par l’outil de configuration.
Solution – Au démarrer de la gare centrale, il envoie une commande broadcaste à tous les nœuds de se réinitialiser.
ça marche mais avec deux carte, ça ne marche plus. Juste une carte, qui devient programmé. Nous sommes en train de trouver la raison.

Pour le Carte Feux (pas de TP) – Nous avons réussi avec CAN et nous pouvons contrôle cette carte à partir de station central. Maintenant, Theodoros, il est en train de travailler sur le SPI. Siwar continue de travailler à CAN bootloader. Vaibhav travaille sur le code existant.

TSV Safe Express: Le débogage avec bus CAN

Hier, nous avons eu problèmes avec multiple nœuds. Alors, aujourdhui, nous essayions de stabiliser le protocol NMRA pour le bus CAN. Un problème intéressant a été les paquets du bus CAN ne sont pas dans le bon ordre. Qu’est-ce qui se passait?
Notre théorie est la suivante. Nous avons « transmit mailbox » dans le contrôleur CAN avec la capacité de 3. La fonction de transmission de la bibliothèque CAN tente de trouver « transmit mailbox  » vide et envoyer le paquet. Supposons qu’il écrit le premier paquet en deuxième mailbox , puis premier mailbox (car il a trouvé les mailboxes vide dans cet ordre). Mais la transmission de messages CAN commence de 0 mailbox. Ainsi, les paquets ne sont pas envoyés dans l’ordre correct.

Une solution possible peut être de s’assurer d’utiliser une seule mailbox pour envoyer des messages CAN. Cela peut être réaliser en commençant par transmettre CAN gestionnaire d’interruption qui se synchronise avec le CAN transmettre fonction à l’aide de sémaphores. Mais, avec ça nous ne pouvons pas prendre l’avantage de trois mailbox. D’autres solutions sont les bienvenus.

Avec, le bootloader, nous avons réussi en faire le lecture et écriture sur le flash. Maintenant, nous sommes en train de faire le l’autre choses de bootloader comme le usart.

Nous avons reçu noter carte feux. Demain, nous allons faire le SPI pour cette carte.

MB Led et IrDA: paquets, procédure de test…

Structure des paquets:

Tout les paquets envoyés sont précédés de l’enchainement de caractères « MBL » qui marque le début d’un paquet. Par la suite, sont envoyés dans l’ordre:

  1. FROM :           8 bits id de l’émetteur
  2. Idpacket:        8 bits id du paquet nécessaire pour les acquittements.
  3. Priority:          4 bits valeur entre 0 et 7
  4. To:                 4 bits permet de savoir à qui est adressé le message (voisin, broadcast, leader)
  5. TTL:               8 bits duré de vie du message sur le réseau
  6. Mode:            8 bits Contient la commande (PING, PONG, DATA_IMG….) le premier bit indique la présence de Data.
  7. Size_of_data:  8 bit Taille de la Data majorée par MAX_DATA_SIZE
  8. Data:             Tableau de d’octet pouvant contenir ce que l’on souhaite.
  9. Checksum :    16 bit.


Procédure de test:

Après avoir étudier l’implémentation de l’IrLAP pour Linux, il est devenu évident qu’il n’était pas nécessaire de l’implémenter. A la place je suis en train de mettre en place un processus de dialogue similaire à celui mis en place pendant le communication challenge.

Dans un premier temps les blocs émettent des PING jusqu’à recevoir un PONG. Dès lors ils associent l’identifiant du bloc à l’un des ports et commence le nécessaire pour l’algorithmie.

Pour le moment je suis en train de débugger cette phase en mettant deux blocs face à face. Dans un premier temps j’utilise un bloc en émission sur lequel je vérifie les paquets envoyés puis je place un second bloc en face et observe pas à pas la procédure de réception du paquet. Hier j’ai pu envoyer un paquet contenant de la data  et ayant un TTL de n. Le bloc qui reçoit ce paquet le réémet avec un TTL de n-1. Ainsi on pouvait voir les deux blocs s’échanger ce paquet jusqu’à atteindre un TTL de 0.

Je m’attache maintenant à la réception de commandes, c’est à dire des paquets sans data tel qu’un PING ou un PONG.  Je rencontre alors des problèmes, notamment avec le checksum et la réémission de ces paquets.