La boussole du smartphone est certainement couplée avec l'accéléromètre. A mon humble avis.

Je dirais plutôt que c'est couplé au gyroscope ;=)

En entrée, tu as la donnée de la boussole et la donnée d'un gyroscope (axe z uniquement, ça suffit si tu as un robot qui se déplace sur le sol). Tu utilises un algo qui fusionne ses donnée et te sort l'orientation du robot par rapport aux pôles magnétiques terrestres.

Tu peux avoir un truc super précis avec ça.

Si tu ne peux pas ajouter de gyroscope, tu es alors obligé de faire une estimation de l'orientation avec seulement les données du magnétomètre. En faisant une moyenne ou en choisissant une valeur médiane parmi X valeurs consécutives, tu peux gagner en précision, mais ça restera pas super je pense...

D'ailleurs mon cher Black Templar j'ai pensé à toi, si jamais un jour tu souhaites publier une toute petite partie de tes travaux dans cette rubrique, n'hésites pas à demander un compte auteur !! Je sais, je sais, tu le fais déjà sur ton site mais on en prendra soin aussi ici... T'auras ton petit sous-onglet rien qu'à toi...

Haha, j'y penserai.

Rappelle le moi vers le mois d'octobre. J'aurai fini ma thèse (sinon je me pend je pense) et aurait donc plus de temps pour ces choses là.

Je pourrai surement faire quelques pages pour présenter le cadre de mes travaux de recherche sans trop rentrer dans les détails techniques (parce que parler d'homomorphisme de graphes, de complexité algorithmique ou de modèle d'interactions distribué, ça risque d'être soulant ^^).

Une sorte de prise de recul sur ce que j'ai fait durant ma thèse, du genre : "Problèmes et enjeux de l'Internet des Objets" ou alors "La ville du futur : verrous technologiques et enjeux sociétaux".

Bonjour à tous,

J'ouvre un topic dédié au montage et au test de l'imprimante 3D de type Prusa i3 (design libre) qui sera proposée prochainement dans la boutique des Makers.

Voici un petit planning prévisionnel du déroulement du test :

EDIT : Bon, je suis complètement à la ramasse côté planning ! :/

Je posterai sur ce topic des nouvelles de l'avancée du test, des photos, ainsi que les livrables.

N'hésitez pas à interagir pour donner des idées à intégrer au test ou pour proposer des améliorations des livrables qui seront posté (si un passage n'est pas assez détaillé par exemple).

Bientôt, quelques photos du colis

WT ? Peut être voulais tu dire WP ? en fait je ne suis pas certain de comprendre...

Super ! Bien joué

 

C'est justement ca le problème, si au cours d'un tournant la voiture frôle un mur en face, elle devrait continuer à tourner (encore plus sérré même) or ce qui se passe la c'est que comme aucune valeur n'est grande, la règle deux à un poids très faible et c'est donc la règle 3 qui prend le dessus et dit de centrer les roues.

 

Voici un exemple (on voit ici que la voiture devrait sérrer à droite, pourtant elle va continuer tout droit):

 

13120367_10205040611449947_805905146_o.png

Dans ton exemple, tu as un obstacle à la fois à droite, à gauche et en face !

Du coup c'est la règle qui dit que tout est proche qui doit prendre le dessus et dans ce cas là, tu tournes du côté droite ou gauche en fonction de la différence de distance entre l'obstacle à droite et celui à gauche ! d'où l'intérêt de bien penser à toutes les règles !

 

Sur ce graph la  ?

 

Présentation sans titre.jpg

 

En fait je crois que je lis et fais mes fonctions d'appartenance à l'envers depuis le début...

Tes données en entrées sont à lire sur l'axe des abscisses et le degré d'appartenance à tel ou tel variable linguistique se lit sur l'axe des ordonnées.

