Raspberry Pi : fabriquons des trucs!

[Killator]

Ah ça... Il fait vraiment un boulot de ouf le "Raspberry master" !

[sky99]

Hello, j'aimerais uniquement te remercier "Sky99" car c'est vraiment un super travail que tu as fait. J'ai rarement vu des explications aussi claires et des tutos aussi simple se balader sur les Forums...

Si tu veux, je te ferais part de mes projets lorsqu'ils seront terminés :)

Merci pour les encouragements :) D'autre part, si tu trouves les tutos clairs, c'est que j'ai atteint mon objectif :) On trouve souvent des ressources sur le net, des tutos et plein d'autres guides, mais beaucoup partent du principe que l'utilisateur à déjà telle ou telle compétence. C'est d'autant plus le cas que le sujet est pointu. Mon but ici c'est que quelqu'un de quasiment novice puisse arriver ici, trouver un tuto qui l'intéresse, et se lancer dans la réalisation du "bidule", sans autres ressources que ce sujet, ou d'éventuels liens qui y seraient cités. Je sais que chaque post ne peut pas contenir toutes les infos, et c'est pour ça que j'ai commencé par un tas de tutos sur les "briques" basiques qu'on utilise par la suite; c'est également la raison pour laquelle j'ai mis tant de temps avant de mettre le tuto "robot", car je voulais les mettre "dans l'ordre", cad parler des motor drivers, des capteurs IR, etc, avant. Je pense également faire des tutos Arduino pour certains points spécifiques, mais dans le même esprit je me dis qu'il faudrait d'abord faire une petite série de tutoriels de base sur Arduino. Du coup je me suis pas encore lancé car ça risque de faire du boulot ^^

Mais sinon, je ne vous oublie pas, j'ai juste pas mal de boulot ces temps ci (je reviens d'une conf à Bruges, et la j'ai des étudiants de L2, des bidules administratifs, etc...).

Mais j'ai quelques trucs sous la main, sans compter tous ceux que j'avais annoncés, et que j'ai en retard. Je pense que je commencerai par le montage pour commander des lampes secteur depuis le Raspberry Pi avec un relais. Celui la prendra peut être un peu de temps, car je veux essayer de faire un peu plus que le simple tuto "hardware", et faire une petite interface web de commande du bidule.

En tous cas, ça vient :)

Ah ça... Il fait vraiment un boulot de ouf le "Raspberry master" !

Merci :) Et j'aime bien le titre, ça claque

Au passage, j'espère commander bientôt des Raspberry Pi modèles A, et je vous ferai des tests/comparatifs entre les deux. Mais déjà, les différences sont : pas de réseau RJ45, un seul port USB, et 256Mo de ram au lieu de 512. Mais le gros "plus", c'est la consommation, puisque le modèle A est donné pour 400mA max, contre 700 mA pour le B. ça fait donc une baisse de la conso de 42%, donc un gain d'autonomie du même ordre sur un projet alimenté par batterie...

Par exemple, la version sans fil sur 5 batteries AA du projet de caméra réseau diffusant en wifi des images d'une webcam pourrait passer de 3H à 4-5h d'autonomie!

Et d'autre part, on pourra simplifier les designs, en utilisant un régulateur step-up au lieu de step-down, avec 2 à 4 batteries AA. Il devient donc facilement possible de prendre deux packs de 4 batteries AA, et mettre ces deux packs en parallèle pour encore doubler l'autonomie... On pouvait le faire avec les 5+ batteries de l'autre projet. Mais les piles rechargeables AA etant vendues par 4 , ça obligeait à acheter 3 packs... Sans compter que les chargeurs rechargent 2 ou 4 batteries, donc c'est plus simple ainsi :)

Et on pourra également alimenter le Pi avec une cellule Lithium Ion de 3.7v, au lieu de deux en série...

Bref, tout plein de choses intéréssantes à venir :)

AH oui, au passage, si vous souhaitez voir des tutos spécifiques en priorité faites le moi savoir :)

[titou190]

