I'm really excited about using a more mature middleware, like DDS, for more
configurable QoS. The amount of data that gets thrown around in a typical
ROS system can be massive and have a wide range of necessary demands for
the data it subscribes to:
- Closed loop controllers often need low latency and high QoS but
usually require low bandwidth
- Perception like RGBD sensing requires high bandwidth but can tolerate
high latency and poor QoS
- AI/high level planning is often painfully in need of throttling
mechanisms (DDS can do this out of the box!)
- You shouldn't have to choose between having visualization and your
robot moving smoothly, there should be a non-trivial inbetween
- If I just want to know some static transform in my URDF at some random
location in my application, I shouldn't have to hook up to the /tf
firehose! (even though I pick on /tf, this is a general problem)
I've been using ROS since C-turtle, but despite the improvements, it still
feels like it takes a little ROS black-magic to get things working
smoothly. Rarely have I had a project where I didn't have to redesign some
aspect of the communication because I sloppy about how I was routing it. I
still don't see it as a framework capable of designing very reliable
systems. Furthermore, these problems will only get worse as
sensors/actuators/algorithms become more sophisticated and increase their
demands.
The time spent redesigning communication is just as much lost time as a
learning a slightly more complicated communication mechanism. And
honestly, I think the learning curve is really only going to be as
difficult as the ROS implementation makes it. The model is still, for the
most part, similar, and so an interface which emulates ROS basic
communication can probably be written. While I understand the concerns of
people who prioritize ease of use, I'd be disappointed if ROS didn't
eventually improve its communication mechanism.
Also, having a low-footprint solution for embedded system communication
would be really nice. There still doesn't seem to be a commonly accepted
standard for this: rosc is in alpha, simple_message is still in
development, apparently people are already using DDS...
-Kelsey
On Sat, Feb 15, 2014 at 1:56 AM, Georg Bartels <
georg.bartels@cs.uni-bremen.de> wrote:
> +1 from me for the following paragraph from Ben:
>
>
> > What I love about ROS is that it has so far been focused on the software
> experience rather than the hardware. It almost seems like a contradiction
> to be worrying about QoS when much of your code is Python scripts and other
> higher-level languages (instead of C) running on Ubuntu (instead of a
> RTOS). I'm certainly not saying that QoS is unimportant -- it would be very
> nice to have -- but I would place simplicity as a higher priority. Maybe
> ROS Industrial would be a better place for DDS or baked-in QoS?
> >
> > -Ben
> >
> > ________________________________________
> > From: ros-users-bounces@lists.ros.org [ros-users-bounces@lists.ros.org]
> On Behalf Of Brian Gerkey [gerkey@osrfoundation.org]
> > Sent: Thursday, February 13, 2014 3:56 AM
> > To: User discussions
> > Subject: [ros-users] ROS & DDS
> >
> > hi,
> >
> > As we work on improving the communications middleware within ROS, one
> > of the approaches that has come up repeatedly is DDS (Data
> > Distribution Service; http://portals.omg.org/dds/). There are lots of
> > positive aspects of DDS as a middleware, and of course some tradeoffs
> > (e.g., in exchange for lots of features in the message transport, the
> > API is incredibly verbose; while there are open source
> > implementations, there's not the feeling of an active community doing
> > development on them).
> >
> > We'd like to understand what the level of interest is within the ROS
> > community for DDS support.
> >
> > So, for those of you who already know something about DDS (especially
> > if you have experience using it), here are some questions to start a
> > discussion. Don't feel obliged to answer every question, and also
> > feel free to answer questions not asked here. If you prefer, you can
> > reply directly to me, and we'll anonymize your comments before
> > potentially sharing them.
> >
> > What's your opinion of DDS (good, bad, ugly, other)? If you like DDS,
> > why? If you don't like it, why not?
> >
> > How would you compare DDS to the ROS middleware?
> >
> > Do you see others in your field using DDS? Have you ever wished that
> > ROS could "speak DDS"? Have you already used DDS in combination with
> > ROS?
> >
> > thanks,
> > brian.
> > _______________________________________________
> > ros-users mailing list
> > ros-users@lists.ros.org
> > http://lists.ros.org/mailman/listinfo/ros-users
> >
> > UTS CRICOS Provider Code: 00099F
> > DISCLAIMER: This email message and any accompanying attachments may
> contain confidential information.
> > If you are not the intended recipient, do not read, use, disseminate,
> distribute or copy this message or
> > attachments. If you have received this message in error, please notify
> the sender immediately and delete
> > this message. Any views expressed in this message are those of the
> individual sender, except where the
> > sender expressly, and with authority, states them to be the views of the
> University of Technology Sydney.
> > Before opening any attachments, please check them for viruses and
> defects.
> >
> > Think. Green. Do.
> >
> > Please consider the environment before printing this email.
> > _______________________________________________
> > ros-users mailing list
> > ros-users@lists.ros.org
> > http://lists.ros.org/mailman/listinfo/ros-users
> >
>
> _______________________________________________
> ros-users mailing list
> ros-users@lists.ros.org
> http://lists.ros.org/mailman/listinfo/ros-users
>
_______________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users
(text/plain)