Application Powered Up

par **Sifflotte** » Lun Aoû 10, 2020 11:09 pm

Salut,

Avant d'exposer mon problème, je vais expliquer la (ma) logique du programme.
J'ai construit un truc qui s'apparente à un char, que je veux rendre autonome.

Quand je lance l'appli, il avance tout droit avec la Led du Hub bleue.
Quand il détecte un obstacle (à droite en jaune et violet à gauche), le soft choisit de manière aléatoire la direction à prendre et continu son petit chemin.
Dans l'absolu, il est capable de tourner sur un circuit ovale fait de coussins sans faire demi-tour, dans un sens comme dans l'autre.

Mais, trop souvent il bug et ce retrouve planté face à un objet, et il essaye désespèrent d'avancer alors que la seule chose à faire est de reculer et changer de direction (c'est le block tout en haut sans boucle)

Et c'est donc mon soucis, comment puis-je le faire reculer si les deux capteurs s'activent en même temps ?

Le top, se serait que si les capteurs C et D détectent à une distance 1(par ex), pendant 3 secondes, il recule pendant 2 secondes, pivote de manière aléatoire et reprend sa route.

J'ai tenté plein (plein) de truc... Avec les data variable... J'ai rien compris...
Merci à Racing Brick d'ailleurs, grosse source d'information.

Je m'en remet à vous, je continu à chercher de mon côté, pour me sortir de cette impasse.

Tchuss

par **Vinz** » Mar Aoû 11, 2020 1:43 pm

Salut,
Je pense qu'un truc comme ca devrait faire l'affaire, j'ai pas de quoi tester.
Le premier bloc tu vérifies les deux conditions, tu attends 3 secondes, tu re-vérifies les conditions, si c'est toujours le cas AB reculent puis AB dans le sens opposé.
Je pense que dans ton cas la distance sera à ajuster, peut-etre faire un "inférieur ou égale à 2", car si l'un capte 1 et l'autre 2 tu ne vérifieras pas les conditions.

Tiens moi au courant si ca marche

par **Sifflotte** » Mar Aoû 11, 2020 7:51 pm

Salut Vinz.

Comme je le redoutais, il y a conflit avec les autres lignes de code.
La marche arrière est bien respectée, mais elle n'a aucun impact.
Les deux premières lignes prennent le dessus. Même avec l'icône " < ".

Les meilleurs résultats que j'ai eu, c'était en mode capteur de couleurs.
Avec le noir, ça marchotait un peu. Mais bof quand même.

Il faudrait pouvoir rendre esclave la marche arrière, et que les lignes de code principales se mettent en stand by.
Une fois terminé, le soft reprend sur les lignes de code principales et continu sa route.

Merci quand même :hello:

par **Sifflotte** » Mer Aoû 12, 2020 1:20 am

TANA!!!

Maintenant que ça fonctionne, il va falloir peaufiner tout ça.
Je ferai un édit pour l'explication.

:bougeotte:

par **Sifflotte** » Jeu Aoû 13, 2020 11:00 pm

@vinz: je me suis inspiré de ton idée de double contrôle des distances, avec les data variables, ça marche bien.

Cepandant...

C'est incroyablement énervant.
Tout peut bien fonctionner comme le contraire. C'est stable comme application ou c'est moi ?

Le gros, l'énorme, le gigantesque problème est que ce sont les 2 Lignes De Codes (LDC) principales qui prennent le dessus.
Malgré les variables a et b, qui commande le marche arrière et la minuterie, ça bug. Les LDC prennent parfois le dessus, malgré la LDC de marche arrière activé. C'est le miollement du chat qui l'indique, car il est difficile de bien distanguer les couleurs du Hub tellement ça clignote. Quand ça fonctionne, je trouve ça bluffant, on dirait un insecte.
Mais c'est pas fiable.
Ou je m'y prends mal.
Ou les deux.