Il existe aussi les puces SN754410 pour 2€ pièce sur Alpha-Crucis (ou 3$ sur pololu), qui sont compatibles broche à broche avec les L293D (on peut donc utiliser exactement le même câblage d'après pololu). Dans la doc, je lis 1A de courant en sortie. Cependant, je ne parviens toujours pas à comprendre si c'est 1A au total, ou 1A par canal. Si c’est 1A par canal, alors cette puce permet de remplacer les deux L293D dans notre montage, si c'est 1A au total, elle n'a aucun intérêt par rapport aux L293D.

Salut ! Je ne sais pas si tu te poses toujours la question concernant la puce SN754410, mais comme j'étais en train de bricoler mon futur petit robot (qui a fait ses premiers tours de roues il y a quelques minutes ), je vois que sur la page les concernant chez Pololu, il est indiqué que c'est 1A par canal.

[sky99]

Il existe aussi les puces SN754410 pour 2€ pièce sur Alpha-Crucis (ou 3$ sur pololu), qui sont compatibles broche à broche avec les L293D (on peut donc utiliser exactement le même câblage d'après pololu). Dans la doc, je lis 1A de courant en sortie. Cependant, je ne parviens toujours pas à comprendre si c'est 1A au total, ou 1A par canal. Si c’est 1A par canal, alors cette puce permet de remplacer les deux L293D dans notre montage, si c'est 1A au total, elle n'a aucun intérêt par rapport aux L293D.

Salut ! Je ne sais pas si tu te poses toujours la question concernant la puce SN754410, mais comme j'étais en train de bricoler mon futur petit robot (qui a fait ses premiers tours de roues il y a quelques minutes ), je vois que sur la page les concernant chez Pololu, il est indiqué que c'est 1A par canal.

Effectivement, j'ai fini par comprendre cela également, c'est donc du tout bon :) Il faut que j'édite le billet !

Au passage, je suis passablement agacé, je viens de passer des plombes à faire un panier sur alpha-crucis, et le site m'a effacé mon panier... Maintenant impossible d'ajouter quoi que ce soit... Leur catalgogue est complet et très intéressant, mais le site semble codé assez bizarrement... ça n'inspire pas super confiance :/

J'aimerais bien trouver un autre site aussi complet, avec des FDP bas!

[Yaug]

Pour alpha crucis après le sale coup qu'ils m'ont fait sur ma livraison, je ne passe plus part eux.

Intéressant ou non !

Surtout qu'il y a de nombreux retour similaire, quand on est pas une entreprise, ils nous snobent.

Donc adios.

[titou190]

Ce qui me gêne un peu avec Alpha Crucis, c'est qu'en réalité la facturation est réalisée depuis la Suisse, donc il peut y avoir des frais bancaires pour un paiement hors zone euro. Ca ne coute pas grand chose de plus, mais ça manque de transparence...

J'ai commandé une puce et divers éléments (notamment une mini clé Wifi) chez MC Hobby dont l'URL est http://mchobby.be/PrestaShop/. C'est une e-boutique belge plutôt bien fourni, tenue par un couple de passionnés d'après ce que j'ai lu. Pour eux, la satisfaction du client est très importante. Au niveau paiement par contre, c'est soit CB via PayPal, soit virement bancaire. Ils expédient soit via Mondial Relay, soit via UPS. Dans le cas de Mondial Relay (UPS je ne sais pas), les expéditions se font 1 fois par semaine, généralement le mardi. Donc pour résumer, ils sont super sympa, mais il ne faut pas être trop pressé et il peut y avoir des frais annexes (paiement et livraison).

Je vais sans doute devoir passer une enième commande, je pense avoir endommagé mon capteur à ultra-son en soudant des fils dessus (je n'avais pas fait de soudure depuis 1996, je pense, donc j'ai quelque peu perdu la main ). De toute façon je manque de place sur la BreadBoard aussi .

Edit : Je viens de commander différents éléments qui me manquaient encore (pour l'alim par batteries, le branchement d'un servo et une breadboard supplémentaire), et j'en ai profité pour prendre un autre capteur à ultra-son de la marque SeeedStudio. Je vous ferai un petit retour quand je l'aurai testé : c'est moins cher que les Maxbotix, et ça a l'air plus pratique à utiliser... (surtout quand on est une quiche en soudure).

[sky99]

Pour ma part, je commande chez eux, car leur catalogue contient plein de trucs qui m'intéressent, et ça m'évite de commander aux USA.

D'autre part, les achats expédiés vers les antilles sont détaxés de TVA, et comme c'est des commandes de "over 9000" petites pièces,

les douaniers ne taxent jamais. Du coup c'est rentable.

J'ai regardé sur ton site, ils ont des choses, mais je trouve les prix très élevés!

Yaug, quel problème exactement as tu eu avec eux, que je sache à quoi m'attendre?

[Yaug]

Ils annoncent avoir un produit en stock, t'envoies ta commande, et le jour de la réception, t'envoies un mail pour te rembourser un produit qu'ils n'avaient en fait pas en stock ...

Perso ça m'a bien soulé, j'ai pris chez eux car leurs frais de port étaient moins cher, et au final, j'ai du me rabattre sur pololu avec les frais de port qu'on leur connait.

Du coup.. j'ai payé 2 fois des frais de port.

et apparemment, vu ce que j'ai trouvé sur plusieurs blogs, ça leur arrive très souvent de dire qu'ils ont un produit en stock et en fait... ils ne l'ont pas.

[sky99]

Ils annoncent avoir un produit en stock, t'envoies ta commande, et le jour de la réception, t'envoies un mail pour te rembourser un produit qu'ils n'avaient en fait pas en stock ...

Perso ça m'a bien soulé, j'ai pris chez eux car leurs frais de port étaient moins cher, et au final, j'ai du me rabattre sur pololu avec les frais de port qu'on leur connait.

Du coup.. j'ai payé 2 fois des frais de port.

et apparemment, vu ce que j'ai trouvé sur plusieurs blogs, ça leur arrive très souvent de dire qu'ils ont un produit en stock et en fait... ils ne l'ont pas.

Je vois!

J'ai aussi lu des critiques sur ce vendeur, j'essaierai de chercher d'autres sources d'approvisionnement. Le problème c'est qu'avec les sites US, on a de gros FDP (le colis traverse 2 fois l’Atlantique : USA-Paris, puis Paris-Guadeloupe, ce qui fait que je me retrouve avec au moins 40$ de FDP) donc ce n'est intéressant que pour de petites commandes. Dommage que snootlab n'aie pas un catalogue plus fourni, car il sont très bien :)

