Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kobuki Dashboard - Extra Features #14

Open
stonier opened this issue Aug 20, 2013 · 7 comments
Open

Kobuki Dashboard - Extra Features #14

stonier opened this issue Aug 20, 2013 · 7 comments
Milestone

Comments

@stonier
Copy link
Member

stonier commented Aug 20, 2013

Update with extra features that help non-developers exhibit kobuki for us.

  • Priority to features that highlight errors in the system and recovery methods/info.

As we test over the next two-three weeks, list here things we think should be in it.

@ghost ghost assigned stonier Aug 20, 2013
@stonier
Copy link
Member Author

stonier commented Aug 20, 2013

  • Is enable/disable there?
  • We need a watchdog process or node to report on crashes.
  • Fork some ros_error output to diagnostics.

@bit-pirate
Copy link
Contributor

  • Is enable/disable there?

We do have enable/disable motors.

  • Fork some ros_error output to diagnostics.

The diagnostics button turns orange/red, when warnings/errors are published on the diagnostics topic. Additionally the rosout button behaves similar.

  • We need a watchdog process or node to report on crashes.

We could make better use of diagnostics, e.g. within all important apps. There is one problem though: If a process dies on start-up or during runtime, it might do so before being able to publish an error message on the diagnostics topic.

On the other hand dying processes are also caught by the rosout widget, but using this would require the non-ros-developers to get acquainted with the logs, i.e. which warnings/errors are important, which are not. That might not be trivial for them.

So, bottom line is, we have already tools in place, which report the problematic situations, but they are not convenient enough. Any ideas how we can change that?

@corot
Copy link
Collaborator

corot commented Aug 22, 2013

rosnode pings nodes to get its status. Can reuse its code to make a watchdog?

another idea: make use of the node attribute "required":

  • using it, if a node in a roslaunch dies, the whole roslaunch is shutdown, what is obviously much more detectable that a single node death.
  • launch a watchdog node within any app or bootstrap roslaunch file. If it dies, notifies the dashboard (or stops sending "keep-alive" messages every second)

But I wonder if we are not pushing to far the dashboard; to me it's (mostly) a convenient hardware status check tool.

@corot
Copy link
Collaborator

corot commented Aug 24, 2013

Should I implement this? Now? It's in my issues disintegration card...

@stonier
Copy link
Member Author

stonier commented Aug 29, 2013

We all have it. Basically I think we get together after refamiliarising ourselves and draw up a list of desirata for a demobot.

@corot
Copy link
Collaborator

corot commented Feb 10, 2014

Useful (but probably not priority) additions:

  • Set digital output port
  • Show digital/analog input ports

@bit-pirate
Copy link
Contributor

👍

We would appreciate a PR for that! ;-)

@stonier stonier removed their assignment Apr 3, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants