Raspberry Pi : fabriquons des trucs!

[Yaug]

Héhéhé !

vivement ton retour.

J'aurais quelques tutos sympa aussi à mettre en place, le temps de finir un gros projet au taff, et je publierais du tuto de capteur IR notamment

[christophefrontignan]

Salut Sky,

Merci de nous donner de tes nouvelles.

Bon courage pour ta thèse, je penserai @ toi le 09.

[Nitro-TecK]

Tiens petite question, j'ai trouver pas mal de tuto sur le net, qui câblent directement le GND au pin du RPI pour utiliser un interrupteur (dans mon cas, juste pouvoir éteindre proprement le RPi sans clavier), c'est risquer ?

[sky99]

Héhéhé !

vivement ton retour.

J'aurais quelques tutos sympa aussi à mettre en place, le temps de finir un gros projet au taff, et je publierais du tuto de capteur IR notamment

j'ai hate de voir ça :)

Salut Sky,

Merci de nous donner de tes nouvelles.

Bon courage pour ta thèse, je penserai @ toi le 09.

Merci des encouragements, je touche au but!

Tiens petite question, j'ai trouver pas mal de tuto sur le net, qui câblent directement le GND au pin du RPI pour utiliser un interrupteur (dans mon cas, juste pouvoir éteindre proprement le RPi sans clavier), c'est risquer ?

Si tu connecte le gnd à un GPIO, ça fait court circuit si le GPIO est en sortie. Si tu veux eteindre le Pi en hard, une solution simple est de prendre un cable USB, le couper, trouver le +5V (ou la masse), et mettre un interrupteur dessus.

Ainsi, ça coupera l'alimentation électrique du pi, et c'est assez facile à faire! Attention toutefois à bien isoler les contacts, un court circuit sur le cable USB pourrait abimer le port USB source.

Une solution plus propre toutefois serait de mettre un bouton sur un GPIO en lecture, et avoir un demon unix qui surveille le bouton. Lorsqu'on a un appui, le demon lancerait sutdown -now...

Et la solution optimale à mon sens serait de faire un petit circuit, avec un relais controlant le transfo 220v-5v du Pi (sauf si il est alimenté par un port USB) pour pouvoir couper l'alimentation secteur et ainsi ne pas consommer pour rien avec le transfo :) (mais forcément c'est moins simple que sur le cable USB, et il faut quelques composants!)

[Nitro-TecK]

Ok c'est donc une sécurité si par mégarde ont utiliser le GPIO associé en sortie et non en attente ?

Pour l'alimentation coupé "a la barbare" j'ai eu le soucis en éteignant comme çà le Rpi, ma carte est devenu illisible (donc formatage etc... et évidemment j'avais pas fais de sauvegarde). La c'est un script ajouter au démarrage qui va vérifier si pendant 2sec le bouton OFF est enclenché, il lance un shutdown -h now (et en option, possibilité de rajouté un LED pour indiquer que le script est chargé).

[Zappi]

Bonjour,

Sur conseil d'un admin je poste ma demande ici (lien du topic original:https://forum.nextinpact.com/topic/168182-retro-pi/)

Alors voila mon "problème" je viens d'installer RetroPI (projet d'emulateur multi plateforme) sur mon Raspberry, l'installation c'est déroulé parfaitement.

Par contre je n'arrive pas à configurer corretcement mon pad nes USB (et non snes comme defini par defaut dans les fichiers de conf), en gros lors de de la config avec le script fournit celui ci me demande d'appuyer sur les touches correspondant au pad snes et non nes et impossible de zapper les boutons que je n'ai pas.

J'ai bisouiller un peu dans certains fichier de conf et commenté des ligne faisant reference au bonton non utilisés mais sans succès.

SI quelqu'un à une idée ou des pistes je suis preneur et bien sur si besoin je peux poster les fichiers de confs ou mieux m'exprimer si vous ne me comprenez pas :)

Merci d'avance.

[sky99]

Salut tout le monde!

Dans deux heures et demi, je soutiens ma thèse :)

Et pour filmer, j'utilise...

Un Raspberry Pi avec le module camera :)

Je vous dirai ce que donne la qualité de l'image dans ce contexte!

A bientôt pour de nouvelles aventures Raspberriesques \o/

[titou190]

Oups, trop tard pour les encouragements, mais par contre on (enfin moi en tout cas c'est sûr ) veut des news !!

[Nemasix]

Je plussoie, alors cette thèse?

[sky99]

Bonjour à tous :)

Ma soutenance est finie, désolé du délai, j'étais surbooké à la fac après (d'ailleurs c'est pas fini )

En résumé, je suis maintenant docteur en informatique, option sciences cognitives ^^

La soutenance s'est très bien passée, les rapports sont très bon, donc tous les voyants sont au vert!

Je vais donc postuler à la fin de l'année comme Maître de conférences à l'Université des Antilles et de la Guyane.