[titou190]

J'ai dû avoir de la chance alors, parce que ça fait 4 fois que je commande chez eux et je n'ai jamais eu le moindre pb (hormis les frais bancaires mais ce n'est pas bien grave, ça). Ce que j'apprécie chez eux, c'est qu'à chaque fois ils ont été très réactifs et que leurs paquets sont très petits :)

[titou190]

Lire la valeur d'un capteur de distance à ultrasons à sortie numérique

Il existe des capteurs de distance à ultrasons ne nécessitant pas l'utilisation d'une puce MCP3008 : c'est possible lorsque la valeur de sortie sur la branche "signal" est binaire. C'est le cas, notamment, du capteur de chez SeeedStudio, modèle SEN136B5B (13,95€ chez AlphaCrucis, $12 chez SeeedStudio directement) Vous trouverez des infos utiles sur ce capteur sur le wiki du constructeur

Comme on peut le voir sur l'image, il y a 3 broches : SIG, VCC et GND (cachée sur l'image). SIG va se brancher directement (ou par l'intermédiaire d'une breadboard) sur un GPIO de votre choix du Raspberry Pi, VCC sur la broche +5V (ça doit probablement marcher aussi avec la broche +3.3V mais je n'ai pas fait le test et ça réclame du +5V), et GND sur la broche GND.

Mais comment peut-on déterminer la distance si le signal est soit 0, soit 1 ?

En fait, le choix fait par SeeedStudio est d'émettre du 1 pendant une durée qui, via une fonction simple, permet de déduire la distance. En pratique, le constructeur indique qu'il faut diviser la durée (en µS) par 58 pour avoir la distance en centimètres.

Le principe est donc :

• la broche SIG est paramétrée en OUTPUT
• on émet du 0 pendant 2 µS
• on émet du 1 pendant 5 µS
• on repasse à 0
• la broche SIG est paramétrée en INPUT
• on attend tant qu'on reçoit du 0 (attente du retour d'impulsion)
• on détermine pendant combien de µS on reçoit du 1
• on divise par 58 cette durée en µS pour avoir la distance en centimètres.

