You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

153 lines
6.0 KiB

See also: [device](device.md)
# What is discovery
Discovery enables a client to get information about live devices, including how to access them.
It does not include connecting to those devices, talking to them, or anything else.
# Domains
DDS domains separate logical systems so they do not interfere with one another on the network. Domains are numbered 0-232. Discovery on domain 0 will not detect devices on domain 1.
All documentation assumes a single domain shared between all entities.
# Participant
A server is a participant in the system, and may publish multiple devices. As an entity in the DDS, it should be named in a way to be easily identifiable and looked up:
- If for a single device, it is suggested to use the same topic root syntax `<model>_<serial>` as below, e.g. `D457_457123`.
# realsense/device-info
Only one topic is used for discovery:
>`realsense/device-info`
This topic is not meant for consumption by ROS, and is not meant to be visible there.
#### Quality of Service
- Reliability: `RELIABLE`
- Durability: `VOLATILE`
# Protocol
The requirement is very simple: whenever a server detects a client, it should broadcast its device-info so the client can see it.
The DDS subsystem enables this by notifying a publisher (the server) that a subscriber (client) exists for the topic.
# Device-Info
The device-info is general information about the device, plus how to access it.
It should not change over the device lifetime.
One device-info per device. At this time, only one device-info per message.
The message format is a [flexible message](../include/realdds/topics/flexible/) using a simple JSON structure, for example:
```JSON
{
"name": "Intel RealSense D405",
"serial": "123622270732",
"product-line": "D400",
"topic-root": "realsense/D405_123622270732"
}
```
| Field | Purpose | rs2_camera_info |
| ---- | ---- | ---- |
| **name** | The name of the device | `RS2_CAMERA_INFO_NAME` |
| serial | The device serial number | `RS2_CAMERA_INFO_SERIAL_NUMBER` |
| product-line | The type of device (D400, L500, etc.) | `RS2_CAMERA_INFO_PRODUCT_LINE` |
| **topic-root** | The path to the root topic for the device | `RS2_CAMERA_INFO_PHYSICAL_PORT` |
| fw-version | The version of the software currently on the device | `RS2_CAMERA_INFO_FIRMWARE_VERSION` |
All are optional except `name` and `topic-root`. Any fields not shown above will be ignored.
The fields above are constants and not expected to change between device restarts! They should likewise remain the same in recovery mode.
Besides the fields above, certain configurable settings may be needed before proper initialization of the device is possible (via the notifications topic). These may change between device initializations:
| Field | Purpose |
|--------------|---------------------------------------|
| multicast-ip | IP address on which topics will be multicast
For example, when multicasting is enabled then the notification topic will be multicast on the `multicast-ip` address. So knowledge of this address is needed before the device can actually be initialized. Very few settings like this should be needed.
# Disconnection
Under normal operation, the DDS subsystem will notify participants of entity disconnections without much delay. If a participant crashes or goes offline unexpectedly, a timeout (currently 10 seconds) is triggered and only then participants are notified.
When it is expected that a server will go offline, the server can elect to send a `stopping` message so that clients can remove the device immediately rather than waiting for DDS to do its thing.
```JSON
{
"topic-root": "realsense/D405_123622270732",
"stopping": true
}
```
The `stopping` field has no set type at this time so any value will do. When it's there, any client should immediately assume the server is offline.
No fields other than the root are necessary with `stopping`.
# Recovery
If the device is in "recovery mode" with limited functionality, this needs to be communicated to the client:
```JSON
{
"name": "Intel RealSense D405",
"serial": "123622270732",
"topic-root": "realsense/D405_123622270732",
"recovery": true
}
```
The `control` and `notification` topics will exist under the topic-root, but will only accept update controls and replies, as discussed elsewhere. No streams should be available in a recovery device.
It is important that the `topic-root` stays the **same as a non-recovery device**: otherwise they are considered different devices.
# Topic Root
This points to the topic used as the device root. This is how to access the device; without it, we're just guessing.
See [Device Initialization](initialization.md).
# librealsense
Librealsense manages a single point from which all other objects are derived: the `context`. To get access to a device, a `context` is created and then `query_devices()` called.
The `context` has been augmented to be able to see DDS devices. This is on by default if `BUILD_WITH_DDS` is on.
When a context is created, a JSON representation may be passed to it, e.g.: `{"dds": { "domain": 123, "participant": "librs" }}`. This allows various customizations:
| Field | Default | Description |
|----------------------|--------:|------------------------------|
| dds | `{}` | Set to `false` to turn off DDS in this context
| dds/`enabled` | `true` | If `false`, DDS is disabled
The `dds` is there by default (i.e., not `false`). The value may contain the following settings dealing with discovery:
| Field | Default | Description |
|------------------|----------------:|----------------------------------|
| domain | `0` | The domain number to use (0-232)
| participant | Executable name | The name given this context (how other participants will see it)
| participant-id | Automatic | The ID; not recommended to use, but may be needed in special circumstances
See a comprehensive list of settings under [device](device.md#Settings).