feat(timing violation monitor): add timing violation monitor node

[nabetetsu]

Description

Closes: #3049

This PR contains timing_violation_monitor node implementation.Timing violation means the event when response time is larger than expected.
For more information on timing_violation_moinitor, please see the Discussion thread.
We are considering the localization as a first step for monitored using this feature. This PR will mainly add the subscribing and monitoring side, the sender side is implemented in another PR.

timing_violation_monitor notifies /diagnostics at specified intervals whether or not the deadline miss has occurred.

All messages used by timing_violation_monitor will be added in tier4_autoware_msgs by this PR.

The following overview diagram of the operation of timing_violation_monitor shows the areas of focus in this PR.

Related links

Discussion thread
Sender implementation
Add new messages

Tests performed

• /diagnostics output from timing_violation_monitor:

---
header:
  stamp:
    sec: 1585897255
    nanosec: 325230283
  frame_id: ''
status:
- level: "\x02"
  name: 'timing_violation_monitor: timing violation monitor'
  message: 'Error: diag period 5(sec)'
  hardware_id: npc2103013
  values:
  - key: 'path#0: ekf-to-ndt (warn)'
    value: 'deadline miss count 18446744073709551611 total 0: path period 0.1(ms) deadline time 0.2(ms) threshold 2'
  - key: 'path#1: pointcloudPreprocessor-to-ndt (error)'
    value: 'deadline miss count 18446649151686050064 total 0: path period 0.1(ms) deadline time 0.15(ms) threshold 1'
  - key: diag_count
    value: '1'
---
header:
  stamp:
    sec: 1585897260
    nanosec: 3921123
  frame_id: ''
status:
- level: "\0"
  name: 'timing_violation_monitor: timing violation monitor'
  message: 'OK: diag period 5(sec)'
  hardware_id: npc2103013
  values:
  - key: 'path#0: ekf-to-ndt (warn)'
    value: 'deadline miss count 0 total 0: path period 0.1(ms) deadline time 0.2(ms) threshold 2'
  - key: 'path#1: pointcloudPreprocessor-to-ndt (error)'
    value: 'deadline miss count 0 total 0: path period 0.1(ms) deadline time 0.15(ms) threshold 1'
  - key: diag_count
    value: '2'
---

• Results shown on rqt_runtime_monitor:
  

Notes for reviewers

timing_violation_monitor is need to launch directly at this moment.
ex: ros2 launch timing_violation_monitor timing_violation_monitor_node.launch.xml

Please let me discuss how it should be launched in the meetings.

Pre-review checklist for the PR author

The PR author must check the checkboxes below when creating the PR.

• I've confirmed the contribution guidelines.
• The PR follows the pull request guidelines.

In-review checklist for the PR reviewers

The PR reviewers must check the checkboxes below before approval.

• The PR follows the pull request guidelines.
• The PR has been properly tested.
• The PR has been reviewed by the code owners.

Post-review checklist for the PR author

The PR author must check the checkboxes below before merging.

• There are no open discussions or they are tracked via tickets.
• The PR is ready for merge.

After all checkboxes are checked, anyone who has write access can merge the PR.

[nabetetsu]

Based on internal discussions, the localization change will be removed in this PR to allow only the timing violation monitor functionality to be added.

[YossyTaka]

How does this relate to https://github.com/tier4/TILDE?

[stale]

This pull request has been automatically marked as stale because it has not had recent activity.

[mitsudome-r]

@nabetetsu @takam5f2 We are also considering to add monitored subscribers to Autoware Core. Is this relevant to this PR?
If this PR is no longer needed, I would like to close it.

[takam5f2]

@mitsudome-r Cc: @nabetetsu

Thank you for the suggestion. It seemed that the similar function is introduced via #6547.

monitored subscribers to Autoware Core looks interesting to me. I think that node should check how old the received data is by itself.

Anyway, I'd like to close this PR.