Hélas le Python ne permet pas de jouer efficacement avec des durées aussi courtes, donc il faut se tourner vers du C/C++.

Voici le code que j'ai écrit à partir de ce qui était proposé sur la page wiki.

#include <stdio.h>#include <sys/time.h>#include <wiringPi.h>using namespace std;void sendPulse(int pin);double getDistanceCentimeters(int pin);int main(void){    int sigIO = 7;    double distanceCm = 0;    if (wiringPiSetup()==-1) {return 0;}    while(1) {	// Emission de l'impulsion	sendPulse(sigIO);	// Calcul de la distance par rapport au retour de l'impulsion	distanceCm = getDistanceCentimeters(sigIO);	printf("Distance evaluee : %.2f cm\n", distanceCm);	delay(500); // on attend 500ms entre chaque lecture.    }    return 0;}void sendPulse(int pin) {    // le port GPIO est configuré en ecriture    pinMode(pin,OUTPUT);    digitalWrite(pin, 0); // On reinitialise a 0    delayMicroseconds(2);    digitalWrite(pin, 1); // On emet l'impulsion    delayMicroseconds(5);    digitalWrite(pin, 0); // On reinitialise a 0}double getDistanceCentimeters(int pin) {    timeval t1, t2;    double elapsedTime;    // le port GPIO est configuré en lecture    pinMode(pin,INPUT);    // attente du retour de l'impulsion    while (digitalRead(pin) == 0) { delayMicroseconds(1); }    // calcul de la longueur de l'impulsion    gettimeofday(&t1, NULL);    while (digitalRead(pin) == 1) { delayMicroseconds(1); }    gettimeofday(&t2, NULL);    elapsedTime = (t2.tv_usec - t1.tv_usec);    return (elapsedTime / 58);}

Avec ce code, j'obtiens des distances assez précises, mais il faudra que je vérifie plus en détail l'exactitude des résultats. Dans l'exemple, la broche SIG est connectée au GPIO7, soit le 4ème à gauche en partant du haut.

Petite précision utile : comme ce code contient des petites spécificités de C++ (bien qu'il ne soit pas du tout orienté objet), il faut bien sûr le compiler avec g++ et pas gcc.

Edit : pour compléter un peu, on peut retrouver une courte spécification de ce capteur à cette adresse. Ca pourra être utile pour déterminer la largeur maximale de l'obstacle détecté en fonction de la distance.

[Yaug]

Mais heu !

Je suis en train de finaliser mon tuto pour lire une distance avec un capteur HC-SR04.

CépoZuste !

:)

Merci pour ton tutoriel !

Le miens est en python, ça permettra de varier les sources, et en plus, j'ai fait un tableau de test de fiabilité pour plusieurs distances.

[titou190]

C'est pas mal ça, ton capteur est assez proche du SeeedStudio que j'ai pris, sur l'aspect et le principe de fonctionnement.

Mon code doit être facilement adaptable pour ton capteur, et ton code python sera aussi facilement adaptable pour mon capteur :).

Tu n'as pas de souci pour la gestion des microsecondes, toi ?

[FelX]

Hello

Je me permet juste d'intervenir rapidement, mais que penseriez vous d'utiliser les interruptions plutôt pour lire ce genre de données?

J'ai trouvé cette article il y a pas longtemps sur un site dont j'avais déjà parlé.

http://www.blaess.fr/christophe/2013/04/15/attentes-passives-sur-gpio/

Bon il est plutôt orienté analyse avec des noyaux temps réel. Mais je pense qu'il y a moyen d'en, tirer quelque chose d'utile pour vous.

Bon courage pour la suite :)

[titou190]

Très intéressant comme approche, effectivement ! Et sans doute plus précis également.

Pour le moment je suis plutôt passé sur d'autres éléments du robot (assemblage physique, balayage façon "radar" avec un servo, affichage "human-friendly" de ce que détecte le radar), mais ce serait sans doute une amélioration notable pour obtenir les infos depuis les capteurs comme le SeeedStudio SEN136B5B ou le HC-SR04 de Yaug

