Bienvenu a toi  !

Le passage a la derniere version de chrome ne semble pas resoudre le probleme (Version 56.0.2924.76 (64-bit)).
 

Je vais me mettre a Edge au boulot , par ce que l'entree 'dernier contenu' du menu est indispendable !

 

Pour moi sous Windows Chrome de mon boulot je n'ai plus le menu du haut du tout. (Version 55.0.2883.87 m (64-bit))

Il y a juste un espace 'gris' au dessus de la barre noir avec mon nom de compte a droite.

Et cet espace gris n'est pas conserve quand je scrolle down.

Cette vesion de chrome est peu etre un peu vielle, on est limite dans les possibilte d'update.

Avec Edge sur le meme ordinateur ca fonctionne comme attendu.

Tu es sur Oliver ? J'ai pas de soucis, même en me déconnectant de mon compte youtube. Elle est bien publique.

Les autres, la vidéo marche toujours pour vous ?

Voilà une petite vidéo des premiers tours de roues officiels !

Ca plante plus !!!

Merci mike pour m'avoir mis sur la piste. En fait c'était pas un pic de courant, mais un trou de courant. Les piles que j'utiilsais ne resistait pas à l'appel de courant lors de changement brutale de direction des moteurs et la tension chutait trop bas, ce qui faisait rebooter la board.

En mettant d'autres piles ca se passe beaucoup mieux.

J'en suis à la génération 3, et le meilleur score est 434ms , c'est le temps de la balancement moyen des 6 tentatives médianes sur 10.
On est encore loin d'un long balancement, mais ça progresse.

C'est une bonne question, et peut-etre la bonne réponse.

En effet j'ai 'massacré' dans tous les sens le robot avec le programme en 'idle' et j'ai pas réussi à le faire planter. En l'activant juste après boom ca à planté.

Je me disais que c'était peut-etre un bug de programme, mais jusque là les "segmentation fault" avait plutôt l'air de planté la board que de la rebooter.

J'avais pas pensé au pic de courant, c'est possible, même si j'ai que de petit moteur et qu'il ne sont pas bloqué, mais peut-etre au moment d'inverser le sens. Je vais regarder cette piste, et aussi le programme lui -même.

En tout cas c'est pas un reset simple du à des chocs. Je préfère ça, ça me parait plus facile a débugguer maintenant.

Bon, quelques petites nouvelles, elles ne sont malheureusement pas toute bonne.

La gestion des Configurations et des Generations est faite, l'algorithme de procréation est écrit.

Pour tester ce que ça donne ,j'ai fait une fausse fonction de 'scoring' d'une configuration basée sur ses paramètres, et après une trentaine de génération ça converge, le meilleur configuration de chaque génération à un score de plus en plus élévé qui s'approche doucement du score maximum.

Voici les choix de paramétrage de l'algorithme génétique que j'ai choisi:

Une génération consiste en 10 configurations.

J'évalue le score de chaque génération, puis je trie les configurations du plus grand score au plus petit score.

Je garde les 3 meilleurs configurations (1,2,3)