Pour la vidéo, le raspi n'a pas donné un super résultat : j'ai du bouger le module caméra (il était scotché sur le boitier ), donc ça a filmé mon ventre

J'ai heureusement d'autres sources vidéo ^^

Du coup dans les temps prochain, je vais travailler sur le concept pour proposer un système de caméra basé sur le pi.

Le problème avec les APN normaux, c'est qu'en HD, ça coupe quand le fichier atteint 4Go à cause de FAT32 qui ne gère pas plus.

D'autre part, la batterie est un problème, alors qu'ici on peut mettre la batterie qu'on veut, ou encore brancher sur secteur.

Avec les batteries dont je dispose je dois pouvoir faire 8-10h de vidéo, avec possibilité de brancher en USB pour charger/maintenir la charge :)

Il serait également intéréssant d'utiliser du Wifi pour synchroniser plusieurs modules de ce type, afin d'avoir des angles de vision multiples.

On doit pouvoir s'en sortir pour une centaine d'euros par "bloc vidéo", avec un espace de stockage confortable (ou simplement un HDD USB).

Le module caméra permet de filmer en 1080p à 30 ou 60FPS (je sais plus si le 60FPS c'est pas uniquement pour 720p et en dessous).

J'ai constaté environ 120mo/minute soit 7Go/heure environ, ce qui reste raisonnable.

Bref, mon prochain projet :)

Sinon, pour ceux qui veulent voir un peu plus de détails sur mes travaux, voici deux liens vers les reportages de la télé locale :

http://pluzz.francetv.fr/videos/jt_13h_guadeloupe_,93535100.html -> le journal du midi, c'est le premier sujet;

http://pluzz.francetv.fr/videos/jt_guadeloupe_,93535114.html -> le journal du soir (second sujet, après le chikungunia, à partir de 3 minutes 30)

Il y a aussi une émission de radio vendredi, donc je n'ai pas encore de lien ^^

Sinon, point intéressant, mes efforts sur le club robotique avec les étudiants ont payé : on aura une option robotique au second semestre!

J'ai déjà commandé et reçu le matos, pour faire 3 robots, basés sur Arduino. Le but est d'aborder la programmation d'un point de vue un peu

plus "concret", sans compter l'aspect ludique qui renforce à mon avis l'apprentissage.

En bref, je vais réfléchir à des fiches de TP sur le sujet, et du coup c'est pensé pour des débutants, donc s'il y a du monde d’intéressé, faites moi signe, je vous transmettrai les supports lorsqu'ils seront faits :)

Avec un peu de chance, si je suis recruté, je pourrai à terme utiliser cette approche pour les cours de programmation "classiques" et motiver les plus avancer, et remotiver les plus en retard :)

Bisous à tous, et à bientôt!

[sky99]

Salut à tous!

J'ai fini toutes mes démarches, et je m'attaque donc à un petit projet de caméra avec le pi.

Pour l'instant, j'ai donc :

-Un raspberry Pi modèle B

-Un module caméra

-Un hub USB pour l'alimentation et avoir plus de ports.

Le tout ensemble, ça fait simplement un Raspberry Pi avec un module caméra branché dessus :)

Le but du projet c'est d'en faire un bidule pratique pour faire des photos et des vidéos. Pour la photo, ça sera difficilement aussi pratique qu'avec un APN classique.

Donc je pense davantage le système pour des usages un peu différents, avec par exemple la vidéo (pouvoir filmer 50h si je veux), mais aussi en photo le time lapse par exemple.

Mon objectif est donc d'avoir un appareil, basé sur le Raspberry Pi et le module caméra, capable de prendre des photos et des vidéos sur commande. Je vais commencer simple, et rajouter

des fonctionnalités au fur et à mesure.

Pour l'instant, puisqu'on est à la phase de prototypage, le tout est installé dans une boite en carton, avec un trou pour la caméra, et un trou de l'autre coté pour faire venir le câble réseau et le câble d'alim.

En mettant à jour raspbian, on active facilement le suport du module caméra, et on peut alors prendre des photos avec raspistill :

raspistill -t 0 -n -o test3.jpg -vf

-t 0 dit au système de faire la photo immédiatement, sinon il attend 5s par défaut. On peut donc avoir un retardateur par cette commande.

-vf permet de retourner verticalement l'image, mon module étant monté "à l'envers".

Je reviendrai une autre fois sur ce programme en détail.

On peut prendre des vidéos avec rasipvid :

raspivid -vf -n -v -t 2000 -o test.h264

cette fois -t 2000 donne la durée de la vidéo.

Je reviendrai également en détail sur ce programme une autre fois.

Pour l'instant, on a donc le matériel pour faire des photos et des vidéos, et on a pu vérifier le bon fonctionnement de l'ensemble.

A partir de maintenant, on va pouvoir travailler à rendre ça pratique.

Pour cela, on va commencer par ajouter une autre interface que la ligne de commande, avec des boutons physiques.