[FelX]

En fait j'ai fait un peu de robotique a l’école, et c'est un principe assez utilisé en temps réel, car le polling en continue d'une sortie, est facilement influencé par des paramètres externes, qui peuvent influencer sur sa vitesse, voir dans un environnement multitâche être interrompu par une autre tache, et *louper* un déclenchement etc.

Et puis la boucle en continue va faire travailler le processeur, assez fortement, et donc avoir un coût énergétique non négligeable.

:)

--edit--

Je devrais pouvoir me remettre a tout ça dans pas trop longtemps, je vous tiendrais au courant :)

--edit2--

J'ai pas eu le temps de verifier, mais un article en lien dans les commentaires semble indiquer que ca fonctionne aussi en python pour ceux qui aiment pas mixer les codes ^^"

[titou190]

Effectivement en naviguant dans les liens on tombe rapidement sur un petit bout de code en Python.

Je pense que j'adapterai mon code pour utiliser ce procédé, ne serait-ce que pour la moindre consommation de ressources (et parce que sur le principe, c'est plus joli )

[FelX]

hehe oui, et puis les interruptions caylebien

Et ça fait toujours un petit challenge en plus ^^"

[sky99]

Très intéressant comme approche, effectivement ! Et sans doute plus précis également.

Pour le moment je suis plutôt passé sur d'autres éléments du robot (assemblage physique, balayage façon "radar" avec un servo, affichage "human-friendly" de ce que détecte le radar), mais ce serait sans doute une amélioration notable pour obtenir les infos depuis les capteurs comme le SeeedStudio SEN136B5B ou le HC-SR04 de Yaug

Salut! Déjà très joli tuto! J'ai pris du temps à modifier mes tutos et la page de tutos, mais ton tuto est maintenant linké dans mes tutos sur les capteurs analogiques et l'index. Ainsi, ceux qui se réfèrent à l'index trouveront ton tuto, et ceux qui lisent les miens auront aussi un lien vers le tien :)

Pour ce que tu mentionnes, (balayage et affichage "human-friendly") je serais très intéressé par voir le résultat :) N'hésites pas à faire une petite vidéo sur youtube, ou autre, pour montrer de quoi ça à l'air... J'avais cette idée en projet, mais je ne l'ai jamais implémentée.

Ce que j'aime bien avec ton capteur, c'est son faible cout. Du coup, je me dis que je pourrais bien en prendre un, lui coller un ATtiny85 ou 2313 qui ferait le polling, et renverait en serial la mesure de distance... Pourquoi pas au passage ajouter un micro-servo pour orienter le tout, et ça ferait pour environ 20€ un capteur motorisé, qui reçoit des commandes, pourrait faire un balayage automatique, et envoyer en mode serie, i2c ou un autre protocole les données récupérées. L'avantage, c'est qu'avec un µC, la conso de celui ci est ridicule, il a des canaux PWM pour gérer un servo, et peut poller à très haute vitesse, en temps réel...

En fait j'ai fait un peu de robotique a l’école, et c'est un principe assez utilisé en temps réel, car le polling en continue d'une sortie, est facilement influencé par des paramètres externes, qui peuvent influencer sur sa vitesse, voir dans un environnement multitâche être interrompu par une autre tache, et *louper* un déclenchement etc.

Et puis la boucle en continue va faire travailler le processeur, assez fortement, et donc avoir un coût énergétique non négligeable.:)

Salut! Sur la conso, je suis pas convaincu que sur un processeur moderne, cela aie beaucoup d'impact. Normalement, il y a des optimisations à ce niveau qui évitent aux unités de calcul de consommer rester à ne rien faire. Cependant dans un µC, je suppose que la situation différente! Mais sur le Pi, il est difficile d'avoir des différence significatives de consommation, car même en underclockant beaucoup, la différence est assez faible.

En tous cas, bravo encore pour le tuto, et désolé de ma réaction lente, mais je souffrais d'un problème dentaire, du coup j'étais complètement au ralenti :)

[FelX]

Hello

