Aller au contenu


Sandro

Inscrit(e) (le) 30 déc. 2013
Déconnecté Dernière activité juil. 09 2021 05:59
*****

Sujets que j'ai initiés

Capteur de distance sans cross-talk

06 mai 2021 - 12:45

Bonjour,

 

Pour la détection de trous, j'ai laissé tombé la solution via la caméra de profondeur (autant elle est assez fiable pour détecter les obstacles, autant elle voit régulièrement des points "beaucoup plus loin" dans les surfaces lisses sans trop de texture, donc c'est galère de détecter les trous).

 

Du coup, je reviens à mon idée initiale, à savoir utiliser des capteurs de distances à faisceau étroit (capteur infrarouge probablement).

 

J'ai fait un test avec des capteurs "sharp" (similaires à https://www.robot-ma...a02yk0f-71.html, possible que ce soit même le même modèle). Le problème est que j'ai du cross-talk entre les capteurs  : quand je branche un seul capteur, j'ai un "peu" de bruit (un peu plus de 20cm entre le min et le max observée pour une distance fixe)  ; mais dès que je branche les deux en même temps, j'ai plus de 50cm entre le min et le max (pour la même distance fixe). Bref, c'est inexploitable.

 

Du coup, est-ce que vous connaissez des capteurs à faisceau "étroit" qui n'ont pas ce problème de cross-talk.

Mes contraintes sont les suivantes :

