Messages

PS quand tu parle de ton robot c'est un que tu a acheté ?

Oui, une verte de chez Viking...

J'avais fait quelques recherches sur les algo utilisés par les fabricants pour le calcul de la route... je cherche encore.
En 1ere approche, après quelques observations en terrasse, lorsqu'elle "bigne" sur le fil, elle s'arrête 1s, tourne d'un angle aléatoire ( entre 25° à 120° à l'oeil) et repart en ligne droite... la magie de l'aléatoire fait qu'elle tond l'ensemble du terrain (assez tortueux d'environ 2000m²) entre 5 à 8 jours.
Pour les fleurs et massifs, les installateurs m'ont déconseillés la pose du fil, ils préconisent plutôt la technique du "choc frontale"... entourer les massifs d'une petite bordure en bois. Le robot étant équipé de "moustache" il réagit de la même façon que lorsqu'il rencontre le fil périmétrique.

J'ai pas regarder très précisément quelle longueur de fil est préconisé sur le kit... à vérifier : la longueur du périmètre de ton terrain pour ne pas être coincé. (et bon courage pour la pose...)

Bonjour,

Une électronique d'un autre âge, mais pourquoi pas. En fait , la solution est donnée dans le 1er lien que tu mentionnes.

La partie émission ( à base de 555 ) fonctionne sans rien faire... donc besoin de rien.
La partie réception est construite autour de 2 inductances dont le signal est amplifié par des LM234. En sortie donc 2 signaux analogiques (0/5V) dont la tension dépend de la distance de la ligne enterrée.
Pour le code à concevoir , il faut donc dans le désordre :
* du code (blocs) pour lire les tensions analogiques des broches reliées à ces inductances (existe déjà)
* du code pour comparer ces valeurs à une valeur de seuil ( à expérimenter par essais successifs) (existe aussi , c'est juste une opération mathématique) pour estimer la distance du fil périmétrique.
* du code pour commander les moteurs en fonctions de la distance (existe aussi)

En fait le plus difficile est de générer le "tracé" ( aléatoire ou non ) que doit suivre la tondeuse de façon à ce qu'elle fasse correctement son travail, couper l'ensemble de la pelouse sans connaitre la géométrie de la ligne enterrée. J'observe ma propre tondeuse les jours d'été et je ne trouve aucune logique à ses rebonds lorsqu'elle "cogne' le fils périmétrique... Un autre problème de taille est le retour à la "maison" lorsque la batterie est déchargée... c'est délicat car il faut connaitre précisément l'état de charge (une simple mesure de tension de la batterie ne suffit pas). La borne de rechargement en elle même est un vrai défi... il faut qu'elle soit en extérieure, permette de recharger la batterie ( donc des contacts électriques nus ) et le tout à la vue de la poussière et de l'humidité, tout en permettant une recharge relativement rapide, sûre ( pour ne pas flinguer la batterie) et en consommant un minimum.

Il va falloir que tu nous montre où en est ton avancement ( châssis, motorisation, batterie, gestionnaire de batterie, emplacement des capteurs... ) et tes algorithmes ( en graphique ou autres ) pour pouvoir cibler l'aide à t'apporter.
Faire le projet de A à Z ... le prix d'un robot tondeuse est une bonne indication de la quantité de travail à réaliser.

PS : le code donné en 3ème lien est  un suiveur de ligne(scotch noir sur une table blanche)  implémenté d'une façon assez classique.

Pour s'amuser... on passe à un tout autre calibre,  la librairie "classique" stepper.h ne suffit pas, il faut se coder ces propres fonctions.

Voici un article qui m'a bien inspiré lorsque j'ai commencé à jouer avec ça. il y a un code fournit en fin d'article pour se donner une idée.
http://www.jangeox.be/2013/12/microstepping-with-arduino.html

Pour que ce soit "agréable" à utiliser avec Blockly, il faudrait mettre tous ça en fonction, faire une bibliothèque puis créer des blocs...  très formateur mais très chronophage.

J'ai vérifié mes calculs pour les 4096 pas... j'avoue ne pas comprendre pourquoi 2048 suffisent ?!?

bah vu que  l'arbre de sortie n'est pas dans l'axe du moteur... aucun doute, il y a un réducteur.

une petite recherche me donne

Caractéristique du moteur:
Diamètre: 28 mm
Tension: 5V
Angle de pas: 5.625°  c'est donc un 64 pas de base
Rapport de réduction: 1/64  donc des pas de 5.625/64 = 0.08789°... et il en faut 4096 pour faire un tour.

Tu as quoi comme driver pour le commander ? ça ressemble sur la photo à un  ULN2003, il y a de quoi "s'amuser" beaucoup plus avec des modes "1/2 pas" "double bobines" voir même du microstepping... ceci dit avec un réducteur , l'intérêt est assez limité. 

L'arbre de sortie ne tournera jamais bien vite par contre il aura une grande précision et un bon couple.

Bon courage pour tes améliorations

Réponse rapide sans test :

Dans le bloc de configuration du moteur, on doit pouvoir créer une variable "int nbpasmoteur_X = 2048" et ensuite dans y faire appel dans le bloc permettant de saisir le nombre de tour.
2048 pas par tour pour un PAP... c'est avec un réducteur non ?

Le code est dispo dans le PDF page 2.

Pour la fabrication, je procède souvent de la façon suivante :
1. Écrire le code en Arduino "pur"
2. Valider, simuler, tester
3. Repérer les "variables" , ce que doit renseigner l'utilisateur.
4. Ecrire; le bloc, le texte, le toolbox, et le generator,
5. Tester , affiner
6. Go

Je pars souvent d'un bloc existant (n'importe lequel du moment que les entrées nécessaires ressemblent à ce que je souhaite), qui sert de squelette, le reste vient avec l'habitude. L'usine à code est intéressant, mais je ne m'en sers plus.

