Personnellement je ferais en sorte d'ajouter un degré de liberté " flexible"  pour l'angle d'orientation de la partie qui tient les poubelles par rapport au corps du robot. 

Au repas, le support pour la poignée des poubelles serait bien " parallèle " à l'axe des roues, mais lorsque le robot tire le poubelle, et qu'il tourne, la "flexibilité" sur ce support permettrait de faciliter les rotations sans détériorer la poubelle ... 

Je vois la poubelle comme une " remorque " au cul du robot... Et une remorque ne doit pas rester à orientation fixe par rapport au corps de la voiture ( du moins dans les virages ) =)

 

EDIT : En regardant le lien donné par levend je devine que cette spécification est bien incluse dans le produit. Présence d'un axe de pivot …

 

oui tu as raison, un axe de rotation vertical pour permettre les "virages", maintenant à voir pour la liberté "horizontale".

Je pencherais également pour un tracteur qui, donc, tirerait la poubelle plutôt que pour un pousseur.

Dans ce sens, je pense que les roues d'origine devraient suffire.

De plus, plus besoin de vérins et de système compliqué.

 

je me rends compte que mon schéma n'est pas précis sur ce point, le robot est tireur pas pousseur, il va sur la gauche, pas sur la droite ^^

Que le centre de gravité de la poubelle vienne entre les roues avants et arrières du robot, en alignant le centre de gravité de la poubelle sur celui du robot.

La structure du dessin est une représentation, clairement faut trouver le bon équilibre entre solidité et masse.

 

Pour autant je me dis que porter la poubelle intégralement ne me semble pas logique, soit on profite qu'elle possède des roues qui sont prévues pour porter sa masse utile, soit il vaut mieux upgrader la poubelle et lui changer ses roues (et rajouter la partie puissance et commandes directement sur la poubelle).

 

