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

[wip] Make diagnostics more reasonable #43

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

mjcarroll
Copy link

The diagnostics topic currently publishes at the rate of the IMU, this should really only publish at a fixed frequency, using diagnostic_updater

@fcolas
Copy link
Contributor

fcolas commented May 19, 2017

Thanks a lot for your contribution, indeed it's probably better. I've made a few comments that should be fixed.
Moreover maybe we should discuss exactly what kinds of diagnostics we should publish. For instance, checking the frequency of the topics doesn't really make sense if we don't know which topics should be published and at which frequency.

nodes/mtnode.py Outdated
@@ -11,6 +11,9 @@
FluidPressure, Temperature, TimeReference
from geometry_msgs.msg import TwistStamped, PointStamped
from diagnostic_msgs.msg import DiagnosticArray, DiagnosticStatus

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please remove this empty line

nodes/mtnode.py Show resolved Hide resolved
nodes/mtnode.py Outdated
self.stest_stat = DiagnosticStatus(name='mtnode: Self Test', level=1,
message='No status information')
self.xkf_stat = DiagnosticStatus(name='mtnode: XKF Valid', level=1,
message='No status information')
self.gps_stat = DiagnosticStatus(name='mtnode: GPS Fix', level=1,
message='No status information')
self.diag_msg.status = [self.stest_stat, self.xkf_stat, self.gps_stat]

self.device_info = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Never mix tab and space in Python code!
This code uses four spaces for indentation (as advised in PEP 8 please comply to this (you have several lines with tabulations).

nodes/mtnode.py Outdated
self.device_info = {
'product_code': self.mt.GetProductCode(),
'device_id': self.mt.GetDeviceID(),
'firmware_rev': self.mt.GetFirmwareRev()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these three lines are over indented: please add only one indentation level

nodes/mtnode.py Outdated

output_config = self.mt.GetConfiguration()
for (k,v) in output_config.iteritems():
self.device_info[k] = v
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unless there is a reason, update is probably better
these two lines could just be: self.device_info.update(output_config)

nodes/mtnode.py Show resolved Hide resolved
nodes/mtnode.py Outdated
self.updater.add("Device Info", self.diagnostic_device)

self.imu_freq = diagnostic_updater.TopicDiagnostic("imu/data", self.updater,
diagnostic_updater.FrequencyStatusParam({'min': 0, 'max': 100}, 0.1, 10),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Frequency of certain field in certain configurations can be up to 2000 Hz.
Does it really make sense to check that the frequency is somewhere between 0 and 2000? Wouldn't it be more useful to check the expected frequency?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would make the most sense to check within a certain tolerance of the desired frequency, which is what I've done elsewhere (+/- 1% or +/- 5% depending on the hardware)

nodes/mtnode.py Outdated
self.imu_freq = diagnostic_updater.TopicDiagnostic("imu/data", self.updater,
diagnostic_updater.FrequencyStatusParam({'min': 0, 'max': 100}, 0.1, 10),
diagnostic_updater.TimeStampStatusParam())
self.mag_freq = diagnostic_updater.TopicDiagnostic("imu/mag", self.updater,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why checking only imu/data and imu/mag?

nodes/mtnode.py Show resolved Hide resolved
@mjcarroll
Copy link
Author

Thanks for the feedback.

This was a very quick stab as I needed it in the field for IMU and mag data, and it was flooding out the rest of my /diagnostics messages. Give me a few days for things to settle down here, and I'll address these comments and take the WIP tag off of this PR.

@mjcarroll
Copy link
Author

I think that fixes the PEP8 violations, must have been using a misconfigured editor.

@fcolas
Copy link
Contributor

fcolas commented Jun 12, 2017

Many thanks for the PEP8 corrections. It looks great.
As for the questions about the frequency values and the topics for which we check the frequency, should it be done by checking the configuration, or do you believe that should be parameters?

Also do you think it could make sense to provide launch and yaml files in order to launch rqt_robot_monitor directly? (might be easier if the solution above is to use parameters since some of them might be in common)
What do you think?

@fcolas
Copy link
Contributor

fcolas commented Nov 28, 2017

@mjcarroll Do you think you would have time to finish this?

@mjcarroll
Copy link
Author

yes thanks for reminder

@fcolas
Copy link
Contributor

fcolas commented Jul 16, 2018

@mjcarroll Ping?

@skohlbr
Copy link

skohlbr commented Oct 15, 2018

Just ran into diagnostics publishing at high rate, so another vote for finishing this PR from me :)

@mjcarroll
Copy link
Author

So the conflicts are now gone, but I no longer have this hardware.

I think it would make sense to have the updater use the frequency that the IMU is set to, but since that's currently not handled in the node, I'm not sure what the best way to do that would be.

@fcolas
Copy link
Contributor

fcolas commented Oct 26, 2018

@mjcarroll Thanks for fixing the conflicts and issues.
We could have an expected parameter for each topic. But then people would have to specify it twice: for the node, and for the diagnostics configuration. Giving access in the node to the configuration might be feasible, but as it's currently supporting several kinds of devices with their different configuration specification, it's not a trivial change.

In the meantime, if you don't have much time, the easiest would be to exclude the frequency check in the pull request to have the reasonable aspect and open an issue calling for this functionality.
It'd be great if you could do that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants