Connection cache -> node

[stonier]

This would be useful to serve a cached state of the master rather than having multiple clients bombarding the master.

It should check the old state vs new state and do latched publishing.

[asmodehn]

We might want to check rosapi... probably already doing something along
these lines...
On May 26, 2015 4:30 PM, "Daniel Stonier" [email protected] wrote:

This would be useful to serve a cached state of the master rather than
having multiple clients bombarding the master.

It should check the old state vs new state and do latched publishing.

—
Reply to this email directly or view it on GitHub
#90.

[asmodehn]

As of e4cf009 the connection_cache_node should be operational. Test coverage is not complete yet.

[stonier]

We should shift some of the rocon python comms api into the connection cache node, e.g. find_service does a master system state lookup on its own.

[stonier]

Listing up some features we want in this node:

• full communications list with full detail ...... for gateway and pyros
• findService api...... for lots of usages
• master.getPublishedTopics equivalent ...... for rocon interactions looking for remocons
• a trigger for spinning up the cache briefly before returning to a slow idling loop......for rapp manager

[asmodehn]

Work in progress : https://github.com/robotics-in-concert/rocon_tools/tree/connection_cache_fixes

Status :

• Full list + last diff pubs : done
• findService : not implemented yet ( should probably be simple ROS services, probably simple to implement once we are sure the list state consistent with actual master state )
• master.getPublishedTopics : didnt look into it yet. We might want to think about duplicating the whole master API exactly, to provide a simple " drop in replacement code " without requiring any changes on user side.
• pub/sub pair providing control of the spin of the Node : done
• Proxy class to use from client Node easily : done
• Unittests to validate cache list state versus Master state : almost done

Things to think about :

• Actions /vs/ Topics : Sometime we want all topics ( even if they are called goal, feedback), and sometimes it seems we want actions as a separate type of connection ?
  Currently the Cache node as an option to filter actions or not... Not sure if there is a better way, if we want to keep this behavior for topics that look like actions...
  Or we should maybe move it to the client/proxy object ?
• Providing a exact replacement for rospy's master proxy / MasterAPI http://docs.ros.org/indigo/api/rospy/html/rospy.msproxy-module.html
  http://wiki.ros.org/ROS/Master_API , so that it s easily replaceable in existing code. Or maybe even better, code that detect if cache node is run and use it, and can (dynamically ?) drop back to original MasterProxy code if cache not there anymore...

[stonier]

Spinning up the Cache

• gateway has a service for this, set_watcher_period
• message type is gateway_msgs/SetWatcherPeriod
• rapp manager in the new gopher implementation has not reimplemented this functionality (yet)

We could use that current format, or better still, switch it to a format where it is just a request with a `spinup duration' variable so the user doesn't need to send a second request returning the node to the original spin period.

[asmodehn]

Quick note : gopher_diagnostics frequency monitor and rocon_interactions manager are using master API directly. They should be using a cache proxy instead.

[stonier]

• Rocon interactions -> use the connection cache #128
• https://bitbucket.org/yujinrobot/gopher_common/issues/155/gopher-diagnostics-use-the-connection