Re: Orocos Comments

On Tue, 26 Dec 2000, Paolo Fiorini wrote:

[...]
> How to overcome the issue of proprietary information, how can we integrate
> with robot hardware if manufacturers don't want. How can we make it robot
> independent? Are we also developing a "universal hardware controller"? Are
> we planning some reverse engineering to come up with drivers for
> "unfriendly" robots? in linux this takes years....
You raise a _very_ critical point here... and I have so good answer to
it. I don't expect any real openness from the traditional robot
manufacturers real soon (that's why I want to start with OROCOS :-) ),
and indeed, we've experienced that `hacking' a robot system is much
more difficult that reverse engineering a device driver. On the other
hand, some manufacturers allow already some low-bandwidth integration,
i.e., at about 20Hz and with some dead times of several tens of
milliseconds. This is for _manipulator robots_; the situation is, I
think, much better with mobile robots. (Am I correct here?)

> In the RT package, don't you think that 1KHz is somehow limitative in high
> performance cases? the scalability of this workpackage will be very
> challenging because we will need to address also communication and delay
> issues and performance may degrade significantly.
Communication should _not_ be done in real time, I think. Unless
processes are on the same motherboard or computer bus, in which case
the normal real-time IPC (InterProcess Communication) function calls
will be sufficient. 1KHz is just an order of magnitude. I know, for
example, that the servo of the KUKA robots runs at 2 KHz. Normal PC
architectures have latencies of about 30 microseconds, so you need
DSPs or so to run any non-trivial algorithms at much higher rate than
a couple of KHz. Did you have any particular applications in mind that
require much higher sample rates?


> In the generic template WP, the comparison with the PCMCIA project is
> optimistic, the robotic world is much more heterogeneous than the PC world
> and much less tolerant.
I'm not sure about this... There is not so much material already
available, but on the other hand, there are a much smaller number of
sensors to be interfaced.

> how do you plan to overcome the lack of cooperation from manufacturers?
If they really don't want to cooperate, than reverse engineering is
the only way :-( I would however try very hard to make the
cooperative. Of course, this will succeed more easily as soon as
OROCOS has created something useful already, and has reached
a non-neglectable numbers of users. At this time, there is nothing
yet...

> How do we plan to address liability issues? assuming that we manage to get
> enough information to "replace" the manufacturer original software with
> ours, who will be responsible for any malfunction?
Open Source software cannot take any liability...it never does. On the
other hand, service companies using this software _can_ have full
liability contracts.

> What incentive will the manufacturer have to test some OSF software on its
> hardware?
I am not targetting the traditional manufacturers, but rather
independent service companies that will start using the software (if
it really proves useful). But I agree that all this is not a simple
thing to do, because robots are still far from being a commodity
product. However, this situation is again very different beween
manipulator robots and mobile robots. And, moreover, OROCOS can also
serve the purposes of add-on robotic tools very well: for example, you
start up a company that builds a vision-controller deburring tool, and
in it you can use OROCOS software while you communicate with the
`master' arm through its proprietary interface.

> Would not be "wiser" to start proposing a medium-high software level,
> providing functions not normally supplied by the manufacturers, instead of
> proposing to replace the proprietary control software? in this way we could
> start building a relation with the manufactuers and then move to lower
> level software.
This is probably the way to go. But, I have already another project in
the making (on local Belgian scale) where machine builders have asked
us to make an open source machine controller :-)

Thanks for the critical remarks! I will take them into account
somewhere in the proposal, where the risks of the project are to be
discussed.

Best regards,

Herman

-- 
[email protected]
We hire Linux programmer: <http://www.mech.kuleuven.ac.be/~bruyninc/jobs>