Implement Autoware Node & Control Center

[xmfcx]

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I've agreed with the maintainers that I can plan this task.

Description & Purpose

In order to be able to track the statuses of Autoware nodes, we introduce the following packages:

• autoware_node (AN)
  • This is package includes a base class for the other autoware nodes to use.
  • It will have the capability to register to the ACC.
  • It will send heartbeats to the ACC upon registration.
  • The heartbeat contains a very light status/error state information.
  • It will also contain a monitored subscription implementation
    • We may add this to somewhere else too, to be discussed later.
    • First let's implement it as part of the base node.
• autoware_control_center (ACC)
  • AN's register here and report their states with heartbeats at rates they define.
  • If it fails to receive the heartbeat (HB) after a deadline, it will mark the node as dead.
  • It will publish the NodeReports message to be used by future GUI tools to track the node states.
• autoware_control_center_msgs
  • Messages and services that will be used for communication between ANs and ACC.
• autoware_test_node
  • Contains the reference implementation and a launch file to run both ANs and an ACC. And some tests.

---

• Here is the feature branch that contains the implementation: feat: add autoware_control_center and autoware_node #84
  • We are in the process of breaking this down feature by feature to make it easier to review.

Steps

1. feat: add autoware_node and autoware_test node #113
   • Only the autoware_node was merged with LifeCycle functionality.
2. feat(autoware_node): remove the lifecycle dependency #187
   • LifeCycle functionality was removed to simplify
3. feat: add autoware_control_center #191
   • Adds the implementation of ACC and registering/deregistering functionality for AN.
   • Also introduces the messages/services for communication.
4. Add the heart beat (HB) functionality
5. Make a package use this base class
6. Create a launch file that includes ACC
7. Test & refine the implementation
8. Once we are satisfied with the implementation, move autoware_control_center_msgs to autoware_internal_msgs repository.

cc. @mitsudome-r @youtalk

Related links

🖱️Click to expand

Continuation from:

• feat: add autoware_node and autoware_control_center #73

• AutowareNode base class for Lifecycle and Monitoring #3194

Nav2 references

• https://docs.nav2.org/concepts/index.html#lifecycle-nodes-and-bond
• https://docs.nav2.org/configuration/packages/configuring-lifecycle.html
• https://github.com/ros-planning/navigation2/blob/main/nav2_util/include/nav2_util/lifecycle_node.hpp

Autoware.Auto discussions

• Autoware.Auto discussions: https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto/-/issues/821
• Discuss Implementing LifeCycleNode Support on Autoware.Auto Nodes - https://gitlab.com/autowarefoundation/autoware.auto/AutowareAuto/-/issues/282
• Autoware Diagnostics and Monitoring - https://gist.github.com/xmfcx/7eaae9750d6317a3a2aa23745ac99444

[xmfcx]

We had a short meeting with @youtalk -san and @mitsudome-r -san.

They've suggested to keep using the https://github.com/ros/diagnostics/tree/ros2 framework.

If we use this, the following list will be obsolete:

• autoware_control_center (ACC)
  • We can keep using the autoware_diagnostic_graph_aggregator or diagnostic_aggregator.
• autoware_control_center_msgs
  • No need to register/deregister anymore.
  • No need for a node report because nodes already publish explicit diagnostics
  • No need for an additional heartbeat message since it's a diagnostic_msgs/msg
    /DiagnosticArray.msg now.
• autoware_node (AN)
  • Was made primarily for 2 purposes:
    • Heartbeat
    • Auto-registering to ACC
    • Lifecycle (removed due to complexity, this reason doesn't exist anymore)
  • Now heartbeat can be added like here: autoware_vehicle_cmd_gate/src/vehicle_cmd_gate.cpp as usual.
  • Similarly, monitored_subscriber function can be implemented as a library somewhere in common.

For these reasons, I'll suggest closing the PRs related to this task. @mitsudome-r @youtalk what do you think?

[mitsudome-r]

Here's my proposal:

• I think we could still have Autoware Node base class to publish logging info (including register/deregister, heartbeat, state, etc)
• As a first step, we can have a small modification to Autoware Node class to publish heartbeat
  • We can try with diagnostic_msgs, but we can also do evaluation with traffics in communication and check if it is feasible first. (I might have to look into the existing diagnostic aggregator in Autoware Universe to check the usage as well)
  • At this stage, there would be no node listening to this message, but that's okay.
• Add register/deregister feature to Autoware Node class
• Create ACC that subscribes above information and reports any failure to the user

[xmfcx]

Add register/deregister feature to Autoware Node class

Can you please review and merge my PR then?

• feat: add autoware_control_center #191

Since it is already implemented, I don't see a reason why it shouldn't be the first step.

[youtalk]

First, we should implement the heartbeat, which is your main objective, at the lowest possible cost. If you want to continue with #191, there aren’t enough tests to see if the lock works properly.