Robotique – Internet des Objets – Cloud

Et autres Technologies du Futur

Interface MapleSim / Port série

Maplesoft a choisi 3Sigma pour développer une interface entre MapleSim, son logiciel de modélisation physique multi-domaine, et le port série de l’ordinateur.

Pourquoi ce choix ?

  • Parce que 3Sigma connaît très bien Maple et MapleSim: les asservissements de nos robots Geeros ont été réalisés avec ces deux logiciels (http://blog.3sigma.fr/?p=254) sur lesquels nous réalisons par ailleurs des formations (http://www.formation-maple.com)
  • 3Sigma a également l’habitude de réaliser des développements utilisant le port série: dans certains de nos robots, une carte Arduino communique par ce biais avec une carte Linux embarqué

 

Qu’apporte à MapleSim une interface avec le port série ?

MapleSim est un logiciel très adapté pour modéliser des systèmes dans différents domaines de la physique. Il permet également de faire des calculs sur des signaux, afin d’enrichir les modèles avec des algorithmes d’asservissement ou de traitement du signal.

L’interface MapleSim / port série permet d’injecter dans votre modèle des données provenant d’un matériel externe connecté au port série de votre ordinateur. Ca peut-être, par exemple, une carte Arduino ! La seule contrainte sur les données envoyées est qu’elles soient séparées par des virgules et que chaque groupe de données se termine par un retour à la ligne.

Sur Arduino, un code qui fonctionne et qui permet d’envoyer les mesures des 6 premières entrées analogiques est le suivant:

// Variable stockant le temps écoulé depuis la dernière mesure
unsigned long previousMillis = 0;

// Intervalle entre deux mesures (en millisecondes)
const long interval = 10;

void setup() {
  Serial.begin(115200);
}

void loop() {
  // Temps courant (en millisecondes)
  unsigned long currentMillis = millis();

  // Ces mesures sont envoyées au port série toutes les "interval" ms
  if (currentMillis - previousMillis >= interval) {
    previousMillis = currentMillis;

    // Les données envoyées *doivent* être séparées par des virgules
    Serial.print((float)millis()/1000);
    Serial.print(",");
    Serial.print((float)analogRead(A0)/1024);
    Serial.print(",");
    Serial.print((float)analogRead(A1)/1024);
    Serial.print(",");
    Serial.print((float)analogRead(A2)/1024);
    Serial.print(",");
    Serial.print((float)analogRead(A3)/1024);
    Serial.print(",");
    Serial.print((float)analogRead(A4)/1024);
    Serial.print(",");
    // La dernière commande d'écriture sur le port série *doit* être println,
    // pour envoyer le caractère de retour à la ligne
    Serial.println((float)analogRead(A5)/1024);
  }

}

Pour avoir plus de détails au sujet de cette interface, disponible à partir de MapleSim 2016, vous pouvez contacter Maplesoft par téléphone au 01 84 73 00 10  ou par email à l’adresse france@maplesoft.com.

Les secrets de conception du robot Geeros avec Maple et MapleSim

Un gyropode est en contact avec le sol via deux roues parallèles ; c’est donc un système instable et seul un asservissement lui permet de rester en équilibre.

Nos robots Geeros n’échappent pas à la règle et nous avons dû concevoir des régulateurs pour les faire fonctionner correctement. D’ailleurs, c’était le but: créer un robot didactique avec des asservissements qui puissent être étudiés et modifiés par les élèves.

Dès lors, nous avions deux possibilités: faire comme tout le monde et utiliser les mêmes outils « classiques » que la majorité des personnes confrontées au même problème, ou rechercher s’il n’existait pas des approches plus modernes et plus efficaces mettant en œuvre du vrai « Model Based Design » (MBD, Conception à Base de Modèle).

Les promesses affichées par le couple Maple / MapleSim étant séduisantes, nous avons décidé d’utiliser ces deux logiciels.

Tout d’abord, pour ceux qui ne le connaissent pas, présentons MapleSim en quelques mots, en insistant sur ses différences avec d’autres logiciels de simulation qui pourraient sembler équivalents alors qu’ils ne le sont pas.

MapleSim est nativement orienté pour la simulation de systèmes physiques, ce qui signifie, entre autres, deux choses:

  • les modélisations se font en utilisant des blocs graphiques issus de la bibliothèque open-source Modelica (https://www.modelica.org). Ces blocs graphiques (ressorts, amortisseurs, résistances, diodes, moteurs de divers types,…) permettent de modéliser facilement des systèmes simples ou très complexes
  • les solveurs utilisés sont spécialement optimisés pour la résolution des équations différentielles avec contraintes algébriques rencontrées dans ce type de systèmes

Mais ce qui fait la grande force de MapleSim, c’est son lien avec Maple. En effet, à partir d’un modèle MapleSim, même très complexe, il est possible de générer automatiquement le jeu d’équations qui régissent le système. Maple permet ensuite de manipuler facilement ces équations pour, par exemple, concevoir un asservissement.

Revenons maintenant à Geeros. On peut trouver « dans la nature » beaucoup de modèles de gyropodes avec leurs asservissements associés. Mais en fait, la plupart du temps, ces modèles sont faux. En effet, écrire les équations exactes d’un gyropode devient vite très compliqué. Pas forcément dans l’écriture de chacune des équations, mais dans la gestion de l’ensemble: toutes ces équations prennent vite beaucoup de place et cela devient raisonnablement impossible de ne pas les simplifier.

Malheureusement, les simplifications conduisent rapidement à écrire les équations du gyropode comme celles du pendule inversé, alors que ce sont deux systèmes différents. Voilà pourquoi on rencontre la plupart du temps des modèles de gyropode faux: c’est humainement difficile de faire autrement.

Avec MapleSim et Maple, le processus de conception est totalement différent: il est facile de réaliser dans MapleSim un modèle de gyropode exact puisqu’il suffit d’assembler des blocs graphiques. Il n’est pas nécessaire d’écrire les équations du système pour faire le modèle. Ensuite, l’ensemble complet d’équations exactes est généré automatiquement dans Maple. Le problème de la manipulation des équations n’existe plus ici car c’est Maple qui s’en occupe: vous n’écrivez rien à la main. Vous avez alors le choix de travailler directement sur cet ensemble d’équations non-linéaires ou bien de les linéariser pour utiliser des techniques de conception d’asservissement plus traditionnelles.

Dans le second cas, pour prendre un exemple, le calcul symbolique des dérivées partielles de chaque équation par rapport à chaque état, permettant de passer des équations non-linéaires à une matrice d’équations linéaires se fait dans Maple en une seule commande. Notons que la matrice d’équations linéaires est toujours symbolique: les résistances, couples moteurs, frottements, inerties, etc… apparaissent toujours, ce qui est très intéressant pour réaliser des études paramétriques dans le domaine linéaire.

La conception de l’asservissement se fait tout aussi simplement. Pour Geeros, nous avons conçu un retour d’état que nous avons ensuite écrit sous la forme d’un PID pour que les élèves aient accès à une forme de régulateur connue.

Au final, l’utilisation de Maple et MapleSim a apporté les deux avantages suivant:

  • l’obtention rapide et aisée d’un modèle « exact », au sens où il n’est pas nécessaire de faire des simplifications pour le réaliser. Bien sûr, au sens strict du terme, le modèle ne colle pas exactement à la réalité car comme dans tout système physique, celle-ci est difficile à modéliser précisément
  • un gain de temps considérable dans le processus de conception puisqu’il n’est pas nécessaire d’écrire des équations à la main

Concernant ce dernier point, même si nous avons fait la conception dans Maple, rien ne vous empêche d’utiliser un autre logiciel (Matlab par exemple). On oppose souvent ces deux logiciels, ce qui est une regrettable erreur car ils sont en réalité complémentaires: MapleSim et Maple sont très forts pour la modélisation physique et la manipulation d’équations symboliques alors que Matlab possèdent de nombreuses boites à outils dans le domaine de l’automatique. De plus, Maple est capable de communiquer nativement avec Matlab pour envoyer des données à ce dernier, lui sous-traiter les calculs et récupérer les résultats.

Dans notre cas de figure, nous n’avons pas utilisé de techniques de conception de correcteur très avancées. Mais si cela avait été le cas nous aurions pu, après avoir obtenu le système d’état linéaire du gyropode dans Maple, envoyer les matrices de ce système à Matlab et utiliser, par exemple, une de ses boites à outils spécialisées en commande robuste. Puis, le résultat de cette conception avancée aurait été récupéré dans Maple et intégré ensuite dans notre modélisation boucle fermée du gyropode asservi dans MapleSim.

En conclusion, même si 80% des gens utilisent les mêmes outils pour faire les mêmes choses, ça vaut toujours le coup de passer un peu de temps pour faire le tour des différentes possibilités qui s’offrent à vous afin de voir s’il n’existe pas de nouveaux outils permettant d’améliorer les processus de conception.

 

Direct connection from Windows to SensorTag without Cloud or smartphone

The SensorTag from Texas Instruments is a great piece of hardware for evaluating the CC2650 microcontroller or… just for fun ! It comes with a lot of sensors (IR temperature, barometric, humidity, ligh, movement,…) you can read using your favorite radio interface. In this article, I will use the BLE (Bluetooth Low Energy) interface.

It also comes with Apps (for Android or iOS) so that you can look at its data on the tiny screen of your smartphone. And of course, since we live in a world where the desktop computer tends more and more to be considered as a prehistoric object, (almost) nothing exists if you want to explore the SensorTag data on the big screen of your computer.

I write « almost nothing » because you can do the following:

  • connect to the SensorTag with your smartphone
  • ask the App to send the data to the Cloud
  • from your computer, get the data from the Cloud

It is explained here more in details.

Simple, isn’t it ? You have 2 objects (the SensorTag and a computer) in your house and to make one communicate with the other one you need a third object (your smartphone) and you need to send your data around the world before getting them displayed less than 10 meters from where they are collected !

 

Is there a better solution ?

Fortunately, some companies and people have made a great job in order to make possible a direct connection between a Windows computer and a SensorTag.

The first thing you will need is a BLED112 dongle, from Bluegiga. It is a BLE dongle with a virtual serial port. You can use it on any computer (Windows, Linux, Mac).

The BLED112 can be controlled through a API (BGAPI) which has implementations in various languages, thanks to Jeff Rowberg (https://github.com/jrowberg/bglib).

Jeff and other people also worked (and obviously are still working) on PyGATT, a Python wrapper on gattool (used on Linux) and BGAPI. The origin of PyGATT is explained here.

We have now all what we need: a Windows PC, a bluetooth dongle, a Python library and the SensorTag documentation. Let’s code a demo !

 

Demo

I created a simple dashboard in order to display the data collected from the SensorTag. Using PyGATT is extremely easy, I just added in my Python program a Tornado Websocket server in order to communicate between this program and the browser-based dashboard.

What you can see on the video is the result of the SensorTag took from rest, put under a light during a few seconds and put back to rest. Sorry, I have no simple mean to make changes in the barometric pressure ;-)
The data collection is updated every seconds, but you can change it easily on the SensorTag.

 

A tutorial ? Some code ?

Yes, it is coming soon, please be patient. As you probably know, making something clean and shareable takes far more time than making this kind of prototype.

Stay tuned ! Updates will be sent via my Twitter account.

 

Next step(s)

Another thing that may be useful is to communicate between a microcontroller and the SensorTag in order to control hardware stuff (relays, motor, …) based on temperature, light,…

It is possible with the use of another product from Bluegiga, the BLE113. If soldering this kind of module is not your cup of tea, you can buy a breakout board there: http://www.jetney.com/breakouts/bluetooth-smart/ble113

You can then connect this breakout board to, let say, an Arduino (through their respective serial interface) and use the Arduino implementation of BGLib for the software part.

So, the next step is to write a SensorTag library based on BGLib. I started to do it and it should be finished soon.

And after, maybe, I will write a C library based on BGLib.

 

Life without Cloud ?

Of course, this acronym (LwC, Life without Cloud) will not become as popular as IoT (Internet of Thing). However, I always wonder why I should connect to the Cloud in order to get the temperature in my house or switch on my lights…

The Cloud is not my enemmy but I like simplicity and I prefer to keep my own data as private as possible.

I will post in this category various examples of IoT interactions you can make without any connection to the Cloud.

Test de la carte de contrôle robot A-Star 32U4 de Pololu

Introduction

Les robots développés par 3Sigma combinent depuis toujours une carte compatible Arduino et une carte sous Linux permettant de gérer la communication Wifi (avec un ordinateur, un smartphone, une tablette,…) pour le pilotage à distance et, éventuellement, la transmission vidéo temps-réel depuis le robot.

Cette architecture est utilisée, par exemple, dans le robot Geeros « RPi »:

  • Une carte Romeo (compatible Arduino Uno) gère la totalité des asservissements et les ponts en H de pilotage des moteurs
  • Une Raspberry Pi (parfois abrégée en « RPi » dans la suite de cet article) communique en Wifi avec l’ordinateur (ou smartphone, tablette,…) de pilotage pour récupérer les consignes de ce dernier et lui retransmettre la vidéo prise par la webcam intégrée au robot et les informations de télémétrie
  • La RPi échange par ailleurs (via une liaison série) avec la carte Romeo pour lui retransmettre les consignes de pilotage et récupérer les mesures qui doivent être renvoyées par la télémétrie

Dans cette architecture, les asservissements sont écrits en C/C++ (dans l’environnement Arduino) et sont exécutés sur la carte Romeo. Cependant, il est apparu depuis quelques temps le besoin, dans certaines filières de l’Education Nationale, d’avoir des robots programmables en Python. Il paraissait donc assez naturel de transférer une partie (ou la totalité) des tâches d’asservissement vers un mini-ordinateur embarquable de type Raspberry Pi.

C’est ce que nous avons tout d’abord fait avec le robot gyropode Geeros « pcDuino ». La carte pcDuino est, au même titre que la Raspberry Pi, un mini-ordinateur facilement embarquable dans un robot. La pcDuino a par ailleurs le bon goût de proposer une connectique et des signaux compatibles avec ceux d’un Arduino classique: on peut ainsi (en faisant toutefois attention aux niveaux de tension, les signaux de la pcDuino étant en 3.3V) lui ajouter directement de nombreux shields du monde Arduino.

Nous avons également conçu un X-Bot « pcDuino » (robot mobile classique à 2 roues + une boule omnidirectionnelle). Ce robot est d’ailleurs celui qui est le plus abouti en terme de programmation en Python puisque tout est fait exclusivement en Python sur la carte pcDuino, alors que dans le cas du Geeros « pcDuino », la mesure de vitesse des moteurs électriques est gérée par un Arduino Pro Mini, tout le reste (y compris les asservissements) étant programmé en Python et exécuté par la pcDuino.

Pourquoi cette différence entre le Geeros « pcDuino » et le X-Bot « pcDuino » ? Tout simplement parce que la mesure de vitesse d’un moteur électrique (plus de détails en cliquant ici) nécessite de gérer des interruptions très fréquemment et rapidement. Or, un mini-ordinateur de type pcDuino ou Raspberry Pi (tout au moins avec leur distribution Linux « standard ») n’est pas fait pour ça. Dans le cas du X-Bot « pcDuino », ça fonctionne mais c’est limite. Dans le cas du Geeros « pcDuino », on est en présence d’un gyropode: les asservissements sont très « pointus » pour pouvoir le faire tenir en équilibre sur ses 2 roues et ils ajoutent trop de charge au système. Celui-ci ne peut pas gérer en plus les interruptions des codeurs incrémentaux des moteurs à courant continu.

Vous pourriez penser que je m’égare (en plus, nous sommes toujours dans la partie « Introduction » !). Mais en fait non: le sujet qui nous intéresse aujourd’hui est le suivant: nous voulons également avoir une version de nos robots dont les asservissements sont programmés en Python sur une Raspberry Pi (histoire de ne fâcher personne: nous n’allons pas obliger les fans de cette carte à utiliser des robots à base de pcDuino !). Mais il y a un problème: la RPi est moins bien fournie que la pcDuino en E/S (je ne parle pas en nombre, mais en type): pas d’entrées analogiques, gestion des interruptions pas suffisamment efficace, seulement deux PWM.

Et c’est là qu’intervient, brbrbrbrbrbrbr (roulements de tambour): l’A-Star 32U4 !
Nous allons maintenant présenter cette carte et voir quel avantage ont peut tirer de son association avec une Raspberry Pi. Nous verrons en particulier que nous pouvons programmer les asservissements en Python sur la RPi et sous-traiter à l’A-Star la gestion de toutes les E/S manquantes sur la Raspberry Pi.

 

L’A-Star 32U4 – Ce que nous aimons

Je suis tenté de dire « j’en ai rêvé, Pololu l’a fait », car cette carte apporte beaucoup de fonctionnalités très intéressantes, détaillées ci-dessous.
Vous pourrez trouver plus de détails dans la documentation officielle (en anglais, désolé).

 

Une carte réellement faite pour le contrôle moteur – Peut s’utiliser de façon autonome

Ce sous-titre peut sembler superflu, mais en fait non: il existe des cartes qui sont censées  être faites pour le contrôle moteur et qui sont en réalité particulièrement mal pensées. Un brillant exemple est l’Arduino Motor Shield.
Et oui, c’est le shield « officiel », mais quand on lit la description, on se rend compte qu’un des PWM utilise la broche numéro 3. Or, quand on fait du contrôle moteur, on a souvent envie de mesurer sa vitesse. Ca se fait en branchant au moins une des deux voies du codeur incrémental sur une entrée de type interruption (plus de détails en cliquant ici). Et bien devinez quoi, une des entrées « interruption » de la carte Arduino Uno est la broche 3. C’est donc impossible de faire l’asservissement de deux moteurs à courant continu en utilisant l’Arduino Motor Shield. Nous ne pouvons donc pas l’utiliser dans nos robots, puisque ceux-ci intègrent toujours la mesure de vitesse des moteurs.
On pourrait se dire « qu’à cela ne tienne, je vais utiliser un Arduino Leonardo ! ».  C’est vrai, c’est moins pire car l’Arduino Leonardo possède 5 entrées interruption. Manque de chance, la broche 3 est l’une des deux broches de l’i2c. Impossible dans ces conditions de brancher le moindre périphérique i2c comme le MPU6050 de nos Geeros. Bref, il y a des produits mieux conçus que l’Arduino Motor Shield (ce shield de contrôle moteur, par exemple, est très bien).

Revenons à nos moutons. L’A-Star 32U4 n’est pas un shield de contrôle moteur, c’est une carte complète intégrant un micro-contrôleur (l’Atmega32u4, le même que celui de l’Arduino Leonardo). Vu de loin c’est un produit analogue à la carte Romeo: une « mono-carte » intégrant micro-contrôleur et pont en H, permettant d’éviter un empilement Arduino + shield.
Et donc, Pololu n’a pas fait la même erreur que l’équipe Arduino: l’i2c et les interruptions restent disponibles.

Cette carte a donc tout pour fonctionner de façon autonome. Et comme nous le verrons par la suite, on peut aussi l’utiliser en conjonction avec une carte Raspberry Pi.

 

Compatible Arduino et bibliothèque logicielle dédiée

L’A-Star peut être programmée à partir de l’environnement Arduino. La procédure d’installation est bien détaillée dans le documentation. Par ailleurs, une bibliothèque logicielle apporte des facilités d’utilisation supplémentaires.
Par exemple, la fonction « setSpeeds » (dans la classe « AStar32U4Motors ») permet de donner une consigne de tension d’alimentation pour chacun des moteurs, sans avoir à gérer le PWM et la direction.

 

S’utilise aussi avec une Raspberry Pi

Un des gros intérêts de l’A-Star 32U4 est qu’elle peut se connecter sur le connecteur 40 broches des Raspberry Pi A+, B+, Pi 2 modèle B et supérieur. Elle est d’ailleurs livrée avec des entretoises permettant de sécuriser le lien entre les deux cartes. C’est très utile car la RPi ne possédant un connecteur que d’un seul côté, bien qu’il y ait deux rangées de broches, les add-ons ont tendance à s’incliner, ce qui pourrait causer des court-circuits.
Les entretoises fournies évitent ce problème. Et au passage ça vous évite de vous en procurer vous-même: les concepteurs de la RPi ayant eu l’idée saugrenue de faire des trous de fixation pour de la quincaillerie M2.5 (alors que le M3 est infiniment plus courant), ce type d’entretoise n’est pas toujours très facile à trouver.

Lorsque l’A-Star est branchée sur une RPi, elle décharge cette dernière de la gestion des E/S bas niveau, en particulier pour la mesure de la vitesse des moteurs. En effet, cette mesure de vitesse nécessite des lignes d’interruption qui puissent être gérées de façon efficace. Certes, la Raspberry Pi est capable de gérer des interruptions, mais il ne s’agit pas ici de réagir à de simples boutons poussoirs. Dans le cas des moteurs utilisés dans nos robots, il faut pouvoir gérer très vite jusqu’à 2500 interruptions par seconde, sur deux voies en parallèle…

La communication entre la partie Atmega32u4 et la Raspberry Pi se fait en i2c (les 2 bus sont connectés nativement). Il existe même une bibliothèque permettant de faire des échanges à haute fréquence malgré le bug de l’i2c sur la Raspberry Pi

L’A-Star apporte également les entrées analogiques qui manquent cruellement à la Raspberry Pi, des PWM supplémentaires (très utile pour des robots multi-axes) et bien sûr les ponts en H nécessaires à la commande de 2 moteurs à courant continu.

 

Une gestion (très) intelligente des alimentations et des niveaux de tension

Les produits du monde Arduino / Raspberry Pi sont rarement décevants en terme de fonctionnalités (ils font ce qu’ils sont censés faire) mais le côté pratique n’est souvent pas au rendez-vous.

Par exemple, si vous avez déjà travaillé sur un projet Arduino avec plus de 2 capteurs, vous avez sans doute utilisé une plaque d’essai ou fait un bricolage pour contourner le manque de broches de masse et d’alimentation (merci DFRobot pour avoir développé le shield E/S permettant de résoudre le problème). Vous avez peut-être également pesté contre l’absence de trous de fixation de certains modules.

Dans le cas de l’A-Star, tout (ou presque) ce qu’on peut rêver de pratique quand on conçoit un robot est présent:

  • il y a un interrupteur on/off. On peut également connecter sa propre solution matérielle d’allumage / extinction grâce à 3 broches dédiées
  • la carte intègre un régulateur de tension 5V, ce qui évite d’en ajouter un, comme dans beaucoup de nos robots (en l’occurrence le S7V7F5, idéal pour fournir 1A à partir de notre batterie LiPo 7.4V)
  • le régulateur de tension prend en entrée des tensions comprises entre 2.7 et 11V: on peut donc alimenter la carte avec un adaptateur secteur 9V, une batterie 3.7V, ou 7.4V,…
  • on peut « attaquer » l’entrée du régulateur de tension de deux façons: en connectant deux fils sur un bornier ou bien en utilisant un connecteur jack. Très intéressant: ces deux entrées sont reliées en amont de l’interrupteur (c’est-à-dire, même si l’interrupteur est sur off). C’est très utile pour recharger une batterie lorsque le robot est éteint:
    (attention, ce qui suit est valable uniquement si vous utilisez cette batterie, intégrant nativement un gestionnaire de charge. Ne jamais faire ce qui suit avec un autre type de batterie)
    la batterie étant branchée sur le bornier, elle peut être rechargée robot éteint par un adaptateur secteur branché sur la prise jack
  • un circuit de commutation permet de pouvoir brancher sans risque en parallèle le câble USB de programmation
  • le régulateur de tension alimente aussi la Raspberry Pi mais si vous souhaitez avoir une alimentation dédiée, c’est également possible. On peut donc avoir sans problème 3 alimentations en parallèle: câble USB, alimentation jack (ou bornier) et alimentation Raspberry Pi
  • le niveau de tension en amont du régulateur peut être connecté (via un cavalier) sur une entrée analogique: c’est donc très facile de surveiller la charge d’une batterie, d’autant plus que la librairie Arduino de l’A-Star fournit une fonction dédiée pour ça: readBatteryMillivoltsLV()
  • toutes les broches « Arduino » de l’Atmega32u4 sont accessibles via un triplé masse – alimentation – signal. Par ailleurs, l’alimentation de ces broches est séparée en 4 groupes. Il est donc possible (dans une certaine mesure) de mélanger des capteurs alimentés en 3.3V et en 5V
  • dans le cas ou une conversion de niveau est nécessaire, (3.3V vers 5V et inversement), 3 convertisseurs sont présents et utilisables

 

Des LEDs et des boutons poussoir

C’est toujours utile pour avoir un retour d’information rapide et donner des commandes simples sans avoir besoin de mettre en place une connectivité évoluée.

 

Un buzzer ?

Oui, il y a un buzzer. A priori ça fait gadget, mais quand on a exécuté le programme d’exemple fourni avec la librairie de l’A-Star, on se demande comment on va s’en passer ;-)
En effet, il est désactivé sur nos robots car il partage le Timer 4 de l’Atmega32u4 avec la fonctionnalité d’exécution sur interruption hardware (cadence 10 ms) de certaines parties du programme.

 

(Petit) regret

Une connectique permettant de rajouter un shield ou tout au moins de connecter (par exemple) un module ESP8266 aurait été la cerise sur le gâteau. D’un autre côté, compte-tenu du facteur de forme choisi (contraint par la taille de la Raspberry Pi), on voit mal comment cela aurait pu être possible car la connectique potentielle est déjà très dense. D’autant plus que la RPi peut apporter ses propres atouts pour la connectivité Wifi de l’ensemble.

 

Conclusion

L’A-Star 32U4 est un produit très bien conçu qui est désormais présent dans notre nouvelle génération de robots à base de Raspberry Pi:

 

 

Pourquoi les prix en euros ne sont pas inférieurs aux prix en dollars ?

Cet article n’a pas pour objectif de répondre à cette question de façon universelle, mais uniquement dans le contexte de l’achat de pièces détachées pour réaliser le robot de vos rêves. Ceci étant, on peut quand même imaginer que les considérations suivantes puissent se généraliser dans un certain nombre de cas de figure.

Si vous avez l’habitude de parcourir des sites de robotique étrangers (au hasard: chinois, américains,…) et français avant de faire vos emplettes, vous avez sans doute remarqué que la carte micro-contrôleur, le capteur, les roues,… que vous souhaitez acheter et que vous voyez à 50 $ à l’étranger coûtent 50 € chez nous, et non pas 40 € comme on pourrait l’espérer avec une parité de 1.25 entre le dollar et l’euro. Notre boutique n’échappe pas à la règle.

Pourquoi ?
Non, ce n’est pas parce que le big boss est un affreux capitaliste qui collectionne les voitures de sport…

La vraie raison tient en deux mots: « TVA » et « frais de port ».

Posons donc les calculs et reprenons l’exemple du produit à 50 $ vu sur un site étranger. Comme vous pouvez vous en douter, le distributeur français ne va pas l’acheter à ce prix-là, mais avec une réduction d’en moyenne 25% (c’est très variable en fonction des fournisseurs).
Le prix d’achat pour le distributeur est donc de 37.50 $.

En appliquant une parité de 1.25 entre le dollar et l’euro, le prix d’achat pour le distributeur est de 30 €.

Jusque là, tout va bien, mais c’est ensuite que ça se gâte. En effet, il faut tout d’abord ajouter le transport et les frais de dédouanement, ce qui fait un minimum de 15%. Le coût du produit remonte donc à 34.50 €.

Il est en théorie possible (parfois) d’économiser quelques euros en choisissant la « poste normale » (étrangère, relayée par son homologue en France) comme transporteur, moyennant un délai plus long. Mais la seule expérience que nous avons faite s’est soldée par un échec cuisant: grâce au travail remarquable d’un célèbre prestataire de transport français que je ne citerai pas (mais dont le nom commence par « Chrono » et finit par « post »), censé prendre le relai de la poste américaine, le colis s’est trouvé renvoyé aux Etats-Unis sans passer par la case 3Sigma. Résultat des courses: nous avons payé deux fois le transport transatlantique.

Il faut rajouter ensuite la marge du distributeur (oui, il faut bien vivre…), disons 20%. Ceci donne le prix de vente HT au client final: environ 41.40 €.

Enfin, il faut rajouter la TVA, qui est payée par le client final (c’est-à-dire vous). Soit dit en passant, les prix affichés sur les sites étrangers sont hors taxe, ce qui faussent d’emblée les comparaisons trop rapides. Avec un taux actuel de 19.6% (j’espère que je n’aurai pas à remettre à jour ce chiffre trop souvent dans le futur…), cela donne (roulement de tambour…): 49.50 €.

Il est bien évident que toutes ces considérations n’auraient pas lieu d’être si on pouvait trouver des fabricants (français, belges,…) pour nos produits favoris. Mais ils sont malheureusement très rares.

Tutoriel Arduino : asservissement en vitesse d’un moteur à courant continu

L’asservissement en vitesse d’un moteur à courant continu est la plupart du temps nécessaire pour les robots mobiles. On peut éventuellement se satisfaire d’un servomoteur à rotation continu dans le cas de petits robots mais dans un cas plus général (comme pour le robot gyropode Geeros), il sera préférable d’utiliser un moteur à courant continu avec réducteur, associé à un codeur incrémental (pour mesurer la vitesse de rotation). Le calcul de l’asservissement sera réalisé par un Arduino. Nous allons détailler tout ceci dans la suite de cet article.

Matériel utilisé

Ce tutoriel peut être mis en application facilement avec l’expérience « Commande de moteur électrique ».

La carte Romeo est intéressante car elle intègre de façon très compacte le micro-contrôleur (AVR Atmega328, le même cœur qu’un Arduino Uno) et un double pont en H permettant de contrôler deux moteurs à courant continu avec un courant max de 2 A en permanence (jusqu’à 3 A en pic). Ce composant est indispensable pour fournir suffisamment d’énergie au moteur et lui permettre de fonctionner à vitesse variable et dans les deux sens de rotation.

Si vous utilisez d’autres éléments pour ce tutoriel, faites un choix cohérent :

  • La tension de la batterie doit correspondre à celle du moteur (pour ne pas griller ce dernier avec une fausse manipulation)
  • Le courant max du moteur doit correspondre à ce que peut supporter le driver de puissance

Concernant ce dernier point, dans la pratique les risques sont très limités si vous ne bloquez pas le moteur. Le courant à vide est en général relativement faible ; le courant max est observé uniquement lorsque le moteur est bloqué alors qu’il est alimenté avec sa tension maximale.

Mesure de la vitesse de rotation avec un codeur incrémental

Le codeur incrémental fournit deux signaux carrés en quadrature, comme sur la capture ci-dessous:

Ces deux signaux permettent de mesurer à la fois la vitesse et le sens de rotation.

Calcul de la vitesse

La mesure de la vitesse se fait simplement en comptant le nombre d’impulsions pendant un temps fixe. Les données du problème sont les suivantes :

  • Le codeur est fixé à l’arbre moteur et non pas à l’arbre de sortie du réducteur (celui utilisé pour l’entrainement). Le rapport de réduction étant 34:1, l’arbre moteur fait 34 tours lorsque l’arbre « principal » en fait 1
  • Le codeur génère 48 impulsions à chaque fois qu’il fait un tour
  • La cadence d’échantillonnage utilisée pour l’asservissement sera de 0.01 s

Par conséquent, lorsque l’arbre principal fait un tour, le codeur génère :
34 * 48 = 1632 impulsions.

Si N est le nombre d’impulsions comptées en 0.01 s, la vitesse est (en rad/s, l’unité standard, sachant qu’un tour fait 2*π radians) :
2*π*N/(0.01*1632)

Un point très important concerne la résolution de la mesure, c’est-à-dire la plus petite valeur qu’il est possible de calculer. La formule est la suivante (en rad/s) :
2*π/(Ts*CPR*ratio)
avec :

  • Ts : cadence d’échantillonnage
  • CPR : nombre d’impulsions par tour du codeur
  • ratio : rapport de réduction du moteur

Le but étant d’avoir la plus faible résolution possible (pour avoir une bonne précision de mesure), il faut avoir Ts et/ou CPR et/ou ratio le plus grand possible. Cependant, ratio est fixé par le besoin en couple ou en vitesse maximale alors que Ts doit être plus petit que le temps de réponse souhaité pour l’asservissement du moteur (voir plus loin). Par conséquent, la seule réelle possibilité est de jouer sur CPR. Lors du choix d’un codeur incrémental, il est préférable de prendre celui qui permet d’obtenir le plus d’impulsions par tour (si le budget le permet).

Dans notre cas de figure, la résolution est la suivante
2*π/(0.01*1632) = 0.4 rad/s

Ce n’est pas exceptionnel, le seul moyen de faire mieux serait de réduire le temps de réponse de l’asservissement de vitesse du moteur (voir plus loin).

Comptage du nombre d’impulsions

Compter le nombre d’impulsions du codeur revient à compter le nombre de fronts montants et descendants des signaux jaune et bleu représentés sur l’image ci-dessus. Pour ce faire, la seule méthode viable consiste à brancher les deux signaux (les fils jaune et blanc sur le codeur utilisé) sur deux entrées « interruption » de la carte Arduino. Les deux autres fils (bleu et vert) seront respectivement branchés sur le 5 V et sur la masse de l’Arduino.

Sur une carte Romeo (comme sur un Arduino Uno d’ailleurs), il y a deux lignes d’interruption (numérotées 0 et 1), qui correspondent aux broches digitales 2 et 3. L’intérêt d’une ligne d’interruption est qu’elle permet, comme son nom l’indique, d’interrompre le déroulement des calculs sur le micro-contrôleur pour effectuer un traitement spécifique, en l’occurrence la mise à jour du compteur d’impulsions, avant de rendre la main à la boucle principale.

La seule « difficulté » est de savoir s’il faut incrémenter ou décrémenter le compteur dans le traitement de l’interruption. Il suffit pour cela d’observer les courbes ci-dessus, obtenues alors que le moteur tourne dans le sens positif. On constate que:

  • Lorsque la voie A (en jaune) passe au niveau haut, la voie B (en bleu) est au niveau bas
  • Lorsque la voie A passe au niveau bas, la voie B est au niveau haut

Quand le moteur tourne dans le sens positif, lors d’une interruption sur la voie A, les niveaux de A et B sont donc inversés. Le code correspondant sur l’Arduino sera le suivant :

void GestionInterruptionCodeurPinA()
{
  if (digitalReadFast2(codeurPinA) == digitalReadFast2(codeurPinB)) {
    ticksCodeur--;
  }
  else {
    ticksCodeur++;
  }
}

En ce qui concerne l’interruption liée à la voie B, c’est l’inverse :

  • Lorsque la voie B passe au niveau haut, la voie A est au niveau haut
  • Lorsque la voie B passe au niveau bas, la voie A est au niveau bas

Le code de traitement de l’interruption de la voie B sera donc le suivant :

void GestionInterruptionCodeurPinB()
{
  if (digitalReadFast2(codeurPinA) == digitalReadFast2(codeurPinB)) {
    ticksCodeur++;
  }
  else {
    ticksCodeur--;
  }
}

Vous aurez peut-être remarqué l’utilisation de la fonction digitalReadFast2() pour lire le niveau des entrées codeur, au lieu de la fonction standard digitalRead(). Cette fonction, issues de la librairie digitalWriteFast (téléchargeable à l’adresse http://www.3sigma.fr/telechargements/digitalWriteFast.zip) permet d’améliorer la rapidité de lecture et d’écriture des entrées digitales pour minimiser le temps passé dans la routine d’interruption (et donc rendre la main plus vite à la boucle de calcul principal). Pour utiliser cette bibliothèque dans votre code, vous devez faire deux choses simples

  • décompresser l’archive que vous aurez téléchargée dans le sous-répertoire « librairies » de l’installation de votre environnement de développement Arduino
  • ajouter au début de votre programme la ligne
    #include <digitalWriteFast.h>

Le code permettant de calculer la vitesse est le suivant :

// Nombre de ticks codeur depuis la dernière fois
codeurDeltaPos = ticksCodeur;
ticksCodeur = 0;

// Calcul de la vitesse de rotation
omega = ((2.*3.141592*((double)codeurDeltaPos))/1632.)/0.01;  // en rad/s

Pour que cela fonctionne correctement, ce code doit être exécuté à la cadence fixe de 0.01 s. L’utilisation de la fonction delay() pour faire ça est une mauvaise méthode. En effet, vous pourriez penser écrire le code suivant :

void loop() {

  // Traitements divers
  // Lecture d'entrées + calculs par exemple

  // Attente de 10 ms
  delay(10);

}

Le problème est que les « traitements divers » vont prendre un certain temps, inconnu (T) et potentiellement variable (dans le cas où ils incluent des instructions conditionnelles). Par conséquent, la boucle sera exécutée toutes les T+0.01 s et non pas toutes les 0.01 s, et la mesure de la vitesse de rotation sera fausse.

La bonne méthode consiste à utiliser un timer du micro-contrôleur pour générer une interruption toutes les 0.01 s. Vous pouvez utiliser pour cela la bibliothèque FlexiTimer2 (téléchargeable ici: http://www.3sigma.fr/telechargements/FlexiTimer2.zip). Après l’avoir décompressée, il faut la placer dans le sous-répertoire « librairies » de l’installation de l’environnement de développement Arduino et ajouter au début du programme la ligne :

#include <FlexiTimer2.h>

Enfin, il faut ajouter les deux lignes suivantes dans la fonction startup() :

FlexiTimer2::set(10, 1/1000., isrt); // résolution timer = 1 ms
FlexiTimer2::start();

La première ligne crée une interruption qui se produit toutes les 10 ms (avec une résolution de 1 ms), ce qui exécute alors la fonction isrt() (contenant le code permettant de calculer la vitesse de rotation et de réaliser l’asservissement de vitesse). La seconde ligne démarre ce timer.

 

Asservissement en vitesse du moteur

Pour asservir le moteur en vitesse, nous allons utiliser un régulateur de type PID (Proportionnel Intégral Dérivé). Ce régulateur combine les 3 actions suivantes:

  • Proportionnelle : action proportionnelle à l’écart entre la consigne de vitesse et la mesure
  • Intégrale: cette action est basée sur l’intégrale par rapport au temps de l’écart entre la consigne et la mesure. Elle permet de compenser une erreur permanente (appelée « erreur statique ») entre la consigne et la mesure
  • Dérivée: cette action est basée sur la dérivée par rapport au temps de l’écart entre la consigne et la mesure. Elle permet d’anticiper cet écart, ce qui est utile pour des systèmes naturellement instables, au prix d’une amplification des bruits de mesure

Il n’est pas utile d’associer systématiquement ces trois actions (la proportionnelle est cependant toujours présente). Dans notre cas de figure, un PI suffira, l’anticipation apportée par l’action dérivée n’étant pas utile.

Les gains proportionnel et l’intégral étant respectivement Kp=0.29 et Ki=8.93, le code du la régulation PID s’écrit:

  /******* Régulation PID ********/
  // Ecart entre la consigne et la mesure
  ecart = vref - omega;

  // Terme proportionnel
  P_x = Kp * ecart;

  // Calcul de la commande
  commande = P_x + I_x;

  // Terme intégral (sera utilisé lors du pas d'échantillonnage suivant)
  I_x = I_x + Ki * dt * ecart;
  /******* Fin régulation PID ********/

 

Code complet

Le code complet permettant de réaliser sur la carte Arduino Romeo cet asservissement de vitesse d’un moteur à courant continu avec codeur incrémental est le suivant :

#include <FlexiTimer2.h>
#include <digitalWriteFast.h> 

// Codeur incrémental
#define codeurInterruptionA 0
#define codeurInterruptionB 1
#define codeurPinA 2
#define codeurPinB 3
volatile long ticksCodeur = 0;

// Moteur CC
#define directionMoteur  4
#define pwmMoteur  5

// Cadence d'envoi des données en ms
#define TSDATA 100
unsigned long tempsDernierEnvoi = 0;
unsigned long tempsCourant = 0;

// Cadence d'échantillonnage en ms
#define CADENCE_MS 10
volatile double dt = CADENCE_MS/1000.;
volatile double temps = -CADENCE_MS/1000.;

volatile double omega;
volatile double commande = 0.;
volatile double vref = 3.14;

// PID
volatile double Kp = 0.29;
volatile double Ki = 8.93;
volatile double P_x = 0.;
volatile double I_x = 0.;
volatile double ecart = 0.;

// Initialisations
void setup(void) {

  // Codeur incrémental
  pinMode(codeurPinA, INPUT);      // entrée digitale pin A codeur
  pinMode(codeurPinB, INPUT);      // entrée digitale pin B codeur
  digitalWrite(codeurPinA, HIGH);  // activation de la résistance de pullup
  digitalWrite(codeurPinB, HIGH);  // activation de la résistance de pullup
  attachInterrupt(codeurInterruptionA, GestionInterruptionCodeurPinA, CHANGE);
  attachInterrupt(codeurInterruptionB, GestionInterruptionCodeurPinB, CHANGE);

  // Moteur CC
  pinMode(directionMoteur, OUTPUT);
  pinMode(pwmMoteur, OUTPUT);

  // Liaison série
  Serial.begin(9600);
  Serial.flush();

  // Compteur d'impulsions de l'encodeur
  ticksCodeur = 0;

  // La routine isrt est exécutée à cadence fixe
  FlexiTimer2::set(CADENCE_MS, 1/1000., isrt); // résolution timer = 1 ms
  FlexiTimer2::start();

}

// Boucle principale
void loop() {

  // Ecriture des données sur la liaison série
  ecritureData();

}

void isrt(){

  int codeurDeltaPos;
  double tensionBatterie;

  // Nombre de ticks codeur depuis la dernière fois
  codeurDeltaPos = ticksCodeur;
  ticksCodeur = 0;

  // Calcul de la vitesse de rotation
  omega = ((2.*3.141592*((double)codeurDeltaPos))/1632.)/dt;  // en rad/s

  /******* Régulation PID ********/
  // Ecart entre la consigne et la mesure
  ecart = vref - omega;

  // Terme proportionnel
  P_x = Kp * ecart;

  // Calcul de la commande
  commande = P_x + I_x;

  // Terme intégral (sera utilisé lors du pas d'échantillonnage suivant)
  I_x = I_x + Ki * dt * ecart;
  /******* Fin régulation PID ********/

  // Envoi de la commande au moteur
  tensionBatterie = 7.2;
  CommandeMoteur(commande, tensionBatterie);

  temps += dt;
}

void ecritureData(void) {

  // Ecriture des données en sortie tous les TSDATA millisecondes
  tempsCourant = millis();
  if (tempsCourant-tempsDernierEnvoi > TSDATA) {
    Serial.print(temps);

    Serial.print(",");
    Serial.print(omega);

    Serial.print("\r");
    Serial.print("\n");

    tempsDernierEnvoi = tempsCourant;
  }
}

void CommandeMoteur(double tension, double tensionBatterie)
{
	int tension_int;

	// Normalisation de la tension d'alimentation par
        // rapport à la tension batterie
	tension_int = (int)(255*(tension/tensionBatterie));

	// Saturation par sécurité
	if (tension_int>255) {
		tension_int = 255;
	}
	if (tension_int<-255) {
		tension_int = -255;
	}

        // Commande PWM
	if (tension_int>=0) {
		digitalWrite(directionMoteur, LOW);
		analogWrite(pwmMoteur, tension_int);
	}
	if (tension_int<0) {
		digitalWrite(directionMoteur, HIGH);
		analogWrite(pwmMoteur, -tension_int);
	}
}

// Routine de service d'interruption attachée à la voie A du codeur incrémental
void GestionInterruptionCodeurPinA()
{
  if (digitalReadFast2(codeurPinA) == digitalReadFast2(codeurPinB)) {
    ticksCodeur--;
  }
  else {
    ticksCodeur++;
  }
}

// Routine de service d'interruption attachée à la voie B du codeur incrémental
void GestionInterruptionCodeurPinB()
{
  if (digitalReadFast2(codeurPinA) == digitalReadFast2(codeurPinB)) {
    ticksCodeur++;
  }
  else {
    ticksCodeur--;
  }
}

Ce code intègre ce qui a été détaillé précédemment.

Connecter la carte Mini2440 sur un réseau Wifi

Maintenant que vous savez connecter la Mini2440 sur votre réseau local, vous êtes en mesure d’y accéder via Telnet et d’envoyer des fichiers via FTP. Mais la Mini2440 étant destinée à être embarquée dans un robot mobile (Geeros), on la voit mal restée branchée à un routeur via un câble Ethernet. Nous allons donc ici lui permettre de rejoindre un réseau Wifi.

Avant de décrire les différentes étapes, vérifions tout d’abord si les outils Wifi sont installés sur votre carte (a priori non). Exécutez la commande « scan-wifi ». Si vous avez en retour « -sh: scan-wifi: not found », cela signifie que vous devez installer le kit Wifi, usb-wifi-kits-for-mini2440-linux-2.6.32.2-20100728.tar.gz.Vérifiez avant que votre version de Linux est bien linux-2.6.32.x (« cat /proc/version »).

Pour cela, vous allez télécharger le fichier sur la Mini2440 en utilisant un client FTP sur votre ordinateur. Mais avant tout vous devez spécifier un mot de passe au compte utilisé sur la Mini2440 (par défaut: root). Après connexion en telnet à, par exemple, ce compte root, créez un mot de passe avec la commande « passwd ».

Vous pouvez maintenant envoyer en FTP l’archive sur la carte. Décompressez-là ensuite avec la commande suivante:

 

tar xvf usb-wifi-kits-for-mini2440-linux-2.6.32.2-20100728.tar.gz

 

 

Avant de ré-exécuter la commande « scan-wifi », redémarrez la Mini2440 et connectez une clé USB Wifi sur le port hôte de la carte. Attention: toutes les clés ne sont pas supportées, loin de là. J’ai personnellement utilisé ce très bon modèle: TP-Link – TL-WN722N. Son antenne permet en particulier d’avoir une très bonne portée ce qui est important pour un robot mobile.

Vous pouvez maintenant exécuter les commandes suivantes:

  • Recherche des réseaux Wifi à proximité:
     

    scan-wifi

     

  • Connexion en Wifi au réseau de votre choix (en mode WPA2 dans l’exemple ci-dessous)
     

    start-wifi wpa2 essid_de_votre_reseau mot_de_passe_de_votre_reseau

     

Après cette dernière commande, l’adresse IP de la carte est assignée automatiquement via DHCP.
Si vous souhaitez la définir vous même, utilisez la commande suivante:

ifconfig wlan0 192.168.43.199

 

Remarque importante: la carte Mini2440 est alors connectée à votre réseau Wifi en mode « managed », c’est-à-dire comme (a priori) vos autres clients Wifi. Deux autres modes pourraient être utiles:

  • Ad-hoc: dans ce cas, la Mini2440 servirait de point d’accès et vous pourriez y connecter directement un ordinateur ou un iPhone, mais pas un smartphone Android, cet OS ne supportant pas (à l’heure de l’écriture de ce billet, espérons que ça change dans le futur) les réseaux Ad-hoc
  • Master: ici, c’est la Mini2440 dans sa configuration de base qui ne supporte pas ce mode

 

Connecter la carte Mini2440 sur votre réseau local

Je démarre avec ce billet une série de tutoriels autour de la carte Mini2440, qui fût un temps le coeur de communication du robot Geeros.

Je précise également qu’un des objectifs de ces tutoriels est de faire « simple et efficace ». Vous ne trouverez pas ici comment installer la distribution Linux de votre choix sur la carte, mais comment la rendre opérationnelle facilement et rapidement.

Pour commencer, si vous ne possédez pas encore de carte Mini2440, je vous conseille de l’acheter ici ou ou ailleurs mais en tous cas, choisissez plutôt une version incluant câbles, alimentation, etc…, ça vous évitera de perdre du temps et de l’argent à acheter ce qui vous manque séparément. En particulier, le câble série que vous possédez peut-être, peut finalement ne pas convenir: il faut un câble droit, pas un croisé.
Il vous restera éventuellement à acheter un adaptateur secteur US-France car vous recevrez peut-être une alimentation avec une prise pour les Etats-Unis.

Avant de poursuivre, voici une photo de la carte, qui nous servira de référence pour la suite:

A la fin de ce tutoriel, la carte sera reconnue sur votre réseau, ce qui vous permettra par conséquent, entre autres, de communiquer avec elle via Telnet, ce qui est plus pratique que d’utiliser la console série. Celle-ci est cependant très utile pour la configuration, comme nous allons le voir.

En « sortie de boite » la carte est a priori configurée avec l’adresse IP 192.168.1.230. Sauf si vous être moyennement chanceux, ça ne correspondra pas à la plage d’adresse de votre réseau local. En ce qui me concerne par exemple, c’est 192.168.0.xxx.

La méthode la plus simple (quoique…) serait bien sûr de modifier la plage d’adresse de votre réseau local, mais ce n’est pas bien compliqué de modifier l’adresse IP de la Mini2440. D’autant plus que ça va nous permettre d’avoir un premier contact avec le Linux embarqué sur cette dernière. C’est ce que nous allons voir ici.

Les étapes à suivre sont les suivantes:

  • mettez l’interrupteur de la flash (interrupteur « Boot Mode » en bas à droite de l’image) en position « NOR » (vers la droite)
  • branchez le câble série entre la carte (UART0 RS232) et votre ordinateur. Pas de port série sur votre ordinateur ? Arghh ! Il faut toujours garder une vieille machine chez soi… Sinon, vous pouvez utiliser un adaptateur USB / série comme on peut en trouver facilement sur Internet
  • branchez un câble Ethernet entre la carte et votre routeur
  • branchez l’alimentation (5V Power In, en haut à droite de l’image)
  • commutez l’interrupteur Power sur « On » (vers la droite)
  • lancez sur votre ordinateur une console série avec les paramètres suivants:
    • 115200 bits/s
    • 8 bits de données
    • Parité: aucune
    • Bits de stop: 1
    • Contrôle de flux: aucun
  • vous vous retrouvez devant le menu d’accueil du bootloader chargé par défaut, Supervivi
  • tapez « b » pour booter la carte. A la fin du boot, vous êtes en mesure de taper des commandes Linux
  • un petit « ifconfig » vous permettra de connaître l’adresse IP de la carte. Si vous avez de la chance, elle sera dans la même plage que votre réseau local. Sinon, changez-là comme ceci (adaptez bien sûr les adresses à ce qui vous convient):
     

    ifconfig eth0 192.168.0.199 netmask 255.255.255.0 up
    route add default gw 192.168.0.1

     

  • depuis votre machine cliente, vous pouvez alors communiquer en telnet (login: root, pas de mot de passe)

Pour éviter de refaire la même manipulation à chaque fois, vous pouvez configurer la carte pour qu’elle ait toujours la même adresse IP:

  • éditez le fichier /etc/eth0-setting pour adapter les adresses IP, Gateway et DNS à votre réseau:
     

    IP=192.168.0.199
    Mask=255.255.255.0
    Gateway=192.168.0.1
    DNS=192.168.0.1
    MAC=08:90:90:90:90:90

     

  • arrêtez proprement le système (« poweroff « ). Rassurez-vous un arrêt sauvage (en allant directement au point suivant) fonctionne aussi
  • commutez l’interrupteur Power sur « Off » (vers la gauche)
  • mettez l’interrupteur de la flash en position « NAND » (vers la gauche). Ceci permet de booter automatiquement sans s’arrêter sur le menu de Supervivi

Vous pouvez désormais rallumer la carte qui va alors démarrer avec l’adresse IP que vous souhaitez.