clarification on classification of nml being "chatty". it is only "chatty" if the confirm-write option is enabled, which turns on a handshake to verify data can be sent successfully (i.e. there is space in destination buffer), and that it was sent correctly (i.e. udp not dropped). read is implemented as a query to the server "if you have new data, please send it".
Thank you,
Robert Dean
Specialist Software Engineer
General Dynamics Robotic Systems
________________________________________
From:
ros-sig-ipc-bounces@code.ros.org [
ros-sig-ipc-bounces@code.ros.org] on behalf of
rdean@gdrs.com [
rdean@gdrs.com]
Sent: Thursday, September 22, 2011 12:24 AM
To:
ntd@gatech.edu;
ros-sig-ipc@code.ros.org
Subject: Re: [ros-sig-ipc] RCS Library
Responding in a list as i think inlining them would be too confusing (or maybe just confusing to me given the late hour)
Marshing:
There is a lack of versioning of the messages. Message logging is not something we usually do, as there are custom logging systems for our robots which include the metadata separate from messaging.
Transport
-One of the drawbacks of NML is that it is a "chatty" protocol. For example, before a message is being written to a queue'd buffer, a query is sent to the other side to verify there is space in the destination queue. On wired networks this is a non-issue, on wireless it can be an issue... but in those cases usually the network load is the result of problems in the over scheme of how messaging is being used. the chattiness of nml is just a symptom of a larger issue.
-"Mailbox" is a term that I have only seen mentioned in the slides. More common is the concept of a queue'd buffer (self-explanatory) and a "status" buffer which only holds 1 message. Something for which the latest state is the best state such as nav uses a status buffer.
-Subscription at an interval is handy for when a client knows it wants regular data. Different processes may consume that data at different rates. Another way to think about it is as adding filtering support at the publisher.
-Coordination of readers/writers is necessary for a queue, as the queue exists on the "server". When a client reads a message, it is removed from the queue. Usually if there are multiple readers a status buffer is the better solution. As it only contains the most recent message, the message is not deleted on client read.
-When the buffer queue fills, new messages are dropped. a config option can be set which will cause an error code to be returned if this occurs. Does ros give an error if a message send fails? i seem to remember the write/read calls returning void... maybe i am just too tired to remember right now.
Other
-originally it was necessary to specify all buffers and processes in advance. in 2004 nmlcfgsvr was released which enabled run time creation of buffers. any new system should use nmlcfgsvr over predefined config files.
-Yes processes can be started/stopped during runtime.
-
http://www.isd.mel.nist.gov/projects/rcslib/getrcs.html for the source.
Thank you,
Robert Dean
Specialist Software Engineer
General Dynamics Robotic Systems
________________________________________
From:
ros-sig-ipc-bounces@code.ros.org [
ros-sig-ipc-bounces@code.ros.org] on behalf of Neil T. Dantam [
ntd@gatech.edu]
Sent: Wednesday, September 21, 2011 11:45 PM
To:
ros-sig-ipc@code.ros.org
Subject: [ros-sig-ipc] RCS Library
(replying via the mailing list)
On 09/21/2011 08:34 PM,
rdean@gdrs.com wrote:
> A question I have is what type of upgrade or change is being looked
> for, enhancing the current system,
This seems like the question we are all asking. There are many
possible changes/upgrades, and we should identify which are worth
pursuing.
> or replacing large parts of it with OpenSource licensed solutions.
All of ROS is already open source, I think.
> As people were mentioning comms protocols, at gdrs we have used
> Real-Time Control Systems Library from NIST for 12+ years. If there
> is a comms option available, rcslib probably has
> it. http://www.isd.mel.nist.gov/projects/rcslib/
I looked through the documentation there. It sounds like rcslib+NML
give you a message transport and data marshaling.
* Marshaling *
The docs say NML uses XDR to encode data. One issue with XDR (and
some other formats like MIT's LCM, as well) is updating a message
definition makes previously logged messages unreadable with the
current version of the software. This is addressed by formats like
Google's Protocol Buffers which have sufficient metadata in each
message to allow interoperation between various version of messages.
There is, of course, some tradeoff between the efficiency and
extensibility of message definitions, ie raw C structs vs. XML. For
one data point though, we've been using Protocol Buffers at kilohertz
control rates. Can someone comment on where ROS message encoding
falls here?
* Transport *
What kind of transport semantics does this library provide? Looks
like polling will send a request to the remote process. Are mailbox
and queueing different things? What's the reason for subscribing to
send at specific intervals? The comment about multiple
readers/writers needing to coordinate to avoid lost/stolen messages
seems like an issue. What does it mean for the network data queue to
overflow (dropped UDP packets?)?
* Other *
Do you have to specify all buffers and processes in advance? Can you
start and stop processes while the system is running? Is there source
code for the library available?
--
Neil Dantam
http://www.cc.gatech.edu/~ndantam3
_______________________________________________
Ros-sig-ipc mailing list
Ros-sig-ipc@code.ros.org
https://code.ros.org/mailman/listinfo/ros-sig-ipc
-------------------------------------------------------
This is an e-mail from General Dynamics Robotic Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated.
_______________________________________________
Ros-sig-ipc mailing list
Ros-sig-ipc@code.ros.org
https://code.ros.org/mailman/listinfo/ros-sig-ipc
-------------------------------------------------------
This is an e-mail from General Dynamics Robotic Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated.
(text/plain)