Je fais 2 enfants par couples de configuration suivante :  1 avec 1 , 1 avec 2, 1 avec 3. (oui il y a un peu de parthénogénèse

     Pour faire un enfant, je prend pour chaque paramètres au hasard celui du parent 1 ou celui du parent 2 puis je le varie au hasard de +- 10%

J'ai donc 6 enfants.

Pour la dernière entrée, je prends une configuration entièrement au hasard, puis je lui fait faire un enfant avec la conf 1. C'est pour rajouter un peu de sang neuf.

J'ai mes 10 configurations pour la prochaine génération, mais  je vais rajouter un peu de mutation.

Je prends 4 configurations au hasard ( sauf la 1, la meilleur que je ne veux pas toucher), et je 'mute' 2 parametres au hasard.

     J'ai décidé qu'une mutation consistait à modifer un paramètre de +- 50% au hasard.

Voilà ma toute nouvelle génération prète à affronter son environement, et à être scorée.

Mais là je suis tombé sur le 'reality check'. 

En voulant maintenant vraiment faire le scoring de chaque configuration sur le robot lui-même, et voir ce que ça donne en vrai, et bien je viens de voir que la board du robot 'reset' toute seule sur certains chocs.
Et rien à y faire pour l'instant. J'ai changé le connecteur de batterie, j'ai mis un peu de 'mousse' pour amortir. Les chocs ne semblent pas violents, mais ça finit par rebooter au bout d'un certain de nombre de test de balancement.....

J'ai tout ce qu'il faut sur le robot pour sauvegarder l'avancement des générations, mais comme ca plante assez vite, ca va etre laborieux de tester et recharger.

Je ne sais pas si je vais donner suite sur cette version du robot.

Crabeel n'est pas une référence, loin de la

Il est nativement pas très stable, ce qui rend encore plus difficile son contrôle. A la main, si je le met a son point d’équilibre, sans moteurs actif, il tombe en moins d'une seconde. Il va falloir un contrôle réactif sans overshoot.

On va voir ce que la génétique me trouve ! , si elle trouve quelquechose.

Je vous tiens au courant.

Mais je vais vraiment juste suivre l'algorithme que j'ai decrit.

Tout le code de ce robot est la :

https://github.com/Bobox214/Crabeel

( et en parallele le code des autres robots que j'ai commence.)

Oui je fais ca sur le MegaPi de Makeblock, qui est compatible Arduino Mega.

Une petite update de Crabeel.

Il fait ses premiers pas tout seul :

Comparé au précédent j'ai fait les améliorations suivantes :

Matériel :

• Le robot est moins haut
• Le centre de gravité est remonté avec les piles en hauteurs
• Retrait du 'bras', n'apportant pas grand chose
• Utilisant d'un BNO055 comme IMU

Logiciel :

• Localisation grace aux encoders et à l'IMU
• Ajout d'une séquence de retour à la position de départ
• Ajout d'une séquence d'autodémarrage du balancement, avec une accélération suivi d'un arret des moteurs.

Les contrôles ( en bluetooth, avec les retours debug), consiste simplement en trois commandes au choix:

• Démarrage du balancement
• Retour à la position initiale
• STOP. ( ca c'est quand une des deux actions précedentes par en vrille

Les prochaines amélioration prévues sont l'ajout d'un écran LCD (celui du magasin de robot-maker), pour montrer son état. et surtout l'implémentation d'un algorithme de selection génétique pour permettre au robot de trouver tout seul le jeu de paramètre qui lui permet de balancer le plus longtemps en moyenne.

Dans mon cas les paramètres sont au nombre de 6 :

• La valeur d'accélération et le temps d'accélération de la séquence de démarrage
• Les coéfficients P,I et D du contrôleur d'équilibre
• La valeur de l'angle d'équilibre ( ce n'est jamais parfaitement 0)

Pour chaque nouvelle configuration le robot va faire surement 10 tentatives. En retirant les 2 meilleurs, les 2 pires et moyennant les 6 valeurs restantes on obtient le 'score' de cette configuration.

Ensuite le principe c'est de prendre 10 configurations aléatoires, consistant en notre génération 0.

On évalue le score de chaque configurations.

On crée la génération 1, par exemple on garde les 4 meilleurs et on les combines 2 à 2 pour créer 6 enfants. On ajoute un peu de mutation aléatoire.

Et on est repartie on evalue la génération 1 et on crée la génération 2.

Bien évidemment la difficulté pour obtenir quelque chose qui s'améliore c'est le dosage entre le nombre de configuration par génération, le choix des reproducteurs, l'algo de reproduction, le pourcentage de mutation et l'algo de mutation.

Autant dire que les chances d'aboutir à un robot en équilibre pendant 20s à chaque fois sont plutôt proche de 0, mais c'est l'aventure qui me motive !

Ce n'est malheureusement pas la suite de l'EV3, étant orienté pour des enfants plus jeune, mais c'est toujours mieux que rien.

Ca formera les prochaines générations !

La plateforme semble plus orientée vers les  entreprises pour cibler des business angels, et pour monter des rounds officiels d'investissement.

Je ne connaissais pas cette plateforme, mais elle m’intéresse beaucoup, ayant la chance de pouvoir y participer.

J'ai donc apporter ma (petite) pierre a l’édifice, ce projet me semble tres pertinent, et avoir de l'avenir.

Bonne chance a vous !

En tout, ca leur aura au moins deja assurer un nouvel abonne ! Je ne connaissais pas la revue, j'ai achete .

Merci pour ces détails supplémentaires, je pense qu'à la fin de ton test les infos utiles seront repris sur la page du shop.

Les trous de fixations sont de quelles tailles ?

Je pense que ca va m'interresser, pour pouvoir afficher l'état de mes robots, sans toujours passer par le log du bluetooth.

Ca ressemble pas mal à une pixy dans l'idée ?

http://www.lextronic.fr/P30095-module-de-reconnaissance-video-pixy.html

Les différences que je vois :

• C'est plus petit
• Les algos sont "programmables" avec un CPU  plus puissant ( et un GPU)
• C'est pour l'instant un peu moins cher.

Vous en voyez d'autres ?

Soit la bienvenue, et j'espère qu'on arrivera à t'aider dans tes besoins.

Et dans l'autre sens j'espère que tu nous partageras quelques photos ou vidéos de tes futures réalisations !

Il a des allures de pokemon !

C'est effectivement plus sympatique et efficace de travailler à plusieurs, mais comme tu le dis, une fois quitté les études il est plus difficile de trouver des associations.

Mais j'ai l'impression qu'avec  la mode des 'maker' et des 'fablab' ça s'améliore.

Et visiblement j'ai l'impression que tu as de la chance une petite recherche 'rennes association maker' donne :

http://www.labfab.fr/

Ca m'a l'air d'être un bon point de départ pour chercher ! 

Oui a priori la pin D0 sert a une connection interne special :

 

 

GPIO16 : Belongs to the RTC module, not the general GPIO module, so behaves differently

Sinon j'ai trouvé ce lien qui propose un possible bout de code pour driver le GPIO16 :

https://github.com/e...uino/issues/123

Pour revenir a Curiosity il doit y avoir le poids de l'ensemble du train roulant à prendre en compte, et peut-etre aussi le dépliage à l'atterrissage.

Mais en regardant l'animation 3D de l'atterissage le dépliage est pas si grand, et peut-etre que des chenilles auraient pu faire pareil :

A mon avis sur un robot a chenilles, si une chenille casse, ton robot ne peux plus bouger ?

Alors que j'ai l'impression qu'avec un 6 roues si une des 'pattes/roues' casse ou deviens inutilisable tu dois pouvoir arriver a  le faire se déplacer quand même.

Dans ce genre d'exploration extra planétaire, la question de qu'est-ce qu'on peut encore faire quand XXX casse me parait assez importante. Quand je vois ce qu'on arrive a faire avec Voyager I (lance en 1977!) , a la limite du système solaire, alors que plus de 80% des systèmes sont HS, ça m'impressionne.

Merci pour toutes ces informations.

Je n'ai pas encore de batterie LiPo, j'avais vu cette histoire de xxC sur ce type de batterie, je pense que c'est  mon principale probleme.

Pour le HAT, il propose la possibilite d'utiliser (entre autre) une alim secteur 5V, 10A. Je ne suis meme pas sur qu'il y ait de regulateur vu que l'alimentation  doit etre entre 5 et 6v max et que l'electronique du hat est alimenté par le raspberry PI lui-meme ( qui est sur une autre source pour moi). Donc je suis moins inquiet sur le régulateur et les pistes. mais je garde ca en tête, surtout si j'alimente avec une batterie 7,4v.

J'ai fait des tests en enlevant le poids des batteries et en alimentant le PI et les servos en externe et ca fonctionne deja mieux, vu qu'il y a moins de poids. Je peux faire des choses en attendant de trouver une meilleur batterie.

Toujours en 5v, mais sur secteur (1.5A) les resultats sont similaires.

Mais en fait je pense que je suis vraiment a la limite, je m'explique :

. J'alimente en 5v pas en 6v , donc j'ai pas le max

. Entre la hanche et le genou de chaque patte il y a  9 cm.

. Entre la hanche et le centre du corps il y a 8 cm

. J'ai pas le poids exactes de la bete, mais c'est plus d'un kilo, je dirais un peu moins de 2kg je pense.

Donc chaque servo de hanche supporte 500g sur 17cm. = 8.5kg/cm.

Est-ce que ce raisonnement est correcte dans son idée ?

Si je mets la bete dans une position un peu moins contraignante, hanche/genou a 70°  ca tient.

Après, pour bouger il faut que ca tienne sur 3 pattes, donc je vais regarder les options pour reduire le poids du corps et la distance hanche/milieu du corps.