Je viens de recevoir un 42028 (d'occas,en neuf les prix sont fous) , ou plutôt, j'ai acheté des chenilles avec de quoi construire un 42028.

En espérant revenir ici avec un truc qui tient la route.

par **Vinz** » Ven Aoû 14, 2020 12:43 pm

C'est logique qu'il se comporte comme cela, dans ton scénario, tu as 2 "process" qui bouclent et qui fonctionnement en parallèle, d'où le fait que ca clignote tout le temps.
De plus tu commences par une action, ce qui se traduit par "peu importe dans quelle situation tu es, vas-y fonce mon gars!"
En l'état, le comportement "normal" de ton code est :
Tu avances, si tu es proche d'un obstacle, tu tournes, puis si tu te retrouves à vérifier tes variables a et b alors c'est la ligne qui dit "recule" qui agit, cependant tu ne dis pas que ton autre ligne ne doit pas s’exécuter pendant ta manœuvre, du coup ton robot reçoit plusieurs ordres en même temps puisque les process bouclent.

Pour gérer des actions en parallèle il faut être sûr qu'elles ne peuvent pas s'entrechoquer dans leurs actions ou leurs conditions (ou alors maîtriser tous les cas possible)
Si tu as des choses en commun, ici c'est le cas, il faut lui dire : Si condition 1 alors action 1, sinon, si condition 2 alors action 2, sinon, si condition 3 alors action 3.

Pour avoir quelque chose de fiable il faut résonner comme suit :

La condition "si" se fait avec le bloc "?" avec deux fleches, tu mets un bloc calcul "and" et de chaque coté du "and" tu mets bloc calcul "<" ou ">" avec le capteur de distance

Bon courage pour le codage, mais c'est comme cela qu'on apprend !
Une fois que ca marchera sans bug, ca sera satisfaisant.

Ensuite tu le laisse faire et tu analyse son comportement pour peaufiner au besoin

Tu peux aussi t’amuser à initialiser des variables avant la boucle, par exemple "r=20" pour la rotation du moteur, et ensuite tu mets ta variables "r" à chaque input des moteurs et tu fais une opération multiplication -1 ( "r" x "-1" ) pour la rotation en sens inverse. Ainsi si tu décides que la rotation c'est 30 au lieu de 20, tu n'as qu'un endroit à mettre à jour et ca s'applique dans tout ton code.

par **Sifflotte** » Ven Aoû 14, 2020 7:43 pm

Et bien je te remercie encore une fois.
Dès que les chenilles montées sur mon truc, je me permettrai de pomper ta ligne code.

Pour revenir sur mon programme ci-dessus, ça à fonctionné pourtant.
Le truc faisait bien la marche arrière, reprenais ça route. La direction était hasardeuse, mais j'étais plutôt content.

Je m'en veux de ne pas avoir tiqué sur les boucles. Maintenant que tu le fais remarquer, c'est une évidence.

On se donne rdv au prochain épisode

Une question bonus: est-ce possible qu'il fasse une marche arrière si les moteurs force de trop ?

par **Sifflotte** » Ven Aoû 14, 2020 9:17 pm

Y'a plus qu'à !

par **Sifflotte** » Dim Aoû 16, 2020 4:47 pm

Salut

Voilà où j'en suis.
Comme promis, la ligne de code que tu as proposé.
Ou ce que j'en ai compris.
(j'ai testé avec les variables, mais je les intègrerai une fois le programme validé)

La marche arrière me pose toujours problème. Il n'y a plus de conflit, mais devant un obstacle, il reculait, avançait, reculait ect.
C'est pour ça que je l'ai programmé pour qu'il pivote et puisse repartir.
Mais il le fait toujours dans le même de rotation.
Je souhaite aussi que passé une certaine inclinaison il fasse marche arrière.
Et dès fois il s'arrête... Comprends pas trop.

Je tente des choses.... jamais vraiment concluante.

Vinz, si tu as les réponses, attends que je lance un appel au secours, car j'aimerai bien y arriver tout seul.
Ta précieuse aide ma fait déjà gagné pas mal de temps.

A+

par **Sifflotte** » Dim Aoû 16, 2020 9:38 pm

L'écran de mon téléphone commence à être petit...

Je pensais galèrer un peu plus, mais finalement j'ai pu programmer la marche arrière quand l'inclinaison est trop forte.
En plus, avec le bloc "÷", il s'oriente automatiquement en fonction du relief.
(si je divise la valeur de D et C, on obtient 1 pour le centre, entre 0.1 et 0.9 pour la droite, et entre 1.1 et 1.75 pour la gauche) . Avec le bloc "<", je demande:
si inférieur, à droite, si supérieur à gauche
Principe appliqué pour la marche arrière standard.

Pour résumer :
Si D et C capte un obstacle frontal ou une inclinaison trop forte, il recule pendant une durée prédéfinis , puis, en fonction de l'emplacement de lobstacle, il s'oriente à l'opposé.

Il a tourné une bonne 1/2 h sans gros bug a signaler.
Qu'en va t'il être tout à l'heure ?

EDIT: pas de bug à la reprise. C'est cool. Mais c'est loin d'être parfait et parfois je me perds dans tout ce bazar...
Pour le bloc ÷, je suis de moins en moins sur de mon coup. Faut que je creuse.

par **Vinz** » Lun Aoû 17, 2020 9:10 am

Tu as bien avancé!
L'idée est là, le reste c'est de l'ajustement
Bien joué

par **Sifflotte** » Lun Aoû 17, 2020 6:59 pm

Merci !

Je remercie aussi @grizzly qui m'a bien calmé et ramené à la raison.
M'aventurer dans Python sans aucune connaissance m'aurai conduit à l'asile.vu comment je galère avec de simple block.
J"en rajoute une couche, ouais, encore: vraiment merci Vinz de t'être intéressé à mon cas.
(si tu pouvais rester dans les parages, ce serait cool, si jamais chui en galère...)

Mon idée de base était de d'abord pouvoir programmé quelque chose de simple, pour ensuite rendre autonome mon 4x4.
Mais.... Vu que mon premier vrai Moc était un char, je me demande si mon premier vrai moc/autonome ne serai pas non plus un char.. Pas sur roues, mais sur chenilles ce coup ci.
C'était de l'utopie avant que je me rend compte de ce qui peux être envisageable.
Cependant, j'ai peur de vraiment me faire chier avec mes hubs 88012. Je vais quand même commander un troisième capteur, histoire de voir jusqu'où je peux aller.
Et pourquoi pas intégré du Ev4 à ma panoplie si je n'arrive pas à ce que je veux....

Avant tout ça, il fautvque:

Je fabrique une pince
Qu'il reconnaisse des pièces de couleurs
Qu'il puisse prendre des pièces de couleurs
Qu'il puisse suivre une bande blanche (ou verte, ou grise... Ah non, pas le gris)
Et pourquoi pas, s'orienter tout seul... D'aller de A à B. Bon, je crois pas que ce soit possible.

A+

par **Sifflotte** » Mar Aoû 18, 2020 10:56 pm

Waouh la belle pince (merci Google image)!

Là où je suis fier de moi, c'est d'avoir couplé et le pincement et l'élévation.
Je me suis décerné une médaille tout seul

Évidement, vous y êtes habitués maintenant, ça marche bien, mais, il faut que je trouve un système de butée variables.
Il y a clutch plus résistant que l'autre et du coup, la pince par en freestyle.
Ce qui est cool, c'est quand la pince s'ouvre complètement, des butées les ré-alignent.

Jvoulais partager mon idée, si dès fois des plus malin que moi amélioreraient ce systeme.
Ya moyen de faire un truc je pense (si ça n'a pas déjà été fait).

Alors ce n'est pas encore automatisé, c'est la prochaine étape (et la commande du capteur)
Bye

par **Vinz** » Mer Aoû 19, 2020 9:25 am

Bien ton système de pince! Avec les clutch qui ré-initialise la position quand tu laches.
Desfois que ca puisse te servir, la pince de l'EV3 GRIPPER est bien fichue, une fois qu'elle a pincé elle se lève du fait que la pince est en butée.
https://www.lego.com/cdn/product-assets ... RIPP3R.pdf

par **Sifflotte** » Jeu Aoû 20, 2020 12:17 am

En effet, la pince est bien fichue.
Même si ce n'est pas but final, je vais la construire pour le fun.

Sinon, jai testé le truc en dehors de chez moi, et il fonctionne nickel.
Faut pas qu'il y est de câble ou un obstacle noir par contre. Va falloir que je me penche dessus.

En parlant couleurs, les performances des 88007 ont pas l'air géniale.
On fera avec.

Le Ev4 me fait de plus en plus de l'œil. Il me coûtera sûrement un bras aussi.

(jai cru comprendre que le P. U serait compatible avec l'ev4. Et un mail reçu de lego le sous-entendait. Par contre c'est clair que Spike restera à part du système P. U.)

Application Powered Up

Qui est en ligne ?