On va commencer simple, avec un bouton pour la vidéo, et un second bouton pour les photos.

On pourra alors ajouter une/des LED pour pouvoir avoir un indicateur de ce que fait le système (par exemple : rouge= en cours de prise de vidéo, jaune= prises de photos en timelapse, bleu= prise de photo, vert = disponible, aucune commande), et/ou un écran LCD pour voir des informations.

Dès lors qu'on aura une interface basique, on pourra rajouter des boutons pour pouvoir régler les paramètres de la prise de vue (délai, durée, exposition, nombre de photos, espacement entre les photos, etc)

On obtiendra alors un système réellement pratique et fonctionnel. On pourra alors envisager toutes sortes d'améliorations, comme l'utilisation d'OpenCV pour reconnaître des objets/personnes/situations, et programmer les prises de vue en fonction de ça (prendre une photo dès qu'une personne est détectée dans le champ), ou l'ajout d'un système de motorisation pour faire pan/tilt et ainsi orienter la prise de vue, ajouter une batterie et éventuellement du wifi pour fonctionner de façon indépendante, une interface web pour commander le tout (et pourquoi pas depuis un smartphone), rendre le tout waterproof pour une utilisation extérieure, le rendre étanche pour une utilisation sous-marine, etc...

Bref, on élargira les possibilités du système au fur et à mesure :)

Ce que je vous propose, c'est de suivre avec moi l'évolution de ce projet, qui commencera très simplement, et sur lequel j'ajouterai des modules facultatifs. Ainsi ceux qui sont intéréssés par un aspect ou un autre pourront utiliser uniquement telle ou telle partie des idées :) Je vais donc poster au fur et à mesure l'évolution de mes réalisations, et quand une partie sera complète, je ferai un tuto bien propre!

Du coup, ceux qui veulent utiliser le pi en vidéosurveillance, mais sans électronique, pourront par exemple ignorer la partie inteface avec les boutons physiques, pour se concentrer uniquement sur les tutos sur l'installation, et la programmation de scripts adaptés...

A bientôt pour de nouvelles aventures, donc :)

[Yaug]

Cool de voir tes projets revenir.

Par contre, pour les reportages, je crois que tes liens ne mènent plus vers les reportages que tu souhaitais.

Ou alors j'ai pas trop saisie ce que tu voulais montrer

En tout cas félicitation Docteur !

[sky99]

Cool de voir tes projets revenir.

Par contre, pour les reportages, je crois que tes liens ne mènent plus vers les reportages que tu souhaitais.

Ou alors j'ai pas trop saisie ce que tu voulais montrer

En tout cas félicitation Docteur !

Salut!

En effet, les liens sont valables une semaine sur pluzz.fr ^^

Si ça t'intéresse, je peux t'envoyer un lien en PM :)

Sinon, la je travaille sur le projet PiCam, mais je crois que ça va m'obliger à faire plusieurs modules utiles pour d'autres projets.

Par exemple : gérer l'allumage/extinction d'un pi. C'est tout con, mais pour un système branché sur batterie, on en a besoin. Par défaut, il faut faire un sudo shutdown pour eteindre le pi;

et il consomme toujours, une fois le shutdown fait. Je veux donc faire un système avec un bouton qui lance le shutdown, puis coupe l'alimentation au bon moment, et qui dans l'autre sens, alimente le pi quand nécessaire pour l'allumer.

De même, un petit module d'interface, pour contrôler le pi avec des boutons, et un petit LCD pour afficher les infos importantes sera utile :)

[Nitro-TecK]

Salut Sky,

Félicitation pour tout en tout cas et dommage pour ton oral en vidéo

Sinon je réagis par rapport à l'allumage et l'extinction du PI car j'avais fais les même recherches, et j'ai donc 2 liens qui te seront j'espère utile :

http://electronics.stackexchange.com/questions/61877/shutdown-controller-for-raspberry-pi-in-a-car

http://www.mausberrycircuits.com/

J'espère que celà te sera utile.

Bon courage pour la suite.

[sky99]

Fabrication d'une caméra basée sur le Pi - premiers essais

Pour faire quelques essais, j'ai commencé par un prototype dans une boite en carton. J'ai récupéré un carton d'une précédente commande, et j'y ai installé le pi, un hub USB fournissant l'alimentation électrique (via un transfo secteur) et j'ai fait des trous pour faire passer les câbles (ethernet et alim), mais également de l'autre coté pour la camera.

J'installe le module caméra, et je le fixe avec du ruban adhesif papier, dit "ruban de masquage".

Pourquoi? parceque ça ne laisse pas de colle sur le circuit, et ça se déchire à la main.

Sur ce, je boote, et je peux tester le fonctionnement.

Pour cela, j'utilise raspistill:

raspistill -t 0 -n -o test.jpg -vf

j'utilise -vf pour retourner l'image verticalement, car mon module caméra est monté " a l'envers".

Tout fonctionne bien, j'ai accès à la photo.

