Développement d'une interface mécanique entre un robot et un AGV

[38luglio]

Bonjour tout le monde,
pour mon travail de thèse je suis engagé dans la réalisation d'une interface de liaison entre un robot collaboratif générique, d'un poids maximal de 40 kg, avec un agv générique. cette interface doit permettre la rotation de l'ensemble du cobot autour d'un axe vertical pour le positionnement de celui-ci dans les opérations de pic et de place (ce besoin pourrait être dû, par exemple, à la volonté d'étendre l'accessibilité du bras ci-dessus, le montage d'une manière "excentrique" par rapport à l'axe de l'interface).

l'interface devra avoir une partie solide à l'agg et une partie tournante, sur laquelle le robot est monté. Pour le développer, j'avais pensé au schéma ci-joint, mais je vous demande quelques conseils sur la réalisation réelle, en termes de composants.

J'avais pensé à un moteur DC, connecté par une brochette ou une transmission d'accident, à un arbre sur lequel la plate-forme tournante qui tient le robot (peut-être au moyen d'un profil rainuré ou simplement au moyen d'un onglet). Compte tenu du fait que les paramètres du système tels que les données de la plaque du moteur et le rapport de transmission seront choisis à la suite de simulations ultérieures sur simulink, je voulais plus en détail sur la "couche" mécanique du système, en particulier sur la configuration verticale de l'arbre (spires, roulements, carrières, codons filetés, etc.) que, seulement pour fixer des idées, j'ai conçu parfaitement cylindrique. Considérez que la base de l'interface aura un diamètre de 500 mm et que la hauteur totale, à l'exclusion du robot, doit être aussi faible que possible. J'attends votre conseil, merci d'avance.

 

[MassiVonWeizen]

Problema sensori interfaccia di accoppiamento

Salve a tutti, sono uno studente di ingegneria meccanica (laurea magistrale) e sto lavorando ad un progetto: devo progettare un' interfaccia intelligente che colleghi Agv - braccio robot e deve permettere la rotazione del braccio intorno al suo asse verticale. L' interfaccia non può ricevere...

www.cad3d.it

 

[38luglio]

Problema sensori interfaccia di accoppiamento

Salve a tutti, sono uno studente di ingegneria meccanica (laurea magistrale) e sto lavorando ad un progetto: devo progettare un' interfaccia intelligente che colleghi Agv - braccio robot e deve permettere la rotazione del braccio intorno al suo asse verticale. L' interfaccia non può ricevere...

www.cad3d.it

Oui, le problème est analogue et j'avais déjà remarqué la discussion, mais dans ce cas on lui a demandé du sens, alors que l'aspect mécanique n'était pas le moins touché.

 

[Fulvio Romano]

Bonjour.
cet axe doit nécessairement être un septième axe interpolé, sinon le robot n'a aucun moyen de savoir où il est.
doit alors être à la récupération du jeu, sinon dans le mouvement du robot se déplace en perdant la répétabilité dans tout le système.
Je ne sais pas le détail que vous devez obtenir

 

[38luglio]

Bonjour.
cet axe doit nécessairement être un septième axe interpolé, sinon le robot n'a aucun moyen de savoir où il est.
doit alors être à la récupération du jeu, sinon dans le mouvement du robot se déplace en perdant la répétabilité dans tout le système.
Je ne sais pas le détail que vous devez obtenir

Salut fulvio, que voulez-vous dire exactement par axe "interpolé" ? à propos de la perte de répétabilité comme cela se produit? Le robot aurait-il tendance à « changer » que l'interface ? pour augmenter la précision, j'avais pensé à insérer un contrôle pid, ayant comme exigence une très petite erreur et un rien d'allongement. au sujet de la disposition mécanique que le modèle est correct ou y a-t-il un meilleur moyen de le faire fonctionner?
Merci beaucoup pour les réponses!

 

[Fulvio Romano]

Le robot a quatre ou six axes. ces axes sont interpolés de sorte que l'effecteur final (utérin) puisse effectuer des trajectoires à partir de primitives définis (linéaire, circulaire, etc.)

L'axe que vous devez faire, l'appeler septième axe même s'il vient réellement avant l'axe 1, comment fonctionne-t-il?
1. Le robot bouge ? alors doit être interpolé pour que le robot puisse le contrôler. le robot doit également être en mesure de contrôler un septième axe parce qu'il essaie de résoudre un système de 7 équations dans 6 inconnus et si vous ne lui donnez pas une fonction optimisée ne sort pas (abb, Kuka, fanuc le faire sans problèmes. ur, doosan, etc. en bonne chance)

2 se tiennent toujours quand le robot bouge ? alors il doit avoir une rétroaction précise que le robot doit savoir par détection directe, sinon le robot ne sait plus où il est après le septième axe déplacé.

Salut fulvio, que voulez-vous dire exactement par axe "interpolé" ? à propos de la perte de répétabilité comme cela se produit? Le robot aurait-il tendance à « changer » que l'interface ?

s'il y a un jeu dans la transmission, la multiplication cinématographique créée par la structure du robot rend très peu précis (précision = précision + répétabilité) positionnement.
Il existe plusieurs façons de créer un système zéro jeu. systèmes préchargés (éviter s'il s'agit d'un robot de soudage par exemple), à la récupération de jeu (par exemple des kiosques), à jeu nul (par exemple des caméras).

pour augmenter la précision J'avais pensé à insérer un contrôle pid, ayant comme exigence une très petite erreur et un rien d'allongement. au sujet de la disposition mécanique que le modèle est correct ou y a-t-il un meilleur moyen de le faire fonctionner?
Merci beaucoup pour les réponses!

un pid est un système linéaire qui ne compense pas la non-linéarité d'un jeu. l'action intégrale annule complètement l'erreur au régime, ne le rend pas seulement petit. De plus, le surallongement ne doit être rien, sinon il gâche les engrenages en peu de temps. Comment éliminer la surallongement ? simple, juste avoir p/i de sorte que la fonction de transfert associée est hypersmorzata. ziegler et nichols sont assez bons pour ça.

Mais dites-moi ce que vous étudiez ? Je pense que c'est trop compliqué.

 

[38luglio]

Le robot a quatre ou six axes. ces axes sont interpolés de sorte que l'effecteur final (utérin) puisse effectuer des trajectoires à partir de primitives définis (linéaire, circulaire, etc.)

L'axe que vous devez faire, l'appeler septième axe même s'il vient réellement avant l'axe 1, comment fonctionne-t-il?
1. Le robot bouge ? alors doit être interpolé pour que le robot puisse le contrôler. le robot doit également être en mesure de contrôler un septième axe parce qu'il essaie de résoudre un système de 7 équations dans 6 inconnus et si vous ne lui donnez pas une fonction optimisée ne sort pas (abb, Kuka, fanuc le faire sans problèmes. ur, doosan, etc. en bonne chance)

2 se tiennent toujours quand le robot bouge ? alors il doit avoir une rétroaction précise que le robot doit savoir par détection directe, sinon le robot ne sait plus où il est après le septième axe déplacé.


s'il y a un jeu dans la transmission, la multiplication cinématographique créée par la structure du robot rend très peu précis (précision = précision + répétabilité) positionnement.
Il existe plusieurs façons de créer un système zéro jeu. systèmes préchargés (éviter s'il s'agit d'un robot de soudage par exemple), à la récupération de jeu (par exemple des kiosques), à jeu nul (par exemple des caméras).



un pid est un système linéaire qui ne compense pas la non-linéarité d'un jeu. l'action intégrale annule complètement l'erreur au régime, ne le rend pas seulement petit. De plus, le surallongement ne doit être rien, sinon il gâche les engrenages en peu de temps. Comment éliminer la surallongement ? simple, juste avoir p/i de sorte que la fonction de transfert associée est hypersmorzata. ziegler et nichols sont assez bons pour ça.

Mais dites-moi ce que vous étudiez ? Je pense que c'est trop compliqué.

alors, je commencerais à partir de la fin, étudier le maître de l'ingénierie mécanique, mais je suis "inquadrato" dans un nouveau chemin, celui de la mécatronique.
l'idée est d'intégrer un cobot avec un agv et de le faire de manière plus générique possible. le fait de créer un axe supplémentaire, en fait, selon le professeur, sert plus à augmenter la sécurité de l'ensemble du système que pour des raisons fonctionnelles (en fait tous les robots ont déjà un axe qui les tourne que la base).
des septième axe reste ferme lorsque le cobot se déplace, agissant seulement sur son positionnement initial, après que l'agg l'a amené à la position requise. puis des options que vous avez mentionnées, la 2 est la bonne. J'avais pensé à contrôler la rotation du septième axe avec arduino et à connecter la même carte au contrôleur du cobot (sur le net j'ai trouvé quelques exemples avec un ur, mais je ne peux pas vous dire les détails, mais je reste un ingénieur mécanique). le cobot connaîtrait son positionnement grâce aux informations transmises par Arduino.
concernant la récupération ou annulation du jeu Je reconnais que je ne suis pas très prudent. Je me souviens que quelque chose comme ça est adopté dans le fraisage (recirculation de sphères préchargées) mais là nous parlons de mouvement traductible (avancée entre la pièce et la coupe) , non?
concernant la pid Je ne me soucie pas beaucoup plus de la recherche de paramètres parce qu'on m'a explicitement demandé de les trouver par simulink (pour faire sursmorzato le système que j'ai pensé agir sur le kd, en outre avec une certaine simulation j'ai remarqué que ce serait assez de contrôle pd).
J'attache une image d'un premier concept d'interface, ci-dessus est un ur10. Merci encore.

 

[Fulvio Romano]

Ne me traite pas de connard, mais...

alors, je commencerais à partir de la fin, étudier le maître de l'ingénierie mécanique, mais je suis "inquadrato" dans un nouveau chemin, celui de la mécatronique.
l'idée est d'intégrer un cobot avec un agv et de le faire de manière plus générique possible. le fait de créer un axe supplémentaire, en fait, selon le professeur, sert plus à augmenter la sécurité de l'ensemble du système que pour des raisons fonctionnelles (en fait tous les robots ont déjà un axe qui les tourne que la base).

Ils sont coaxiaux ? Quel blasphème !
et quel serait l'avantage sur la sécurité? Comment contrôlez-vous les accélérations ? Le couple ? La vitesse ? Comment contrôlez-vous les prémètres d'iso 10218 ?

où septième axe reste ferme lorsque le cobot se déplace, agissant seulement sur son positionnement initial, après que l'agg l'a amené à la position requise. puis des options que vous avez mentionnées, la 2 est la bonne. J'avais pensé à contrôler la rotation du septième axe avec arduino et à connecter la même carte au contrôleur du cobot (sur le net j'ai trouvé quelques exemples avec un ur, mais je ne peux pas vous dire les détails, mais je reste un ingénieur mécanique). le cobot connaîtrait son positionnement grâce aux informations transmises par Arduino.

Ok, donc tu n'as pas besoin d'être enterré. Non seulement, mais quand le robot bouge, c'est fini. Donc ça n'a aucun effet sur la sécurité, non ?

concernant la récupération ou annulation du jeu Je reconnais que je ne suis pas très prudent. Je me souviens que quelque chose comme ça est adopté dans le fraisage (recirculation de sphères préchargées) mais là nous parlons de mouvement traductible (avancée entre la pièce et la coupe) , non?

Oublie ça. Mettez un frein sur l'axe lent et vous l'avez réparé. Si vous utilisez ur vous ne pouvez pas faire des opérations aussi complexes, ils utilisent un frein à sauter (l'étoile ninja) comme ils l'appellent. . )

 

[38luglio]

Ne me traite pas de connard, mais...

Ils sont coaxiaux ? Quel blasphème !
et quel serait l'avantage sur la sécurité? Comment contrôlez-vous les accélérations ? Le couple ? La vitesse ? Comment contrôlez-vous les prémètres d'iso 10218 ?

Vous aviez vos propres doutes, mais le travail que j'ai été commandé est celui-ci.
sur la sécurité j'avais pensé à sortir la vitesse maximale permise à tcp pour ne pas avoir d'impacts dangereux avec l'homme (de l'iso que vous avez mentionné et de 15066) et limiter la vitesse de l'"sept axe" en fonction de cette valeur (alors il n'a qu'à agir pour le positionnement) en espérant qu'il ne sort pas trop faible valeur. En fin de compte, cela devrait être l'amélioration de la sécurité, même si elle est réduite à la phase dans laquelle la seule interface fonctionne, les cobots ont déjà une sécurité intrinsèque (je me rends compte qu'elle est très peu cohérente, mais c'est tellement).

Oublie ça. Mettez un frein sur l'axe lent et vous l'avez réparé. Si vous utilisez ur vous ne pouvez pas faire des opérations aussi complexes, ils utilisent un frein à sauter (l'étoile ninja) comme ils l'appellent. . )

Voici le problème que cette interface doit s'adapter à autant de cobots possibles, pas seulement à ceux de l'ur, alors pourquoi un frein? N'avons-nous pas parlé du problème de précision d'angle réduit par les jeux de diffusion ?

 

[Fulvio Romano]

Vous aviez vos propres doutes, mais le travail que j'ai été commandé est celui-ci.
sur la sécurité j'avais pensé à sortir la vitesse maximale permise à tcp pour ne pas avoir d'impacts dangereux avec l'homme (de l'iso que vous avez mentionné et de 15066) et limiter la vitesse de l'"sept axe" en fonction de cette valeur (alors il n'a qu'à agir pour le positionnement) en espérant qu'il ne sort pas trop faible valeur. En fin de compte, cela devrait être l'amélioration de la sécurité, même si elle est réduite à la phase dans laquelle l'interface ne fonctionne que, les cobots ont déjà une sécurité intrinsèque (je me rends compte qu'elle est très peu cohérente, mais tant que cela)

Eh bien, alors prenez le plus grand cobot qui existe et taillez la vitesse de sorte que:
- avec la mouture maximale ne dépasse pas la vitesse limite
- avec le bras minimal ne dépasse pas la paire limite

Voici le problème que cette interface doit s'adapter à autant de cobots possibles, pas seulement à ceux de l'ur, alors pourquoi un frein? N'avons-nous pas parlé du problème de précision d'angle réduit par les jeux de diffusion ?

si vous arrêtez le mouvement toujours dans la même direction le jeu est zéro parce que la transmission est déjà préchargée. si vous freinez l'axe lent, le reste du jeu à la fin de la paire n'affecte pas le mouvement de la base du robot.