Solution simple sous Windows : outil "Capture".
Solution moins simple : IMP ECRAN puis retouche logiciel.

Il reste cependant la grille... mais je ne suis pas perfectionniste à ce point.

Salut,

Voici une proposition pour des blocs concernant les moteurs PAP :
On peut mettre plusieurs moteurs en spécifiant les broches utilisées.
Je n'ai fait le bloc de configuration que pour une connexion 4 fils, mais on peut "facilement" créer un deuxième bloc à partir de celui ci pour une connexion 2 fils.

Pour l'accrochage, je ne me pose jamais la question. A mon avis si le bloc ne renvoie rien, on doit pouvoir l'attacher en haut et en bas.

Le type du paramètre qui ne tient pas : je crois bien que ça n'a jamais fonctionné même dans l'ancienne version (sans la partie electron)

En effet, ça n'enregistre pas le type du paramètre... . J'ai l'impression que chez BlocklyDuino ils ont des pistes https://github.com/BlocklyDuino/BlocklyDuinoReboot/blob/master/blocks/procedures.js
mais je n'arrive pas à intégrer leurs modifications aux tiennes... j'essaie mais comme je ne comprend pas bien ce que je manipule, le résultat ne fonctionne pas.

Pour la console as tu le message "démarrage de la communication série" qui s'affiche ?

non, j'ai un caractère lorsque j'ouvre la console un caractère non imprimable (carré) j'ai bien vérifié les vitesses ... ceci dit ça fonctionne du 1er coup dans l'IDE arduino.
un petit pdf pour montrer ce que je vois.

Résultats détaillés : c'est l'option "--debug" de la doc (https://github.com/arduino/arduino-cli) mais tu es sûr du résultat ? Il cause beaucoup...

je joins un PDF pour montrer les différences

Bonjour,

Beau travail !!!

Je viens d'installer la version électrifiée et de faire quelques tests :
I)test du "hello World !" :

Code Sélectionner Étendre


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

void loop() {
    Serial.println("Hello World!");
    delay(1000);
}


1) Compilation OK ( il me manque les  résultats détaillés, mais je comprend ce choix)
2) Téléversement OK (même remarque)
3) Console série PAS OK... j'appuie sur connection et toujours RIEN.
4) En passant par la console de l'IDE, ça fonctionne.

II) Test fonction carré

Code Sélectionner Étendre


int i;
float carre(float x) {
  return x * x;
}

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

void loop() {
    for (i = 1; i <= 10; i=i+1) {
      Serial.println((carre(i)));
    }
    while(true);
}


1) Compilation OK
2) Téléversement OK
3) Console PAS OK

J'ai voulu sauvegarder au format B@ (j'aime bien le nom de l'extension )
1) Sauvegarde OK
2) Ouverture du fichier OK MAIS le type du paramètre de la fonction ne "tient" pas en retourne en char...

Je tentais le coup car je cherche depuis longtemps à modifier ça... mais je n'y arrive pas. Je pense que la solution est dans l'écriture et la lecture du XML. Cependant cette partie du code qui permet la génération du XML ainsi que sa lecture sont très obscurs pour moi.

