Tool for message inhibition / injection

asked 2013-04-18 16:42:50 -0500

zouhair
11 ●1 ●1 ●3

updated 2013-04-18 16:45:52 -0500

Is there any GUI tool that allows live monitoring of ROS traffic, and potentially modification of these messages by either inhibiting them or say overriding values?

Basically something like rxbag or rqt gui but with the ability to modify messages on the fly (per example force a certain signal to a value, inhibit a message, etc.) In some sense it's a combination of the topic_tools mux/drop.

This is driven by a desire to simulate arbitrary sensor failures for a system which uses ROS for message passing to a monitoring station.

Anyway, I am hoping something like this already exists. If not, does someone have an idea of whether this is doable at all? Seems like it'd be a hybrid between topic_tools/mux & drop?

Thanks, -z

edit retag flag offensive close merge delete

add a comment

1

answered 2013-04-19 10:54:36 -0500

William

17335 ●101 ●182 ●262 http://wjwwood.io/

The only way to accomplish this is to have a node which subscribes to the source of the topic and republishes it to another topic which the destination is subscribed to. Then that node can manipulate, pause, drop, or what ever you want before republishing the data.

So you would have:

image description

Where you introduce a new node (possibly just a python script) which subscribes to the original topic (/cmd_vel), modifies it, and republishes it to a new topic (/scaled_cmd_vel) which the destination now subscribes to instead of the original topic.

This must be setup before everything is running (it can be configured at launch time but not run time).

It is possible to update the nodes at run time, but there is no easy way to do this, nor any tool that does this that I am aware of.

edit flag offensive delete link

add a comment

2

answered 2013-04-18 22:08:34 -0500

Philip

990 ●8 ●11 ●28 http://www.kit.edu/

updated 2013-04-21 02:40:33 -0500

My understanding of the ROS communication scheme (simplified) is that the roscore keeps a list of all active publishers and subscribers. Each time a new pub/sub goes up (e.g. by starting a node), roscore checks if there already is a sub/pub with a matching topic. If this is the case, the matching pub and sub are notified of each other; all further communication is then handled directly between pub and sub (without involvement of roscore).

This basically means that there is no machine/node/whatsoever through which all messages are routed. For this reason, I don't see how arbitrary messages could be monitored and/or altered on the fly...

That said, I'd also have a need for what you described for especially the same reason!

EDIT: From the point of view of network topology, ROS nodes usually span a partially connected mesh, which leads to the status described above. By altering the pub-/sub-topics of each node, you can switch to a star network as pointed out in other answers. This should probably be used for testing purposes only, as it introduces a single point of failure (if the central republishing node dies, everything "stops").

edit flag offensive delete link

add a comment

0

answered 2013-04-19 10:23:34 -0500

zouhair
11 ●1 ●1 ●3

Thanks for the answer Philip.

So does that mean that it's not even possible to have some python script that would do this by listening to some messages then republishing them after some filtering/processing? Wouldn't that be doable by making all other nodes subscribe to those topics but only emitted by said script?