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 ^^

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.

2018, 2019, 2020 ... je dois être synchro à l'année c'est pas possible.

 

Le temps passe à une vitesse !

 

Bref, j'ai changé d'emploi (1 semaine avant le covid), mieux payé, plus proche et donc je retrouve un peu de temps pour reprendre ce sujet.

 

Et aussi parce que cet été je me suis occupé de 4 ruches ce qui m'a pris un temps considérable en manipulation et sans compter le déplacement de 2 ruches sur plusieurs mètres, il m'a fallu 2 semaines à raison d'1 mètre environ par jour.

 

Maintenant que les finances suivent (dans des limites tout de même), il me semble que le remplacement de la partie "commande" de mes moteurs issus d'un fauteuil électrique est un passage obligatoire.

 

 

Une question @Mike118, les cartes contrôleurs Sabertooth sont-elles compatibles avec tous les moteurs CC ?

 

Encore merci.

 

@+

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é.

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

 

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.

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).

 

 

@+

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

@+

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 ?

 

@+

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...

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 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

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 !

 

 

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 !

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)

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 ?

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.

@+

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

Quelques photos du proto:

19/08/2018:


01/09/2018:


08/09/2018:


09/09/2018:

En tout cas merci pour vos retours car j'ai besoin d'être challengé et de sentir un intérêt, sentiment que l'on perd assez vite quand on bosse seul ou presque.

 

C'est vrai que y'a du challenge, j'ai encore pas mal d'inconnues, entre l'architecture électronique et informatique, le rapport poids/puissance, l'autonomie energétique, les contrôles commandes, les checkpoints sécu, les arrêts d'urgence, les passages de câbles, les doubles vérif, ... la liste est vite longue et l’exhaustivité pas évidente, mais qui ne tente rien...

 

c'est sûrement ambitieux je ne m'en rends pas compte et je suis novice dans la construction de robot.

Je suis conscient que la somme des connaissances n'est pas égal à l'ensemble des connaissances, il me manque sans aucun doute le test de la réalité, je tomberai avec certitude de cheval, mais l'important est de remonter en selle et de continuer

 

J'ai encore pas mal de taff, il me faut avancer sur le design de la partie méca, je posterai d'ici la fin de semaine de quoi illustrer cette partie.

 

@+

compliqué : 1 action = 1 réaction : long/fastidieux mais prévision maitrisée.

complexe: 1 action = différentes réactions : prévision incertaine.

 

Le projet est principalement découpé en 2 grosses phases:

- assistant et aide à prise de décision: l'apiculteur positionne lui-même le robot devant la ruche et donc c'est à lui qu'incombe de vérifier que les opérations ne vont pas renverser la ruche (stabilisation..)

- robot autonome: l'apiculteur a validé en amont les actions à effectuer, le robot utilise son propre système de repérage, de prise de décision pour se "coller" à la ruche et faire les opérations.

 

Pour le moment je focus sur la 1ère phase, le workflow est de mettre le robot dans une position "autorisée", d'ancrer le robot au sol (blocage des roues, déploiement d'appuis supplémentaires) puis de "bloquer" le corps de la ruche (blocage sol/corps), ensuite seulement on se permet de soulever les hausses.

 

En toute franchise, les hausses sont "posées" les une sur les autres, le seul "blocage" est causé par la propolis qui se casse assez facilement si tu exerce une poussée transverse (cissaillement) ou bien en utilisant le principe du levier, mais en effet c'est un point important.

 

Quand à la précision elle n'est pas très fine, on opère sur des hausses d'environ 40 cm, une précision au cm suffit amplement.

 

Il est possible comme tu l'évoque que l'ajout d'un ergot de positionnement/levage soit nécéssaire sur chaque hausse, je dois faire des tests dans ce sens.

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

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)