Diagnostics published at laserscan frequency

[sjusner]

We are running ROS2 Humble with the sick_scan_xd driver for a Sick Tim scanner.

The diagnostics are published at 15 Hz on /diagnostics. Is this intended behavior? Would it not make more sense to have it published at the configured frequency of the diagnostic_updater, which is per default 1 Hz.
This parameter can be changed for the sick_scan_xd node, but is not respected, as an update is forced on every loop iteration.

I understand, that an update should be forced if there is an error occurring, but under normal operation this amount of diagnostics messages is unexpected (to me)

Thanks for your time.

[rostest]

Thank you very much for your comment. We will add this point to our backlog and investigate it further if needed. As the diagnostic messages only take up a small volume of data, we consider the current situation to be acceptable, although we consider your argument to be valuable.

[sjusner]

Thanks for looking into this.
Just to add some information: I think due to this behavior, a warning message is sent out whenever the diagnostics update is triggered from the diagnostic_updater, as all updates always get sent out. See the following example where a warning is sent out between two messages stating everything is okay:

---
header:
  stamp:
    sec: 1739795823
    nanosec: 510894149
  frame_id: ''
status:
- level: "\0"
  name: 'tim_driver: /scan topic status'
  message: ''
  hardware_id: none
  values:
  - key: Events in window
    value: '10'
  - key: Events since startup
    value: '25739'
  - key: Duration of window (s)
    value: '0.666663'
  - key: Actual frequency (Hz)
    value: '15.000079'
  - key: Target frequency (Hz)
    value: '15.000000'
  - key: Minimum acceptable frequency (Hz)
    value: '13.500000'
  - key: Maximum acceptable frequency (Hz)
    value: '16.500000'
  - key: 'Earliest timestamp delay:'
    value: '0.049464'
  - key: 'Latest timestamp delay:'
    value: '0.049464'
  - key: 'Earliest acceptable timestamp delay:'
    value: '-1.000000'
  - key: 'Latest acceptable timestamp delay:'
    value: '0.087667'
  - key: 'Late diagnostic update count:'
    value: '0'
  - key: 'Early diagnostic update count:'
    value: '0'
  - key: 'Zero seen diagnostic update count:'
    value: '0'
---
header:
  stamp:
    sec: 1739795823
    nanosec: 521429094
  frame_id: ''
status:
- level: "\x01"
  name: 'tim_driver: /scan topic status'
  message: No data since last update.
  hardware_id: none
  values:
  - key: Events in window
    value: '9'
  - key: Events since startup
    value: '25739'
  - key: Duration of window (s)
    value: '0.607688'
  - key: Actual frequency (Hz)
    value: '14.810239'
  - key: Target frequency (Hz)
    value: '15.000000'
  - key: Minimum acceptable frequency (Hz)
    value: '13.500000'
  - key: Maximum acceptable frequency (Hz)
    value: '16.500000'
  - key: 'Earliest timestamp delay:'
    value: '0.000000'
  - key: 'Latest timestamp delay:'
    value: '0.000000'
  - key: 'Earliest acceptable timestamp delay:'
    value: '-1.000000'
  - key: 'Latest acceptable timestamp delay:'
    value: '0.087667'
  - key: 'Late diagnostic update count:'
    value: '0'
  - key: 'Early diagnostic update count:'
    value: '0'
  - key: 'Zero seen diagnostic update count:'
    value: '0'
---
header:
  stamp:
    sec: 1739795823
    nanosec: 577937610
  frame_id: ''
status:
- level: "\0"
  name: 'tim_driver: /scan topic status'
  message: ''
  hardware_id: none
  values:
  - key: Events in window
    value: '9'
  - key: Events since startup
    value: '25740'
  - key: Duration of window (s)
    value: '0.600421'
  - key: Actual frequency (Hz)
    value: '14.989472'
  - key: Target frequency (Hz)
    value: '15.000000'
  - key: Minimum acceptable frequency (Hz)
    value: '13.500000'
  - key: Maximum acceptable frequency (Hz)
    value: '16.500000'
  - key: 'Earliest timestamp delay:'
    value: '0.049470'
  - key: 'Latest timestamp delay:'
    value: '0.049470'
  - key: 'Earliest acceptable timestamp delay:'
    value: '-1.000000'
  - key: 'Latest acceptable timestamp delay:'
    value: '0.087667'
  - key: 'Late diagnostic update count:'
    value: '0'
  - key: 'Early diagnostic update count:'
    value: '0'
  - key: 'Zero seen diagnostic update count:'
    value: '0'
---

[rostest]

Many thanks for this valuable hint. We also think that this warning would disappear if we reduced the update rate to 1 Hz. We will discuss the next steps internally.