development of a mechanical interface between a robot and an agv

[38luglio]

Hello everyone,
for my thesis work I am engaged in the realization of a link interface between a generic collaborative robot, having maximum weight of 40 kg, with a generic agv. this interface must allow the rotation of the entire cobot around a vertical axis for the positioning of this in the operations of pick and place (this need could be due, for example, to the desire to extend the accessibility of the arm above, mounting it in an "eccentric" way compared to the axis of the interface).

the interface will have to have a solid part to the agg and a rotating part, on which the robot is mounted. To develop it, I had thought of the attached scheme, but I ask you some advice on the actual realization, in terms of components.

I had thought of a dc engine, connected by a skewer or accident transmission, to a tree on which the rotating platform that holds the robot (maybe by means of a grooved profile or simply by means of a tab). Taking into account that the system parameters such as engine plate data and transmission ratio will be chosen as a result of subsequent simulations on simulink, I wanted more in detail on the mechanical "layout" of the system, in particular on the vertical shaft configuration (springs, bearings, quarries, threaded codons, etc.) than, only to fix ideas, I designed perfectly cylindrical. Consider that the base of the interface will have a diameter of 500 mm and the overall height, excluding the robot, must be as little as possible. I wait for your advice, thank you in advance.

 

[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

yes the problem is analogous and I had already noticed the discussion, but in that case it was asked of the sensory, while the mechanical aspect was not minimally touched.

 

[Fulvio Romano]

Hi.
this axis must necessarily be an interpolated seventh axis, otherwise the robot has no way to know where it is.
must then be at game recovery, otherwise in the robot movement moves by losing repeatability throughout the system.
I don't know the detail you have to get

 

[38luglio]

Hi.
this axis must necessarily be an interpolated seventh axis, otherwise the robot has no way to know where it is.
must then be at game recovery, otherwise in the robot movement moves by losing repeatability throughout the system.
I don't know the detail you have to get

Hi fulvio, what exactly do you mean by "interpolated" axis? about the loss of repeatability as this happens? Would the robot tend to "shift" than the interface? to increase precision I had thought of inserting a pid control, having as requirement a very small error and a nothing overelongation. about the mechanical layout that pattern is okay or is there a better way to make it work?
Thank you very much for the answers!

 

[Fulvio Romano]

The robot has four or six axes. these axes are interpolated so that the end effector (uterine) can perform trajectories from defined primitives (linear, circular, etc.)

The axis you have to do, call it seventh axis even if it actually comes before axis 1, how does it work?
1. Does the robot move? then must be interpolated so that the robot can control it. the robot must also be able to control a seventh axis because it is trying to solve a system of 7 equations in 6 unknowns and if you don't give it an optimized functional does not come out (abb, kuka, fanuc do it without problems. ur, doosan, etc. in good luck)

2 stands still when the robot moves? then it must have a precise feedback that the robot must know by direct detection, otherwise the robot no longer knows where it is after the seventh axis moved.

Hi fulvio, what exactly do you mean by "interpolated" axis? about the loss of repeatability as this happens? Would the robot tend to "shift" than the interface?

if there is a game in the transmission, the cinematic multiplication created by the structure of the robot makes very little precise (precision = accuracy + repeatability) positioning.
There are several ways of creating a zero-game system. preloaded systems (avoid if it is a welding robot for example), to game recovery (e.g. kiosks), to game null (e.g. cams).

to increase precision I had thought of inserting a pid control, having as requirement a very small error and a nothing overelongation. about the mechanical layout that pattern is okay or is there a better way to make it work?
Thank you very much for the answers!

a pid is a linear system that does not compensate for the non-linearity of a game. the integral action completely cancels the error at regime, does not only make it small. Moreover the over-elongation must be nothing, otherwise it spoils the gears in a short time. How do you eliminate overelongation? simple, just have p/i such that the associated transfer function is hypersmorzata. ziegler and nichols are pretty good at this.

But tell me what you're studying? I think we're making it too complicated.

 

[38luglio]

The robot has four or six axes. these axes are interpolated so that the end effector (uterine) can perform trajectories from defined primitives (linear, circular, etc.)

The axis you have to do, call it seventh axis even if it actually comes before axis 1, how does it work?
1. Does the robot move? then must be interpolated so that the robot can control it. the robot must also be able to control a seventh axis because it is trying to solve a system of 7 equations in 6 unknowns and if you don't give it an optimized functional does not come out (abb, kuka, fanuc do it without problems. ur, doosan, etc. in good luck)

2 stands still when the robot moves? then it must have a precise feedback that the robot must know by direct detection, otherwise the robot no longer knows where it is after the seventh axis moved.


if there is a game in the transmission, the cinematic multiplication created by the structure of the robot makes very little precise (precision = accuracy + repeatability) positioning.
There are several ways of creating a zero-game system. preloaded systems (avoid if it is a welding robot for example), to game recovery (e.g. kiosks), to game null (e.g. cams).



a pid is a linear system that does not compensate for the non-linearity of a game. the integral action completely cancels the error at regime, does not only make it small. Moreover the over-elongation must be nothing, otherwise it spoils the gears in a short time. How do you eliminate overelongation? simple, just have p/i such that the associated transfer function is hypersmorzata. ziegler and nichols are pretty good at this.

But tell me what you're studying? I think we're making it too complicated.

then, I would start from the end, study mechanical engineering master, but I am "inquadrato" in a new path, that of mechatronics.
the idea is to integrate a cobot with an agv and to do so in a more generic way possible. the fact of creating a further axis, in fact, according to the professor, serves more to increase the safety of the whole system than for functional reasons (in fact all robots already have an axis that rotate them than the base).
the seventh axis remains firm when the cobot is moving, acting only on its initial positioning, after the agg brought it to the required position. then of the options you mentioned, the 2 is the correct. I had thought of controlling the rotation of the seventh axis with arduino and connecting the same card to the controller of the cobot (on the net I found some examples with a ur, but I can't tell you the details, but I still remain a mechanical engineer). the cobot would know its positioning thanks to the information transmitted by arduino.
about the recovery or cancellation of the game I admit I'm not very careful: I remember that something like this is adopted in the milling (recirculation of preloaded spheres) but there we talk about translatory motion (advancing between piece and cut) , no?
about the pid I don't care much more about the search for parameters because I was explicitly asked to find them by simulink (to make oversmorzato the system I thought to act overpowered on the kd, moreover with some simulation I noticed that it would be enough pd control).
I attach an image of a first interface concept, above is a ur10. Thanks again.

 

[Fulvio Romano]

Don't call me an asshole, but...

then, I would start from the end, study mechanical engineering master, but I am "inquadrato" in a new path, that of mechatronics.
the idea is to integrate a cobot with an agv and to do so in a more generic way possible. the fact of creating a further axis, in fact, according to the professor, serves more to increase the safety of the whole system than for functional reasons (in fact all robots already have an axis that rotate them than the base).

Are they coaxial? What a blasphemy!
and what would be the advantage on safety? How do you control the accelerations? The couple? speed? how do you control the prameters of iso 10218?

il seventh axis remains firm when the cobot is moving, acting only on its initial positioning, after the agg brought it to the required position. then of the options you mentioned, the 2 is the correct. I had thought of controlling the rotation of the seventh axis with arduino and connecting the same card to the controller of the cobot (on the net I found some examples with a ur, but I can't tell you the details, but I still remain a mechanical engineer). the cobot would know its positioning thanks to the information transmitted by arduino.

Okay, so you don't need to be buried. not only, but when the robot moves this is off. So it has no effect on safety, right?

about the recovery or cancellation of the game I admit I'm not very careful: I remember that something like this is adopted in the milling (recirculation of preloaded spheres) but there we talk about translatory motion (advancing between piece and cut) , no?

Forget it. Put a brake on the slow axis and you fixed it. If you use ur you can't do such complex operations, they use a jumper brake (the ninja star) as they call it. . )

 

[38luglio]

Don't call me an asshole, but...

Are they coaxial? What a blasphemy!
and what would be the advantage on safety? How do you control the accelerations? The couple? speed? how do you control the prameters of iso 10218?

You had your own doubts, but the job I was commissioned is this.
on the safey I had thought of pulling out the maximum speed allowed to tcp for not having dangerous impacts with the man (from the iso that you mentioned and from 15066) and limit the speed of the "seven axis" according to this value (then it only has to act for positioning) hoping that it does not come out too low value. In the end, this should be the improvement to safety, even if it is reduced to the phase in which the only interface works, the cobots have already an intrinsic safety (I realize that it is very little consistent, but so much it is).

Forget it. Put a brake on the slow axis and you fixed it. If you use ur you can't do such complex operations, they use a jumper brake (the ninja star) as they call it. . )

here is the problem that this interface has to adapt to as many possible cobots, not only to those of the ur, then why a brake? Didn't we talk about the problem of angle accuracy reduced by broadcast games?

 

[Fulvio Romano]

You had your own doubts, but the job I was commissioned is this.
on the safey I had thought of pulling out the maximum speed allowed to tcp for not having dangerous impacts with the man (from the iso that you mentioned and from 15066) and limit the speed of the "seven axis" according to this value (then it only has to act for positioning) hoping that it does not come out too low value. In the end, this should be the improvement to safety, even if it is reduced to the phase in which the interface only works, the cobots already have intrinsic safety (I realize that it is very little consistent, but so much so)

Well, then take the biggest cobot that exists and size the speed so that:
- with the maximum grind do not exceed the limit speed
- with the minimum arm does not exceed the limit pair

here is the problem that this interface has to adapt to as many possible cobots, not only to those of the ur, then why a brake? Didn't we talk about the problem of angle accuracy reduced by broadcast games?

if you stop the movement always in the same direction the game is zero because the transmission is already preloaded. if you brake the slow axis the remaining game at the end of the pair does not affect the movement of the base of the robot.