Re: [Ros-sig-mm] Fwd: connection state and transports

Top Page
This message is part of the following thread:
Mthe complete thread tree sorted by date
M+\Armstrong-Crews, Nicholas - 0447 - MITLL at <-
MMM 
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Ken Conley
Date:  
To: Armstrong-Crews, Nicholas - 0447 - MITLL
CC: ros-sig-mm@code.ros.org
Subject: Re: [Ros-sig-mm] Fwd: connection state and transports
On Thu, Sep 22, 2011 at 9:40 AM, Armstrong-Crews, Nicholas - 0447 -
MITLL <> wrote:
> PS - the simplest discretization of network health is network up/down (equivalently, "Rosie can talk to Bender" or "she can't"); maybe that's all we care about for now, but let's remember there's more to it than that.

I'm in favor of the simplest expression as possible -- ultimately, the
clients will have to write code that does something with this
information. It complicates a system if every node I write to attempt
to heuristically and independently change its behavior based on
perceived network health; similarly, it complicates a system if the
networking layer has too much state that affects behavior, as I now
have to understand that additional state to figure out what is going
wrong.

- Ken

> -----Original Message-----
> From: [mailto:ros-sig-mm-bounces@code.ros.org] On Behalf Of Armstrong-Crews, Nicholas - 0447 - MITLL
> Sent: Thursday, September 22, 2011 12:29 PM
> To:
> Subject: Re: [Ros-sig-mm] Fwd: connection state and transports
>
> Just to clear up any misconceptions...
>
> When I refer to "network performance," I mean the constraints placed on the performance of an application by the network physical layer (e.g., the maximum throughput I can achieve given that my 802.11g network card reports a 5Mbps connection with a signal strength of -65 dBm). Maybe a better term is "network health." As Ken mentioned, there are other metrics of performance (e.g. latency) and we should be specific about what we're optimizing.
>
> Of course, anything transport layer and up is subject to these constraints (I can't download at 100Gbps over 802.11g). These higher layers might impose more stringent constraints (e.g., ROSTCP adds packet overhead, reducing throughput by 10%). But in my mind, the focus of this SIG is not to reduce transport overhead from 10% to 9%. So when I say "performance," this is not what I mean.
>
> The thing is, with mobile robots talking over wifi, the network health changes as the robots move around! That's why we need network monitoring. In another use case, if we're talking about ROS machines connected to the internet over ethernet, then network congestion is a maybe a bigger culprit for changing network health... but still necessary to monitor. Client applications (nodes) may have to change their behavior as a result of knowing the network health.
>
> I know flaky wifi is not the focus of this SIG either, but in my experience it is the single largest impediment to viable multi-robot applications with ROS. In contrast, it sounds like we all came up with workable multi-master solutions on our own. So I suggest we either: 1) just grab one of those, make it bullet-proof, and stick it into Fuerte; or 2) re-cast this SIG as multi-robot/multi-device and consider *all* the issues associated therewith.
>
> -N
>
> -----Original Message-----
> From: [mailto:ros-sig-mm-bounces@code.ros.org] On Behalf Of Ken Conley
> Sent: Thursday, September 22, 2011 11:12 AM
> To:
> Subject: [Ros-sig-mm] Fwd: connection state and transports
>
> Re-forwarding the thread (original was sent w/o subscribers active)
>
>
> ---------- Forwarded message ----------
> From: Ken Conley <>
> Date: Wed, Sep 21, 2011 at 12:22 PM
> Subject: Re: [Ros-sig-mm] connection state and transports
> To: Jeff Rousseau <>
> Cc: "" <>
>
>
> On Wed, Sep 21, 2011 at 11:31 AM, Jeff Rousseau <>
> <> wrote:
>>> -----Original Message-----
>>> From: Ken Conley [mailto:kwc@willowgarage.com]
>>> Sent: Wednesday, September 21, 2011 1:33 PM
>>> To: Jeff Rousseau <>
>>> Cc: Daniel Stonier; Jonathan Fink; Bill Morris; ;
>>>
>>> Subject: Re: Fuerte SIG: Multi-Master Support
>>>
>>> On Wed, Sep 21, 2011 at 6:41 AM, Jeff Rousseau <>
>>> <> wrote:
>>> > AFAIK, rospy and rosjava both don't even implement the UDP transport
>>> yet--so would it be out of the question to add simple connection state
>>> support into the roscpp UDP Transport implementation?
>>>
>>> The current UDPROS protocol provides for a 'PING' heartbeat packet:
>>>
>>> http://www.ros.org/wiki/ROS/UDPROS
>>>
>>> I'd have to read the source of roscpp to see the current way that it is
>>> consumed.
>>
>> That's good news.  So if we have some connection state information already in the ROSUDP implementation, we can expose it.  I guess the next question is how should it be exposed?
>>
>>>
>>> FYI: I delayed on implementing UDP in rospy mainly to allow roscpp to
>>> understand the UDP use case better.  For example, some frameworks don't
>>> allow messages over the max UDP framesize to be transmitted, whereas
>>> roscpp does fragment packets -- that decision complicates implementation,
>>> and it's unclear that it provides much benefit.  So, on one end of the
>>> spectrum you have single-message-inside UDP frame protocol, and on the
>>> other end you have something like Reliable UDP, which basically attempt to
>>> provide faster startup and greater bandwidth than TCP.
>>
>> So currently roscpp's UDP implementation is more in the RUDP and we may have to backtrack a bit to a simpler single-message per frame?  I'll also have to dig up the roscpp code to see whats happening behind the scenes... Might this also be why Nick was describing his UDP performance through ROS as "not so great"?
>
> I wouldn't go quite so far as to say it's more RUDP.  RUDP is
> basically a different TCP, UDPROS is definitely an 'unreliable'
> transport.  I'm merely positing that, based on our use cases, we may
> wish to simplify the transport.  Simplification would make it easier
> to implement across all client libraries, and potentially deliver
> similar "performance" (see below).  It would also allow us to throw an
> error to the user that basically says "don't use large messages with
> UDPROS", which is probably good advice.  The other direction is to
> attempt to make UDPROS packet fragmentation perform better over wifi,
> at which point we might be better switching to ZeroMQ (or OpenPGM,
> which ZeroMQ uses).
>
> I don't know what Nick was referring to, but it's important to be
> specific about what 'performance' means (latency, CPU usage,
> bandwidth, reliability, etc...).   UDPROS is as about as good as it
> can be on latency and bandwidth.  It doesn't score well on
> reliability.  If we accept the fact that we don't want a good
> reliability score, we can make it even simpler and better guide users
> on good use practices.
>
> I'll point to OpenPGM's 'critique' whitepaper, which generally covers
> the main issues around UDP-ish protocols:
>
> http://code.google.com/p/openpgm/wiki/OpenPgmCritique
>
>  - Ken
>
>>> > ZeroMQ is nice and all, but really for multi-master all we need is a way of
>>> finding out when our connection goes bad (multicast support is nice, but not
>>> necessary).  I don't think making a language dependent transport is really a
>>> good idea, especially when some of our best supported languages don't
>>> even implement UDP yet.
>>>
>>> I'm not sure what you mean by language-dependent transport.  ZeroMQ has
>>> bindings in all the languages in the best supported languages, though it does
>>> require a native interface to the C library.
>>
>> Sorry for the confusion.  I merely meant that the lack of native language implementations (ie not C wrapped) makes it seem like less of a good idea (especially if java/Android is to be one of the first-class supported languages).  Although I didn't state it before, it also being LGPL and not BSD makes it mildly annoying since it would be such a low-level building block.  These issues aren't deal-breakers; I just think the pros/cons should be heavily considered.
>>
>>>
>>>  - Ken
>>>
>>> >
>>> >> -----Original Message-----
>>> >> From: Ken Conley [mailto:kwc@willowgarage.com]
>>> >> Sent: Monday, September 19, 2011 12:56 PM
>>> >> To: Daniel Stonier
>>> >> Cc: Jonathan Fink; Jeff Rousseau <>; Bill Morris;
>>> >> ;
>>> >> Subject: Re: Fuerte SIG: Multi-Master Support
>>> >>
>>> >> On Sat, Sep 17, 2011 at 10:01 AM, Daniel Stonier
>>> >> <>
>>> >> wrote:
>>> >> > Hi all,
>>> >> > I can feel the lag across the pond here in Korea! Go to sleep and
>>> >> > the discussion gets quite lively.
>>> >> > Our current scenario and its relevance with respect to multimaster
>>> >> > : http://www.ros.org/wiki/fuerte/Planning/Multimaster/Concert
>>> >> > Some notes on a few of the comments in this thread:
>>> >> > ZeroMQ: I remember looking at this for the higher level
>>> >> > communications framework before we got started. I haven't used or
>>> >> > tested it enough to make a qualified opinion, but it looks solid as
>>> >> > a codebase that could sit underneath the ros serialisation and
>>> >> > comms libraries. Its alot of work writing, bugfixing and
>>> >> > maintaining all that raw socket code, for all those platforms and
>>> >> > languages. Whether there are serious enough advantages to embark on
>>> >> > such a big shift I don't know. In what ways might we take advantage
>>> >> > of a multicast transport? That might be interesting for some high
>>> bandwidth 1-n publications.
>>> >>
>>> >> If we supported ZeroMQ, it would be as an optional backend -- all of
>>> >> the Java/Python/etc... support is done via bindings on the C library,
>>> >> so it would limit the current versatility of rospy/rosjava (there is
>>> >> an Android NDK option,
>>> >> but...)
>>> >>
>>> >> multicast is both useful and non-useful, in the same way that
>>> >> zeroconf is.  It only really works if you're network supports it,
>>> >> which, in my experience, means it works at home but it doesn't work at
>>> work.
>>> >> multicast would be very useful for ros topics like /tf and /rosout,
>>> >> which create a large number of stateful connections currently.  In
>>> >> general, multicast would be useful for any topic connections across a
>>> >> wifi boundary, for the same stateless reasons.
>>> >>
>>> >> > Master Syncs: I like these, they fit with the concert/building
>>> >> > manager solution well and the MasterSync api is relatively easy to
>>> >> > use. One point - it currently works with the robot's ros master
>>> >> > hidden, but the concert/building manager's ros master exposed.
>>> >> > Which means it doesn't fit as a means directly syncing between two
>>> >> > robots that want to maintain that security layer (hidden ros masters).
>>> >> >
>>> >> > We're probably not all that interested in this as a feature, but I
>>> >> > suspect others might - would removing the master sync's remote
>>> >> > connection to a specialised xmlrpc server which relays commands to
>>> >> > it's ros master be a good approach? You could then zeroconf
>>> >> > advertise this server which has limited functionality rather than
>>> >> > the ros master itself. Maybe that's just complicating things too much.
>>> >>
>>> >> It's complicated enough that I'm not fully parsing what you mean in
>>> >> the first pass.
>>> >>
>>> >> > If master syncs are a useful idea...
>>> >> >  - A PublicRelationsServer of the style above
>>> >>
>>> >> I don't know what PublicRelationsServer is.
>>> >>
>>> >> >   - Maybe flag the MasterSync to toggle between using ros master's
>>> >> > or public relations servers
>>> >> >  - Move MasterSync's out of the app manager so they can be used by
>>> >> > anyone
>>> >>
>>> >> I'm fine with moving the code out.  It's intentionally hidden as it
>>> >> doesn't work well in an unreliable network scenario (relies on errorless
>>> XMLRPC calls).
>>> >>
>>> >> >  - MasterSync as a ros node?
>>> >>
>>> >> It is a ROS node in the app manager setup.  It's nice as you can
>>> >> potentially interrogate it using normal ROS tools.
>>> >>
>>> >> >  - Use MasterSync's as a means of watchdogg'ing connectivity?
>>> >>
>>> >> The master data does not contain connectivity information; it could
>>> >> only really watchdog if we add in TTL to the master registrations (a
>>> >> future enhancement).
>>> >>
>>> >> My general hope was to reimplement the master backend with
>>> something
>>> >> like Redis (a key/value store).   Redis has replication and TTL
>>> >> features, though I have not had a chance to benchmark over wifi just
>>> >> yet.  It basically uses a telnet-like connection to do all the sync.
>>> >>
>>> >>  - Ken
>>> >>
>>> >>
>>> >> > Cheers,
>>> >> > Daniel.
>>> >> > On 17 September 2011 05:47, Jonathan Fink <>
>>> wrote:
>>> >> >>
>>> >> >> On Sep 16, 2011, at 12:40 PM, Ken Conley wrote:
>>> >> >>
>>> >> >> > On Fri, Sep 16, 2011 at 6:55 AM, Jonathan Fink
>>> >> >> > <>
>>> >> >> > wrote:
>>> >> >> >>
>>> >> >> >> On Sep 16, 2011, at 9:46 AM, Jeff Rousseau
>>> >> >> >> <>
>>> >> >> >> wrote:
>>> >> >> >>
>>> >> >> >> Thanks for starting Jon, here's my scenario:
>>> >> >> >>
>>> >> >> >> I have several (3 to 5 on a given day) custom robot platforms
>>> >> >> >> that are utilized for testing multi-robot coordination
>>> >> >> >> algorithms-which might I add is painful in ROS, hence this
>>> discussion.
>>> >> >> >>
>>> >> >> >> Since a single-master solution of passing all topics to all
>>> >> >> >> machines doesn't scale well beyond 2 machines due to the amount
>>> >> >> >> of traffic that would require on my  802.11g network (fault:
>>> >> >> >> tf, kinect data, etc.), I've resorted to instantiating many
>>> >> >> >> instances of the foreign_relay node to cross-publish only the
>>> >> >> >> topics my work requires.  Frustratingly this can still saturate
>>> >> >> >> the 802.11g network, so I have a messy combination of
>>> >> >> >> topics_tools/throttle and foreign_relays.  The
>>> >> >> >> configuration/setup of how and what data is shared is tedious
>>> >> >> >> and error prone (many local and foreign relays with redundant
>>> data).
>>> >> >> >>
>>> >> >> >> On a good day, all is well in the lab and my robots coordinate
>>> >> >> >> over their shared topics just fine.  On a bad day, a robot will
>>> >> >> >> wander just out of range of the wifi and take down everything
>>> >> >> >> due to the fragility of all my carefully configured set of
>>> >> >> >> relayed topics.
>>> >> >> >>
>>> >> >> >> So my high-level user stories are:
>>> >> >> >> 1.       As a ROS user, I want the system to be tolerant to
>>> >> >> >> network connection drops, providing a mechanism for
>>> >> >> >> notification so that the individual nodes affected can respond
>>> accordingly.
>>> >> >> >> 2.       As a ROS user, I want to be able to share specific
>>> >> >> >> topics and services across machines in a network with minimal
>>> configuration.
>>> >> >> >>
>>> >> >> >> Jon's stories seem to match my own, are there any others we
>>> >> >> >> want to consider?  There are many possible solutions to both (1)
>>> and (2).
>>> >> >> >>
>>> >> >> >> So far proposed solutions to (2) seem to be:
>>> >> >> >> *         a master discovery mechanism coupled with * topic and
>>> >> >> >> service whitelists for available topics for foreign masters to
>>> >> >> >> publish/subscribe/call to
>>> >> >> >>
>>> >> >> >> Anyone have ideas for a solution to (1)? It could be as complex
>>> >> >> >> as a "graceful degradation and QoS" system to a binary
>>> >> "dropped/connected"
>>> >> >> >> callback mechanism provided to nodes through the master.  I see
>>> >> >> >> the difference between a full QoS and basic connection-state
>>> >> >> >> handling meaning that without QoS support throttling/bandwidth
>>> >> >> >> issues would be the responsibility of the user and not the system.
>>> >> >> >>
>>> >> >> >> Unfortunately, (1) is a fundamental problem of using TCP over
>>> >> >> >> wireless channels.  UDP-based topics should increase
>>> >> >> >> performance a bit. but then you lose state information about
>>> >> >> >> the channel.  I've recently been pointed to mockets (Institute
>>> >> >> >> for Human and Machine Cognition (IHMC) Nomads Team) as an
>>> >> >> >> example of a way to build application-level sockets between
>>> >> >> >> nodes that operate on a dynamic/noisy network.  Incorporating
>>> >> >> >> something like this as an alternative transport in ROS might
>>> >> >> >> help.  However, the modification to the ROS communication
>>> >> >> >> structure in order to fully take advantage of the added
>>> >> >> >> features would be fairly major I think (almost certainly not
>>> >> >> >> fitting into the current ros::Transport API).
>>> >> >> >
>>> >> >> > What in particular are you worried about fitting into the
>>> >> >> > transport API?  We tried to make it as generic as possible and
>>> >> >> > could make even more generic if necessary.
>>> >> >>
>>> >> >> I guess I'm thinking things like desired bandwidth allocation or
>>> >> >> the ability to know when a transport/socket is no longer viable
>>> >> >> (TCP will eventually time out but this is probably not fast enough
>>> >> >> and isn't very "clean").
>>> >> >>
>>> >> >> >
>>> >> >> > Thanks for the pointer to mockets -- the license, though, is a
>>> >> >> > non-starter for us (it's research/non-commercial only).  That
>>> >> >> > said, there's nothing in the mockets documentation that makes it
>>> >> >> > appear particularly special; one that I've been investigating is
>>> ZeroMQ.
>>> >> >> > It has many language bindings and has both TCP and multicast
>>> >> transports.
>>> >> >> > I don't know it's performance over wifi, though.
>>> >> >>
>>> >> >> Hmm, I hadn't looked at the mockets license. I'll take a look at
>>> >> >> ZeroMQ and maybe poke around to see what other options there are
>>> >> >> out
>>> >> there.
>>> >> >>
>>> >> >> -Jon
>>> >> >>
>>> >> >> >
>>> >> >> > - Ken
>>> >> >> >
>>> >> >> >> -Jon
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> From: Jonathan Fink [mailto:jon.fink@gmail.com]
>>> >> >> >> Sent: Friday, September 16, 2011 8:29 AM
>>> >> >> >> To: Jeff Rousseau <>
>>> >> >> >> Cc: Daniel Stonier; Ken Conley; Bill Morris;
>>> >> >> >> ;
>>> >> >> >> Subject: Re: Fuerte SIG: Multi-Master Support
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> On Sep 16, 2011, at 7:25 AM, Jeff Rousseau
>>> >> >> >> <>
>>> >> >> >> wrote:
>>> >> >> >>
>>> >> >> >> If there are no objections, I'll gladly coordinate.
>>> >> >> >>
>>> >> >> >> Sounds great.
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> We should probably start by calling out a number of
>>> >> >> >> user-stories we'd like to see supported, and then enumerate the
>>> >> >> >> features necessary to realize them.  We can then prioritize the
>>> >> >> >> list based on what we think we can accomplish given the time
>>> >> >> >> before the fuerte freeze.
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> If this doesn't mesh with your expected workflow, I'm open to
>>> >> >> >> other ideas-but this is usually how I start projects.
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> I think email should work fine to share a few initial
>>> >> >> >> user-stories but perhaps it is worth it to shift to a wiki
>>> >> >> >> format pretty quickly so that it is easier to keep track of the
>>> >> >> >> use cases and features we are interested in targeting?
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> Is everyone agreed that email (at least initially) is the best
>>> >> >> >> way to discuss this SIG? We can move to logged chat if the
>>> >> >> >> back-and-forth becomes tiresome.
>>> >> >> >>
>>> >> >> >> To get the ball rolling, my personal user-story:
>>> >> >> >>
>>> >> >> >> I originally started looking at the idea of multiple ROS
>>> >> >> >> masters for working with a team of mobile ground robots where
>>> >> >> >> network connectivity is provided by an 802.11s mesh.  There
>>> >> >> >> were two major issues that we ran into in this
>>> >> >> >> scenario: (a) the network is dynamic and may not always be
>>> >> >> >> connected and (b) some basic ROS capabilities (specifically the
>>> >> >> >> transform library) don't play very nicely across a
>>> >> >> >> medium-to-low bandwidth network (robotA doesn't really care
>>> >> >> >> about the transform from /robotB/base to /robotB/odom).
>>> >> >> >>
>>> >> >> >> While this environment presents potential concerns for the
>>> >> >> >> underlying transports supported by ROS right now, multi-master
>>> >> >> >> support seems like a starting point (i.e. running an
>>> >> >> >> independent master on each robot and having masters
>>> communicate
>>> >> >> >> with each other to synchronize their knowledge of nodes/topics).
>>> >> >> >>
>>> >> >> >> To this end I developed what I called 'rosmaster_sd' (sd for
>>> >> >> >> service
>>> >> >> >> discovery) whereby I made minimal additions to the existing
>>> >> >> >> rosmaster to (1) enable UDP-broadcast-based discovery between
>>> >> >> >> masters and (2) mirror xml-rpc calls from the "local" master to
>>> >> >> >> update subscription/advertisement of topics across multiple
>>> >> >> >> masters (since the underly network is still IP-based, when
>>> >> >> >> connectivity exists, nodes are able to make direct connections
>>> >> >> >> to nodes on other robots).  To address (b), we made it so that
>>> >> >> >> a topic must be on a whitelist (or conversely, not on a
>>> >> >> >> blacklist) before it is echoed between masters -- this means
>>> >> >> >> that certain high-bandwidth topics like '/tf' or '/rosout' are
>>> sequestered.
>>> >> >> >>
>>> >> >> >> This type of approach works well for issue (b) but doesn't
>>> >> >> >> really address (a).  A more complex synchronization method
>>> >> >> >> (rather than an event-based xml-rpc echo) would be one step to
>>> >> >> >> handle changing network connectivity.  I have the cost for what
>>> >> >> >> I call 'rosmaster_sd' posted on github if anyone is
>>> >> >> >> interested: jonfink/multimaster-ros-pkg - GitHub
>>> >> >> >>
>>> >> >> >> -Jon
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> From: Daniel Stonier [mailto:d.stonier@gmail.com]
>>> >> >> >> Sent: Friday, September 16, 2011 1:56 AM
>>> >> >> >> To: Ken Conley
>>> >> >> >> Cc: Jon Fink; Bill Morris; Jeff Rousseau
>>> >> >> >> <>;
>>> >> >> >> ;
>>> >> >> >> Subject: Re: Fuerte SIG: Multi-Master Support
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> On 16 September 2011 09:36, Ken Conley
>>> <>
>>> >> wrote:
>>> >> >> >> (taking meta-coordinator hat off)
>>> >> >> >>
>>> >> >> >> The first order of business is to select a coordinator.  Jeff
>>> >> >> >> -- given that you started this ball rolling, would you like to take that
>>> title?
>>> >> >> >>
>>> >> >> >>  - Ken
>>> >> >> >>
>>> >> >> >> Tuning in just to keep the ball rolling.
>>> >> >> >>
>>> >> >> >> I'm willing for Jeff to take the reins if he is happy to do so.
>>> >> >> >>
>>> >> >> >> Daniel.
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> On Thu, Sep 15, 2011 at 8:44 AM, Ken Conley
>>> >> <>
>>> >> >> >> wrote:
>>> >> >> >>> Hello all,
>>> >> >> >>>
>>> >> >> >>> Your SIG, Multi-Master Support, is good to go.  Your fellow
>>> >> >> >>> members are in the 'To:' field.  Thank you all for stepping
>>> >> >> >>> forward to participate.
>>> >> >> >>>
>>> >> >> >>> I am sending this e-mail mainly to help put people in contact.
>>> >> >> >>> There are instructions for the next steps below; these are
>>> >> >> >>> mainly there just to make sure your SIG is 'active' and that
>>> >> >> >>> information about what you are planning to do is captured.  In
>>> >> >> >>> general, you are free to communicate/organize as you best see
>>> >> >> >>> fit for the nature
>>> >> of your SIG.
>>> >> >> >>>
>>> >> >> >>> Instructions:
>>> >> >> >>>
>>> >> >> >>>   1. Each SIG designates a SIG Coordinator. If an SIG cannot
>>> >> >> >>> agree on a coordinator, one will be chosen for you.
>>> >> >> >>>   2. The coordinator will organize planning meeting(s) for the SIG.
>>> >> >> >>> This can be over IRC, video chat, at IROS, or whatever medium
>>> >> >> >>> bests fits the composition of your SIG. The deadline for these
>>> >> >> >>> meetings is September 28th.
>>> >> >> >>>   3. Each SIG group will post their planning notes as a
>>> >> >> >>> sub-page of
>>> >> >> >>>  http://ros.org/wiki/fuerte/Planning/<SIG-NAME>. The deadline
>>> >> >> >>> for posting these notes is September 30th. SIGs can have
>>> >> >> >>> followup meetings, but this initial deadline is to ensure that
>>> >> >> >>> the SIG is activated.
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>> The first freeze for Fuerte is in January, so there is not
>>> >> >> >>> much time as you might thing to get work done.  It is okay if
>>> >> >> >>> some of the things you discuss go beyond the Fuerte timeline;
>>> >> >> >>> the main goal of these SIGs is to help find developers of
>>> >> >> >>> similar interest so that work can be coordinated better.  Try
>>> >> >> >>> to be realistic: our general rule of thumb is that it takes ~6
>>> >> >> >>> months to develop new libraries and 1 year for them to become
>>> >> >> >>> 'stable' (i.e. used enough for the design to be vetted).  If
>>> >> >> >>> you have any
>>> >> questions/feedback, please feel free to contact me.
>>> >> >> >>>
>>> >> >> >>> cheers,
>>> >> >> >>> SIG meta-coordinator
>>> >> >> >>>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> The information transmitted is intended only for the person or
>>> >> >> >> entity to which it is addressed and may contain confidential
>>> >> >> >> and/or privileged material. Any review, retransmission,
>>> >> >> >> dissemination or other use of, or taking of any action in
>>> >> >> >> reliance upon this information by persons or entities other
>>> >> >> >> than the intended recipient is prohibited. If you received this
>>> >> >> >> in error, please contact the sender and delete the material
>>> >> >> >> from any computer.
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> The information transmitted is intended only for the person or
>>> >> >> >> entity to which it is addressed and may contain confidential
>>> >> >> >> and/or privileged material. Any review, retransmission,
>>> >> >> >> dissemination or other use of, or taking of any action in
>>> >> >> >> reliance upon this information by persons or entities other
>>> >> >> >> than the intended recipient is prohibited. If you received this
>>> >> >> >> in error, please contact the sender and delete the material
>>> >> >> >> from any computer.
>>> >> >> >>
>>> >> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >
>>> > The information transmitted is intended only for the person or entity to
>>> which it is addressed and may contain confidential and/or privileged material.
>>> Any review, retransmission, dissemination or other use of, or taking of any
>>> action in reliance upon this information by persons or entities other than the
>>> intended recipient is prohibited. If you received this in error, please contact
>>> the sender and delete the material from any computer.
>>> >
>>> >
>>
>> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
>>
>> _______________________________________________
>> Ros-sig-mm mailing list
>>
>> https://code.ros.org/mailman/listinfo/ros-sig-mm
>>
> _______________________________________________
> Ros-sig-mm mailing list
>
> https://code.ros.org/mailman/listinfo/ros-sig-mm
> _______________________________________________
> Ros-sig-mm mailing list
>
> https://code.ros.org/mailman/listinfo/ros-sig-mm
> _______________________________________________
> Ros-sig-mm mailing list
>
> https://code.ros.org/mailman/listinfo/ros-sig-mm
>

This message was posted to the following mailing lists:
ros-sig-mm
Mailing List Info | Nearby Messages		<-Re: [Ros-sig-mm] Fwd: connection state and transportsRe: [Ros-sig-mm] [ros-users] multi-master support for Fuerte->
code.ros.org list archives administrated by ros.orgLurker (version 2.3)