En effet sur l'approche consommation, vu que tu endors le process ca doit pas jouer beaucoup, vu que de toute façon le proc va charger autre chose en attendant, cependant du point de vue performance je pense que ca doit être un peu mieux, car le process n'est appelé qu'au besoin, donc pas besoin de le réveiller pour 'rien', et le proc peu charger une autre tache de moindre importance en attendant, sachant qu'elle sera interrompue en cas de détection, et je pense aussi que ça doit être mieux niveau précision, vu que la latence introduite par le sommeil de la tache est supprimé.

Après c'est juste un point de vue programmation linux , pour les arduino, je ne connais pas assez pour juger ^^".

[titou190]

Salut !

Pas de souci concernant le délai de réaction, sky99. De toute façon on est ici pour s'amuser, on a tout notre temps .

En attendant d'avoir un beau radar qui balaie en permanence, et une sortie plus précise, voici ce que j'ai obtenu avec un balayage de -45° à +45°, et une interprétation du résultat par un petit bout de code en PHP, l'idée étant d'avoir ensuite un rafraîchissement automatique via un peu d'Ajax.

Mes valeurs issues d'un balayage simple, avec un écart de 5° (angle:valeur;...) :

-45:5;-40:334;-35:363;-30:389;-25:337;-20:181;-15:180;-10:180;-5:180;0:159;5:159;10:133;15:158;20:178;25:88;30:171;35:104;40:106;45:106

Et l'affichage pour le moment, très basique :

Prochaines étapes, donc : réduire l'écart à 1°, en gérant mieux les angles parce que pour le moment, j'ai un peu de mal avec la manipulation "précise" du servo, accélérer le balayage, et envoyer le résultat via une socket à quelque chose qui va me générer ensuite le radar.

[sky99]

Hello

En effet sur l'approche consommation, vu que tu endors le process ca doit pas jouer beaucoup, vu que de toute façon le proc va charger autre chose en attendant, cependant du point de vue performance je pense que ca doit être un peu mieux, car le process n'est appelé qu'au besoin, donc pas besoin de le réveiller pour 'rien', et le proc peu charger une autre tache de moindre importance en attendant, sachant qu'elle sera interrompue en cas de détection, et je pense aussi que ça doit être mieux niveau précision, vu que la latence introduite par le sommeil de la tache est supprimé.

Après c'est juste un point de vue programmation linux , pour les arduino, je ne connais pas assez pour juger ^^".

Oui, je suis assez d'accord avec toi. Avec les interruptions, on doit pouvoir avoir des temps très très courts, et donc en pratique poller plus vite. Maintenant il faut voir jusqu'ou on peut descendre :) Mais le plus gros problème avec le pi pour ce genre d'application, c'est justement la précision des timings. Comme le système n'est pas temps réel, on est forcément limité... D'un autre coté ça rend plus intéressantes les solutions :)

Salut !

Pas de souci concernant le délai de réaction, sky99. De toute façon on est ici pour s'amuser, on a tout notre temps .

En attendant d'avoir un beau radar qui balaie en permanence, et une sortie plus précise, voici ce que j'ai obtenu avec un balayage de -45° à +45°, et une interprétation du résultat par un petit bout de code en PHP, l'idée étant d'avoir ensuite un rafraîchissement automatique via un peu d'Ajax.

Mes valeurs issues d'un balayage simple, avec un écart de 5° (angle:valeur;...) :

-45:5;-40:334;-35:363;-30:389;-25:337;-20:181;-15:180;-10:180;-5:180;0:159;5:159;10:133;15:158;20:178;25:88;30:171;35:104;40:106;45:106

Et l'affichage pour le moment, très basique :

Prochaines étapes, donc : réduire l'écart à 1°, en gérant mieux les angles parce que pour le moment, j'ai un peu de mal avec la manipulation "précise" du servo, accélérer le balayage, et envoyer le résultat via une socket à quelque chose qui va me générer ensuite le radar.

Très honêtement, ça en jette déja pas mal je trouve :) Et je comprends tes problèmes avec le servo, via le pi, en softpwm, je n'ai pas pu avoir une meilleure résolution non plus que 5°. D'ailleurs j'avais du "jitter" sur les mouvements, et c'est pourquoi je pense passer par des µC, même simples pour gérer les servos. En pratique, avec un Arduino, j'ai un mouvement complètement "lisse", sans à coups, mouvements parasites, et par incréments de 1°. Et on doit pouvoir faire plus précis en envoyant directement les impulsions pwm au servo...