Du coup, je fais un petit script, pour pouvoir prendre une photo :

#!/bin/bashtimestamp=`date +%s`output="pic_"output=$output$timestamp".jpg"raspistill -t 0 -n -o /home/pi/code/media/$output -vf

Ce script prend simplement une photo, en créant un nouveau fichier à chaque fois. le nom du fichier sera le timestamp unix du moment de la photo, on aura donc les fichiers dans un ordre chronologique, avec une indication du moment de la prise.

Pour prendre une photo, il me suffit alors tout simplement de lancer le script, en faisant:

sh pic.sh#ou bienbash pic.sh#ou encore si l'on a fait un chmod pour rendre le script executable :./pic.sh 

Puisque nous y sommes, pourquoi ne pas faire un script permettant de prendre N prises de vues, pour faire du timelapse?

en voici un simple, qui prend en argument le nombre de prises de vue à faire :

#!/bin/bashif [ "$#" -lt 1 ]then    echo "Missing argument : number of pictures to take"else    i=0    while [ $i != $1 ]; do        i=`expr $i + 1`        echo "image $i"	sh /home/pi/code/media/pic.sh    donefi

(je rédige mes codes et messages dans les programmes en anglais, mais n'hésitez pas à changer pour du français : il suffit de remplacer ce qui est entre guillemnts! )

Ce script se lance via :

bash timeLapse.sh N

ou N est le nombre de prises de vues souhaitées.

A cette étape, nous avons donc une boite capable de prendre des photos si l'on tape une ligne de commande. C'est pas mal, et l'aspect timeLapse peut déjà servir tel quel, puisque vous pourrez prendre autant de photos que souhaité, pourvu que l'alimentation électrique soit fournie. En montant l'ensemble dans une boite transparante, vous pouvez faire une installation waterproof, utilisable en extérieur.

Cependant, pour ma part, ce n'est pas encore suffisant, je veux aller plus avant, en rendant le dispositif plus "user friendly".

C'est ce que nous ferons dans le prochain post :)

[sky99]

Fabrication d'une caméra basée sur le Pi - premiers essais

Passons maintenant à la réalisation d'une première interface utilisateur. Par cela, je ne veux pas dire un affichage graphique, mais des boutons pour interagir avec la caméra.

Puisque nous cherchons à tester des idées, on va partir sur des bases simples.

Donc pour l'instant, l'interface sera composée de plusieurs boutons :

des bouton poussoir, et un interrupteur.

Les boutons poussoirs nous serviront à faire une action à chaque appui, et

l'interrupteur à activer une fonction jusqu'à ce qu'on le remette en off.

J'ai fait un schema avec Fritzing, sur lequel j'inclus également une LED RGB qu'on pourra utiliser plus tard pour afficher ce que fait la camera :

Je n'inclus pas tout dans ce premier prototype, on va se contenter de 3 boutons : un power, un photo, et un timelapse pour le moment. On verra également plus tard pour la LED d'état.

Je fais donc un petit montage :

-

L'objectif sera maintenant de faire un petit programme qui lit les boutons et qui effectue une action quand on appuie dessus. Comme action, on pourra par exemple exécuter notre script pic.sh!

Voici par exemple un script :

#!/usr/bin/env python from time import sleepimport osimport RPi.GPIO as GPIO GPIO.setmode(GPIO.BCM)GPIO.setup(17, GPIO.IN) while True:        if ( GPIO.input(17) == False ):                inputval = GPIO.input(17)                os.system('bash /home/pi/code/media/pic.sh')        sleep(0.1);

on exécutera le script ainsi :

sudo python readButton.py

Dès lors, lorsque l'on appuie sur le bouton, une photo est prise.

Je crée également un petit script shutdown.sh pour arrêter la machine :

#!/bin/bashshutdown now

Je mets alors à jour le script lisant les boutons :

#!/usr/bin/env pythonfrom time import sleepimport osimport RPi.GPIO as GPIOGPIO.setmode(GPIO.BCM)GPIO.setup(17, GPIO.IN)GPIO.setup(22, GPIO.IN)GPIO.setup(23, GPIO.IN) while True:        if ( GPIO.input(17) == False ):                os.system('bash /home/pi/code/media/pic.sh')                inputval = GPIO.input(17)                sleep(0.1);        if ( GPIO.input(22) == False ):                os.system('bash /home/pi/code/media/pic.sh')                inputval = GPIO.input(17)                sleep(0.1);        if ( GPIO.input(23) == False ):                os.system('bash /home/pi/code/media/shutdown.sh')                inputval = GPIO.input(23)                sleep(0.1);        sleep(0.1);

Le gros bouton est un interrupteur : en effet, quand on appuie dessus, il reste enfoncé, et il faut rappuyer pour qu'il ne soit plus enfoncé.

Du coup, en faisant ainsi, j'appuie une fois, et la caméra commence à prendre des photos, jusqu'à ce que je rappuie. ça permet en fait de faire un timelapse sans taper de commande et de paramètres :)

