vendredi 27 mai 2011

/Flash: Bilan après quelques 500km

Un bilan s'impose après plus de 500km en compagnie de la dernière release du proto de l'avertisseur radar.

Tout d'abord, je me suis rendu compte que la version 0.83 diffusée n'était pas la bonne ... la faute au fait que je bosse sur plusieurs ordi en parallèle.
Je comptais donc re-uploader le fichier, mais je pense apporter quelques modifs suite à mon petit voyage.

Au titre des évols envisagées:
- le remplacement des LED par un buzzer fait apparaître un pb invisible (et surtout inaudible !) avec les LED: lorsque des trames GPS arrivent sur le port COM, il arrive parfois que ça grésille dans le buzzer. Il faut que je regarde ça. Les premières investigations ne semblent pas mettre en cause des parasitages, mais plutôt des lourdeurs dans les traitements, qui font que le traitement des trames prend trop de temps, et "déborde" sur les temps d'émission des bips.

- Lorsqu'on roule sur des axes rapides urbains (périph, rocades), on se fiche un peu d'être prévenus des radars feu: il y a tout de même rarement des feux sur les axes à 110km/h. Un traitement particulier va être rajouté.

- en complément du point ci-dessus, je vais même peut-être purement ne pas prendre en compte les radar feux si la vitesse GPS est supérieure à un seuil (80km/h par exemple), et forcer des extracts en cas de franchissement du seuil. Un extract de radar de la BDD prend dans les 350m à 130km/h en province (bdd de 1790 radar), il y a donc peu de chance pour qu'un radar passe à la trappe, surtout sur des vitesses inférieures, mais ça m'est arrivé ...

- sur les zones super chargées (IDF surtout), il y a largement plus de 10 radar sur la zone d'extract. Hors actuellement je relance un extract en BDD seulement lorsque la position GPS arrive en limite du bord de zone. Il faut que je modifie le bord de zone afin qu'il soit ramené au 10 ieme radar le plus loin, et pas systématiquement à la valeur théorique.

Je pensais partir sur la version 1 de /Flash après ces quelques km, mais une nouvelle version du proto va voir le jour.

/Flash: les fichiers radar

Voici les fichiers radar:

Nouvelle version de la BDD Ile de France, datée du 27/05.


Liste des radar en Ile de France, daté du 27/05/2011

Liste des radar sur le reste de la France, daté du 04/05/2011

Cette liste est extraite d'une "souche" provenant de la liste des radar fournis par gpspassion.com (base de radar en version standard d'octobre 2010) et disponible ici
De cette base ont été supprimés tous les radar mobiles (il y en a 12000 !), puis quelques-uns ont été rajoutés, au gré de mes besoins.

Dans les 2 listes de radar utilisés dans mon avertisseur, seul le paramètre 'vitesse' est inutilisé aujourd'hui.
Une explication sur le contenu de ces fichiers a été faite dans un billet précédent

mardi 17 mai 2011

/Flash: Explications sur le code

Voici, dans les grandes lignes, l'approche que j'ai retenu pour réaliser mon avertisseur sonore ...