A prioris, le cas de figure ou il y a des obstacles devant à droit et à gauche ne se produira pas dans le circuit donné (du moins je l'espère ahah)

Et oui, l'indice est le même pour des obstacle à différente distance, c'est justement l’intérêt. C'est justement pour résoudre le problème dont je parlais dans un post précédent : 

 

 

J'ai trouvé la source de mon problème majeur, en fait quand la voiture est dans un virage serré, l'avant de la voiture et parfois très proche du mur.

De ce fait, les mesures droite et gauche sont à ce moment la toute les deux très petite ce qui pose un problème.

 

En effet, la règle numéro deux dit que si une mesure est plus grande que l'autre, alors on tourne les roues dans le sens de la plus grande mesure, mais si les deux mesures sont (bien que différentes) petite, alors la règle numéro 3 qui dit que si les deux mesures sont petites alors on centre les roue est vraie aussi et il y a donc un conflit entre les deux règles.

Le résultat de ce conflit est une orientation des roues pas assez forte qui provoque la collision de la voiture.

Il n'y a pas de conflit entre les règles car la règle 2 dit que si l'une des deux mesures est petite et l'autre grande alors ...

Dans ton cas les 2 sont petites donc cette règle règle aura un poids très petit lors de la fusion par l'opérateur OU !

Et pour que la voiture ne tourne pas pareil quand les obstacles sont respectivement à 1cm et 2cm et 1m et 2m, il suffit d'include la distance_avant dans la règle. Ainsi, si il détecte un indice -0.5 a 70cm d'un mur, le tournant sera moins sérré que si il le détecte à 10cm du mur.

 

De plus, le fait d'utiliser juste un indice au lieu des deux distances va simplifier les règles non ?

Tu peux essayer, mais je ne vois pas l'intérêt perso

Comment tu à calculer ca ?

J'ai lu les valeurs en ordonnée sur ton graphique pour une abscisse à 0.3

Aah, je croyais que ce n'étais pas obligatoire, c'est peut être ca qui fous le bordel alors

Ce n'est pas obligatoire, mais dans ce cas, il faut bien savoir ce que l'on fait car ça peut entrainer des comportements étranges.

Sinon vous pensez que c'est une bonne idée ou pas du tout ce que je suis en train de faire ?

Non

Avec ça, tu te compliques la vie pour rien et en plus, tu auras une entrée diff qui n'est pas évident à interpréter... Que fais-tu si tu as des obstacles à gauche et à droite et devant ?

De plus ton indice sera le même si, imaginons, les obstacles à droite et à gauches sont respectivement à 1 et 2 cm de toi ou à 1 et 2 m !

 

Pour la fonction d'appartenance à l'orientation de cet indice, j'ai fais le graph suivant :

 

Présentation sans titre.jpg

 

Mais la je bloque totalement du le calcule des appartenance avec ce graph :/ Comment est ce que je calcule par exemple les appartenance pour un indice de 0.3 ?

Pour un indice de 0.3, tu as une appartenance à 15% petit, 50% grand et 50% moyen.

Pour tout x, essaye que la somme de tes trois variables linguistiques fasse 100%

Tout à la fin de cet article, tu as un exemple de ce qu'il se passe lorsque la somme des fonctions n'est pas égale à 1.

J'ai un ami qui l'a acheté en kit.

Il en est ravi !

En fait je pense que le problème viens de la variable linguistique "centré"  de l'orientation. En effet, comme elle est définie à zéro, sont poid ne pèse pas dans l'équation finale ce qui fait que si on à par exemple 30% de droite 30% de centré et 0% de gauche, au lieu d'avoir au final 15% de droite on va avoir encore 30% de droite et c'est pour ca que ma voiture braque trop fort :/

J'ai oublié de répondre à ça.

Bien sûr que si ça pèse dans l'équation finale, même si sa valeur est 0 !

Si tu as un 0/20 en math, ça va influer ta moyenne !

Lors de la défuzification tu fais un calcul de barycentre ou de centre de gravité, tout ça, ce sont des moyennes

 

Mes règles sont pour l'instant: 

 

SI distance_gauche = grande ET distance_droite = petite ET distance_avant = près ALORS orientation = gauche

SI distance_gauche = petite ET distance_droite = grande ET distance_avant = près ALORS orientation = droite

SI distance_gauche = petite ET distance_droite = petite ET distance_avant = loin ALORS orientation = centrée

 

Je n'arrive pas à voir quoi rajouter comme règle :/

SI distance_gauche = grande ET distance_droite = petite ET distance_avant = loin ALORS ???

SI distance_gauche = grande ET distance_droite = grande ET distance_avant = près ALORS ???

SI distance_gauche = grande ET distance_droite = grande ET distance_avant = loin ALORS ???

SI distance_gauche = petite ET distance_droite = grande ET distance_avant = loin ALORS ???

SI distance_gauche = petite ET distance_droite = petite ET distance_avant = près ALORS ???

De plus la conclusion, c'est toujours l'orientation, tu n'avais pas dit que tu voulais aussi jouer sur la vitesse ? Dans ces cas là, pour chaque règle, tu dois déterminer l'orientation et la vitesse.

Le reste est correct.

Salut Newbie !

Tout d'abord, tu as combien de données en entrée et de variable linguistiques pour ces données ? Et combien de variable de sortie ?

En entrée, tu as distance_droite, distance_gauche et distance_centre ? Les variables linguistiques sont petit et grand ?

Dans ce cas, tu as 2^3 règles à définir. Sinon tu oublies des cas particulier.

Deuxièmement, tu ne peux pas prendre des variables de sorties comme variable d'entrée. Ta règle "SI orientation est xxx ALORS xxx" n'est pas bonne.

Tu dois tout exprimer en fonction de variable d'entrée "Si capteur_gauche = xxx ET capteur_droit = xxx ET capteur_centre = xxx ALORS orientation = xxx ET vitesse = xxx"

Troisièmement, dis-nous ce que tu as choisi comme opérateur ET / OU ainsi que la méthode de défuzification.

C'est aussi le choix de ces opérateurs qui conditionnent la qualité du résultat en sortie.

De mes souvenirs de cours, l'intérêt de la logique floue était de faire des raisonnements symboliques en prenant en compte l'incertitude qu'il y a sur les notions (genre petit, grand, etc.). En relisant rapidement un cours, je vois que ça n'était pas exact, puisque selon la méthode de défuzzification, on peut avoir une valeur qui n'appartient pas à une catégorie.
Après, j'ai un biais négatif envers cette approche : elle essaie de définir des catégories symboliques artificielles (données par l'humain) pour contrôler un robot à un niveau subsymbolique.
Alors que ça peut être fait élégamment sans passer par cette notion symbolique, avec une approche purement numérique (Braitenberg en version simple, réseaux de neurones en version plus compliquée avec apprentissage des poids de connexion). Mais là, j'ai un biais positif.

