ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

The source of topics in someone else's package

asked 2018-08-27 12:48:49 -0500

MTDzi gravatar image

updated 2018-08-29 04:25:51 -0500

I'm going through this package, and in particular this file in which I found three topics whose "source packages" and meaning are unknown to me:

  • /right_constraint_index,
  • /left_constraint_index, and
  • /lsr/angle

I would like to be able to run this package (roslaunch seems to be working according to the instructions in the README), but I don't know how to resolve the above three topics.

I'm new to ROS and the only means of finding the "source" of these topics (nodes that publish to them) is by going through the package's dependencies. But that didn't help. I obviously googled them and searched for their parent packages on ros.org -- but to no avail. Also, I tried to get in touch with the author of the package but, again, no luck there.

Hence, I turn to you with the question: what do you think is their origin?

But more generally: what are the standard methods of identifying mysterious topics found when going through somebody else's code?

As a side note: I have an idea that these three topics are a means of parametrizing the behavior of the robot during the run (so that one might find the right values of the parameters that correspond to the best local solution), but I wasn't able to verify it.

EDIT: to summarize the discussion in the comments below, my question boils down to:

Is there is a "standard topic repository" that I can use to better understand the use of topics in somebody else's code?

and the short answer is: no, there isn't. You're dependent on the authors and the documentation provided with the code.

edit retag flag offensive close merge delete

Comments

1

If with "the source of topics" you mean: where are the publishers defined that publish to them, or the subscribers that subscribe, then you'll have to read the source, yes.

If you are asking something else, please clarify, as I have a hard time figuring out what you're asking.

gvdhoorn gravatar image gvdhoorn  ( 2018-08-28 03:32:01 -0500 )edit

My question boils down to the following: "If I don't know what kind of information the node expects through these unknown topics, what methods of finding this out can I follow?" In other languages / libraries, if I encounter a function that I don't know, I can read the documentation, or...

MTDzi gravatar image MTDzi  ( 2018-08-29 04:03:08 -0500 )edit

...if there is none, I can go through its implementation. In the example above, this approach doesn't apply.

If, however, I was able to find packages that use topics named as those above, I could figure out whether this is what the node expects. And if so, I would use those packages to supply...

MTDzi gravatar image MTDzi  ( 2018-08-29 04:03:27 -0500 )edit

...the node with the required information.

Is my reasoning wrong?

MTDzi gravatar image MTDzi  ( 2018-08-29 04:07:06 -0500 )edit

re: read documentation: I would say that is exactly the same in this case. Many ROS pkgs document the types and semantics of the topics they use/expect. See abb_driver as an example.

But just as with other software: you're dependent on the authors ..

gvdhoorn gravatar image gvdhoorn  ( 2018-08-29 04:07:35 -0500 )edit

.. to have provided you with that documentation. If they didn't, then you can't use that.

re: go through its implementation: I'm not sure how ROS nodes are different here. It's all C++/Python/some other language. Provided you know those languages, you could read the sources.

gvdhoorn gravatar image gvdhoorn  ( 2018-08-29 04:08:45 -0500 )edit

re: use topics names: no, this is not something you can do. Topic names do not encode sufficiently the types of info that flow across the topic. I can create a /chatter topic that carries geometry_msgs/PoseStamped, while the ROS tutorials use std_msgs/String. You'll have to look at ..

gvdhoorn gravatar image gvdhoorn  ( 2018-08-29 04:09:49 -0500 )edit

.. the type of the topic to see whether things are compatible. And here again you will be somewhat dependent on the authors of the node(s): if they used primitive types like Int32 and Float64, then those msgs carry almost no semantic meaning. If however they used something like ..

gvdhoorn gravatar image gvdhoorn  ( 2018-08-29 04:11:18 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted
1

answered 2018-08-29 04:23:34 -0500

gvdhoorn gravatar image

updated 2018-08-29 04:28:46 -0500

I think I was hoping there is a "standard topic repository" that would provide this kind of information.

Now I think I know what you're asking: topic names are almost arbitrary, types are not however. Topics are typed, so both participants in pub-sub need to declare the same types. That avoids the situation where you attempt to send incorrectly formatted information to a certain subscriber.

But that doesn't solve the complete problem. Typing addresses the syntax part of communication. But for semantics we still need something more.

So besides typing, additional semantics are captured in what is typically called a "ROS API". For serious systems, those are captured in REPs. Those REPs provide additional information on the types that should be used for certain topics, their names and what their intended use is.

See REP 138: LaserScan Common Topics, Parameters, and Diagnostic Keys for an example, but there are some others as well (and some REPs standardise entities other than topics or parameters, such as REP 103: Standard Units of Measure and Coordinate Conventions and REP 105: Coordinate Frames for Mobile Platforms).

REPs have not been used that much in more recent years, but I believe they are something that comes close to your "standard topic repository", at least conceptually.

edit flag offensive delete link more

Comments

Thanks :)

MTDzi gravatar image MTDzi  ( 2018-08-29 04:27:27 -0500 )edit

Note that this also isn't a complete solution: even if there are standards, you're still dependent on the package authors to have implemented them. And then additionally: there aren't standards for everything. So sometimes developers don't have a choice but to come up with something themselves.

gvdhoorn gravatar image gvdhoorn  ( 2018-08-29 04:29:56 -0500 )edit
0

answered 2018-08-28 04:50:26 -0500

Just to clarify your question, you're trying to find out which nodes publish messages to these topics. This is a different question than asking what their "source packages" are which may be the source of the confusion.

The nodes which publish these topics, if they even exist, would not be a dependency of this package. Dependencies are this libraries and headers required to build and run the executables. The node in this package will build and run quite happily even if these topics are never published, it might not behave as expected but that's a different issue.

As I think you already suspect it's possible that the developers intended to publish to these topics manually using rostopic from the command line or in a launch file. That would be a little unusual but would explain why you can't find a publisher to those topics in the code base.

Have you tried running the node to see what happens?

edit flag offensive delete link more

Comments

I have. Callbacks associated with those topics act as setters for attributes necessary for the node to behave "correctly" (at least to me). One way of dealing with this is just to hard-code those attributes with values I deem reasonable and hope for the best. But I was actually more interested in...

MTDzi gravatar image MTDzi  ( 2018-08-29 04:10:55 -0500 )edit

...what other, seasoned users of ROS do in a situation like this. Like I said, I'm new to ROS, and I think I was hoping there is a "standard topic repository" that would provide this kind of information.

MTDzi gravatar image MTDzi  ( 2018-08-29 04:13:15 -0500 )edit

I'll add an EDIT to my question to make it clearer for others.

MTDzi gravatar image MTDzi  ( 2018-08-29 04:21:09 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2018-08-27 12:48:49 -0500

Seen: 145 times

Last updated: Aug 29 '18