Orocos Comments
Paolo Fiorini <[email protected]>
| Newsgroups | gmane.science.robotics.orocos.user |
|---|---|
| Message-ID | <[email protected]> |
Dear Herman and mailing list Members, I have read the proposal and I must congratulate Herman for his work, rarely a proposal starts with so much well organized material. As I mentioned earlier, I am very interested in the project, however, there are a few points that, in my opinion, need be addresses to overcome the commission potential criticism. Here are a few comments to Part B. 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.... 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. 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. Do you remember the difficulties in getting information about the meteor frame grabber to write a general purpose driver? how do you plan to overcome the lack of cooperation from manufacturers? 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? if we follow OSF policy of assuming no liability, will that limit the use of the software? What incentive will the manufacturer have to test some OSF software on its hardware? Who will carry out testing and integration, a robot is much more expensive than a PC and there is no IBM-compatible robot? 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. My best regards, paolo === Paolo Fiorini, PhD Jet Propulsion Laboratory Dip. Scientifico e Tecnologico California Institute of Technology Universita' di Verona Ph: +1 818 354 9061 +39 045 802 7963 Fx: +1 818 393 5007 +39 045 802 7928 http://robotics.jpl.nasa.gov/people/fiorini http://www.sci.univr.it/~fiorini