Kill handler logging
DSsoto opened this issue · comments
Make the alarm handler for the kill alarm log the time and reason for any kills to a file.
Right now it logs to ros logs right? This would just need to be making sure there are enough ros log prints in the server or client nodes. I thought it logs whenever new alarms are received currently.
You're right about that, but ros logs have way too much info to be useful. I think the vehicle being killed is special enough that a warrants an easy to read log of when and why.
If I'm not mistaken you can get specific logs from specific nodes. The alarm server node would probably not have too much garbage right? I haven't looked too much into ros logging but I imagine getting a specific nodes output would be something that's possible.
Then we'd make a script that makes getting that specific log easier, the implementation is besides the point.
We need to do something about the DVL beam x not returned messages, it's impossible to see anything out of the water on that window because of all those messages.
@whispercoros If we make a gui and this is on it, no need to log it.
Until you kill ROS or whatever and it goes away.
Rospy doesn't have a throttled logger like roscpp does (last time I checked), it'd be pretty easy to implement one in that file. I can do it unless David wants to.
@duggerd the logs do persist even after all ros stuff is killed. I'll look at how the ones for the alarm server node look and if they look usable then I'll just write a script to make it easier to get from the obscure folders they're usually saved to.
I was planning on writing an RQT plugin for ros_alarms at some point before I package it, but someone might want to implement a quick fix while I am working on the CI.
@mattlangford want's to create a python version of roscpp throttled logging.
I have writing dvl beam heartbeat listeners with a dvl_loss meta alarm on my list.
Update: I was mistaken on two fronts.
- It looks like python throttled logging has gotten added in the new version of ros.
- The driver (which I thought was in python) is in a header file.
I am going to make changes to this file to reduce the logging it does without losing data.
Update:
- DVL mesages spamming the sub launch console was dealt with in #218.
- Haven't yet worked on DVL alarm integration.
Have we solved this with the implementation of kill bags from online_bagger?
@whispercoros in a way yes. But this should be easier to parse, and able to be done more quickly. I made a more specific issue to address this (#260).