On Fri, Jul 3, 2009 at 15:19, John Yamokoski<yamokosk [..] ...> wrote:
> Greetings everyone,
>
> The Orocos website does a good job at showing a wide range of
> applications in which Orocos is used. But I was wondering, besides
> Kuka and the Mitsubishi PA-10 (what we currently have), what other
> manipulators, if any, are people controlling with Orocos. We have been
> considering the purchased of another manipulator with a greater
> payload capacity than the PA-10. So one of our requirements is that
> this new manipulator has a nice, open API. And ideally, we'd like one
> where someone has successfully integrated it with Orocos.
It seems the irony is that although Orocos was initially developed for
serial robots, they are today the least represented. The reason for
this is implicitly in your mail: the standards interface to such
manipulators is/was so closed/slow that it is hardly necessary to
close a real-time loop/framework around them. Only hacking the
hardware opens them up to the level we want. Visionaries like Herman
predict that industrial robots will open up more the next two years,
looking at the newer models of Kuka, Comau, ABB and especially Barret
(for small payloads). Our experience is that you'd like to get your
hands dirty first, in order to measure if you're getting what the
manufacturer promises. For example, the KUKA LBR has a dead time of
50ms using their 'real-time' interface running at a 12ms loop. But
they promised they would fix it with the next software update.[*]
Peter
[*] I'm just reporting what Tinne and Wilm measured, not my own experience.
survey of robots being used with Orocos
A Dimarts 14 Juliol 2009, Peter Soetens va escriure:
> On Fri, Jul 3, 2009 at 15:19, John Yamokoski<yamokosk [..] ...> wrote:
> > Greetings everyone,
> >
> > The Orocos website does a good job at showing a wide range of
> > applications in which Orocos is used. But I was wondering, besides
> > Kuka and the Mitsubishi PA-10 (what we currently have), what other
> > manipulators, if any, are people controlling with Orocos. We have been
> > considering the purchased of another manipulator with a greater
> > payload capacity than the PA-10. So one of our requirements is that
> > this new manipulator has a nice, open API. And ideally, we'd like one
> > where someone has successfully integrated it with Orocos.
>
> It seems the irony is that although Orocos was initially developed for
> serial robots, they are today the least represented. The reason for
> this is implicitly in your mail: the standards interface to such
> manipulators is/was so closed/slow that it is hardly necessary to
> close a real-time loop/framework around them. Only hacking the
> hardware opens them up to the level we want.
An it's not an easy task. Sadly, AFAIK, the industrial robots (by now) only
offers closed and hide interfaces to control their robots.
> Visionaries like Herman
> predict that industrial robots will open up more the next two years,
> looking at the newer models of Kuka, Comau, ABB and especially Barret
> (for small payloads).
The Barret is the only one that it's a real open robot. If I'm wrong, please
correct me.
> Our experience is that you'd like to get your
> hands dirty first, in order to measure if you're getting what the
> manufacturer promises. For example, the KUKA LBR has a dead time of
> 50ms using their 'real-time' interface running at a 12ms loop. But
> they promised they would fix it with the next software update.[*]
The kuka people says that you could connect with their interface at 12ms loop
(Kuka RSI-XML), and they are working on a new interface at 4ms. But, I must
say that we don't have one and we don't have done tests
Leo
survey of robots being used with Orocos
On Tue, 14 Jul 2009, Leopold Palomo-Avellaneda wrote:
> A Dimarts 14 Juliol 2009, Peter Soetens va escriure:
>> On Fri, Jul 3, 2009 at 15:19, John Yamokoski<yamokosk [..] ...> wrote:
>>> Greetings everyone,
>>>
>>> The Orocos website does a good job at showing a wide range of
>>> applications in which Orocos is used. But I was wondering, besides
>>> Kuka and the Mitsubishi PA-10 (what we currently have), what other
>>> manipulators, if any, are people controlling with Orocos. We have been
>>> considering the purchased of another manipulator with a greater
>>> payload capacity than the PA-10. So one of our requirements is that
>>> this new manipulator has a nice, open API. And ideally, we'd like one
>>> where someone has successfully integrated it with Orocos.
>>
>> It seems the irony is that although Orocos was initially developed for
>> serial robots, they are today the least represented. The reason for
>> this is implicitly in your mail: the standards interface to such
>> manipulators is/was so closed/slow that it is hardly necessary to
>> close a real-time loop/framework around them. Only hacking the
>> hardware opens them up to the level we want.
>
> An it's not an easy task. Sadly, AFAIK, the industrial robots (by now) only
> offers closed and hide interfaces to control their robots.
That's not really true! But the _performance_ of the open interfaces they
offer is often not good enough for advanced tasks.
>> Visionaries like Herman
>> predict that industrial robots will open up more the next two years,
>> looking at the newer models of Kuka, Comau, ABB and especially Barret
>> (for small payloads).
>
> The Barret is the only one that it's a real open robot. If I'm wrong, please
> correct me.
You are right, as far as I know.
>> Our experience is that you'd like to get your
>> hands dirty first, in order to measure if you're getting what the
>> manufacturer promises. For example, the KUKA LBR has a dead time of
>> 50ms using their 'real-time' interface running at a 12ms loop. But
>> they promised they would fix it with the next software update.[*]
>
> The kuka people says that you could connect with their interface at 12ms loop
> (Kuka RSI-XML), and they are working on a new interface at 4ms. But, I must
> say that we don't have one and we don't have done tests
The last news is that the 4ms has been released (we don't have it yet), and
on top of the faster rate it also got rid of the dead time of 2-3 cycles as
present in the current interface. (Disclaimer: that's what the KUKA
engineers told me; we have not yet had the chance to test.)
Herman
PS John: do you happen to have some published papers available about the
research at UFL on the X-rayed knee motion models?
survey of robots being used with Orocos
A Dimarts 14 Juliol 2009, Herman Bruyninckx va escriure:
> On Tue, 14 Jul 2009, Leopold Palomo-Avellaneda wrote:
> > A Dimarts 14 Juliol 2009, Peter Soetens va escriure:
> >> On Fri, Jul 3, 2009 at 15:19, John Yamokoski<yamokosk [..] ...> wrote:
> >>> Greetings everyone,
> >>>
> >>> The Orocos website does a good job at showing a wide range of
> >>> applications in which Orocos is used. But I was wondering, besides
> >>> Kuka and the Mitsubishi PA-10 (what we currently have), what other
> >>> manipulators, if any, are people controlling with Orocos. We have been
> >>> considering the purchased of another manipulator with a greater
> >>> payload capacity than the PA-10. So one of our requirements is that
> >>> this new manipulator has a nice, open API. And ideally, we'd like one
> >>> where someone has successfully integrated it with Orocos.
> >>
> >> It seems the irony is that although Orocos was initially developed for
> >> serial robots, they are today the least represented. The reason for
> >> this is implicitly in your mail: the standards interface to such
> >> manipulators is/was so closed/slow that it is hardly necessary to
> >> close a real-time loop/framework around them. Only hacking the
> >> hardware opens them up to the level we want.
> >
> > An it's not an easy task. Sadly, AFAIK, the industrial robots (by now)
> > only offers closed and hide interfaces to control their robots.
>
> That's not really true! But the _performance_ of the open interfaces they
> offer is often not good enough for advanced tasks.
What is not really true?
- only hacking the hardware to get the need level to work for us?
or
- the closed of hide interfaces to control the robots?
[...]
> >
> > The kuka people says that you could connect with their interface at 12ms
> > loop (Kuka RSI-XML), and they are working on a new interface at 4ms. But,
> > I must say that we don't have one and we don't have done tests
>
> The last news is that the 4ms has been released (we don't have it yet), and
> on top of the faster rate it also got rid of the dead time of 2-3 cycles as
> present in the current interface. (Disclaimer: that's what the KUKA
> engineers told me; we have not yet had the chance to test.)
where did you obtain that information? The Kuka people told me that the end of
July they will not have any available
Regards,
Leo
survey of robots being used with Orocos
On Tue, 14 Jul 2009, Leopold Palomo-Avellaneda wrote:
> A Dimarts 14 Juliol 2009, Herman Bruyninckx va escriure:
>> On Tue, 14 Jul 2009, Leopold Palomo-Avellaneda wrote:
>>> A Dimarts 14 Juliol 2009, Peter Soetens va escriure:
>>>> On Fri, Jul 3, 2009 at 15:19, John Yamokoski<yamokosk [..] ...> wrote:
>>>>> Greetings everyone,
>>>>>
>>>>> The Orocos website does a good job at showing a wide range of
>>>>> applications in which Orocos is used. But I was wondering, besides
>>>>> Kuka and the Mitsubishi PA-10 (what we currently have), what other
>>>>> manipulators, if any, are people controlling with Orocos. We have been
>>>>> considering the purchased of another manipulator with a greater
>>>>> payload capacity than the PA-10. So one of our requirements is that
>>>>> this new manipulator has a nice, open API. And ideally, we'd like one
>>>>> where someone has successfully integrated it with Orocos.
>>>>
>>>> It seems the irony is that although Orocos was initially developed for
>>>> serial robots, they are today the least represented. The reason for
>>>> this is implicitly in your mail: the standards interface to such
>>>> manipulators is/was so closed/slow that it is hardly necessary to
>>>> close a real-time loop/framework around them. Only hacking the
>>>> hardware opens them up to the level we want.
>>>
>>> An it's not an easy task. Sadly, AFAIK, the industrial robots (by now)
>>> only offers closed and hide interfaces to control their robots.
>>
>> That's not really true! But the _performance_ of the open interfaces they
>> offer is often not good enough for advanced tasks.
>
> What is not really true?
That industrial robots have no open interfaces.
> - only hacking the hardware to get the need level to work for us?
> or
> - the closed of hide interfaces to control the robots?
>
> [...]
>
>>>
>>> The kuka people says that you could connect with their interface at 12ms
>>> loop (Kuka RSI-XML), and they are working on a new interface at 4ms. But,
>>> I must say that we don't have one and we don't have done tests
>>
>> The last news is that the 4ms has been released (we don't have it yet), and
>> on top of the faster rate it also got rid of the dead time of 2-3 cycles as
>> present in the current interface. (Disclaimer: that's what the KUKA
>> engineers told me; we have not yet had the chance to test.)
>
> where did you obtain that information? The Kuka people told me that the end of
> July they will not have any available
>From the head of R&D at KUKA Augsburg, and from the KUKA research centre in
Belgium.
Herman
survey of robots being used with Orocos
A Dimarts 14 Juliol 2009, Herman Bruyninckx va escriure:
> On Tue, 14 Jul 2009, Leopold Palomo-Avellaneda wrote:
> > A Dimarts 14 Juliol 2009, Herman Bruyninckx va escriure:
> >> On Tue, 14 Jul 2009, Leopold Palomo-Avellaneda wrote:
> >>> A Dimarts 14 Juliol 2009, Peter Soetens va escriure:
> >>>> On Fri, Jul 3, 2009 at 15:19, John Yamokoski<yamokosk [..] ...> wrote:
> >>>>> Greetings everyone,
> >>>>>
> >>>>> The Orocos website does a good job at showing a wide range of
> >>>>> applications in which Orocos is used. But I was wondering, besides
> >>>>> Kuka and the Mitsubishi PA-10 (what we currently have), what other
> >>>>> manipulators, if any, are people controlling with Orocos. We have
> >>>>> been considering the purchased of another manipulator with a greater
> >>>>> payload capacity than the PA-10. So one of our requirements is that
> >>>>> this new manipulator has a nice, open API. And ideally, we'd like one
> >>>>> where someone has successfully integrated it with Orocos.
> >>>>
> >>>> It seems the irony is that although Orocos was initially developed for
> >>>> serial robots, they are today the least represented. The reason for
> >>>> this is implicitly in your mail: the standards interface to such
> >>>> manipulators is/was so closed/slow that it is hardly necessary to
> >>>> close a real-time loop/framework around them. Only hacking the
> >>>> hardware opens them up to the level we want.
> >>>
> >>> An it's not an easy task. Sadly, AFAIK, the industrial robots (by now)
> >>> only offers closed and hide interfaces to control their robots.
> >>
> >> That's not really true! But the _performance_ of the open interfaces
> >> they offer is often not good enough for advanced tasks.
> >
> > What is not really true?
>
> That industrial robots have no open interfaces.
Ok, I think that both understand the same for open (I guess). So, as I think
you are more informed than me. Please, could you enumerate some industrial
robots with "Open Interface"?
And, in my case I would like to have it so open that I could access at least
to the torques applied in each joint to develop my own controllers. To have
an open interface with a limited option could be an option in a short term,
but not a long term. In general, I would like to ear that your proposes from
the RAM(*) are considering by the industry. And, really I would be very
happy.:-)
> > - only hacking the hardware to get the need level to work for us?
> > or
> > - the closed of hide interfaces to control the robots?
> >
> > [...]
> >
> >>> The kuka people says that you could connect with their interface at
> >>> 12ms loop (Kuka RSI-XML), and they are working on a new interface at
> >>> 4ms. But, I must say that we don't have one and we don't have done
> >>> tests
> >>
> >> The last news is that the 4ms has been released (we don't have it yet),
> >> and on top of the faster rate it also got rid of the dead time of 2-3
> >> cycles as present in the current interface. (Disclaimer: that's what the
> >> KUKA engineers told me; we have not yet had the chance to test.)
> >
> > where did you obtain that information? The Kuka people told me that the
> > end of July they will not have any available
> >
> >From the head of R&D at KUKA Augsburg, and from the KUKA research centre
> > in Belgium.
Good to know.
(*) Robotics Software: The future Should be Open
survey of robots being used with Orocos
On Tue, 14 Jul 2009, Leopold Palomo-Avellaneda wrote:
> A Dimarts 14 Juliol 2009, Herman Bruyninckx va escriure:
>> On Tue, 14 Jul 2009, Leopold Palomo-Avellaneda wrote:
>>> A Dimarts 14 Juliol 2009, Herman Bruyninckx va escriure:
>>>> On Tue, 14 Jul 2009, Leopold Palomo-Avellaneda wrote:
>>>>> A Dimarts 14 Juliol 2009, Peter Soetens va escriure:
>>>>>> On Fri, Jul 3, 2009 at 15:19, John Yamokoski<yamokosk [..] ...> wrote:
>>>>>>> Greetings everyone,
>>>>>>>
>>>>>>> The Orocos website does a good job at showing a wide range of
>>>>>>> applications in which Orocos is used. But I was wondering, besides
>>>>>>> Kuka and the Mitsubishi PA-10 (what we currently have), what other
>>>>>>> manipulators, if any, are people controlling with Orocos. We have
>>>>>>> been considering the purchased of another manipulator with a greater
>>>>>>> payload capacity than the PA-10. So one of our requirements is that
>>>>>>> this new manipulator has a nice, open API. And ideally, we'd like one
>>>>>>> where someone has successfully integrated it with Orocos.
>>>>>>
>>>>>> It seems the irony is that although Orocos was initially developed for
>>>>>> serial robots, they are today the least represented. The reason for
>>>>>> this is implicitly in your mail: the standards interface to such
>>>>>> manipulators is/was so closed/slow that it is hardly necessary to
>>>>>> close a real-time loop/framework around them. Only hacking the
>>>>>> hardware opens them up to the level we want.
>>>>>
>>>>> An it's not an easy task. Sadly, AFAIK, the industrial robots (by now)
>>>>> only offers closed and hide interfaces to control their robots.
>>>>
>>>> That's not really true! But the _performance_ of the open interfaces
>>>> they offer is often not good enough for advanced tasks.
>>>
>>> What is not really true?
>>
>> That industrial robots have no open interfaces.
>
> Ok, I think that both understand the same for open (I guess). So, as I think
> you are more informed than me. Please, could you enumerate some industrial
> robots with "Open Interface"?
ALl the ones that Peter mentioned in his original post; Mitsubishi, ABB
(new generation), KUKA (via RSI), Comau (since 20 years already via an
interrupt routine on their PCI bus), Barret WAM (via a nice SDK).
> And, in my case I would like to have it so open that I could access at least
> to the torques applied in each joint to develop my own controllers.
_That_'s the "performance problem" I was talking about! :-) Forget about
that, except for the WAM.
> To have
> an open interface with a limited option could be an option in a short term,
> but not a long term. In general, I would like to ear that your proposes from
> the RAM(*) are considering by the industry. And, really I would be very
> happy.:-)
It's (one of) my responsibilities in the BRICS project to make concrete
proposals to robot manufacturers to make this happen, in a trade-off
between protecting their IP and their hardware. The liability issues are
huge: if they give you access to everything, _they_ will still remain
liable to some extent (in the current legislation of "industrial robots")
and _they_ will get the bad marketing blames when your controller kills
someone. We as academics should not underestimate the severity of these
issues...
>>> - only hacking the hardware to get the need level to work for us?
>>> or
>>> - the closed of hide interfaces to control the robots?
>>>
>>> [...]
>>>
>>>>> The kuka people says that you could connect with their interface at
>>>>> 12ms loop (Kuka RSI-XML), and they are working on a new interface at
>>>>> 4ms. But, I must say that we don't have one and we don't have done
>>>>> tests
>>>>
>>>> The last news is that the 4ms has been released (we don't have it yet),
>>>> and on top of the faster rate it also got rid of the dead time of 2-3
>>>> cycles as present in the current interface. (Disclaimer: that's what the
>>>> KUKA engineers told me; we have not yet had the chance to test.)
>>>
>>> where did you obtain that information? The Kuka people told me that the
>>> end of July they will not have any available
>>>
>>> From the head of R&D at KUKA Augsburg, and from the KUKA research centre
>>> in Belgium.
>
> Good to know.
>
> (*) Robotics Software: The future Should be Open
It should! (And it will.... At least one version of that future :-))
Herman
survey of robots being used with Orocos
A Dimecres 15 Juliol 2009, Herman Bruyninckx va escriure:
> On Tue, 14 Jul 2009, Leopold Palomo-Avellaneda wrote:
> > A Dimarts 14 Juliol 2009, Herman Bruyninckx va escriure:
> >> On Tue, 14 Jul 2009, Leopold Palomo-Avellaneda wrote:
> >>> A Dimarts 14 Juliol 2009, Herman Bruyninckx va escriure:
> >>>> On Tue, 14 Jul 2009, Leopold Palomo-Avellaneda wrote:
> >>>>> A Dimarts 14 Juliol 2009, Peter Soetens va escriure:
> >>>>>> On Fri, Jul 3, 2009 at 15:19, John Yamokoski<yamokosk [..] ...> wrote:
[....]
> >>> What is not really true?
> >>
> >> That industrial robots have no open interfaces.
> >
> > Ok, I think that both understand the same for open (I guess). So, as I
> > think you are more informed than me. Please, could you enumerate some
> > industrial robots with "Open Interface"?
>
> ALl the ones that Peter mentioned in his original post; Mitsubishi, ABB
> (new generation), KUKA (via RSI), Comau (since 20 years already via an
> interrupt routine on their PCI bus), Barret WAM (via a nice SDK).
>
> > And, in my case I would like to have it so open that I could access at
> > least to the torques applied in each joint to develop my own controllers.
>
> _That_'s the "performance problem" I was talking about! :-) Forget about
> that, except for the WAM.
That's the point !!!
You cannot do a force control without access to the torques I guess.
> > To have
> > an open interface with a limited option could be an option in a short
> > term, but not a long term. In general, I would like to ear that your
> > proposes from the RAM(*) are considering by the industry. And, really I
> > would be very happy.:-)
>
> It's (one of) my responsibilities in the BRICS project to make concrete
> proposals to robot manufacturers to make this happen, in a trade-off
> between protecting their IP and their hardware.
IP? International Protection?
> The liability issues are
> huge: if they give you access to everything, _they_ will still remain
> liable to some extent (in the current legislation of "industrial robots")
> and _they_ will get the bad marketing blames when your controller kills
> someone.
Good point, but I'm not a lawyer and I don't know specifically the legislation
about that. But I have thought that the protection against a people come from
another parts as jails, restricted area, etc. Really, I would like to think
that the security is _only_ difficulty (I don't underestimate it ...) for
the robot manufacturers to release "Open robots" ...
> We as academics should not underestimate the severity of these
> issues...
Of course, I agree .. I have seen our Stäubli robots moving to high speed and
I wouldn't like to be near them ....
[...]
> > (*) Robotics Software: The future Should be Open
>
> It should! (And it will.... At least one version of that future :-))
We have a lot of work .....
Regards,
Leo
survey of robots being used with Orocos
On Wed, 15 Jul 2009, Leopold Palomo-Avellaneda wrote:
> A Dimecres 15 Juliol 2009, Herman Bruyninckx va escriure:
>> On Tue, 14 Jul 2009, Leopold Palomo-Avellaneda wrote:
>>> A Dimarts 14 Juliol 2009, Herman Bruyninckx va escriure:
>>>> On Tue, 14 Jul 2009, Leopold Palomo-Avellaneda wrote:
>>>>> A Dimarts 14 Juliol 2009, Herman Bruyninckx va escriure:
>>>>>> On Tue, 14 Jul 2009, Leopold Palomo-Avellaneda wrote:
>>>>>>> A Dimarts 14 Juliol 2009, Peter Soetens va escriure:
>>>>>>>> On Fri, Jul 3, 2009 at 15:19, John Yamokoski<yamokosk [..] ...> wrote:
> [....]
>>>>> What is not really true?
>>>>
>>>> That industrial robots have no open interfaces.
>>>
>>> Ok, I think that both understand the same for open (I guess). So, as I
>>> think you are more informed than me. Please, could you enumerate some
>>> industrial robots with "Open Interface"?
>>
>> ALl the ones that Peter mentioned in his original post; Mitsubishi, ABB
>> (new generation), KUKA (via RSI), Comau (since 20 years already via an
>> interrupt routine on their PCI bus), Barret WAM (via a nice SDK).
>>
>>> And, in my case I would like to have it so open that I could access at
>>> least to the torques applied in each joint to develop my own controllers.
>>
>> _That_'s the "performance problem" I was talking about! :-) Forget about
>> that, except for the WAM.
>
> That's the point !!!
>
> You cannot do a force control without access to the torques I guess.
Of course you can! By adding a 'compliance control' loop around a velocity
loop, for example. This is the most common approach.
>>> To have
>>> an open interface with a limited option could be an option in a short
>>> term, but not a long term. In general, I would like to ear that your
>>> proposes from the RAM(*) are considering by the industry. And, really I
>>> would be very happy.:-)
>>
>> It's (one of) my responsibilities in the BRICS project to make concrete
>> proposals to robot manufacturers to make this happen, in a trade-off
>> between protecting their IP and their hardware.
>
> IP? International Protection?
Intellectual Property :-)
>> The liability issues are
>> huge: if they give you access to everything, _they_ will still remain
>> liable to some extent (in the current legislation of "industrial robots")
>> and _they_ will get the bad marketing blames when your controller kills
>> someone.
>
> Good point, but I'm not a lawyer and I don't know specifically the legislation
> about that. But I have thought that the protection against a people come from
> another parts as jails, restricted area, etc. Really, I would like to think
> that the security is _only_ difficulty (I don't underestimate it ...) for
> the robot manufacturers to release "Open robots" ...
Security for people is one thing, security for their own hardware is
another thing. You _can_ kill a robot when having access to everything, you
know. For example, burning motors is too easy to do, if you can control
current/torques but don't take into account the heating properties of your
actuators...
>> We as academics should not underestimate the severity of these
>> issues...
>
> Of course, I agree .. I have seen our Stäubli robots moving to high speed and
> I wouldn't like to be near them ....
>
> [...]
>
>>> (*) Robotics Software: The future Should be Open
>>
>> It should! (And it will.... At least one version of that future :-))
>
> We have a lot of work .....
Indeed :-)
Herman
survey of robots being used with Orocos
A Dimecres 15 Juliol 2009, Herman Bruyninckx va escriure:
> On Wed, 15 Jul 2009, Leopold Palomo-Avellaneda wrote:
> > A Dimecres 15 Juliol 2009, Herman Bruyninckx va escriure:
> >> On Tue, 14 Jul 2009, Leopold Palomo-Avellaneda wrote:
> >>> A Dimarts 14 Juliol 2009, Herman Bruyninckx va escriure:
> >>>> On Tue, 14 Jul 2009, Leopold Palomo-Avellaneda wrote:
> >>>>> A Dimarts 14 Juliol 2009, Herman Bruyninckx va escriure:
> >>>>>> On Tue, 14 Jul 2009, Leopold Palomo-Avellaneda wrote:
> >>>>>>> A Dimarts 14 Juliol 2009, Peter Soetens va escriure:
> >>>>>>>> On Fri, Jul 3, 2009 at 15:19, John Yamokoski<yamokosk [..] ...>
> >>>>>>>> wrote:
> >
> > [....]
> >
> >>>>> What is not really true?
> >>>>
> >>>> That industrial robots have no open interfaces.
> >>>
> >>> Ok, I think that both understand the same for open (I guess). So, as I
> >>> think you are more informed than me. Please, could you enumerate some
> >>> industrial robots with "Open Interface"?
> >>
> >> ALl the ones that Peter mentioned in his original post; Mitsubishi, ABB
> >> (new generation), KUKA (via RSI), Comau (since 20 years already via an
> >> interrupt routine on their PCI bus), Barret WAM (via a nice SDK).
> >>
> >>> And, in my case I would like to have it so open that I could access at
> >>> least to the torques applied in each joint to develop my own
> >>> controllers.
> >>
> >> _That_'s the "performance problem" I was talking about! :-) Forget about
> >> that, except for the WAM.
> >
> > That's the point !!!
> >
> > You cannot do a force control without access to the torques I guess.
>
> Of course you can! By adding a 'compliance control' loop around a velocity
> loop, for example. This is the most common approach.
But I think, that you need a fast interface to close the loop, with a few ms,
So, if you don't have access to the torques and your interface to the velocity
and positions is slow .. your life will not be easy to make control, no?
But maybe I'm wrong ...
> >>> To have
> >>> an open interface with a limited option could be an option in a short
> >>> term, but not a long term. In general, I would like to ear that your
> >>> proposes from the RAM(*) are considering by the industry. And, really I
> >>> would be very happy.:-)
> >>
> >> It's (one of) my responsibilities in the BRICS project to make concrete
> >> proposals to robot manufacturers to make this happen, in a trade-off
> >> between protecting their IP and their hardware.
> >
> > IP? International Protection?
>
> Intellectual Property :-)
:-)
> >> The liability issues are
> >> huge: if they give you access to everything, _they_ will still remain
> >> liable to some extent (in the current legislation of "industrial
> >> robots") and _they_ will get the bad marketing blames when your
> >> controller kills someone.
> >
> > Good point, but I'm not a lawyer and I don't know specifically the
> > legislation about that. But I have thought that the protection against a
> > people come from another parts as jails, restricted area, etc. Really, I
> > would like to think that the security is _only_ difficulty (I don't
> > underestimate it ...) for the robot manufacturers to release "Open
> > robots" ...
>
> Security for people is one thing, security for their own hardware is
> another thing. You _can_ kill a robot when having access to everything, you
> know. For example, burning motors is too easy to do, if you can control
> current/torques but don't take into account the heating properties of your
> actuators...
you can repair a killed robot, but not a person killed (I guess...)
Leo
survey of robots being used with Orocos
On Wed, 15 Jul 2009, Leopold Palomo-Avellaneda wrote:
> A Dimecres 15 Juliol 2009, Herman Bruyninckx va escriure:
>> On Wed, 15 Jul 2009, Leopold Palomo-Avellaneda wrote:
>>> A Dimecres 15 Juliol 2009, Herman Bruyninckx va escriure:
>>>> On Tue, 14 Jul 2009, Leopold Palomo-Avellaneda wrote:
>>>>> A Dimarts 14 Juliol 2009, Herman Bruyninckx va escriure:
>>>>>> On Tue, 14 Jul 2009, Leopold Palomo-Avellaneda wrote:
>>>>>>> A Dimarts 14 Juliol 2009, Herman Bruyninckx va escriure:
>>>>>>>> On Tue, 14 Jul 2009, Leopold Palomo-Avellaneda wrote:
>>>>>>>>> A Dimarts 14 Juliol 2009, Peter Soetens va escriure:
>>>>>>>>>> On Fri, Jul 3, 2009 at 15:19, John Yamokoski<yamokosk [..] ...>
>>>>>>>>>> wrote:
>>>
>>> [....]
>>>
>>>>>>> What is not really true?
>>>>>>
>>>>>> That industrial robots have no open interfaces.
>>>>>
>>>>> Ok, I think that both understand the same for open (I guess). So, as I
>>>>> think you are more informed than me. Please, could you enumerate some
>>>>> industrial robots with "Open Interface"?
>>>>
>>>> ALl the ones that Peter mentioned in his original post; Mitsubishi, ABB
>>>> (new generation), KUKA (via RSI), Comau (since 20 years already via an
>>>> interrupt routine on their PCI bus), Barret WAM (via a nice SDK).
>>>>
>>>>> And, in my case I would like to have it so open that I could access at
>>>>> least to the torques applied in each joint to develop my own
>>>>> controllers.
>>>>
>>>> _That_'s the "performance problem" I was talking about! :-) Forget about
>>>> that, except for the WAM.
>>>
>>> That's the point !!!
>>>
>>> You cannot do a force control without access to the torques I guess.
>>
>> Of course you can! By adding a 'compliance control' loop around a velocity
>> loop, for example. This is the most common approach.
>
> But I think, that you need a fast interface to close the loop, with a few ms,
> So, if you don't have access to the torques and your interface to the velocity
> and positions is slow .. your life will not be easy to make control, no?
> But maybe I'm wrong ...
You are not wrong...
>>>>> To have
>>>>> an open interface with a limited option could be an option in a short
>>>>> term, but not a long term. In general, I would like to ear that your
>>>>> proposes from the RAM(*) are considering by the industry. And, really I
>>>>> would be very happy.:-)
>>>>
>>>> It's (one of) my responsibilities in the BRICS project to make concrete
>>>> proposals to robot manufacturers to make this happen, in a trade-off
>>>> between protecting their IP and their hardware.
>>>
>>> IP? International Protection?
>>
>> Intellectual Property :-)
>
> :-)
>
>>>> The liability issues are
>>>> huge: if they give you access to everything, _they_ will still remain
>>>> liable to some extent (in the current legislation of "industrial
>>>> robots") and _they_ will get the bad marketing blames when your
>>>> controller kills someone.
>>>
>>> Good point, but I'm not a lawyer and I don't know specifically the
>>> legislation about that. But I have thought that the protection against a
>>> people come from another parts as jails, restricted area, etc. Really, I
>>> would like to think that the security is _only_ difficulty (I don't
>>> underestimate it ...) for the robot manufacturers to release "Open
>>> robots" ...
>>
>> Security for people is one thing, security for their own hardware is
>> another thing. You _can_ kill a robot when having access to everything, you
>> know. For example, burning motors is too easy to do, if you can control
>> current/torques but don't take into account the heating properties of your
>> actuators...
>
> you can repair a killed robot, but not a person killed (I guess...)
Yes. But, for a company, repairing a tainted image is also extremely tough...
Herman