3 réponses à ce sujet

[boBot]

Bonsoir,

 

Si vous n'avez pas consulté ma présentation, elle décrit rapidement le porteur du projet et ce n'est pas réjouissant. C'est ici.

 

Projet : réalisation d'un robot transporteur de bacs de picking (préparation de commandes)

 

Objectif : faciliter la vie des préparateurs de commandes

 

Aspect humain : le préparateur ne sera pas remplacé par un robot. L'un assiste l'autre et inversement. Le gain de temps sera redéployé dans des tâches humaines plus évoluées. C'est un impératif. L'opérateur humain procédera au prélèvement du produit et à sa validation par codes à barres

 

Existant : écran embarqué indiquant gisement (position), quantité, image et description des produits à picker. Validation du code à barres par lecteur embarqué. Il est utilisé depuis 1 an et donne toute satisfaction. Je l'ai conçu et le maîtrise (ou c'est lui qui me maîtrise)

 

Sur le marché :

• http://fetchrobotics.com/follow-pick/
• http://effistore.effidence.com/up/follow-me.html : système français, sera testé en mai 2016 à la gare de l'Est
• http://milvusrobotics.com/en/atr-autonomous-transportation-robot
• http://www.neobotix-robots.com/mobile-robots-overview.html
• http://www.ottomotors.com/vehicles

Il y en a d'autres mais je n'ai pas les liens sous la souris ce soir.

 

Ce sont généralement des bots suiveurs. Mais pourquoi ne pas précéder plutôt que suivre (puisqu'il peut avoir le gisement, avec une cartographie c'est ok).

 

Merci de vos retours.

[boBot]

Oups... je reviens !

 

Mon planning a été un peu chargé ces temps derniers :

• écriture de la V2 du logiciel de préparation de commandes (ça roule et c'est plus modulaire)
• réalisation d'une fonction d'acquisition de poids depuis une balance avec édition automatique de l'étiquette d'expédition. Ca a été difficile mais la logique fonctionne maintenant, il ne reste plus qu'à améliorer les règles métier (suis-je autorisé à éditer cette étiquette ou doit-il y avoir une vérif manuelle de la qualité de l'adresse d'expédition, du risque d'une commande frauduleuse, d'une commande nécessitant une validation complémentaire...).

Ce qui est super, c'est de voir un système pensé et créé ex nihilo utilisé tous les jours de manière naturelle au point de devenir indispensable.

Si cela en intéresse certains, je peux donner plus d'info sur le système de pesée et la façon dont il fonctionne (3 process discutent, certains par modification du nom de la fenêtre, d'autres par génération de caractères frappés au clavier, d'autres par le déplacement et la création d'un fichier).

 

Revenons à notre bot de 7 lieues (j'ai laissé le projet tourner en tâche de fond durant les heures passées sur la route).

 

Je suis allé voir OpenBeam et MakerBeam (merci pour l'info) mais cela risque de m'emmener très loin.

Je souhaite m'affranchir des problèmes mécaniques et utiliser une base matérielle existante afin de valider la faisabilité du projet.

 

L'un des problèmes rencontrés réside dans l'acquisition de la position du bot. J'expérimente l'API GPS du matériel de picking (c'est un smartphone sous Androïd) mais dans un entrepôt, ce n'est pas gagné. Je vais bien voir quelle est la résolution de l'info récupérée. Sinon, des étiquettes RFID passives pour avoir des points de référence ?

 

Je garde un oeil sur cet article de www.numerama.com (ça pourrait servir ?).

 

Bon, y'a du boulot et, comme dirait Boris Vian ...

j'y retourne immédiatement

 

 

[Mike118]

 

 

L'un des problèmes rencontrés réside dans l'acquisition de la position du bot. J'expérimente l'API GPS du matériel de picking (c'est un smartphone sous Androïd) mais dans un entrepôt, ce n'est pas gagné. Je vais bien voir quelle est la résolution de l'info récupérée. Sinon, des étiquettes RFID passives pour avoir des points de référence ?

 

 

C'est un des problème majeur de la robotique mobile =) 

On distingue plusieurs type de solutions : 

La localisation par odométrie  => En gros le robot connais sa position initiale, et connais/mesure l'ensemble de ses déplacements pour savoir où il est , certains point pouvant servir pour du re-calage . 

( regroupe aussi bien l'odométrie au niveau de roue, l'odométrie visuelle, l'utilisation des IMU ou autre ... ) 

 

La localisation par observateur extérieur => En gros le robot communique avec " quelque chose " qui lui dit où il est .  ( système de caméra, tracking laser etc... ) 

La localisation par triangularisation => Système balises,  etc...

La localisation par SLAM / cartographie

 

le mélange / fusion de ces méthodes


Je ne connais pas d'autres méthodes de localisation ( sauf oubli involontaire ) 

 

[boBot]

Merci de cette réponse rapide, précise, concise et efficace.

 

Je vais tester avec un observateur extérieur (GPS intégrant un référentiel wifi). Je n'en attends pas grand chose.

 

C'est sympa d'avoir précisé "cartographie" après "SLAM" car ça réduit le bruit de fond en recherche sur Qwant (et sur Gogol en 2ème moteur).

 

Je pense partir d'un point zéro (identifié) et calculer un trajet optimal vers un point x (en odométrie roue) avec calage ponctuel RFID (il me faut vérifier la portée & la précision RFID).

Mais si la roue pète, je fais quoi ? (c'était la minute rigolade) :-)