Hi Daniel,

At the time we designed and prototyped the ROS communications system,
Google's Protocol Buffers wasn't yet available. We ended up deciding
not to switch to it IIRC because we liked our own way of doing
hierarchical, cross-package composition of messages and the syntax of
creating/using arrays. There were some other reasons too, that
unfortunately I can't remember at the moment, but I'm sure others will
add to this discussion. And of course it would be awesome for someone
to create a ROS message <--> Protocol Buffers bridge generator :)

You're definitely correct that there are many middleware solutions out
there. The ROS system, like all of them, is a collection of tradeoffs,
which are good or bad depending on the requirements of the task. For
example, we don't touch security at all, figuring that is best left to
people who actually do security, like VPN's. In general, ROS is
significantly less specified than formal systems like CORBA. This can
be good or bad, depending on your software-engineering
background/requirements and coding style. While contracts and other
higher-level constructs could be built using ROS as a lower-level
transport, they (intentionally) aren't first-class objects -- the ROS
communications layer is meant to be a lowest-common-denominator, the
type of code that you would have to write anyway if you wanted to
implement your own publish/subscribe system.

If you're looking for a fully-featured middleware system, ICE (
http://www.zeroc.com/overview.html  ) is definitely worth a look.
However, note that an important consideration with middleware is
licensing, since all code using the system has to link against it.
Many other systems are GPL or require a separate license for
commercial use. We wrote the ROS communications core from scratch in
part to ensure that it is clean BSD from a licensing standpoint.

HTH,
Morgan


On Thu, Dec 2, 2010 at 11:56 PM, Daniel Stonier <d.stonier@gmail.com> wrote:
> I feel a bit newbish asking this because I'm a robotics trained
> programmer than a university trained one, so no real experience with
> networked programming apart from opening and closing the odd posix
> socket, hopefully you won't hold it against me ;)
>
> Why exactly did RoS build its own, fairly extensive communications
> system? I love the fact that it
>
> 1) Abstracts data types in simple text files.
> 2) Mostly handles serialisation in a cross platform way.
> 3) Framework allows for compile time validation of callbacks (no void
> pointers for data).
> 4) No bottleneck at the server.
>
> However, was there nothing that suited ros requirements previously?
> I'm guessing no since ros usually avoids reinvention of the wheel.
> Just seems odd given that it appears to be such a fundamental
> requirement for alot of projects.
>
> So, to the point - we have another group (non-control, strictly
> software) here who have a real need for upgrading their communications
> systems. They'll also be connecting with our control boards. The above
> requirements are ideally suited to what they want and ros
> communications would seem to fit their need, except for the fact that
> we can't realistically build the miminum for an roscore outside of
> linux yet.
>
> Are there currently any alternatives to ros for this? I've done a bit
> of testing with google protobuffs, but only to do serialisation on
> large data type dumps to files. You'd still need a framework on top of
> this to provide the other requirements.
>
> Also, would there be any disadvantages to using ros communications for
> a purely networking project's need?
>
> Cheers,
> Daniel.
>
> --
> Phone : +82-10-5400-3296 (010-5400-3296)
> Home: http://snorriheim.dnsdojo.com/
> Yujin Robot: http://www.yujinrobot.com/
> Embedded Ros : http://www.ros.org/wiki/eros
> Embedded Control Libraries: http://snorriheim.dnsdojo.com/redmine/wiki/ecl
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>