Problème : il faut encore lancer le script, ce qui n'est pas pratique si on est loin d'un PC!

On va donc faire un service afin que ce programme s'exécute automatiquement au démarrage:

#! /bin/sh# /etc/init.d/stillpic### BEGIN INIT INFO# Provides:          stillpic# Required-Start:    $local_fs # Required-Stop:     $local_fs# Default-Start:     2 3 4 5# Default-Stop:      0 1 6# Short-Description: stillpic daemon# Description:       takes a picture when the button is pusshed### END INIT INFO# Some things that run always#touch /var/lock/stillpicscript="/home/pi/code/media/readButtonSimple3.py"# Carry out specific functions when asked to by the systemcase "$1" in  start)    echo "Starting script stillpic "    sudo python $script &    ;;  stop)    echo "Stopping script stillpic with pid $PID"    sudo kill -s 9 `ps -eo pid,cmd | grep "python $script" -m 2 | cut -d ' ' -f 1`    ;;  *)    echo "Usage: /etc/init.d/stillpic {start|stop}"    exit 1    ;;esacexit 0

On enregistre ceci dans /etc/init.d/stillpic, puis exécute la commande suivante pour "installer le service", et pouvoir le démarrer/arrêter avec start et stop :

sudo update-rc.d stillpic start 20 2 3 4 5 . stop 80 0 1 6 .

On peut alors faire :

sudo /etc/init.d/stillpic start

pour demarrer le script.

Pour l'arrêter malheureusement, le stop ne fonctionne pas bien, il faudra faire un

sudo killall python

Quand j'aurai trouvé comment faire un vrai stop propre, je mettrai à jour.

Dans tous les cas, maintenant, au démarrage, le script se lance et vous pourrez donc prendre des photos et faire du timelapse.

Encore une fois, on verra plus tard pour la vidéo.

Le troisième bouton sert à arrêter proprement le pi.
Pour l'instant,il arrête le système, ce qui permet d'éviter la corrpution de données qu'on risque

en débranchant brutalement le pi. Toutefois, le pi "arrêté" consomme toujours autant qu'en idle,

il faudra donc soit le débrancher, soit rajouter une solution pour couper l'alimentation automatiquement.

Par exemple, les liens proposés par Nitro-Teck le permettent. Pour ma part, je vais opter

pour une temporisation : quand on appuie sur le bouton, le pi fait son shutdown, puis enverra

un signal à une puce contrôlant l'alimentation, qui la coupera environ une minute après.

La suite au prochain épisode :)

[kaptainjp]

Bonjour,

Félicitation pour tous ces beaux articles sur le raspberry.

J'ai une compétence très très réduite en électronique mais j'ai un projet. Je me heurte à des questions sur des limites de faisabilité.

L'énoncé est le suivant : je souhaite mesurer la vitesse et surtout la position d'une boule de bowling sur la piste.

Mesurer la vitesse semble réalisable avec 2 détecteurs de passage distants.

Déterminer la position de la boule est un autre sujet. Une piste de bowling est constitué de 39 lattes de bois de 1 pouce de large. Je veux savoir sur quelle latte passe la boule.

Une technique possible et existante serait de mettre un portique au dessus de la piste et d'y adjoindre 39 détecteurs mais cela n'est pas pratique et cela ne peut pas rester à demeure.

J'ai pensé à mettre un détecteur ultrason d'un côté de la piste et mesurer au passage de la boule. A l'arrêt, cela semble jouable facilement mais en situation de jeu, j'ai un doute sur la capacité de prendre la mesure correctement.

J'ai fait quelques calculs : une boule de bowling fait 22cm de diamètre. La surface "utile" pour la mesure est de 10cm, elle va passer à 30km/h soit 8m/s. Il faut donc réaliser la mesure en 1/80 seconde. Afin d'être sûr de la mesure, il faudrait peut être en faire plusieurs dans ce laps de temps.

Est ce que cela serait jouable avec un HC-SR04? ou avec autre chose? ou une autre idée?

[RaphAstronome]

Je ne suis pas particulièrement connaisseur de ce genre de chose mais une camera filmant la scène d'en haut ne pourrait pas détecter la boule et calculer son mouvement ?

Après il faut avoir assez de contraste entre la boule et la piste ainsi que suffisamment de puissance de traitement.

[kaptainjp]

Je veux que le système reste discret donc une caméra au dessus ça va pas être terrible.

Donc, le système serait composé de 2 faisceaux laser et une sonde ultrasonique.

_________________________________________

Joueur L1 U1 L2 Quille

_________________________________________

Quand la boule commence à couper le laser L2, cela signifie que la partie "ventrue" de la boule commence à passer devant la sonde U1 : donc on déclenche la prise de mesure jusqu'à ce que la boule cesse de couper la laser L1( ce qui signifie que l'on quitte la partie ventrue de la boule.

