What I learned in ROS this week

Messages:

In a discussion with members of OSRF (https://github.com/ros/std_msgs/issues/7#issuecomment-59396705) I learned that std_msgs shouldn’t really be used as stand alone message types directly on topics as they contain no semantic information describing what they are. Rather you should use custom message types.

Ex. If I have a message of type Float32 I know nothing about how it should be processed. On the other hand if I have a message of type PredictionError I know what it’s for and what to do with it.

ROS and the web:

rosbridge provides a small web server that converts communication to and from the ros master into JSON (Javascript Object Notation), which can then be readily used in a web page. This is a potential alternative for creating GUI’s via rqt.

Subscribers sequentially block!:

I haven’t quite confirmed this, but based on a comment from one of the OSRF guys at ROSCon and some of my own experience it appears that subscribers to a particular topic are processed one at a time in a blocking way. Meaning that if there are 3 subscribers to a topic then ros master will pass the data to the first subscriber, wait for it to finish, then call the second, wait for it to finish, then call the third, etc.

This can be seen fairly easily by timing various functions where publishing occurs and seeing how their timing changes when you add more subscribers.

There are 2 ways I can think of around this at the moment:

• UDPROS (http://wiki.ros.org/ROS/UDPROS) - This should use a broadcast type system, so there should be no blocking or sequential calls
• in the callback functions of your subscribers, just grab the data and store it, don’t process it at this time. Rather, either kick off another thread to handle the processing, or have a single thread which triggers regularly and grabs the latest data from wherever you’ve stashed it.

Contributing to ROS:

I’m in the process of getting my first pull-request merged into ros_comm. Here’s what I’ve learned from the experience:

• First submit an issue, talk to the owners of the repo, and see if they will approve the request before you go write a whole bunch of code that may or may not ever be accepted.
• Use the same docstring format to comment your code as the file you are editing. At least ros_comm seems to use the following format: http://epydoc.sourceforge.net/manual-epytext.html
• Write your code as if for Python3. So that means use .values() over .itervalues() as an example.
• Follow PEP8 style guides for spacing, etc. http://legacy.python.org/dev/peps/pep-0008/
• Even if you are just refactoring code, expect it to be treated as new code and scrutinized as such, even if you didn’t write it.

One Python Gotcha:

Do not initialize an array or dict using default arguments like so:

def foo(my_dict={}, my_list=())

Instead do:

def foo(my_dict=None, my_list=None):

      my_dict = my_dict or {}

      my_list = my_list or {}

For an explanation check out: http://stackoverflow.com/questions/1132941/least-astonishment-in-python-the-mutable-default-argument