- pas de cross-talk (j'aurais entre 4 et 8 capteurs pointant en arc de cercle devant le robot)
- utilisable en outdoor même en plein soleil (les capteurs pointeront à 45° vers le bas).

- portée d'au moins 1.5m (en outdoor, y compris par temps ensoleillé). 2m serait un plus

- pour l'instant pas de contrainte d'étanchéité/résistance particules, mais si le capteur a un peu de protection, c'est un plus

- prix raisonnable (disons 25€ max par capteur, 35€ max s'il est IP54)

 

Est-ce que vous avez des idées?

Merci d'avance

Sandro

 


Détection de trous dans le sol avec une caméra de profondeur

27 avril 2021 - 03:40

Bonjour,

 

Au boulot, on a un robot équipé d'une caméra stéréo, qui nous fournit un nuage de points 3D (et une image de profondeur).

 

On s'en sert déjà pour détecter les obstacles "positifs" (ie qui dépassent du sol), ce qui marche assez bien.

 

Je voudrais maintenant faire l'inverse : détecter les obstacles négatifs, ie les "trous" dans le sol, pour que le robot s'arrête avant de tomber dans un escalier ou une marche ou une tranchée, ...

 

A première vue c'est facile : tous les points 3D qui sont en dessous du niveau du sol sont des trous.

En pratique, en tout cas avec ma caméra à 90cm de hauteur, ça ne marche pas bien du tout : j'ai énormément de faux positifs dues aux oscillations du robot.

 

Est-ce que vous avez une idée de comment identifier les trous dans ces conditions?

(si c'est une solution ROS, alors j'ai a disposition une depth image et un poincloud2, si c'est une idée d'algo,alors il "suffit" de l'implémenter)

 

Merci d'avance

Sandro


tubes aluminium et taraudage

11 avril 2021 - 11:43

Bonjour,

une autre question (cette fois-ci sans lien avec la robotique).

 

Je cherche à faire une petite tente de secours en forme de pavé droit (longueur 2.20m, largeur 1.5m, hauteur 1.5m), constitué d'une armature (toit rectangulaire et poteaux aux 4 coins) et recouverte ensuite d'un assemblage de couvertures de survies. Les coins sont fait à l'imprimante 3D

 

J'ai fait un rapide test avec des arceaux de tente, ça fonctionne, mais il y a risque que les arceaux du toit se séparent (car ils sont prévus pour être en compression, donc à la moindre traction ils se déboîtent). On peut sécuriser ça un peu avec un élastique à l'intérieur des arceaux et/ou avec du gros scotch pour relier les arceaux entre eux. Mais ces solutions ne me satisfont qu'à moitié.

De plus, les arceaux sont un peu trop élastiques à mon goût.

 

Je réfléchissais donc à la possibilité de remplacer les arceaux par des tubes en aluminium, ce qui est plus léger et plus rigide à diamètre égal que la fibre de verre.

 

Est-ce que vous pensez que des tubes de diamètre extérieur 6mm (intérieur 4mm, donc 1mm d'épaisseur) ferraient l'affaire?

 

Si oui, est-ce que vous pensez que je peux les tarauder en 5mm, de manière à les relier par des bouts de tige filetée M5? Ou est-ce que le tube est trop fin pour que ça tienne?

 

Merci d'avance

Sandro


fixer cylindre en impression 3D sur un axe 3mm

11 avril 2021 - 11:33

Bonjour,

Je suis en train de me remettre un peu sur mon projet de robot spéléo que j'ai délaissé pendant un bout de temps.

 

Un des premiers problèmes à résoudre pour reprendre les tests dans de bonnes conditions, c'est de remplacer les roues. Actuellement, j'ai des roues dures "crantées", qui sont simplement insérer "en force" sur les axes des moteurs. Vu qu'il ne faut que peu de force pour les insérer "en force", et vu que pour les 4 roues du haut, il y a environ 1/8 du poids du robot par roue en traction dans l'axe de la roue, j'ai régulièrement des roues qui tombent!

 

Un dernier problème est qu'actuellement, la roue est placée directement sur l'axe des moteurs (ce qui n'est pas bon pour le moteur, et fait que dans certaines configurations le moteur peut cogner contre la paroi.

 

 

Pour résoudre tous ces problèmes à la fois, j'ai décidé de mettre 2 roues par "bras" de mon robot au lieu d'une seule et de déporter le moteur via un engrenage à angle droit. Pour les roues, je voudrais tester avec un cylindre (en impression 3D probablement) recouvert de chambre à air de vélo.

 

Il me faut donc fixer deux cylindres en impression 3D sur un axe lisse de 3mm de diamètre : une particularité de mon robot est qu'il faut non seulement transmettre le couple (rotation), mais que j'ai en plus une force de l'ordre de 2.5N (250g force) en moyenne (disons pic : 10N (ie 1kg force)) parallèlement à l'axe.

 

Est-ce que vous avez une idée comment bloquer mon cylindre à la fois en rotation et en translation?

 

NB : je peux facilement limer les axes pour y ajouter un replat

 

Merci d'avance

Sandro


Communication arduino vers micro-ordi en environnement bruité

20 novembre 2020 - 05:37

Bonsoir,

J'ai un petit problème sur le robot du boulot : on a un micro-ordinateur muni d'un GPIO (Jetson Xavier AGX, c'est un peu comme une raspberry pi en beaucoup plus puissant), qui communique en I2C avec un arduino et (sur un autre bus I2C) avec un joystick.

 

Le problème est que les esclaves (arduino et joystick) sont assez loin du maitre (jetson), respectivement 1.5 et 2m. De surcroit, l'environnement est assez bruité (on a de gros moteurs DC dans le robot). Du coup, la communication I2C n'est pas très fiable :

 

1) Pour la communication avec le joystick, j'ai coté jetson des "crash" de l'I2C ("Resource temporarily unavailable"), mais si je redémarre le programme coté Jetson, il redémarre normalement. Je n'ai pas fais de tests plus en détail, pour l'instant j'ai juste fait un workarround qui fait que le temps de redémarrage ne pose pas de problème

 

2) Pour la communication entre la Jetson et l'arduino :

 

2.1) Initialement, aucune communication possible dès qu'on allumait les phares (bruit de 1V sur SDA et SCK) : résolu en rajoutant des condensateurs entre ground et +12V. Impossible de relancer le programme coté Jetson après un crash (crash immédiat).

 

2.2) Parfois l'Arduino tire SDA à 0V et ne relâche pas le bus : ça vient probablement d'un "bruit" dans le signal I2C qui fait qu'il ne respecte plus le standard. La librairie Wire de l'Arduino gérant très mal les erreurs se retrouve bloquée. Impossible de relancer le programme coté Jetson après un crash (crash immédiat). Un reset de l'Arduinopermet ensuite de relancer le programme coté Jetson

En implémentant un double whatchdog logiciel (basé sur timers) sur l'arduino (reset 10s après le boot si pas de signal I2C, reset 250ms après le dernier signal I2C reçu en l'abscence d'un nouveau signal), on arrive a récupérer d'une partie des erreurs, mais pas toujours.

 

2.3 Dans l'état actuel des choses, il arrives encore que la communication crash (plus rarement, peut être en moyenne après 10 minutes) lorsque le robot roule : redémarage coté Jeton toujours impossible("Resource temporarily unavailable"). La Jetson reçoit parfois des valeurs erronées (flip d'un bit (nb : vu que la valeur par défaut est 0, j'ai observé que des flip 0->1)).

Donc la communication n'est toujours pas stable, et il arrive encore que l'Arduino (je pense) bloque le bus et ne le libère pas (malgré le reset via jmp 0). Les valeurs éronnées ne sont pas trop graves en soit (il suffit d'ajouter une checksum).

 

 

 

 

 

Donc est-ce que vous avez une idée comment on peut facilement communiquer la Jetson avec l'Arduino (via I2C ou autrement) avec une distance de 1.5m en environnement plutôt bruité?

Pour le Joystick (lui même en I2C), vous avez une idée?

 

Merci d'avance

Sandro

 

PS : il y aurait bien la possibilité de connecter l'arduino en USB, mais d'après ce que m'a dit un ancien stagière (partit il y a 2 mois), on ne peut pas mettre 2 arduinos de même type sur le même hub USB (et on en a déjà un, et pas d'autre port USB disponible)