Moi aussi je préfère les méthodes du type RdN & co.

Seulement dans ce type de problème, un RdN n'est pas forcement mieux qu'un système flou pour la simple est bonne raison que dans le premier cas tu n'arrives pas à interpréter le poids des neurones, alors que dans un système flou, tu as des règles, des variables linguistiques et des opérateurs que tu peux interpréter.

Si tu modélises le problème de Newbie par un RdN de 3 neurones d'entrée, 8 neurones cachés et 2 de sorties, en linéarisant le RdN tu te rends compte qu'on arrive à peu près au mêmes équations qu'avec un système flou. Sauf qu'avec un système flou, tout est explicite alors qu'avec un RdN, tout est implicite. Pour une autre structure de RdN, ça devient très difficilement interprétable (voir impossible à interpréter, ça marche, c'est tout, on ne sait pas pourquoi).

 

L'autre intérêt, c'est qu'il est possible de calculer des informations dérivées des mesures de distance : en faisant une différence temporelle entre deux mesures, on peut obtenir une estimation de la vitesse à laquelle l'obstacle se rapproche (donc de la vitesse du véhicule si l'obstacle est fixe) : hors, s'il se rapproche doucement, il n'y a pas besoin de tourner beaucoup du côté le plus dégagé ; à l'inverse, s'il se rapproche vite, tu peux avoir envie de braquer fort pour prendre la courbe correctement.

Tu n'as pas besoin de coder ça dans un système flou car si tes règles sont bonnes et tes opérateurs assez fins, le système adaptera tes vitesses automatiquement en fonction de la distance de l'objet. Du coup, l'objet se rapprochera toujours avec la même accélération.

J'ai déjà implémenté le déplacement de robots à l'aide d'un système flou et j'ai été étonné par la fluidité avec laquelle ils se déplacent.

Couplé à un algo d'attracteur par champ de potentiel ou par bande élastique, ça te fait un algo de planification de trajectoire basique mais redoutablement efficace en milieu convexe qui t'évite les obstacles sans connaitre l'environnement à l'avance et qui peut largement se calculer en temps réel.

Si tu as un peu de temps pour tester cet exemple tu te rendras compte de ce que je dis par toi même : http://www.ferdinandpiette.com/blog/2011/08/exemple-de-systeme-flou-un-planificateur-de-trajectoire/

La vitesse de ton robot sera juste limité par la vision de celui-ci (distance max à laquelle tu peux détecter un objet avec tes capteurs) ainsi que par le nombre de fois que tu réexécute l'algo par seconde.

Après, ça ne prend pas en compte la cinématique du robot, c'est à dire qu'on est pas garanti que le robot puisse effectuer le mouvement demandé (on ne prend pas en compte l'encombrement du robot, sa capacité maximale d'accélération et autre). Mais de toute façon, un RdN non plus.

Pour prendre en compte ces critères, il faut un vrai algo de plannif comme DKP par exemple : http://www.ferdinandpiette.com/blog/2011/05/algorithmes-de-planification-de-trajectoires-bref-etat-de-lart/

P.S. : Je ne dis pas que les RdN ou autre méthode purement numérique sont moins efficaces, j'essaye juste de te convaincre qu'un système flou peut l'être tout autant avec l'avantage d'avoir un comportement intelligible par n'importe quel humain

De mon point de vue, la logique floue n'est pas adaptée : tu n'as pas besoin de raisonner sur des symboles (ce que tu appelles variables lnguistiques), tu as besoin de déterminer des commandes (angle de ta direction, vitesse de ta propulsion) qui sont continues.

Je ne vois pas en quoi la logique flou est inadaptée.

Un système flou sert bien à déterminer des commandes en mode continue.

Le moyen d'y arriver, c'est de prendre en compte des règles d'inférences exprimées en langage naturelle car on ne veut pas s’embêter à modéliser le système.

Sinon, ça à l'air sympa le Braitenberg vehicle, je ne connaissais pas

Ok, je comprend mieux.

Du coup, la fonction d'appartenance à l'orientation aura 3 variables linguistiques : gauche, centré, droite.

Et si tu veux modéliser ça part du tout ou rien comme je l'ai fait dans mon exemple, gauche sera un dirac en -1, milieu, un dirac en 0 et droit, un dirac en 1 (et non en 0, 0.5 et 1).

J'aurais donc pour chaque capteur deux variables linguistique distance_petite et distance_grande et pour l'orientation des roues une variables linguistique "orientation" (Cette valeur me donnera la valeur de l'orientation, il me suffira de déterminer si elle doit être positive ou négative en fonction du sens)

Que signifie la variable linguistique "orientation" ? Pourquoi ne pas avoir directement la vitesse des roues (gauche et droite) ?

 

Autres questions: Quel est l’intérêt de mettre plus de variables linguistiques pour un problème sachant que le résultat sera toujours un pourcentage ? Comment est ce qu'on "code", les fonctions d'appartenance des variables linguistiques ?

Le fait de mettre plus de variables linguistiques en entrée te permettra d'avoir plus de règles et donc d'affiner le calcul des sorties (même si c'est toujours une vitesse entre 0 et 1, la manière de calculer cette vitesse sera différente et (on peut l'espérer), plus adaptée). Le tout, c'est de savoir si les variables d'entrées ont une réelle influence sur la sortie ou non.

C'est un peu comme l'age du capitaine : c'est une info que tu as mais qui ne te sert pas à résoudre le problème. Si tu la prend en compte, tu complique le système sans rien changer au résultat

Mais je pense que sans passer par un réseau de neurone ni faire d'apprentissage tu peux avoir un robot très rapide avec juste de la logique flou.

Oui !!!!

De toute façon, logique floue ou réseau de neurone, c'est plus ou moins pareil ! Tu peux construire un réseau de neurone à partir des règles d'inférences et des opérateurs de ton système floue et inversement.

La seule différence, c'est que dans un système floue, tu as des critères fixe et des règles d'inférences souvent choisies selon une expertise humaine.

Alors qu'un réseau de neurone (s'il a un apprentissage) sélectionne ses propres critères et règles, bien que du coup, tout ça ne soit pas très intelligible pour un humain.