Pour les faisceaux de détection de passage, que me conseillez vous comme composants (pas trop cher) efficaces pour le principe énoncé ci dessus?

NB: j'ai commandé mon raspberry et une sonde HC-SR04.

[sky99]

Bonjour!

Il existe des détecteurs ultrasons à plus ou moins longue portée.

Par exemple : http://www.adafruit.com/products/985

Celui la a une portée de 5m, il en faudrait donc 8 pour couvrir une distance de 40m.

Je pense que ce serait possible, mais il faudra régler plusieurs problèmes :

• placer les capteurs sur la piste
• faire arriver le fil jusqu'aux capteurs
• gérer les possibles interférences
• gérer la largeur du faisceau.

J'ai trouvé un schéma montrant l'angle de détection du HC-SR04, et le problème, c'est que

ces capteurs ne détectent pas uniquement en ligne droite, mais dans un cône. Du coup il faudra voir ce qu'il

se passe avec les bords de la piste, ou les objets alentours.

En revanche, une solution pratique, économique, efficace et potentiellement précise pourrait être d'utiliser une

caméra.

En effet, en prenant un raspberry pi et un module caméra, il est possible de faire un petit boitier de la taille

d'un disque dur 2.5", en plus épais (disons 10*8*4cm), incluant le module caméra, le pi, une clé wifi, et

permettant de faire un traitement très précis. il est possible de rendre l'ensemble très discret, et communiquant par wifi.

Le seule problème sera de trouver une source d'alimentation, mais des solutions sont possibles (batterie, prendre

du courant sur le plafonier, faire passer des fils avec une gaine transparante et amenant du +5V et la masse, etc).

Dans le post, tu parles de lasers. C'est en effet LA solution pour cette application, mais pas forcément dans le sens

ou tu l'entends.

Avec un télémetre laser, on peut en effet mesurer une longueur jusqu'à une distance importante, avec une précision

millimétrique.

Le problème est le coût de tels composants, au moins 100-200$.

Une autre solution serait de faire ce dont tu parles, avec des faisceaux qui seront coupés par la boule.

Dans ce cas, le plus simple, économique, et sur serait d'utiliser non pas des lasers, mais des couples emetteur-récepteur

infrarouge.

Lorsque l'espace entre les deux est dégagé, le faisceau est capté. Quand ce n'est plus le cas, l'obstacle est devant.

On s'en sort pour un coût très faible, puisqu'une diode IR adaptée coûterait environ 1€ max, et le récepteur 2-3€ au plus.

L’inconvénient par rapport aux lasers, c'est que l’émission se fait sur un cône. Toutefois, on peut trouver des systèmes permettant

de guider la lumière, et vu la largeur de la piste, ça ne devrait pas être trop dur. Le laser aurait pour avantage d'être quasi totalement

cylindrique, et donc de ne pas s'élargir significativement. En revanche, un émetteur laser est plus cher (5-6$), et on doit prendre des

précautions pour ne pas avoir de reflets vers les yeux des usagers, selon la puissance.

La diode IR ne présente pas ces défauts.

En revanche, avec un laser, on peut viser un point très précis, et donc on peut facilement faire un montage avec une photorésistance

comme récepteur. A 1m, il ne devrait pas être trop difficile de viser un cercle de 5mm de rayon, et une photorésistance, ça vaut quelques

centimes, et c'est très facile à utiliser.

Pour revenir aux questions de ton premier post , je pense que le capteur ultrasons risque de ne pas aller, si tu veux plusieurs mesures pour le passage

de la boule, car en 1/80s, ça laisse peu de temps pour ce type de capteur. Le signal se déplace à la vitesse du son, soit environ 300m/s.

Il faut donc déja 1/300 de seconde pour parcourir 1m aller retour, plus du temps pour le traitement. ça reste envisageable, mais pas 50 mesures. Mon capteur fonctionne lui a 20Hz, donc pas assez vite pour une application du genre. Il faut voir le tien, si sa fréquence de rafraichissement permet de faire ce que tu souhaites.
pour ma part, je pense que les faisceaux avec les détecteurs suffisent.

SI on a 3 capteurs de ce type, on peut calculer la vitesse sur une première portion, puis la vitesse sur une seconde portion. Ainsi, on peut calculer la force générée par le frottement. Du coup, connaissant ça, deux capteurs suffisent, et on peut alors calculer la position et la vitesse de la boule, puisque c'est une trajectoire linéaire. Comme on a la gravité et le frottement qui s'exerce, et la gravité est compensée par la réaction du support, on a donc quelques calculs simples, en appliquant des lois physiques simples.

Une autre approche serait, si la surface est assez uniforme, d'utiliser des accéléromètres ou des microphones pour analyser les vibrations de la boule,

et en triangulant, calculer la position de la boule. ça se fait aussi, avec un peu de traitements, de callibrage et de calculs.

J'espère avoir pu t'être utile :)

Oups, j'ai lu 40m, au lieu de 40 pouces.

