Add more docs and a clean integration example publisher.

[sgillen]

Adds a new architecture doc, a clean example on how to integrate greenwave diagnostics inline, and a small Agents.md file.

[greptile-apps]

Greptile Summary

This PR adds comprehensive documentation and a clean example showing inline greenwave diagnostics integration. The new DESIGN_AND_IMPLEMENTATION.md consolidates architecture details, API documentation, and integration patterns. The example_greenwave_publisher_node demonstrates proper use of GreenwaveDiagnostics class for inline monitoring. Documentation references updated from r2s_gw to ncurses_dashboard. New AGENTS.md provides repository guidelines for AI tools.

Key additions:

• Complete inline integration example with IMU publisher
• Comprehensive design documentation with service API details
• Repository guidelines for developers and AI agents
• Clean separation of concerns in documentation structure

All code follows project conventions, includes proper tests, and demonstrates best practices for inline diagnostics integration.

Confidence Score: 5/5

• This PR is safe to merge with no functional risks
• Documentation and example code addition with no changes to existing functionality, proper test coverage, clean implementation following project patterns
• No files require special attention

Important Files Changed

Filename	Overview
docs/DESIGN_AND_IMPLEMENTATION.md	Comprehensive new design doc with inline integration guide, service API documentation, and implementation patterns - well-structured
greenwave_monitor/CMakeLists.txt	Added build targets for example_greenwave_publisher_node executable and its gtest, proper dependencies and install rules
greenwave_monitor/include/example_greenwave_publisher_node.hpp	New header for example inline greenwave diagnostics integration node - clean structure with explicit timer cancellation in destructor
greenwave_monitor/src/example_greenwave_publisher_node.cpp	Reference implementation showing inline greenwave diagnostics integration pattern - demonstrates proper updateDiagnostics and publishDiagnostics usage
greenwave_monitor/test/test_example_greenwave_publisher.cpp	Tests for example node with parameter validation and message publish verification - clean test structure

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[ExampleGreenwavePublisherNode Constructor] --> B[Declare Parameters: topic, frequency_hz]
    B --> C[Create Publisher for sensor_msgs/Imu]
    C --> D[Initialize GreenwaveDiagnostics with config]
    D --> E[Create publish_timer at frequency_hz]
    D --> F[Create diagnostics_timer at 1Hz]
    
    E --> G[publish_message callback]
    G --> H[Create Imu message with header]
    H --> I[Publish message]
    I --> J[Extract timestamp from header]
    J --> K[Call updateDiagnostics with timestamp]
    
    F --> L[publish_diagnostics callback]
    L --> M[Call publishDiagnostics on greenwave_diagnostics]
    M --> N[Diagnostics published to /diagnostics topic]

Loading

_{Last reviewed commit: c7b17d4}

[greptile-apps]

_{4 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

_{11 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

rclcpp::init() called in SetUp() will cause tests to fail if run multiple times in same process, since ROS context is already initialized

Suggested change

	rclcpp::init(0, nullptr);
	if (!rclcpp::ok()) {
	rclcpp::init(0, nullptr);
	}

[greptile-apps]

_{11 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}

[bmchalenv]

Should we mention to not press "enter" on externally monitored topics as it may create a duplicate diagnostic subscription?

[bmchalenv]

Suggested change

In particular, the messages follow conventions from [Isaac ROS NITROS](https://github.com/NVIDIA-ISAAC-ROS/isaac_ros_nitros), which means configured NITROS nodes can be monitored by greenwave monitor frontends without any additional subscriber overhead. For example the drivers from [Isaac ROS NOVA](https://github.com/NVIDIA-ISAAC-ROS/isaac_ros_nova) can be monitored out of the box. Furthermore, you can set `ENABLE_GLOBAL_NITROS_DIAGNOSTICS=1` to configure all NITROS nodes to publish diagnostics (more info [here](https://nvidia-isaac-ros.github.io/repositories_and_packages/isaac_ros_nitros/isaac_ros_nitros/index.html)).

In particular, the messages follow conventions from [Isaac ROS NITROS](https://github.com/NVIDIA-ISAAC-ROS/isaac_ros_nitros), which means configured NITROS nodes can be monitored by greenwave monitor frontends without any additional subscriber overhead. For example the drivers from [Isaac ROS Nova](https://github.com/NVIDIA-ISAAC-ROS/isaac_ros_nova) can be monitored out of the box. Furthermore, you can set `ENABLE_GLOBAL_NITROS_DIAGNOSTICS=1` to configure all NITROS nodes to publish diagnostics (more info [here](https://nvidia-isaac-ros.github.io/repositories_and_packages/isaac_ros_nitros/isaac_ros_nitros/index.html)).

To keep it consistent with marketing, Nova instead of NOVA

[bmchalenv]

Suggested change

	- Frontends render from a single dictionary maintained by the UIadaptor, rather than a stream of diagnostics messages.
	- Frontends render from a single dictionary maintained by the `GreenwaveUiAdaptor`, rather than a stream of diagnostics messages.

Nit, we call it GreenwaveUiAdaptor in the code, just to align some naming.

[bmchalenv]

Suggested change

	### 3) UI adapters
	### 3) UI adaptors

Super nit, keep using british adaptor for consistency

[bmchalenv]

Nit, for this section we say where to look in code but don't link to it. As a user I'd find it useful to use this as a spot for jumping and looking at the code.

[greptile-apps]

_{11 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}