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

What tools are available for persistent storage in ROS?

asked 2017-05-10 16:46:56 -0500

BJP gravatar image

updated 2017-05-10 18:04:29 -0500

130s gravatar image

I have a small amount of information (e.g., camera position and orientation) that I would like to persist through roscore shutdowns and restarts. There are potentially multiple providers and multiple consumers of this information so it seems like a latched ROS topic would be appropriate -- the only difference is that I would like to latch to disk instead of just latching in memory. Are there any tools that accomplish this task or something like it?

I see that warehouse_ros exists, but setting up a MongoDB just for a few hundred bytes of information seems like ultra overkill. warehouse_ros seems geared more toward storing very large amounts of information.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
3

answered 2017-05-11 17:49:23 -0500

BJP gravatar image

updated 2017-05-30 14:28:35 -0500

I decided there was apparently no generalized/robust way to persist information using the ROS infrastructure, so I wrote something myself: https://github.com/MisoRobotics/persi... That package allows the user to read from and write to ROS topics and this node will take care of ensuring that the topic is populated with the message from last session next time the system is started up.

EDIT: This actually doesn't work (well) because of the way ROS topics are architected. If a topic represented a series of messages that supersede each other (the way I assumed it would work since that seems like the vast majority of use cases, and is the way it works within a single node), this would work great. Instead, a topic just represents a set of instantaneous messages with no assumption of precedence or behavior -- sometimes, as in the case of /tf_static, messages on a topic represent the accumulation of information instead of a sequence of information. If there are two nodes who each have a latched message where the type doesn't include a timestamped header, how a subscriber should interpret the message pair they'll receive upon subscription is completely undefined.

edit flag offensive delete link more

Comments

I'm a fan of sending a pull request to somewhere upstream for such a useful and generic feature. Maybe ros_comm?

130s gravatar image 130s  ( 2017-05-11 18:14:46 -0500 )edit

I'm glad you think it's useful and generic :) If people end up finding it useful as a separate package, I might consider a pull request in the future, but not a whole lot of time available right now.

BJP gravatar image BJP  ( 2017-05-12 09:54:11 -0500 )edit

Question Tools

3 followers

Stats

Asked: 2017-05-10 16:46:56 -0500

Seen: 781 times

Last updated: May 30 '17