L'exploitation des radar en base de données se fait de la façon suivante:
1- On extrait un nombre de radar max (défini à 10 pour l'Arduino 2009, car l'Arduino plante au dessus. On doit s'approcher du max de consommation de RAM) les plus proches de la position actuelle GPS.

L'extract est limitée à une zone autour de la position actuelle, définie à 0.18° (soit environ 15km²)
et réduite à 0.08° (soit environ 7km²) sur l'Ile de France car il y a beaucoup de radar, ce qui provoque des temps de traitement trop long pour que l'avertisseur soit réactif.
Si la zone d'extract n'entraine pas un extract de 10 radar, on n'aggrandit pas la zone de recherche
(inutile de prévenir le conducteur s'il y a des radar à 50km).
Ce point est traité dans la fonction 'extract_liste_rdr

2- Lorsque la zone est extraite, l'avertisseur calcule en permanence la distance véhicule-radar la plus faible et prévient le conducteur si certaines conditions sont remplies:
- le véhicule se rapproche du radar
- le véhicule se dirige vers le radar, avec un cone d'approximation
- le véhicule est à une distance raisonnable du radar, distance dépendant du type de radar
- le véhicule n'est pas arrêté (histoire de ne pas être inondé de bip lorsque le feu est rouge ou dans les bouchons)
Ce point est traité dans la fonction 'calc_distance_rdr'


3- Lorsque le véhicule se rapproche du bord de la zone d'extraction, une nouvelle extraction est lancée.
Deux critères définissent le déclenchement de ce nouvel extract:
- la distance par rapport au bord de la zone, définie à 2,5km sur l'IDF
- l'écart mini entre la pos actuelle du véhicule et le radar, défini à 1,5km sur l'IDF

Si on passe sous la distance mini ET que l'écart avec le radar le plus proche est supérieur à l'écart min, on lance un nouveau calcul.
Le calcul est effectué dans la fonction 'calc_distance_bord_zone' et la décision est prise dans la fonction 'calc_distance_rdr'

La fonction 'recup_trame_gps' lit le port série pour récupérer la position GPS.
En cas de perte de trame ou de récupération erronée, la fonction attend 10 secondes avant de faire savoir qu'il y a un problème (en arrêtant de prévenir le conducteur de la proximité d'un éventuel radar).
A l'avenir, dans ce cas de figure, la position du véhicule sera rafraîchie par projection. Cela permettra de prévenir d'une éventuelle présence de radar dans un tunnel par exemple.

La fonction 'buzzer' permet de prévenir le conducteur en fonction du type et de la distance du radar

Enfin, les fonctions 'writeString' et 'writeNumber' permettent de logguer des infos sur la carte SD: axe des radar, et, pour contrôle, la liste des radar extraits dans la fonction 'extract_liste_rdrainsi que la position du véhicule lors de l'extraction.

samedi 14 mai 2011

GraarduiCut: Cherche moteurs déserpérément

Comme indiqué dans le premier billet consacré à GraarduiCut, les moteurs de propulsion ne sont pas du tout adaptés: rotation trop rapide, pas assez de couple.

J'ai surfé sur le web, à la recherche de moteurs dans le genre de ce qu'on trouve sur les quads des enfants.
Sur le quad de mon fils, il y a un moteur pas plus grand que ceux actuellement montés sur GraarduiCut, équipés d'un réducteur balèse ...
Résultat, ça traine mon fils de 2 ans et demi, et j'ai même surpris ma fille de 7 ans assise avec mon fils, et le quad arrivait à les trainer (pour combien de temps ?).

J'avais donc pour objectif de me trouver 2 ex de ce genre de moteur.

Je ne peux même pas trainer dans les déchèteries: il me faut 2 moteurs identiques, et les quads n'en ont qu'un :-(


Autre piste:
des moteurs ayant une vitesse de rotation lente, style moteurs de lève-vitre.
Je n'ai par contre aucune idée de la conso de ces moteurs. Les équipements électriques des voitures sont rarement économes en énergie, ça me fait donc un peu peur.


Si vous avez des idées, n'hésitez pas à m'en faire part ...

mardi 10 mai 2011

GraarduiCut:Quelques photos

Mon proto de robot tondeuse est à l'image de la taille de mon jardin: petit :-)

Voici quelques photos de GraarduiCut:

Une vue générale du robot
vue générale du robot GraarduiCut

Les moteurs de propulsion
Vue sur les moteurs de propulsion de GraarduiCut


Les lames
Vue sur les lames de GraarduiCut


La partie électronique avec le moteur de lame en arrière plan
Vue sur le coeur de GraarduiCut: l'Arduino


Quelques chiffres:
GraarduiCut fait 42cm de large, roues comprises
la lame fait 20cm

/Flash: Le code du sketch

Ci-joint le code de l'avertisseur de radar.

La version courante est la 0.83.
Elle reprend donc les principales fonctionnalités décrites dans les billets précédents, et notamment dans celui-ci.

Le code est téléchargeable ici:
Version 0.83

dimanche 8 mai 2011

Robot tondeuse: Le concept "GraarduiCut"

GraarduiCut: Grass Arduino Cutter ;-)
L'idée est de concevoir une tondeuse robot autonome, low-cost.
Le coeur du robot est bien-sûr un Arduino (2009, mais un Uno ferait tout aussi bien l'affaire)

Je suis donc parti sur une plateforme toute simple en contre-plaqué, 2 roues motorisées à l'arrière, 2 roues folles à l'avant sur amortisseur, de simples contacts à l'avant, une lame de coupe.

Les moteurs de propulsion sont des moteurs RS-5404SH équipés de réducteurs (il faudrait que je calcule le rapport de réduction)
.
Le moteur de la lame est un moteur de petite perceuse.

Les moteurs sont pilotés par un pont en H intégré: le L298.


La tondeuse fonctionne, si ce n'est que les moteurs de propulsion ont un couple trop faible pour promener le robot lorsque la pelouse est haute (la hauteur étant toute relative). Je contourne le pb en affectant une valeur forte à mon PWM, ce qui fait que le robot trace comme un malade lorsque la pelouse est courte ... et se tape donc les obstacles à une vitesse vertigineuse.


La priorité est donc de mettre la main sur des moteurs avec un facteur de réduction important, et un couple plus adapté, et de changer l'étage de commande, car le pont en H est franchement trop juste ...

Idéalement, des moteurs utilisés dans les quads électriques des gamins seraient tout à fait adaptés: ils doivent avoir un couple tout de même assez important pour pouvoir trainer un mini biker de 20-30kg, et ne pas trop consommer: mon fils à un de ces quads avec un moteur en 6 volts, équipé d'une batterie pas très puissante, et à quand même une bonne autonomie.

Aujourd'hui, le robot se contente d'aller (à peu près) droit devant lui, de rebondir contre les obstacles, et de reprendre sa route.

Les évolutions attendues dès que j'aurai mis la main sur des moteurs:
- détecter la présence de la pelouse, afin d'éviter d'aller se balader sur la terrasse
- détecter le niveau de batterie pour couper le jus à temps dans un premier temps ...
- ... et retrouver sa base dans un second temps (mais là, va y avoir du boulot !)
- détecter une éventuelle averse, pour éviter de sortir quand le temps n'est pas adapté à une tonte
- détecter le niveau de luminosité, afin de programmer des sorties de nuit, quand les enfants sont couchés et ne risquent pas de se mettre les pieds et les doigts dans les lames ...

A bientôt donc pour la suite de l'aventure ...

Finalisation du proto ...

Après pas mal de km de tests, le proto de l'avertisseur de radar a encore bénéficié de quelques modifications.

Pêle-mêle:

  • C'est bien parti pour rester sur un avertisseur de radar à base de buzzer: les LED obligeaient de jeter un oeil permanent pour savoir s'il y avait un risque. Le buzzer prévient désormais de la manière suivante:
    1 bip: avertisseur de radar fixe
    2 bips: avertisseur de radar mobile
    3 bips: avertisseur de radar feu

    Il y a une petite inversion dans l'ordre des radar depuis mon dernier billet. La raison est purement pratique: dans la majorité des cas, j'ai affaire soit à des radar fixe, soit à des radar feux. Distinguer 3 bips d'1 seul est plus simple de que 2.
    J'ai par ailleurs franchement allégé la base de données concernant ces foutus radar mobiles, sinon l'avertisseur n'arrête pas de sonner. En plus, comme je ne fais pas franchement d'excès de vitesse, ça ne me sert pas à grand chose (d'autant que les radar mobiles sont plus tolérants en terme d'excès de vitesse ...)

  • L'avertisseur de radar émet un son sous certaines conditions:
    - il faut rouler (à plus de 7km/h)
    - il faut s'approcher du radar
    - il faut être dans l'axe du radar (à + ou - 10° près, ce qui pourrait bien être revu à la baisse si ça sonne de trop)
    - il faut être à moins de 500m d'un radar feu, et à moins de 1000m d'un radar fixe ou mobile

    Pb résiduel: un radar fixé situé sur une route parallèle à moins de 1000 mètres provoquera une alerte. Il faudrait rajouter un contrôle sur le relèvement

  • Pour améliorer les performances sur l'Ile de France (où il y a pas mal de radar), la base de données à été séparée en 2.

  • Pour permettre de mettre à jour les caps des radar sans trop se prendre la tête, tous les radar "croisés" sur la route sont sauvegardés dans un fichier, avec le cap GPS.
Voilà pour les dernières news ... bientôt le code !