Le chemin dont je parle est déjà emprunté par cette poubelle (et d'autres), tirée par un humain bien sûr, mais si on met ce genre de roue TT sur le robot et que la masse globale repose majoritairement sur lui sans lui faire porter 100% de la masse utile, on devrait trouver une similarité avec ce que fait un humain, c'est à dire tirer sans porter.

 

Je crois que la solution est justement la capacité à incliner plus ou moins la poubelle, de façon que le centre de gravité de la poubelle mais aussi du robot puisse franchir les obstacles.

 

Donc je penche pour une question de stabilité de l'ensemble accompagnée d'une capacité d'adaptation (déplacement du centre de gravité), sans doute amélioré avec des capteurs d'obstacles (pour éviter un mur, un humain, une voiture ou un trop gros caillou) et des capteurs gene niveaux à bulles pour le maintien de l'horizontalité.

Bonjour à tous,

 

un besoin exprimé par un membre de ma famille, vieillissant (70 ans passés), marchant avec difficultés mais habitant au bout d'une impasse privée.

 

L'impasse fait 100m, elle est droite mais n'est pas bitumée, le sol est celui d'un chemin de terre, avec des trous (plus large quee profond) et des cailloux de la taille d'une noix au maximum, voie urbaine typique pour un vélo tout chemin.

 

Donc l'idée au brouillon est celle-ci: 

 

Un robot téléguidé (radiocommande) qui tire une poubelle qui peut avoisiner les 100 Kgs (charge utile), sur un chemin de terre et sur une distance de 500 m.

 

Donc début classique, une structure pour 2 roues motorisées, et une roue libre.

J'ai pensé à 2 verins pour l'usage "métier". Le premier (en vert sur l'image ci-dessus) pour attraper la poubelle par les poignées et potentiellement verrouiller le maintien.

Le second (en bleu sur l'image ci-dessus) pour faire basculer la poubelle et déplacer son centre de gravité entre ses roues et celles du robot, afin que son poids participe à l'accroche des roues motorisées sur le sol.

 

Le tout alimentée par une batterie 24v pour donner assez de puissance aux motors.

 

Pas de challenge technique, juste faire un truc qui serve, s'inspirer du design thinking pour faire ce projet en s'appuyant sur le retour d'expérience utilisateur.

 

Je vais le faire Create Commons pour permettre de se le faire soi-même, si jamais d'autres retex peuvent alimenter le débat.

 

Prochaines étapes:

définir les spécifications techniques de la structure (conception, fabrication, montage), du matériel actif (roues, moteurs, vérins), du matériel electro (controleurs, cpu, transmission).

 

 

@+

Je savais bien que j'avais vu quelque chose qui faisait ça (mais pas en version télécommandé plutôt version transpalette électrique) :

https://www.francetr...on-2-poubelles/, le lien c'est juste l'option pour les poubelles, le Jumbo tractor est aussi sur le site pour un prix tout à fait déraisonnable pour des poubelles mais l'ensemble peut-être source d'inspiration.

Si ça peut t'aider dans ta conception...

 

 

oui alors merci pour l'info c un super exemple !

 

bon clairement le produit cité https://www.francetr.../jumbo-tractor/est un vrai tracteur personnel ! 5 k€, 600 W en 24 V, charge utile 500 Kg, charge tractée 1T5, 100 Kg à vide.

mais oui la même chose en + light, 200 W en 24 ou 12 V, charge tractée 150 Kg, 30 Kg à vide.

 

Finalement ma conception n'est pas si déconnante à la vue du design de ce tracteur.

Ou bien on maintien le bas de la poubelle de façon à la "solidariser" au robot, pas de risque de bascule entre les 2:

 

Le HSDPA tombe à 1.8Mbps de download pour un utilisateur qui pilote un robot c'est OK mais si pas en déplacement rapide (transports / voiture).

 

Pour le pilotage des robots un download de 1Mbps c'est le strict minimum pour que ça fonctionne en rognant toutes les marges avec la qualité actuelle et le son basse latence.

 

Pour la connexion d'un robot lui même c'est du 1Mbps d'upload qu'il, faut mais extrêmement stable (ADSL2+).

Ce qui signifie 4G préférable car la 3G+ sera limite car l'upload tombe souvent sous les 1Mbps,

Et si la liaison robot -> serveur prend du retard c'est tout les utilisateur qui le subissent.

 

Salut et merci pour ces précisions.

 

Du coup on pourrait très bien l'implémenter avec du WiMax non (plus fiable sur des zones non urbaines) ? Vous avez fait une couche d'abstraction à la partie "transport" de vos données ?

 

De mémoire on peut même implémenter de la QoS sur le WiMAx il me semble...

Le service "vigibot" est toujours en cours de "développement" donc oui c'est normal qu'il manque des informations.

 

Je m'en doute bien, c'était juste pour aider, car rien de mieux pour un projet qu'un œil neuf qui donne une vision customer

 

 

Sur le principe pour mettre en place le pilotage par internet il faut côté robot : 

Une raspberry pi avec une connection internet 3G+ qu'on connecte en UART sur le robot à piloter.

 

Donc suivant la couverture, le mini viable c'est du HSPDA, c'est bien ça ? on parle de quel débit mini, 1Mb/s full-duplex ?

 

 

Si vous avez d'autres questions n'hésitez pas.

 

- Comment est alimentée la RPi ?

- ok pour l'UART, mais concrètement coté robot, faut une API des contrôles commandes ? (j'suis pas du tout expert de l'UART, pour moi c'était une puce qui permet l'échange sur le port série avec un PC ?)

- tu aurais un cahier des charges de ce qu'il faut mettre en place coté robot ? une RPi, une carte sim avec abonnement, une caret d'extension j'imagine ? quel espace physique, quel conso électrique, quelle conso de données ?

 

désolé ca me semble encore très flou pour moi, et encore une fois je te pose ces questions pour comprendre et te donner une vision 'newbie' dans ton service, si tu trouves que j'en demande trop, indique le moi simplement

 

Vous êtes encore en phase de testing, que puis-je proposer pour que nous puissions trouver un terrain de travail commun ?

 

Je suis intéressé mais peut-être est-ce trop tôt dans mon dev ? (on est loin de parler de robot pour le moment)

Salut Mike,

j'ai en effet regardé le service que tu proposes, je me demandais comment ça pouvait s'intégrer surtout pour un robot qui ne serait potentiellement pas en zone "couverte", j'entends que sa zone d'action sera dans les champs, orée des bois, clairière de campagne... pas vraiment couvert par du wifi.

De plus la première étape ne concerne pas un robot qui se déplace tout seul ni à distance, les actions doivent être surveillées de près, l'opérateur doit être à coté.

Toutefois dans un futur proche j'espère que je parviendrai à rejoindre l'étape autonomie et sans aucun doute qu'une prise en main à distance sera obligatoire pour plusieurs raisons, dont la sécurité (situation type: le lidar du robot détecte un obstacle que l'IA ne sait pas interpréter, un opérateur devra pouvoir prendre le contrôle pour décider ou piloter lui même.

Je suis donc intéressé par Vigibot, mais en regardant le site il m'a manqué des infos importantes: les prérequis coté client (robot j'entends), le coût, le mode d'implémentation, les garanties ?

Pour en revenir au mode de déplacement, je ne compte pas faire que de la caméra, d'ailleurs elle ne servira que très peu au déplacement, elle est là pour photographier les cadres (et construire une base de connaissances), les autres moyens techniques sont ceux cités:
- un GPS pour rejoindre une géolocalisation
- un lidar pour identifier un obstacle sur le chemin (piloté par GPS)
- et c'est seulement lors que le lidar reconnait (ou croit reconnaitre) une ruche que la caméra permet de reconnaitre un code qui identifie la ruche et permet son positionnement correct (+ capteur de proximité), pour finir sur des capteurs de contacts avant de valider la position.

Il est certain que c'est un gros morceau et ce n'est pas une fonction primaire, c'est pourquoi ca reste optionnel.
D'ailleurs on pourrait en effet mettre en place un pilotage à "longue" distance avant de bosser sur l'auto-mobilité.

Faudrait que je poste les workflows pour montrer les enchainements, j'ai aussi les use cases.

@+

peut etre encore en tant que réseau privé ou communautaire ( lottissement ..  )

 

 

Salut,

 

oui c'est bien ce dont je parle, le WiMax (ou Lora) n'est pas à voir comme une offre opérateur en tout cas pas dans ce contexte... quoique.

Plus précisement soit j'ai un environnement controlé en ville avec une couverture wifi ou 4G suffisante, soit je m'éloigne des centres urbains et j'ai le risque d'avoir un débit insuffisant.

Ton site d'exploration (es-tu un industriel, un particulier, un agiculteur...) n'est pas forcement couvert par du wifi (coût d'installation, analyse fine des zones, gestion massive d'appliances...), les technologies type WiMax sont entre le wifi (portée 50m) et la 4G, pas forcement le meilleur choix si tu cherche le moins cher ou le plus performant mais plutôt un bon compromis.

Quand je parle de WiMax je suis certain que cela ne concerne pas tout le monde, il faut être dans la situation décrite plus haut, en fait la véritable question était: le VigiBot est-il adapatable à d'autres technos de transports de données ?

 

@+

On attend le topic annoncé avec impatience =)

 

 

Voici: http://www.robot-maker.com/forum/topic/12318-ara-assistant-robotique-apicole/

 

Raiden

merci

Bonjour à tous,

 

Mon username est un anagramme

 

La quarantaine, vivant entre Lyon et Roanne, je suis issu d'une formation en mécanique (bac F1) puis en design produit avant de travailler dans l'informatique (infra, dev et pilotage de projet) en autodidacte.

 

Il y a 5 ans je me suis devenu apiculteur amateur par curiosité, chaque année je récolte ma propre conso de miel (et j'en donne beaucoup également).

 

L'année dernière (2017) je me suis lancé dans la création d'un "Assistant Robotique Apicole", je me suis donné 2 ans pour faire un proto fonctionnel.

Toutes les infos sont regroupées sur un site sous licence CC BY-SA 4 (open-source).

 

Je vais ouvrir un topic sur ce robot car j'ai besoin de faire vivre ce projet et d'avoir un retour d'autres personnes.

 

En vous souhaitant une bonne journée.

 

Raiden

 

Le cahier des charges (évolutif):

 

Critères marketing:

• ​​Public cible:
  • ​> 40 ruches
• Coût de fabrication:
  • < 5 k€

Critères techniques:

• Surfaces de fonctionnement:
  • terre
  • sable
  • béton
  • forêt
  • jungle
  • montagne
• Dimensions:
  • largeur (transversal): < 200 cm
  • longeur: < 200 cm
  • hauteur: < 200 cm
• Vitesse de déplacement:
  • 50 cm/s ( = 30 m/mn = 1,8 km/h)
• Vitesse d'extraction/insertion d'un cadre:
  • 1 mn < 3 mn ( 60 s < 180 s)
• Energie:
  • Electricité
  • Autonomonie:
    • 4 h < 10 h (Batteries)
  • Temps de charge:
    • 1 h < 12 h
  • Rechargement:
    • Réseau EDF
    • Solaire (Panneau embarqués)
• Capacité de chargement:
  • Poids à charger:
    • < 150 kg
  • Nombre de hausse:
    • </= 4
• Poids:
  • < 500 kg
• Fonctions primaires:
  • se déplacer
  • respecter un chemin de points de passage
  • repérer (identifier repère visuel, se positionner) la ruche.
  • extraire un cadre d'une ruche rapidement. (< 2 minutes)
  • limiter l'ecrasement d'abeille.
  • photographier chaque face de chaque cadre
  • changer un cadre ancien par un neuf
  • déplacer un ou plusieurs cadre dans une ou plusieurs hausse
  • déplacer une ruche sur N mètres (pied compris ?)
• Fonctions secondaires:
  • retour automatique à la borne de rechargement:
    • en cas de fonctionnement en essaim (robot > 2):
      • envoi des ordres au robot de remplacement
      • ordonnancement des taches suivant un chemin optimisé (minimiser le déplacement sans risquer une collision ou un risque apicole)
      •  
  • aménager un rucher:
    • orienter les ruches
    • placer les ruches
  • gestion d'un rucher d'élévage:
  • maintien température intérieure de la ruche à 35° (un cadre de chauffage installé dans la ruche pendant les opérations sur les cadres)

Salut Mike et merci pour ce super retour !

 

Sans aucun doute que j'acheterai de quoi piloter ces moteurs dans quelques semaines et de préférence sur la boutique.

 

J'ai pas mal de cartes RPi et Arduino qui trainent, mais je suis clairement incompétent en electronique, autant j'ai déjà installé des cartes controleurs pour moteur cc et pas-à-pas, autant rajouter une télécommande me semble compliqué car je ne l'ai jamais fait.

 

Quand à la ligne de code, bien au contraire je suis pour mais en essayant d'éviter une usine à gaz ^^ (je tombe facilement dans le piège !)

 

Je vais donc me bricoler avec les moyens du bord de quoi "bouger" ce joystick et je suis d'accord que je vais méchament manquer de précision, une fois que je saurais où je mets les pieds concernant le "pilotage" (reflechir au design en gros), j'acheterai de quoi monter la soluce, de préférence sans m'enfermer dans des solutions propriétaires.

 

le besoin aujourd'hui est:

- permettre au propriétaire de diriger le robot à courte distance (entre 1 et 20m) -> Fil/Radio/Bluetooth/Wifi/IR ... (le poids et l'usabilité sont importants au même titre que le coût et la complexité d'implémentation).

- ajouter une interface (API) pour:

- - ajouter un système de capture et d'analyse de proximité pour bloquer des commandes de direction en opposition avec les valeurs de ces capteurs (faire rentrer le robot dans un mur) -> ??

[plus tard] - - diriger à grande distance ( > 20m) -> Carte 3G+

[plus tard] - - pilotage automatique (bien bien plus tard ^^)

 

Pour l'odométrie vous avez surement raison, c'est juste que la surface de déplacement ne sera pas plane et que j'ai peur que l'information ne soit pas fiable par conséquent, mais faudra que je creuse, il existe en effet un paquet de solutions techniques et comme tu le soulignes certaines sont consommatrices de calculs donc de processeurs et d'energie, sans parler de latence.

 

Enfin, tu as raison pour Vigibot, j'attends ton post dédié avec impatience

Ce sont des moteurs CC de fauteuils roulants avec frein mais sans codeurs ? C'est bien ça ?

c'est une bonne question !
ils viennent d'un fauteuil roulant Dupont mais impossible de trouver le modèle sur le net.
Par contre j'avais chopé les ref des moteurs, on les trouve sur le net, je les posterai à l'occase.
J'avais comme idée de démonter le poste de commande et de remplacer le joystick par une arduino car j'imagine du traitement analogique, mais j'avoue pour le moment ne pas avoir regardé plus que ça.
L'objectif c'est de valider que le robot peut faire les actions que j'imagine, c'est du bricolage avec ce que j'ai sous la main

Bonjour à tous,
 
je vous présente un projet commencé en juin 2017:
 

 
Le projet ARA (Assistant Robotique Apicole) consiste à développer un robot industriel de moyenne taille qui va aider tout apiculteur professionnel et semi-pro à optimiser les taches récurrentes de manutention, ainsi qu'une aide artificielle et intelligente pour la gestion technique du rucher.
 
Le projet n'est pas professionnel (j'ai un travail salarié à plein temps), je n'ai aucune structure juridique ni aucun objectif financier mais le coût de fabrication va forcement contraindre son usage par des apiculteurs possédant plusieurs dizaines de ruches pour en amortir le coût, ce type d'apiculteur ne peut en aucun cas être un amateur en raison de l'implication humaine que demande la gestion d'un rucher de ce type.
Pour les non connaisseurs, on parle de semi-pro entre 200 et 400 ruches, pro au delà.
 
Concrètement, les remplacements de hausses, la récupération et l'inspection des cadres, toutes les taches physiquement contraignantes seront exécutées par un robot sous le contrôle total ou programmé de l'apiculteur.
De plus, le robot embarque une IA qui apportera une analyse précise de l'état de chaque cadre afin de proposer un plan d'action optimisé dont l'objectif est maintenir le rucher dans un niveau opérationnel exceptionnel tout en améliorant la vie de milliers d'abeilles.
 
Tous les documents et informations relatives à ce projet sont sous licence Creative Commons BY-SA 4 (c'est open-source).
 
J'ai comme objectif de sortir un proto du modèle de base (sans IA) pour juin 2019.
 
L'analyse fonctionnelle graphique:

 
 
Voici les différents modèles avec leurs fonctionnalités :

 

Une vue des différents éléments fonctionnels (ce n'est pas du tout une version définitive, ceci ne représente que des parts du robot) :

 
Une série animée mettant en scène un workflow d'extraction d'un cadre de hausse:


Je rajouterai d'autres éléments bientôt, surtout un statut de l'avancement et quelques photos.

Apicalement,
Raiden

Radio de modélisme  
Sur la boutique on propose celle ci : Radiocommande 6 voies  et le tutoriel associé à cette radiocommande et les tutoriels associés : 
Découverte de la radiocommande et utilisation de la radiocommande avec arduino .  

Mais il y en a beaucoup d'autres un peu partout sur le net ...  Surtout si il y a besoin de plus de Voies ... Vu que celle qu'on propose ne dispose que de 6 voies ( Attention juste à choisir des fréquence légale en France)

 

Module bluetooth : 
=> en connectant un module bluetooth à un arduino par exemple et en faisant le soft dédié sur un smartphone et sur l'arduino tu peux piloter ton robot avec ... 
Sur la boutique on propose ce module bluetooth pour n'importe quel type de microcontrôleur , ou celui là module bluetooth directement adapté pour les arduino uno et mega en shield.  et on pourra trouver plusieurs robot qui utilisent cette méthode sur le forum ... dont le rocbot d'ashira ...

 

Par Wifi; 

=> Exemple NodeMCU  Raspberry pi les intègre déjà ... mais là encore il y a d'autre solutions ...

On notera par exemple le tuto pour piloter un robot en wifi de gerardosamara

 

 

merci pour ces infos et les liens, le tuto wifi est sympa !

Salut à tous,
 
14 mois sont passés mais le projet n'a pas autant avancé que je le voudrais.
 
J'ai bossé sur la partie soft pour valider les composants hard, dont voici quelques schémas.
 
L'architecture logique:

 
L'architecture technique:


L'architecture logicielle:



Pour la partie electro mes lacunes sont clairement bloquantes.

J'ai l'impression d'attaquer tous les fronts à la fois et je perds trop de temps à essayer de comprendre avant de me rendre compte que je suis parti sur la mauvaise voie...

Savez-vous s'il existe des électroniciens qui font payer leur service à la tache ou à l'heure peut-être ?


En vous remerciant par avance

@+

C'est ambitieux très ambitieux mais faisable mais ambitieux

 

Salut,

 

par ambitieux, tu veux dire compliqué ou complexe ?

 

j'ai fait les use case, défini les workflow métier, lister les actions mécaniques, ... les solutions techniques existent et ne sont pas très couteuses.

Pour l'instant je n'ai pas identifié de points bloquants, de ma fenetre en tout cas.

 

Ca ne veut pas dire qu'il n'y a pas de travail mais j'ai déjà ma base fonctionnelle qui tourne avec 2 moteurs issus d'un ancien fauteuil electrique acheté 300€ sur LBC, cette base permet de déplacer plus de 120 kilos (en plus du poids du robot/batterie) sur du gros gravier (je ne parviens mm pas à stopper le déplacement par ma seule force), c'est plus que suffisant pour "porter" une hausse de 20 Kg.

 

En ce moment je cogite sur la structure montante, c'est la partie "difficile" de la méca, comment faire toutes les actions en limitant l'utilisation d'actionneurs et de contacteurs.

 

C'est certain que je n'ai pas les meilleures solutions mais si je parviens à atteindre les jalons, ca répondra au moins fonctionnellement au besoin initialement énoncé.

Dans un processus d'amélioration continue l'objet s'améliorera, intégrera de nouvelles fonctionnalités et sera économe en énergie, en maintenance préventive et en coûts d'exploitation.

 

Mes autres projets me prennent aussi du temps, je ne peux donc pas être réactif tous les jours mais je mettrai régulièrement ce topic à jour avec quelques jours de latence.

 

@+

Raiden

Voilà où mes compétences s'arrêtent.

Ceci est le boitier de commande des 2 moteurs des roues arrières:








Il me semble préférable de ne m'attaquer qu'au joystick pour commencer (sans le remplacer si possible = commande de secours).

L'objectif est de permettre un pilotage à courte distance (j'ai essayé en ayant le bloc commande fixé au cadre, c'est trop compliqué à gérer car le pilotage au joystick ne peut se faire que si le joystick est à constante distance avec ta main... ce qui n'est pas le cas quand tu te tiens à coté du robot et que celui-ci se déplace).


Je ne cherche pas forcement une commande sans fil (même si ca serait pas mal) mais une commande qui pourra par la suite être programmable (au moins pour la détection d'obstacle: ne pas défoncer la ruche, même si le proprio est à coté...)

J'imagine un arduino auto-alimenté (batterie spécifique) et comm par radio ou bluetooth, pilotable d'un tél ou d'une télécommande type modélisme.


J'ai regardé les réf du joystick sur le net sans succès, le fabricant est très connu mais peu d'info technique sur ce joystick (qui doit dater des années 1995).

Il va surement me falloir mesurer les tensions qui sortent de chaque fil de ce joystick en fonctionnement, est-ce la bonne démarche ?

Bonjour à tous et merci pour vos retours,

 

pour être concis (car je peux vite m'étendre sur le sujet), j'ai la connaissance métier, ok ça ne fait pas 20 ans que je fais de l'apiculture, je ne suis pas non plus un pro mais j'ai été 2 ans en rucher-école et j'ai croisé des anciens comme des nouveaux, et ca fait 5 ans que j'ai des ruches et que je lis et échanges avec des apiculteurs.

 

L'idée n'est pas de remplacer l'apiculteur (loin de moi cette idée) mais de l'aider car de mars à aout, le travail est très physique (et je parle pas du taff en dehors du rucher), non seulement il faut effectuer des visites régulières pour "capter" les indicateurs de prise de décision (maladie, parasite, risque d'essaimage, etc..) mais il faut aussi effectuer des actions de remplacement, d'aggrandissement, de déplacement...

 

Les semi-pro comme les pros sont souvent aidés lors de cette période, par la famille en majorité mais aussi par des intérimaires lors des grosses périodes (récolte entre fin avril et juillet, suivant le type de fleurs), le travail est physique et épprouvant !

 

Les grands jalons dans l'implémentation des fonctionnalités:
 

- juin 2019: soulevement d'une hausse: aider physiquement l'apiculteur pour lui permettre d'effectuer ses actions (soulever un cadre pour regarder, le retirer...) = confort et soulagement du dos (une hausse de 9 cadres peut vite faire une 20aine de kilos sans problème !).
 

- juin 2020: prise en photo des 2 faces d'un cadre: construire une base de données pour prise de décision et historisation = remplace le carnet et permet de revisionner un cadre hors du rucher (faut s'imaginer en vareuse en train de regarder un cadre à travers le "grillage" avec des milliers d'abeilles qui volent !).

Plus tard ces photos seront elles-mêmes analysées par une IA/Computer Vision pour détecter le nombre d'alvéoles de tel ou tel type (couvain, miel, faux-bourdon...), les parasites,... couplé à une IA/System Expert (règles métier), on pourra déterminer des actions à prendre ou à suggerer à l'apiculteur.

 

- 2021-2022: auto-positionnement du robot (GPS / Lidar (SLAM) / CV) pour intervention en autonomie (scénarios, commandes unitaires,..) sous contrôle (télécommande, application de contrôle, historisation, ...)

 

- le reste plus tard

 

---

 

@Path:

Salut,

il y a divers scénarios et cette animation est juste "illustratrice" de quelles actions, la hausse pourrait être "emportée" pour la récolte par exemple, ou bien "changée" en raison de la détection d'un parasite... ne focalise pas sur cette anim, c'est pas un workflow propre.

Je posterai ce soir le cahier des charges avec les pré-requis technique (poids à soulever, type de terrain, ...).

 

Concernant le changement de ruches, c'est justement un pré-requis de ne rien changer:, aujourd'hui une ruche (au sens cabane en bois qui héberge un essaim), coute entre 100 et 300 € (pour les modèles avec toit en pente, beau bois..).

Pour un semi-pro qui possède 200 ruches, il a investi 20 000 euros rien qu'en "cabanes" ! l'opération n'est tout simplement pas rentable si on lui demande de modifier toutes ses ruches... en plus du coût d'achat du robot.

 

 

@Forthman

Salut,

oui j'ai un gosse de 12 ans et une femme et d'autres activités en plus ^^

oui j'en conviens les délais peuvent paraitre courts mais les jalons sont raisonnables je ne cherche pas à produire un robot autonome en moins d'1 an, j'en serai bien incapable ^^

L'objectif est aussi de réduire les composants pour gagner en poids et en conso energétique, je développerai cette partie plus loin (et dans quelques jours je pense).

 

 

@Mike118

Salut,

non je ne connais pas du tout et je vais prendre le temps de regarder en détail.

 

je suis ouvert à toute opportunité du moment que cela permet de faire vivre un projet, mon but n'est pas de développer ce projet tout seul, bien au contraire, mon but est de partager mon savoir, mes idées et de parvenir à concrétiser des actions si possible à plusieurs, mais j'ai du mal à embarquer des personnes de mon entourage, ca leur semble trop compliqué, voir complexe, peut-être est-ce moi qui communique mal..

 

En tout cas je cherche à m'appuyer sur des "briques" existantes, j'avais justement regardé du coté de ROS et en ce moment je tente de travailler avec OpenCV, mais pour le moment je n'ai pas trouvé de suites logicielles (API ou services) qui penchent dans ce sens, il me faudrait creuser. En tout cas je vais lire ce que tu proposes

 

 

---

 

 

Globalement je travaille avec un dev sur la partie prog mais il est habitué à faire des logiciels en .NET (alors que je lui demande du Python ou C++) et ne connait ni la CV ni Linux, pas trop Arduino et Raspberry et le fait bénévolement à distance (il est à coté de Toulon).

Mes compétences ne sont pas expertes mais je sais modéliser 3D (Solidworks, ...), utiliser des systèmes embarqués (Arduino, Raspberry), concevoir des structures mécaniques, piloter des projets (c'est mon activité principale dans mon travail salarié), programmer (PHP, Python, ..), opérer sur Linux, faire des graphiques de présentation, bricoler, apprendre, ...

 

Je n'ai pas peur d'un manque de compétences car tout s'apprend (et se partage ^^) mais j'ai clairement besoin d'aide pour ne pas me tromper dans les choix et aussi garder une motivation ce qui s'obtient principalement en équipe ou du moins grâce à une émulsion de groupe.

 

 

J'ai d'autres documents à partager que je posterai ce soir ou demain.

 

@+

Raiden

 

 

Pourquoi ne pas simplement " rallonger les fils des moteurs " d'environ 1 m  ? Vous gardez le boîtier dans la main ... des fils qui vont jusqu'au robot, et aucun développement à faire ... 

Sinon oui en l'absence d'info sur le joystick, des mesures de tension est une bonne démarche. 

 

 

C'est que je trouve que le boitier n'est pas pratique, très adapté à un pilotage assis, le bras reposant sur la commande et le maniement du bout des doigts, mais debout c'est une autre histoire, le boitier est lourd, le joystick trop avancé, ce qui fait que le poids du boitier est au milieu de l'avant bras, je ne trouve donc pas la solution ergonomique même si tu as raison c'est techniquement la solution la plus simple à mettre en œuvre (et surement la moins chère ^^).

 

Une autre option: une arduino qui déplacerait mécaniquement le joystick, simplement un déplacement sur un plan (2 axes), avec 2 moteur pas-à-pas comme pour beaucoup de machine outil à commandes num, à priori une simple extension contrôleur pour chaque moteur, le tout combiné à un algo de déplacement x/y.

Ca m'éviterait de faire du reverse ingé de ce boitier tout en gardant la possibilité de changer de type de commande et de faire du sans-fil assez simplement.

 

Je délire ?

 

En fait faut même que je connecte ce pilotage à ton système et voilà c'est contrôlable à distance !

Je dis ça je dis rien, je veux pas détourner le sujet ...

 

Matériellement, on a Pablo qui est le sujet qui s'en approche le plus  avec l'utilisation de moteurs identiques et l'ajout de capteurs pour l'odométrie,  l'intégration d'une boussole (qui a évolué depuis),   télécommandé par bluetooth , par wifi avec un smartphone , ou avec une radiocommande (ha non j'ai rien écris là-dessus) , un repérage par GPS et RTK ...

 

Je ne peux que conseiller d'utiliser un des contrôleurs sabertooth : pas de souci d'approvisionnement, la gamme évolue, pilotable par tout ce qu'on veut, archi connu dans le milieu des makers qui font du lourd.

 

Salut Ulysse,

 

ho ho ho ! en effet le coté propulsion est très proche ! je vais regarder ton topic avec attention

 

Pour l'odométrie je pense que l'objectif est différent et par conséquent la solution technique aussi il me semble: dans ton cas l'ensemble du dessin doit être parfait, d'où un comptage précis des tours de roue, bien plus fiable qu'un GPS. Mais surtout ton robot ne se soucie guère de l'environnement, son but est de tracer le plus fidèlement possible (et je trouve l'idée assez tripante en soit, j'adorerai détourner son utilisation avec de la peinture sur un mur ou sur le sol, le robot tagueur voir revendicaliste !).

 

Dans mon cas c'est tout l'inverse, c'est en relation avec l'environnement que le robot doit interagir, son propre déplacement n'étant pas contraint par lui même mais par les objets qui l'entourent, on est plus proche du SLAM, l'odométrie n'apportant pas d'information robuste dans ce sens.

 

 

Merci pour le lien vers Sabertooth c'est tout à fait ce qu'il me faut !