si on a 40 pouces, un pouce faisant environ 2.6cm, ça fait 40*2.6=104cm?!

1m04 ça me semble court pour une piste de booling!

A mon avis, tu dois vouloir dire 40 pieds?

dans ce cas, la piste mesure 1287cm, disons 13m.

Dans ce cas si on place les capteurs presque dans l'axe, il en faut deux voire 3, et on

peut mesurer ainsi la position et la vitesse de la boule dans l'axe.

reste à vérifier si la fréquence de rafraîchissement suffit, mais ça doit être gérable!

En plus on peut sans doute trouver un capteur capable de faire 10-12m.

[kaptainjp]

Non, je confirme 39 pouces

Une piste de bowling fait "aux arrondis de conversion près" 19m de long sur 1m de large (soit 39 pouces).

une piste de bowling est constituée de 39 lattes de bois d'un pouce de large. La technique de jeu est basée sur la précision et la régularité à passer sur les flèches (cf image ci dessous).

La mesure a effectué est donc "en travers" de la piste pour déterminer sur quelle latte passe la boule au niveau des flèches. Quand la boule entre dans la zone "fleche", on déclenche une prise de mesure pour déterminer la distance entre l'appareil et la boule et par déduction obtenir la latte sur laquelle se trouve la boule. Quand la boule sort de la zone, on arrête de prendre les mesures et on fait le tri de toutes les mesures prises pour ne garder que les valeurs cohérentes (<1m , donc indiquant la présence d'un élément sur la piste) :

exemple :

1,12

1,13

1,12

1,12

0,75

0,70

0,69

0,70

0,68

0,73

0,79

1,12

1,13

on prend la plus petite valeur et on garde les valeurs entre (lapluspetite <= valeur <= lapluspetite + 4cm) et on fait la moyenne.

Je viens de recevoir mon raspberry et j'attend le capteur pour faire les premiers essais en statique avec le HC-SR04.

To be continued...

[sky99]

Salut!

Désolé, j'avais compris dans l'autre sens. En fait, la position de la boule dans le sens de la longueur t'importe peu, mais dans le sens de la largeur, afin de savoir si on a bien visé? Je pensais que les lattes étaient transversales par rapport à la trajectoire de la boule.

Du coup ça simplifie ou complexifie le problème sur certains aspects...

Si le but est de savoir au niveau des flèches sur quelle latte on se trouve, ça pourrait être plus simple, puisqu'il suffit de détecter la distance au passage,

par un rayon/echo ultrason perpendiculaire.

Le problème c'est la précision.

Pour le HC-SR04 je trouve une résolution de 0.3cm, mais quelle est la précision de la mesure?

Si on part sur une précision équivalente, ça devrait aller.

Il faudra sans doute faire un peu de boulot pour débruiter les mesures, vu la forme de la piste.

Par contre un problème se pose : si je tire en diagonale, je peux partir dans la goutière, et être au milieu

au moment ou je passe dans le capteur!

Il faudrait donc idéalement deux jeux de capteurs, pour pouvoir déterminer la variation de distance latérale, et ainsi calculer la trajectoire.

Au passage, attention avec ce capteur, il fonctionne en 5V, alors que les GPIO fonctionnent en 3.3V. Pour lire les valeurs il faudra donc baisser la tension du signal logique haut à 3.3V ou moins. Selon les specs, on ne peut pas alimenter le composant en 3.3V, il faut au moins 4.5V.

Attention, car ça peut griller les GPIO si ils reçoivent du 5V au lieu de 3.3V.

Une solution c'est de mettre un petit transistor qui laisse passer ou non du 3.3V vers le GPIO, et commandé par la sortie 5V du HC-SR04.

Si tu veux un coup de main fais moi signe :)

[kaptainjp]

Bonjour,

Merci pour les infos. J'ai trouvé un schéma pour brancher le capteur sur les GPIO qui utilise 2 résistances 330Ohm et 470Ohm pour réduire la tension. Cela suffira-t-il?

En ce qui concerne la trajectoire de la boule, les joueurs de bowling utilsent 2 types de boules : une boule réactive qui a une trajectoire en arc de cercle pour tenter le strike et une boule neutre pour aller en ligne droite pour faire tomber les quilles restantes. Donc, la boule ne passera pas forcément dans l'axe, bien au contraire (ex :

)...

Pour le problème de trajectoire, c'est la deuxième partie du projet qui consistera à mettre 2 voire 3 appareils tout au long de la piste.