Sur mon robot toutefois, l'approche que j'ai prise est de faire tourner le robot sur lui même pour balayer quand un obstacle est trouvé :)

De manière générale, je pense qu'il faudrait que je fasse un petit travail sur la liaison RaspberryPi-Atmega/ATtiny. Vu qu'il est possible de programmer un µC depuis un Arduino, pourquoi pas depuis les GPIO du Raspberry Pi?

Enfin, ça fait encore des tutos sur ma todo list ^^

Ah au passage, si tu as les spécifications de ton rangefinder, tu peux connaître la taille minimale de la zone de détection, peut être en fonction de la distance. Du coup, si tu sais qu'un écho sonar détecté implique forcément un objet faisant au moins Xcm de coté, tu peux dessiner un point plus à cette échelle, ce qui te permet d'obtenir non plus des points isolés, mais des surfaces!

[titou190]

J'ai légèrement adapté mon algo de balayage - qui est encore très imparfait cependant - de façon à contourner cette limitation d'environ 5°.

En fait je lui demande maintenant de faire 5 balayages : -45° -> 45° puis 41° -> -44° puis -43° -> 42° puis 43° -> -42° puis -41° -> 44°

Bon, c'est un peu fait à l'arrache puisqu'on voit bien qu'il y a des valeurs d'angle bien trop proches aux extrémités, mais c'était juste un test.

J'obtiens maintenant le radar suivant :

On voit bien qu'il a remarqué que j'étais face à lui ?

L'écho ci-dessus correspond aux valeurs suivantes (j'ai coupé les valeurs excessivement grandes, dans la capture d'écran) :

-45:734;-40:191;-35:638;-30:639;-25:229;-20:185;-15:51;-10:734;-5:-16497;0:562;5:735;10:315;15:36;20:35;25:35;30:36;35:37;40:174;41:188;36:170;31:528;26:40;21:36;16:36;11:36;6:36;1:36;-4:36;-9:36;-14:606;-19:733;-24:734;-29:733;-34:735;-39:733;-43:147;-38:185;-33:175;-28:-17003;-23:121;-18:735;-13:309;-8:167;-3:735;2:314;7:735;12:36;17:35;22:35;27:35;32:36;37:36;43:735;38:210;33:735;28:37;23:36;18:36;13:35;8:35;3:36;-2:35;-7:36;-12:354;-17:735;-22:310;-27:733;-32:639;-37:-16602;-41:638;-36:192;-31:276;-26:186;-21:735;-16:654;-11:177;-6:733;-1:734;4:36;9:36;14:35;19:35;24:35;29:35;34:36;39:36

Certains angles manquent également à l'appel, il y a encore du boulot avant d'avoir quelque chose de clean :)

Edit : petite amélioration du rendu (tout en CSS )

Edit 2 : encore une petite amélioration suite à la suggestion de FelX dans le post #176, toujours en CSS pur

Edit 3 : voilà, les points sont reliés et on voit mieux ce que perçoit le capteur lorsqu'il balaye la zone, je trouve. Pour relier les points, j'ai trouvé une petite fonction Javascript que j'avais la flemme de créer moi-même, honnêtement ce n'est pas génial, mais ça fait le boulot ^^. Si vous avez besoin du code, je pourrai vous faire un zip (2 fichiers PHP).

[FelX]

Pas mal, :)

Peut etre juste une graduation pour les segments pour savoir une distance ? Sinon bravo :)

PS: La question qui tu, tu as fait une ligne de balayage avec ?

[titou190]

Peut etre juste une graduation pour les segments pour savoir une distance ? Sinon bravo :)

Oui pour l'instant c'est décoratif mais je vais y apporter un peu de pertinence, quitte à avoir un aspect de radar

PS: La question qui tu, tu as fait une ligne de balayage avec ?

Pas compris ta question, par contre. Les valeurs sont issues du programme qui fait bouger le servo à coup de 5° avec les 5 balayages que j'ai indiqué, d'où quelques valeurs un peu exotiques (du style la distance négative -16497 à -5° ), si c'est ce que tu demandes.