keeping state: Latched Topics vs ROS Parameters vs Service Request

asked 2018-03-10 16:02:18 -0500

8272 ●34 ●503 ●129 https://www.linkedin.c...

updated 2018-03-10 16:12:22 -0500

Hi!

I'm trying to hold state about a piece of software in my stack. For instance, to tell if a fan is on or not from another process through ROS.

The 3 ways that come to mind is changing a parameter but the parameter server is super not high performance and I will be querying this at well over 5 hz. Another option is to have the state be a latched topic but I'm unsure if this is actually any better performancewise. Finally, just have a service call that asks for the state of that component

Any thoughts?

edit retag flag offensive close merge delete

add a comment

answered 2018-03-10 18:53:55 -0500

ahendrix

47576 ●179 ●367 ●662 http://namniart.com/

updated 2018-03-11 04:15:18 -0500

I would use a latched topic.

A brief comparison of the differences relevant to what you're doing:

Parameter
- Polling or using cached parameters places load directly on the ROS master; this doesn't scale well to large data
- cached parameters help but still result in load on the ROS master
- Data is stored on the master, so it's available (but maybe out of date) if the node that sets that parameter isn't running
Topics
- Data is transferred directly between nodes, so it scales better to larger data and number of subscribers
- Data isn't available if the publisher node stops
- Push-based; updates are delivered to a callback in the receiving node only when the publisher publishes a new message
- If you need staleness detection, it must be done in the subscriber
Services
- Data is transferred directly between nodes
- Data isn't available if the server node stops
- Will require polling the service server; this results in additional load in both the server and client when compared with topics.
- Easy to detect that the server has stopped responding

edit flag offensive delete link

Comments

I would add that typically in dataflow applications, 'state' is derived from data. "fan is on" is something that should either be directly represented by a dataflow, or be derived from one. Hence a topic. Latching such a topic is then just a minor optimisation.

gvdhoorn ( 2018-03-11 03:57:58 -0500 )edit

Thanks for the input! I did some rough testing and found that the CPU of publishing a state at 10 Hz vs 100 Hz to provide near real-time state information for other nodes works better than parameters (obviously) and slightly better than persistent services.

stevemacenski ( 2018-03-11 17:43:49 -0500 )edit

I do wish though that ROS had built in a better parameter server. Maybe my next big project.

stevemacenski ( 2018-03-11 17:44:25 -0500 )edit

I do wish though that ROS had built in a better parameter server. Maybe my next big project

can you clarify this a bit? The type of information that you describe is definitely not something that should be stored on the parameter server. It's state info that encodes the state of one of your ..

gvdhoorn ( 2018-03-12 03:04:04 -0500 )edit

.. sensors. / actuators. It seems like a textbook example of what pub-sub is for.

gvdhoorn ( 2018-03-12 03:05:10 -0500 )edit

A sensor or actuator, I agree. There's often times you have state about the state of a particular program (Is this thing active, what's the last person that called it, when did that happen). These are great small sized things that would make sense to be able to grab when needed...

stevemacenski ( 2018-03-13 13:15:26 -0500 )edit

and calling it a "parameter server" I agree, but equivalently if there's just a call response for the status of things registered, it is useful for high level applications. Other middlewares like zeromq allow for this, ROS's param server wasn't written with high rate access / modification in mind.

stevemacenski ( 2018-03-13 13:16:32 -0500 )edit

Which is fine, that wasn't the purpose at the time, but if we can make a ROS "param server" that allows efficiently for constant querying and doesn't place stress on the master, its a win win win.

stevemacenski ( 2018-03-13 13:17:21 -0500 )edit

see more comments

keeping state: Latched Topics vs ROS Parameters vs Service Request

1 Answer

Comments

Question Tools

Stats

Related questions

keeping state: Latched Topics vs ROS Parameters vs Service Request edit

1 Answer

Comments

Question Tools

Stats

Related questions

keeping state: Latched Topics vs ROS Parameters vs Service Request