To be continued (j'attend toujours la livraison du capteur...)

Merci.

[youri_1er]

Bonjour à tous,

Je découvre ce sujet très intéressant, je pense que je vais y passer un petit moment!

Pour le moment avec mon RPi j'ai pus faire quelque chose de vraiment utile pour moi ... débriquer mon Pogoplug V2!

Il est possible d'utiliser OpenOCD sur le Rpi et donc d'en faire un module Jtag, comme il est possible d'utiliser le port série de la bête, et ça tombe bien car pour reflasher un pogoplug c'est tout ce qu'il nous faut.

Pour OpenOCD l'on utilisera les commandes suivantes :

sudo apt-get update
sudo apt-get install -y autoconf libtool libftdi-dev libusb-1.0.0-dev

prenez le lien Git sur la page suivante puis:

cd openocd-git

puis :

./bootstrap
./configure --enable-sysfsgpio\
     --enable-maintainer-mode \
     --disable-werror \
     --enable-libftdi \
     --enable-ep93xx \
     --enable-at91rm9200 \
     --enable-usbprog \
     --enable-presto_libftdi \
     --enable-jlink \
     --enable-vsllink \
     --enable-rlink \
     --enable-arm-jtag-ew \
     --enable-dummy \
     --enable-buspirate \
     --enable-ulink \
     --enable-presto_libftdi \
     --enable-usb_blaster_libftdi \
     --prefix=/usr

Et enfin

make
sudo make install
sudo cp -r tcl/ /usr/share/openocd

OpenOCD s'utilise avec un fichier de config dans lequel il faudra penser à inclure la ligne suivante au début :

source [find interface/sysfsgpio-raspberrypi.cfg]

et le tout se branche suivant l'information fournis lors du lancement de openOCD avec un fichier de config comme indiqué ci dessus:

openocd -s /usr/share/openocd -f raspberrypi.cfg

dans mon cas :

SysfsGPIO nums: tck = 11, tms = 25, tdi = 10, tdi = 9
SysfsGPIO num: trst = 7

Pour la partie port série c'est bien plus simple, il suffit d'installer son plus bel outils de lecture de port série tel que minicom ou picocom et d'utiliser la connexion disponible sur les PIN 8 (TXD) et 10(RXD) en veillant à brancher la masse si besoin (pin 6) et l'alimentation sur les pin 1(3.3v) ou 2(5v) suivant la tension désiré.

Ce port permet une communication dans les deux sens, et donc cela peu s'avérer utile pour débuger un boot qui ne marche pas tan sur le Rpi que sur tout autre PC (notament le Pogoplug dans mon cas).

Voila, je n'ai pas lu tout le sujet donc j'espère ne pas faire doublon, et que ce sera utile, mais je pense que ceci pourrait permettre à certain de se lancer, avec le Rpi, dans la programmation de puces (PIC32) et donc dans des projets de plus grande envergure:

https://code.google.com/p/picnc/wiki/OpenOCD_PIC32_Programmer

[sky99]

Bonjour,

Merci pour les infos. J'ai trouvé un schéma pour brancher le capteur sur les GPIO qui utilise 2 résistances 330Ohm et 470Ohm pour réduire la tension. Cela suffira-t-il?

En ce qui concerne la trajectoire de la boule, les joueurs de bowling utilsent 2 types de boules : une boule réactive qui a une trajectoire en arc de cercle pour tenter le strike et une boule neutre pour aller en ligne droite pour faire tomber les quilles restantes. Donc, la boule ne passera pas forcément dans l'axe, bien au contraire (ex : http://www.youtube.com/watch?v=x-JDJCJRApA)...

Pour le problème de trajectoire, c'est la deuxième partie du projet qui consistera à mettre 2 voire 3 appareils tout au long de la piste.

To be continued (j'attend toujours la livraison du capteur...)

Merci.

Pour les résistances, si c'est bien dimensionné, ça devrait protéger les GPIO. Maintenant c'est à tester, car j'ai lu que sur

certains circuits avec des timings très élevés, ça peut générer des variations sur le signal et donc du bruit (pas de risque,

mais des mesures peut être faussées).

Maintenant, si ça passe, c'est que tout va bien, à priori :)

Sur la trajectoire, si elle est rectiligne c'est simple, puisqu'il suffit de calculer le vecteur d'accélération de la boule et connaitre

sa vitesse initiale, et tout va bien. Maintenant avec une trajectoire courbe ça complique singulièrement :)

Sauf si on peut établir un/des modèles, après tout une boule de bowling a une certaine inertie, et j'imagine que l'ensemble

doit varier de trajectoire difficilement, donc pas de changements brusques à petite échelle...

Mais du coup la caméra me parait encore plus adaptée :)

Bonjour à tous,

Je découvre ce sujet très intéressant, je pense que je vais y passer un petit moment!

Pour le moment avec mon RPi j'ai pus faire quelque chose de vraiment utile pour moi ... débriquer mon Pogoplug V2!

(...)

https://code.google.com/p/picnc/wiki/OpenOCD_PIC32_Programmer

Super, je t'ajoute dans la liste des tutos :)

Au passage c'est une bonne idée, j'avais pensé à utiliser un Arduino pour parler à des périphériques (routeur, modem, etc)

en mode série, mais pas à utiliser le pi pour ça... Or c'est très logique, vu qu'on peut avoir un shell, taper des commandes,

etc...