allow regex parsing of log messages to get values

[tkruse]

That was one of the considerations at the beginning, but I'm not sure if that can be done nicely without ending up in parsing hell.

parsing hell is part of the game. I believe a lot of code should be written without thinking of a dashboard application in mind, unless the dashboard is an essential part of that software. There are more hells than parsing hell.

I believe there are several good arguments for logging in also machine readable format, not just dashboards, so some people will already do that and have their own convention for message output. Those people can benefit from such a feature. The others will just have to find another way. You should not enforce any particular format for rosdashboard, though you can suggest one format and write a tutorial of how to get that output and how to use it in a widget.

You could make it possible that when subscribing to a topic, it is possible to run a filter on message structures to get a value. People can implement their own filters your default filter could be just a wrapper for python re search and re.sub().

A default idea would be for people to log using a format like x = '12345:[foo]: bar was 42' so they can enter an re pattern in rosdashboard to apply pat = "[0-9]+:[[a-zA-Z0-9_]+]: bar was ([0-9]+)"

and you have a function for that that does:

def filter(pat, x):
  if re.match(pat, x):
    return re.sub(pat, '\\1', x)

This will return None for other messages, which you would not pass to the widget.

This is not ideal, but I think it would be worse to create a new publisher for that in the code just in case somebody uses a dashboard. One can argue that any module should publish its relevant state to the world, but that does not mean people will do it. If you want to win over users, I think it is easier if you also allow them their dirty ways.

[kaserf]

I'm not fully sure if we are on the same page. rosdashboard was intended as development tool which you can use to find errors in your program. The use case to monitor the state of a robot constantly as pr2-dashboard and turtlebot-dashboard do came up later.

What I had in mind originally is that you have a piece of code on which you are currently working on (developing a feature or debugging current code) and use rosdashboard.log() just as you would use printf() to print out values on the console. In that scenario you would add debugging output lines only temporarily to understand the current workflow and data that is processed.

The second use case is to monitor behavior constantly. For that I agree with you that a functionality to parse existing methods would be nice. I'm still not sure if I completely understood how you want to match data to widgets. Do you recommend to have a one-pattern-per-widget approach and leave the routing to the user (by choosing a distinctive pattern).

[tkruse]

Yes, if the user can create widgets by pattern matching log messages, one pattern per widget, that's an easy way to introduce a dashboard without changing existing code and without requiring more topics, and without adding a new dependency to rosdashboard.

This allows to debug code that is installed from binaries with visualisation, which your code depends on. If people write code that they debug using a real robot or a simulation, then there are many packages in play which the people do not want to checkout from source and add rosdashboard log lines in, they might just want a visualisation of the existing log message values.

This also helps other people in the world who want to contribute to your project. You can publish your code on github without any rosdashboard.log debug statements in it, but with machine-readable log messages, you can provide with your code a rosdashboard widget config, and some other developer can checkout both, run the code and debug it using the same widget configuration as you, without having to add rosdashboard.log lines to the code.

This also prevents people from accidentally comitting code to a shared repository with rosdashboard lines in it, undesired dependencies to rosdashboard in the cmake files etc.

Actually, it could be interesting to even allow rosdashboard to read piped data from stdout, like this: $ run_my_code | rosdashboard - Then people can do print("pattern: %s"%value) in their code and even have that shown in rosdashboard. But you don't have to implement that, that's just to think about.

[kaserf]

I like your arguments and agree with you (especially the external dependencies could be a problem for other projects).

Before I can implement this I have some other issues which in my opinion are of a higher priority.