On pourrait même imaginer un système floue qui (une fois les critères choisi par un humain) apprend lui-même les règles à appliquer !!

En tout cas avec les données que tu as et les sorties sur lesquels tu peux agir, pour moi ça sent à plein nez le cas d'école pour usage de la logique floue  =) au " fuzzy logic "  ( Invocation de Black Templar ? ) 

Bon après il n'y a jamais "une seule façon de faire "  ,  on peut invoquer R1D1 et parler de la mise en place d'un petit réseau de neurone =) On peut même parler d'algorithme génétique et d'apprentissage  https://www.youtube....h?v=5lJuEW-5vr8  ( de nouveau invocation de Black Templar avec ses poissons =) )

Aaaa, tu sais comment me parler ! Algo G, réseau de neurones, logique floue, il ne manquait plus que le mot clef "Filtre de Kalman" et ça aurait été parfait

De ce que je me rappelle de la logique floue c'est un système de prise de décision basés sur des probabilités. Ca donnerais un truc comme ca dans mon cas SI capteur_droit SUPERIEUR A capteur_gauche ET QUE capteur_avant INFERIEUR A un_seuil ALORS on se trouve surement dans un virage vers la droite. C'est ca ?

Pas exactement non, la logique floue, ce n'est pas basé sur les proba mais sur l'appartenance à des ensembles.

