Marché

On me demande de donner une étude de marché. Cela est je pense difficile, et l'innovation ne peut à mon avis se faire sans risque.

Depuis quelques jours, je réfléchis à une comparaison entre d'une part et le train et l'avion, et d'autre part, l'éoliennes classique et l'éolienne volante.

Le train comme l'éolienne est lourd en investissement, mais a de bons rendements. Le train comme l'éolienne ont révolutionné le monde. Le train existait avant l'avion, mais les hommes rêvaient déjà de voler. Aujourd'hui l'éolienne existe, mais des hommes rèvent d'éoliennes volantes. Il a fallu 100 ans pour que nous soyons capables de construire des avions géants comme les airbus A380. Combien en faudra-t-il pour développer les éoliennes volantes?.

A ces débuts, l'aviation s'est développée de manière industrielle avec la première guerre mondiale. Aujourd'hui c'est la crise écologique qui pourrait être le moteur du développement des éoliennes aériennes.

Une différence notable cependant : la vie des humains n'est pas en jeu. ce qui doit permettre d'être plus audacieux et d'accélérer les développements des éoliennes aériennes.

Voici un panorama du marché actuel et des hypothèses sur un marché futur.

Les concepteurs/fabriquants existants :
-les "gros" : ils existent depuis plus d'une moitié de décennie ce qui est une éternité dans le secteur, ont souvent l'appui d'un groupe puissant, ou de subventions étatiques.
Makani power : existe déjà depuis 5 ans et vient d'être racheté par Google. Leur prototype est très complexe et semble difficile à agrandir.
Skysails : après une première expérience dans la traction des cargos avec un système automatisé, Skysails se lance dans l'énergie, en visant surtout les implantations offshores. Skysails est une sorte de dinosaure un peu lourd qui a déblayé le chemin, mais a grillé beaucoup d'énergie en passant rapidement au prototype à taille réelle.

- les "moyens" : plus jeunes, ou n'ayant pas fait le choix de la levée de fond à outrance. Eventuellement des entreprises de l'éolien qui se lance dans l'éolien aérien.
Kitegen et KiteNRG,
Enerkite, etc

- les "startups" : elles sont souvents issues d'universités ayant travaillé sur le sujet.
Ampyx : spin off de TU Delft.
TwingTec : spin off de l'ETH Zurich

- les inventeurs : souvent isolés, ils peuvent cependant s'associer en réseau. Ils n'ont généralement pas encore fait le choix d'une technologie, et regardent/représentent toutes les alternatives.
-Kpower
-Flygen

- les journalistes/experts/bloggers : ils surveillent et commentent l'activité du secteur, souvent sans prendre part au développement. Leur recul et la comparaison des différentes solutions peuvent-être intéressants, mais beaucoup pensent avoir une vision globale car ils ont identifiés quelques acteurs. Leurs questions et septicisme fait naître jour après jour de nouvelles solutions, et ce sont à l'heure actuelle les seuls "clients" du secteur.

Les concepteurs/fabriquants potentiels
La technologie de l'éolienne aérienne faisant appel à moins de matériaux et à plus de contrôle, les futurs entreprises du secteur pourront venir aussi bien de l'industrie (Alstom, EDF, DCNS) que du service logiciel (comme le montre Google).

Les futurs clients :
Le client final est le foyer ou l'entreprise qui a besoin d'électricité. Si une partie est prête à payer plus cher, la majorité préfère une bonne guerre et quelques catastrophes naturelles pour continuer à vivre dans le même confort.
Un client intermédiaire serait EDF, du fait de l'obligation d'achat si le prix est élevé, ou du fait de la loi du marché dans le cas contraire (marge importante possible).
Un autre client intermédiaire serait un gestionnaire du site de production.
Un autre client pourrait-être l'installateur.
Pour les activités de recherche/conception/développement, un client est le fabriquant.

Autres acteurs

Collectivités et politiques
Ils s'intéressent à la dimension économique locale (création ou maintien d'emploi)

Riverains : du fait de l'éloignement par rapport à la côte, les problèmes de voisinage (gêne visuelle) que l'on retrouve avec les éoliennes disparaissent.
Les plaisanciers, pêcheurs sont par contre directement concernés par une activité qui peut limiter leur zone de chalandise.
L'impact sur les êtres vivants marins (oiseaux, poissons, mammifères, végétaux, coraux) devra être considéré. Si dans le cas nominal, l'impact semble réduit par rapport à l'éolien classique, il faut également considérer la possibilité de crash.
Les matériaux utilisés sont également incertains à ce jour (fibre polymère, textile, carbone?) et l'impact de leur production dépend grandement de la technologie de la filière de production (la filière de production du silicium n'est aujourd'hui pas adapté par exemple pour la filière solaire).

Part de marché visée :
Équivalente à la France, pour la conception.

Traversée de l'Atlantique en relais kitesurf

6 courageux se lancent le défi de traverser l'Atlantique en kite en se relayant (avec le support d'un voilier).
http://enablepassion.com/

Open Atelier à Plateforme C

Aujourd'hui passage aux open atelier de Ping à Plateforme C.

On m'a conseillé kokopelli pour la réalisation de pièce en 2D ou 3D avec des scripts python. J'essaie.

J'ai également fait quelques tests des moteurs qui n'avaient pas tourné depuis longtemps.
Je vais réinstaller un banc de test dans la semaine afin de tester un nouveau proto matériel (toujours en attente de poulie commandée il y a 15 jours sur ruedelamer).

2e5 design de cerfs-volants

Un site qui révele des ficelles pour la conception de cerfs-volants http://2e5.com/

KPower : cerf-volant faisant des loopings couplé à un cerf-volant autozenith

KPower est un groupe d'anciens cerfs-volistes et de fermiers texans, essayant de trouver des solutions pour récupérer l'énergie du vent grâce à des cerfs-volants (pour des usages directement mécaniques), mais de manière robuste (sans automatisme). Une approche très pragmatique qui peut parfois surprendre.
Ils ont une ferme "AWE camp" au Texas, où ils testent de nombreux prototypes dans un esprit 100% open hardware
Ils participent activement à la mailing list AirborneWindEnergy@yahoogroups.com où ils ont posté la vidéo suivante cette semaine.