Quelques questions :
* Cette version ne bouleverse pas la création des blocs il me semble, peut-on me confirmer ?
* Pourra-t-on avoir une option pour obtenir les "résultats détaillés" lors de la compilation et du téléversement?

PS  : J'ai vu que la bascule référence/fonction est là, je vais reprendre mon travail sur cette partie.

[s d'avis de ne pas garder d'AnalogWrite car c'est une connerie pour l'apprentissage]

Je serais d'avis de ne pas garder d'AnalogWrite car c'est une connerie pour l'apprentissage

+1 ... rien d'analogique la dedans. MLI ou PWM est à mon avis préférable (en plus ça fait du vocabulaire).

ben oui c'est con mais je leur apprends aussi à faire beau

Avec le formatage auto, aucunes excuses valables pour rendre un code non lisible, je pousse même le vice à leur faire mettre des commentaires...

(...) c'est vérifier si les blocs génèrent un code exact, bien formaté

La rentrée étant assez tendue, je ne peux pas apporter beaucoup d'aide pour le moment sur le moteur.

Beaux travaux, je vais suivre particulièrement tes développements sur le rf433 

Salut,
Il y a quelques blocs "cachés" dans les toolbox (toolbox_arduino_all.xml à partir de la ligne 110 par exemple) que tu peux dé-commenter pour voir ce qu'il font, le soucis c'est que certains n'ont pas les générateurs associés... ça donne cependant une petite base de travail sur les chaines de caractères.

a+

Salut,

Désolé, je déterre un peu le sujet mais je compte faire une activité "connexion à une API de météo" avec mes élèves donc comprendre le fonctionnement des blocs existants pourraient m'aider à gagner du temps. Il faudra très certainement en créer de nouveaux pour la connexion à l'API mais je m'en chargerai sans soucis.

L'exemple que j'avais mis et que je viens de remettre à jour, utilise l'esp en mode serveur, je n'ai pas fait les blocs correspondant au mode client (ce que tu cherches à faire) il faudra donc les faire (il devrait y en avoir 2 ou 3) je veux bien m'en charger mais je n'ai pas l'esp sous la main  (il est resté au bahut). C'est pour quel niveau de classe ? les blocs que je conçois sont souvent assez bas niveau pour des élèves de TSTI2D et TSSI.

un exemple de connexion à une API tiré d'un site anglais : https://medium.com/@cgrant/using-the-esp8266-wifi-module-with-arduino-uno-publishing-to-thingspeak-99fc77122e82

Ce site utilise les commandes AT, pourquoi pas, mais ce n'est pas le moyen que j'utilise (à par pour configurer l'esp). J'utilise plutôt la bibliothèque  wifiesp.h qui permet de gérer l'esp sans passer directement par les commandes AT.
On pourrait aussi envisager une lecture de flux RSS http://pigo.free.fr/projet-mini-projet-web-extraction-des-donnees-integrees-a-un-fil-rss.html pour récupérer les données météo mais ça demande surement plus de travail au niveau du traitement.

Serait-il possible Bzhtitude que tu postes ici une capture de la version définitive de ton programme exemple un peu plus haut ? Car j'ai l'impression qu'il y a eu des changements au niveau des blocs depuis et je ne suis pas sûr d'arriver au même résultat. Si tu peux éventuellement aussi préciser de quels menus viennent les blocs, notamment si certains ne sont pas dans "ethernet" ou "communication logicielle".

Il n'y a pas souvent de définitif avec moi, je cisèle mes blocs au fur et à mesure des besoins et des retours élèves et collègue. L'ensemble des blocs spécifiques sont dans le menu ethernet. Tous les blocs en rouge ne te seront pas utile en mode client (quoique). Ces blocs font appel à une bibliothèque maison que l'on a développée et qui se trouve sur le github de blockly@rduino.

Bon courage dans tes développements et tiens moi au courant si tu veux que je fasse les blocs manquants (ça ne devrait pas être bien long) mais il me faudrait un cahier des charges en fonction de ce que tu attends comme "niveau" pour ces blocs.

a +


PS : je profite du retour sur ce fil pour signaler que maintenant les appels aux fichiers HTML se font grâce à un fichier .h externe, ce qui est beaucoup plus simple.

Çà me plait beaucoup, par contre , le choix par "fonctions" ne tient pas lors de la validation, les blocs affichés reviennent toujours en mode "référence" ...

un petit PDF pour expliquer plus simplement.