Contrairement à la logique classique où tu ne peux appartenir qu'à un seul ensemble à la fois (soit tu es grand, soit tu es petit), en logique floue, tu peux appartenir en même temps à plusieurs ensembles avec un certain degré d'appartenance (tu peux être à la fois grand à 67% et petit à 33% (tu appartiens à 67% à l'ensemble grand et à 33% à l'ensemble petit).

C'est sur la base de cette logique floue que tu peux construire un système flou pour résoudre des problèmes pour lesquels tu peux avoir une expertise humaine forte, mais pas de formalisation mathématiques précise !

Tu exprimes tout une série de règles à adopter en langage naturel (SI obstacle_droite loin ET obstacle_gauche proche ALORS vitesse_droite petite ET vitesse_gauche grande)

Le système floue va automatiquement fusionner toutes tes règles et te sortir un résultat pour la vitesse de tes roues.

Ce qui fait que tout ce que tu as à faire, c'est d'exprimer tes règles (que tu peux rajouter au fur et à mesure que ton expertise sur le problème augmente).

Je te laisse lire la série d'articles que j'ai écrit à ce sujet : http://www.ferdinandpiette.com/blog/les-dossiers/dossier-la-logique-floue/

Et en particulier cet exemple de planificateur de trajectoire : http://www.ferdinandpiette.com/blog/2011/08/exemple-de-systeme-flou-un-planificateur-de-trajectoire/

J'ai regardé aussi le réseau de neurone, ça à l'aire cool, mais de ce que j'ai compris, pour que ca marche, il faut naviguer plusieurs fois dans le circuit pour l'analyser et on aura le droit qu'à un essais le jour de la présentation (sur un circuit inconnu qui plus est) :/

Tu peux faire un réseau de neurone générique qui va déterminer la vitesse de tes roues en fonction des données des capteurs.

Tu apprends ton réseau de neurones (soit par un algo génétique, soit par une autre methode d'apprentissage plus classique) sur différents circuits, et une fois ton réseau entrainé, il est sensé pouvoir se déplacer sur n'importe quel circuit !

Dans la vidéo que Mike à posté, mes poissons apprennent à se déplacer vers un plancton. Une fois entrainé, un poisson peut trouver son chemin vers le plancton quelque-soit sa position.

Je suis en première années à Epitech, et cette école est justement connu pour ne pas guider les étudiants pour les pousser à chercher par eux même

C'est génial comme façon de faire, mais ça implique que l'étudiant soit assez mature pour creuser un sujet par soi-même !

Sur ce genre de projet, je me serai surement amusé à trouver la meilleure solution en utilisant le moins d'information possible (par exemple, juste 3 données sur les 32 disponibles : la mesure à -30°, celle à 0 et celle à 30°). Je suis sur que tu n'as pas besoin de plus pour avoir le robot le plus rapide et ça aurait montré aux profs que ce n'est pas parce que l'on a plein de données qu'il est pertinent de toutes les exploiter : peu de données bien choisies et bien traités peuvent apporter un bien meilleur résultat que plein de données en vrac que l'on ne sait pas exploiter

File nous ton schéma électronique si tu veux que l'on puisse t'aider.

J'ai vu un article sur la retropropagation, mais je n'ai pas compris grand chose ...

Regarde l'article de wikipédia mais en Anglais, il est mieux fait que celui en français et tu as le code de l'algo (en pseudo code)

https://en.wikipedia...Backpropagation

Tu as vu cette vidéo ?

C'est un projet réalisé par des étudiants de mon école

http://www.franceinfo.fr/emission/nouveau-monde/2015-2016/une-main-robotisee-pour-personnes-handicapees-20-04-2016-07-00

Pas mal les sous-menus, toutefois si cela est possible, j'aurais laissé le titre du menu, c'est-à-dire "Forum" visible même quand tu es sur un des sous-menus, mais ce n'est qu'un détail.

En effet, moi aussi. Je verrai où ça en est mercredi et si ce n'est pas fini, je continuerai à bosser là dessus

Sinon, sur la page principale du forum, je trouve le titre (Robot Maker pour les passionnés de robotique) trop collé à la première catégorie de forum.

Je propose :

.ipsType_pagetitle, .ipsType_subtitle => margin-bottom: 1em;

Oops, autant pour moi, il faut virer cette modification car ça influe sur les autres pages

Il faut la remplacer plutôt par celle là qui aura le même effet sans se répercuter les autres pages :
#board_index => margin-top: 1em;

Et je modifierai aussi

.ipsType_pagedesc => line-height: 1;

Pour que la description d'un forum prenne moins de place (sur la page listant les topics du forum en question)

Sinon, sur la page principale du forum, je trouve le titre (Robot Maker pour les passionnés de robotique) trop collé à la première catégorie de forum.

Je propose :

.ipsType_pagetitle, .ipsType_subtitle => margin-bottom: 1em;

Un premier jet pour avoir une idée :

- Il faut rajouter une transition pour ne pas que ça s'affiche/cache violemment.

- Il faut réussir à afficher le sous-menu par dessus le reste (là il est caché par le premier sous forum...)

Je ne suis pas là jusque mercredi prochain, donc si tu veux t'amuser un peu, voici le code

Au niveau du HTML, dans un élément menu (ici l'élément Forum) :

<li>
  <a title="Forum robotique" href="http://www.robot-maker.com/forum/">Forum</a>
  <ul class="dropdown"><li><a href="#">Test 1</a></li><li><a href="#">Test 2</a></li></ul>
</li>

Le CSS associé (je sais, les !important, ça fait moche) :

.dropdown {
    display: block !important;
    margin: 0 !important;
    width: 100% !important;
    position: absolute!important;
    left: 0 !important;
    visibility: hidden;
}
.dropdown li {
    border-bottom: solid 2px #ddd !important;
    border-right: solid 2px #ddd !important;
    transform: none !important;
}
#fun1 ul li:hover > .dropdown {
    visibility: visible;
}

 

Arf c'est vendu...

 

Par contre pendant que je t'ai sous le coude, est ce que tu te sentirai de me faire un joli dropdown effect propre si je rajoute des sous menu dans les onglets sous forme ul li à l'intérieur des li existants.

 

A titre d'exemple sous l'onglet forum j'aimerai y insérer des sous menu de type nouveau contenu ou encore membres...

Pourquoi pas, je peux toujours essayer.

Je ne suis pas un pro du CSS3, mais je dois pouvoir faire ça.

File moi un exemple HTML avec le CSS associé et je regarde ce que je peux faire

Plusieurs centaines de watts !! Oh Punaise !!!

 

Et l'utilisation final c'est?

Pas de panique, j'y vais progressivement !

Je commence par 10W pour me familiariser avec la forte puissance et ses contraintes et puis j'augmenterai au fur et à mesure

Le projet, c'est de faire mumuse avec des panneaux solaires et des batteries pour alimenter certains équipements chez moi.

Du coup, j'ai plusieurs petits projet :

• Un contrôleur de charge pour les batteries (à base d'un régulateur Buck) entre les panneaux et les batterie.
• Un régulateur inverseur en pure sinus 12V DC => 220V AC qui peut supporter plusieurs millier de watts (pareil, je commence petit avec 10W histoire de me familiariser petit à petit avec les contraintes magnétiques à forte puissance)

Pour commencer, je reçois un panneau monocristallin de 10W avec une batterie de moto 7Ah.

Ça me permettra déjà de voir le rendement de ce genre de bestiole.

Ensuite, j'ai déjà repéré des panneau 100W pour charger des batteries de voitures (80-100Ah)