Je trouve que c'est un prototype très intéressant permettant d'avoir à la fois un système très stable (et indépendant des mouvements de la plateforme, par exemple dans le cas d'une plateforme flottante) avec le cerf-volant autostable statique, et un sytème dynamique stabilisé (naturellement instable et performant) avec l'aile de traction.
La stabilité du vol en looping peut-être assurée grâce à un rappel pouvant être créé grâce à l'écartement des points d'accroche du cerf-volant de traction sur la ligne du cerf-volant delta (le delta n'est pas ici un très bon choix, mais c'est ce qu'ils avaient sous la main).
La stabilité du cerf-volant delta est évidemment limitée à une certaine plage de vent, mais le principe est bon. 

Matériel utilisé

Les applications pour la production d'énergie sont directes.
Pour la navigation, l'intérêt est moins évident, peut-être pour le vent arrière.

TU Delft - Simulateur -Uwe Fechner

Une petite page de pub pour le travail d'Uwe Fechner, doctorant à l'université de Delft.
Il est en train de publier le code du simulateur de vol qu'ils ont développé.
Après quelques difficultés liés à mon utilisation d'une version différente d'ubuntu, j'ai finalement réussi à installer et tester rapidement le code qui est disponible sur bitbucket. Rolf van der Vlugt participe également.

Je vais leur filer un coup de main pour passer la visualisation dans webgl, afin de réduire les dépendances.

Voici quelques copies d'écran de l'interface :

Job opportunities !

Non, robokite n'embauche pas encore !

Voici cependant quelques offres d'emplois qui témoignent du dynamisme dans le secteur.

Kitemill (Norvège) ouvre un poste d'ingénieur aérodynamique et d'ingénieur en automatique/contrôle. Merci Sofien pour l'info!

Ampyx recherche un ingénieur en automatique du vol.

MINESTO

Après quelques nouvelles sur les paravannes associées au kite, on passe maintenant complètement sous l'eau avec Minesto, qui développe un système de récupération de l'énergie du courant à base de cerf-plongeant. Le principe est proche de celui de Makani, mais sous l'eau.
Magnus Landberg, l'inventeur de ce prototype soutenu pas Saab, l'avait à l'origine appellé Enerkite.
Un foil rigide attaché à un flotteur (lui même attaché au sol) par un câble atteint des vitesses atteignant 10 fois celle du courant. Sous ce foil est placée une petite turbine qui produit l'électricité. Un prototype de la taille d'une planche à voile (3 m d'envergure, échelle 1:4) a apparemment été testé. Ils sont actuellement dans la phase de "scaling up" pour atteindre le mégawatt (projection pour 2015), et font donc un peu de com! L'approche par étape présentée sur leur site me paraît raisonnable. Voici quelques photos de minesto

Nouvelles publications du Gipsa lab

Le GIPSA lab de Grenoble vient de publier de nouveaux papiers sur les kites :

• un papier sur une expérimentation indoor du "reverse pumping" qui permet de maintenir un cerf-volant en l'air, où de le faire monter en transférant l'énergie de manière mécanique par le câble (tension) 
•  un papier sur la gestion automatique de la puissance (et de la trajectoire) avec des rafales (simulées en soufflerie) pour résister au décrochage, à l'inversion de portance, à la surcharge et la souscharge.

ENSTA Bretagne

J'avais rencontré Richard Leloup, doctorant à l'ENSTA, lors de l'AWEC 2013. Richard travaille sur le calcul numérique des performances des kiteboats, en comparaison par rapport à la voile classique. A l'occasion de la publication, d'un papier dans le livre "Airborne Wind Energy", l'ENSTA a publié un article présentant l'ensemble de l'équipe travaillant sur le sujet. http://www.ensta-bretagne.fr/index.php/actualite/tracter-des-navires-avec-la-force-du-vent-le-projet-beyond-the-sea/

Olivier Suire, Luc Armant, l'Aile d'eau, le retour?

J'avais déjà parlé sur ce blog du travail l'Aile d'eau de Luc Armant, qui semblait depuis travailler principalement dans le parapente.
J'avais également présenté Seaglider, le système de paravanne commercialisé.

Je viens de découvrir (dans un post récent sur un forum) un autre projet, dans lequel on retrouve Luc Armant.

Les vidéos d'il y a deux ans montrent les premières expérimentations (de ce projet ou de Cglider, j'avoue être perdu ?)


Ce qui est un peu étrange c'est que ce projet semble également lié au projet Cglider de Sylvain Claudel (et Didier Coste), mais ne semble avoir rien en commun avec le Seaglider de Stéphane Rousson (même prononciation en anglais! Ce nom désigne également un robot sous-marin avançant avec les vagues).
 Olivier Suire est lui connu pour le crab buggy :

TOWT

Transoceanic Wind Transport est une entreprise créée pour affréter des navires à voile au transport de marchandise.

C'est une des applications potentielles du projet robokite.
Ce matin le Biche, un vieux gréement de type thonier dundee, faisait escale à Nantes pour faire le plein de denrées avant de remonter vers la Bretagne.

Je suis aller prendre quelques photos et essayer de rencontrer l'équipage. Ils restent jusqu'à demain. J'irai leur donner un coup de main demain après-midi pour le chargement de la cargaison.

Edit 25/11/2013 : j'ai pu rencontré Guillaume Le Grand et son équipe. Un reportage sur le commerce à la voile sera bientôt publié sur Euradio (et la question de l'utilisation des cerfs-volants y sera abordée.

Programme android

Robokite repose actuellement sur deux applications android : IP Webcam et sensorUdp. La première est très satisfaisante, gratuite, mais pas libre, et ne pourra donc être modifiée le jour où besoin.
La deuxième est libre, mais semble bugguée (à moins que le bug ne soit dans les données reçues par l'application).

Je prévois donc d'une part de faire un fork de sensorUdp, et d'autre part de trouver une application open source en remplacement de IP Webcam.
Je crois enfin avoir trouvé une application intéressante : wifi camera (android eye). J'arrive bien à récupérer l'image dans le navigateur (attention il y a un bug dans l'adresse ip proposé). Il me reste à tester avec simplecv.

Oscilloscope et benchmark firmata

L'autre jour, je cherchais un "oscilloscope" arduino dans le navigateur.
J'ai finalement redeveloppé ma propre version à partir de différentes versions.

Au début, j'avais essayé d'intégrer firmata, pour être le plus générique possible. Pour cela j'utilisais le "StandardFirmata" d'arduino, et la bibliothèque pyfirmata du côté python.
Malheureusement, j'observais des plats au niveau de l'oscilloscope, avec environ 5 valeurs par seconde. J'avais observé ces plats dans des captures d'écran d'autres oscilloscopes utlisant arduino et firmata. J'étais donc passé sur un programme maison arduino faisant un envoi en continu des données de pins (en ascii) plutôt que firmata. Cela fonctionnait beaucoup mieux.

J'en avais conclu que firmata était peut-être générique, mais probablement lent.

Cependant l'utilisation de firmata pour des applications temps réels, comme avec johny-five, m'a interrogé sur les performances réels, et sur la source de ces plats (firmata sur l'arduino ou pyfirmata sur le pc?).

J'ai donc comparé les différentes implémentations de firmata python, ainsi que d'autres solutions similaires. Malheureusement sur les deux implémentations python, la deuxième est bugguée. J'ai en tout cas pu vérifier l'existence de plat (freeze). Le script de test est ici

• python-firmata

Ne marche pas

• pyfirmata

28kHz mais  seulement 40Hz effectif environ (les données sont freezées).

• Python-Arduino-Proto-API-V2 

Environ 50 Hz 

• Python-Arduino-Command-API

Environ 60 Hz

Code créatif

Hier, j'étais à la session Code Créatif (organisée tous les mercredis soir à Nantes).
Sébastien qui travaillait sur un projet de domotique (contrôle de télérupteur via arduino au travers d'une interface web) m'a fait découvrir différentes solutions. Il a choisi duino + heim control, mais m'a également parlé de johny-five, notamment utilisé par Xavier Seignard de Stéréolux, qui utilise firmata. Les deux solutions ont en commun de faire appel à Node.js qui est un serveur en javascript. Johny-five est en fait une API permettant de contrôler l'arduino et toute une bibliothèque de capteurs ou actionneurs directement dans le serveur en javascript (tournant par exemple sur un raspberry). Je n'ai pas trouvé de solution python équivalente.
J'ai également découvert red-node qui est développé par des chercheurs d'IBM dans le domaine des objects connectés et qui permet de programmer directement des "comportements" de manière graphique dans le navigateur.
Cela devrait permettre une démocratisation de la programmation pour une adaptation rapide à de nombreux usages à partir de briques de base.

Cela m'a en tout cas poussé à reconsidérer l'utilisation de firmata comme standard d'échange. J'ai donc réalisé un benchmark pour vérifier les problèmes que j'avais eus avec la fréquence de rafraichissement des données "feedback". Ce sera le sujet d'un autre article.

Accéléromètre + Magnétomètre + Gyroscope

 L'utilisation d'un accéléromètre et d'un magnétomètre est limité si les capteurs subissent des accélérations (par exemple si embarqués sur le cerf-volant ou sur les lignes). Le gyroscope permet de régler ce problème pour des accélérations suffisamment faibles ou à moyenne nulle.

Voici trois idées de solutions :
 
- Motorola G : le nouveau téléphone qui sort la semaine prochaine à partir de 169 euros. Avantage : GPS, Wifi, écran, USB OTG, batterie et plus encore. Ma solution préférée pour de l'embarqué grand public, mais un peu boîte noire.

-INEMO-M1 : le nouveau composant de ST-microelectronics maintenant disponible pour certains clients (une dizaine d'euros, avec processeur, mais à intégrer physiquement, et plateforme de codage pas évidente)


-PixHawk : le système de pilote automatique open hardware de référence pour les drônes qui sort une version 3DR pour 199 $.

Peak : une aile monopeau avec depower

La marque Flysurfer vient de sortir une nouvelle aile monopeau qui a l'avantage d'avoir un véritable depower.
Par rapport à une aile type parapente (NASA wing), c'est plus léger, plus compact.
L'aile est également conçue avec la barre, et même un sac à dos/baudrier.

Apparemment super pour tirer des skis ou un skate partout dans le monde !

En voici une super présentation en français, 



PEAK - Main Features #2 from FLYSURFER Kiteboarding on Vimeo.

Un GPS RTK Open Source?

 J'ai trouvé le projet piksi sur kickstarter. Ce projet a levé 166 000 $ (14 000 $ attendus!).
Le GPS RTK open source coûterait environ 900 $, soit 10 fois moins environ.
Pour rappel le GPS RTK permet d'atteindre une précision centimétrique.

Open-Atelier

Aujourd'hui c'est openAtelier.
J'ai discuté avec Jean-Pierre, (maître cerf-volant !) qui réfléchit aussi au projet de pilote de cerf-volant.
Il a imaginé un système avec un cerf-volant à un fil. Il se met à tourner lorsqu'on relache le fil (du bon ou du mauvais côté), et repart droit lorsqu'on retend le fil. Après discussion ça ne semble vraiment pas plus simple à piloter...

Cerf-volant dans la nuit

J'avais déjà posté la vidéo du cerf-volant équipé de LED scintillantes blanche et rouge

J'ai commencé le traitement vidéo permettant de retrouver les deux leds, ce qui permettra de retrouver la position et l'orientation du cerf-volant.

Les cercles fins correspondent aux positions trouvées par l'algorithme

Le code est ici

Scipy 2013

Scipy est une bibliothèque scientifique très célèbre pour python.
La conférence Scipy 2013 s'intéressait à Scipy mais plus généralement à l'utilisation de python pour les scientifiques, et par exemple à Sympy qui permet de faire du calcul symbolique avec python.

Parmi les nombreuses présentations en ligne, c'est celle de Pydy qui m'intéressait. Pydy est une bibliothèque pour la simulation de système dynamique, par exemple pour faire du contrôle (l'exemple correspondait à un pendule inversé à N degrés de liberté). Une alternative serait arboris, dont j'aime l'API mais qui n'est plus mis à jour, et n'a pas la même ambition.

Le site de Pydy est actuellement buggé, et l'installation pas encore évidente, mais j'ai réussi à le faire fonctionner à partir des sources.

Mon objectif est pour l'instant de faire un simple modèle de pendule, avant de coder les équations du vol d'un cerf-volant.

Oscilloscope

Je n'étais pas satisfait des oscilloscopes (pour visualisation des pins sur l'arduino) que j'avais trouvés sur le net :

-utilisation de langages que je ne maîtrise pas
-fréquence de rafraichissement visible.

J'ai donc modifié quelques projets pour avoir ma propre version d'un oscilloscope (toujours dans le navigateur avec HTML5).

J'utilise la bibliothèque javascript flotr2.js, développée dans le secteur financier.

J'ai d'abord essayé d'utiliser firmata (avec pyfirmata) pour sonder les données, mais c'était trop lent (3 données par secondes environ).
Finalement j'envoie les données de l'arduino en continue (toutes les 20ms environ) et vient les lire encore plus vite avec le PC (serveur tornado).
Les données sont ensuite envoyées vers le navigateur via websocket + JSON.
Les données une fois récupérées sont mises en forme par flotr2.

J'ai eu quelques problèmes de résolution, qui m'ont conduit à finalement envoyer les données sous forme d'entier (0 à 1023) puis à normaliser dans le navigateur pour avoir un résultat entre 0 et 1.

Le code source est là. Pour moi l'objectif est d'intégrer le tout dans l'interface de contrôle du cerf-volant.

Amélioration à prévoir :
- ajout de légende (fait)
- pouvoir stopper le défilement
- pouvoir choisir les voies à afficher
- pouvoir choisir la durée (30s, 5min, 30min, etc...)
- incorporer avec slider pour contrôle pwm

Kite line mount

Je réfléchis depuis quelques temps à un système léger pour monter mon téléphone sur les lignes avants.

J'avais pour l'instant réalisé un premier prototype avec des morceaux de bois, des colsons et un sandow (le téléphone était dans une house étanche).

Il y avait trop de bois (trop lourd, trop d'inertie).
Les colsons étaient fermés autour de la ligne et ce n'était pas pratique pour les enlever/remettre.
Le sandow ne tenait pas.

Cahier des charges
-léger
-équilibré
-peu d'inertie (pour bien suivre les mouvements des lignes
-accès à l'écran du téléphone et aux touches sur les côtés
-champ de vision de la caméra arrière libre
-démontable
-fixe ou glissant sur les lignes au choix
-s'adapte au niveau de la jonction de deux lignes en V, ou sur une ligne seule


J'avais trouvé des modèles commerciaux, mais je réfléchissais à imprimer un support avec une imprimante 3D. J'ai trouvé ce modèle http://www.thingiverse.com/thing:27109 pour une gopro.

J'ai fait un prototype (en carton!) afin de voir comment adapter ceci à un téléphone dans une housse souple (à noter le petit trou pour la caméra)

J'hésite à utiliser des pattes comme sur le système pour la gopro, ou à utiliser de simples baguettes de reliure. De même je pense que la plus grande partie du support peut se faire avec une plaque à découper, sur laquelle seraient vissés des embouts plastiques.

Edit 25/11/2013 : nous avons réfléchis à supprimer au maximum la structure avec Jean-Pierre. Cela pourrait donner quelque chose comme ça :

Le système ne tient plus qu'avec des fils et des pinces (trombonnes ici!)

Pour rappel, le premier prototype en bois (les fils ne sont pas utilisés)

Correction bug magnétomètre

J'ai finalement trouvé le problème avec le magnétomètre. L'erreur ne venait ni de l'algorithme utilisé, ni de son implémentation, ni même de la qualité intrinsèque du magnétomètre.

Le problème semble être une erreur de signe dans les données reçues depuis le téléphone mobile. Le signe sur l'axe Y était inversé (les conventions sur les autres axes étaient les mêmes pour accéléromètre et magnétomètre sauf pour un des axes).

J'ai trouvé le bug grâce au développement d'un outil de visualisation de l'attitude du téléphone dans le navigateur (copie d'écran ou vidéo à venir)
Le code source est là

Détermination de l'attitude à partir de 2 vecteurs d'observation

Actuellement, pour estimer l'attitude du téléphone, j'utilise le magnétomètre et l'accéléromètre (ce qui suppose peu de mouvement du téléphone). L'algorithme utilisé n'utilise que les directions, pas les amplitudes.

Un autre algorithme utilise les amplitudes. Il demande donc de connaître a priori le champ magnétique (amplitude et inclinaison avec la verticale), mais doit en échange permettre une plus grande robustesse aux accélérations.

En voici une implémentation en python que j'ai testé, mais cela ne résoud toujours pas mes problèmes d'irrégularité des mesures:

https://github.com/muzhig/ESOQ2

Calibration magnétomètre

J'utilise le magnétomètre du téléphone portable.
Le cap évolue bien si le téléphone est debout ou couché, mais il peut avoir un biais et ce biais n'est pas le même lorsque le téléphone est couché ou debout.
Je pense que cela est dû à des problèmes d'offset.

Ces erreurs systématiques doivent pouvoir être corrigées par une calibration.
Ces erreurs sont décrites dans http://www.freescale.com/files/sensors/doc/app_note/AN4246.pdf. Les mesures se trouvent sur une ellipsoide décentrée au lieu d'une sphère. Il faut identifier cette ellipsoide pour pouvoir corriger. Un algorithme permettant d'identifier seulement le centre de l'ellipsoid est proposé dans ce document.

Un post sur le forum diydrones http://diydrones.com/forum/topics/magnetometer-soft-and-hard-iron-calibration s'intéresse également à la correction des mesures.

Le post http://www.varesano.net/blog/fabio/ellipsoid-sphere-optimization-using-numpy-and-linalg présente un algo en python mais qui ne traite pas le cas générique.

J'ai récupéré le fichier de test http://www.varesano.net/files/acc.txt et l'ai testé avec le code donné dans http://davidegironi.blogspot.it/2013/01/magnetometer-calibration-helper-01-for.html#.UnfKgHjSWRY. Le code est en matlab mais fonctionne en grande partie avec octave.

Le code complet que j'ai utilisé est ici

Pour l'acquisition des données, j'ai utilisé le script https://github.com/baptistelabat/robokite/blob/master/ObjectTracking/mobileState.py que j'ai légèremment adapté pour créer un fichier de sauvegarde.

Voici les résultats obtenus pour l'identification de l'ellipsoide
Ellipsoid center     :
                   0.177 -0.107 0.566
Ellipsoid radii      :
                   46.6 45.6 43.3
Ellipsoid evecs      :
                   -0.816442 0.42536 -0.390503
                   0.319485 0.896097 0.308123
                   -0.480991 -0.126805 0.867507
Ellpisoid comp evecs :
                   0.948847 0.0100939 -0.0268862
                   0.0100939 0.948304 -0.00195987
                   -0.0268862 -0.00195987 0.984806

Et voici une image des données initiales (rouges) et corrigées (bleues)

Je trouve malheureusement que la différence n'est pas significative... A creuser.