This is a thread started on the Orca mailinglist (triggered by some events
on ICRA07 about "microsoft robotics studio", the open source answer to it,
and the European project Rosta
liberty of crossposting my reply also on the orocos developers mailinglist,
because the topic is really worth it....
On Fri, 27 Apr 2007, amak4609 [..] ... wrote:
> in general, is it worth trying to promote some sort of
> cooperation/standardization in robotics? i think so, even if it hasn't
> been super successful so far.
I agree with you: the various open source projects should do _something_ now
to start real integration...
> regarding this particular RoSta 'project'. first of all, as the organizers
> have stressed several times it's not a project but a 'coord. action'. the
> difference is in the levels of funding and expected results. there's just
> enough money to discuss things, come up with requirements, etc. They also
> have funding for 1 full-time person to evaluate different options against
> their requirements. at the end of 2 years one possible outcome would be to
> actually propose one or several real projects.
> If you want my opinion... it makes no sense to say "let's standardize
> robotics". you have to identify things which makes sense to standardize,
> in what domain, for what purpose.
> here a few ideas:
> 1. static data formats, file formats, etc.
> these are definitely possible to standardize across a bunch of application
> if not the whole field. e.g. data structures, log file formats, coordinate
> systems. this is easy to do and would be very valuable, especially if it
> leads to good 'standard' data sets. (someone brought up config file format
> as another candidate but I'm not sure how it would work.)
These are certainly the best and easiest things to start with. I will
profit from the CARE opportunity and meet with Klas Nilsson from Lund
University (one of the CARE partners) to sit together for two days (May
21-22) and try to kickstart this effort...
Any inputs welcome! Maybe we should ask CARE to add a wiki or mailinglist
for this purpose...? I asked them at the ICRA, and they are willing to do
so. Anyway, having a concrete 'representation' from the open source
projects would help a lot to get things to move fast: both for ourselves as
for CARE. As you said yourself: most of the standardization effort is about
"just do it" and not so much about science anymore....
With respect to log formats: I just found out about TimeDoctor
which is an Eclipse plugin for visualising logs from the Linux kernel. but
I think this infrastructure could be used for logging of robotics events
I think the open source projects should select two or three of these
"infrastructure" projects to standardize on, in order to ease integration.
(And we have to get our "Not Invented In This Project" egos out of the way...)
My concrete suggestions are:
- Eclipse as the IDE.
- Blender as 3D visualisation, simulation and programming tool.
(See my more concrete suggestions about Blender here:
> 2. libraries
> good implementations of key algorithms are sorely needed. this came up
> several times on the Player list and recently Alex B. and Ben were talking
> about it as well. if someone (an open-source group or a company) wrote a
> good localization library then it would be quickly integrated into
I fully agree again. That's why the Orocos project took the approach to
separate functionalities (kinematics, Bayesian filters, ...) into separate
libraries, instead of hard-wiring them in the realtime framework.
> 3. communication
> my feeling is that technically it is be possible to implement a large
> portion of the robotic field with one middleware (needeless to say, i
> believe that middleware is essential here). :) however, this is a
> 'religious' issue which cannot and should not be decided by a committee.
> let the 'market' sort it out.
I agree with the fact that there is no "one size fits all" approach. And
that's where the open source world has a potential competitive advantage
with respect to MS. _But_, then we have to make sure that interested users
can "shop" at one place, have information about which use cases are best
for which kind of application, and that they can download packaged
solutions that integrate with the "IDE" and "3D" infrastructure tools that
we should begin to use...
> 4. architecture
> cannot be standardized in general (and for this reason Orca does not
> specify any). however, for a particular application, e.g. tight
> closed-loop control, it is possible and probably useful.
> 6. binary compatibility of components
> this is the holy grail of standardization but requires agreeing on
> everything above. it's achieved within individual component-based
> frameworks but i don't think anybody wants or can pick a single winner at
> this point.
There will be no single winner: various use cases require various
solutions. What we have to do is (i) to identify the various use cases, and
(ii) to provide easy packaging for each of them.
K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group