From 3e5980feb8f84f78812ebf97141000f1b64dde89 Mon Sep 17 00:00:00 2001 From: Juanjo Garcia Date: Mon, 13 Jan 2025 17:27:22 +0100 Subject: [PATCH] Refs #22575: solved failing CI Signed-off-by: Juanjo Garcia --- docs/rst/getting_started/entities.rst | 6 +++--- docs/rst/getting_started/monitor.rst | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/rst/getting_started/entities.rst b/docs/rst/getting_started/entities.rst index edac54fb..b6c3b652 100644 --- a/docs/rst/getting_started/entities.rst +++ b/docs/rst/getting_started/entities.rst @@ -46,7 +46,7 @@ for a more detailed explanation of the *DomainParticipant* entity in DDS. Each *DomainParticipant* can communicate only under a single *Domain*, (see :ref:`logical entities ` section), which creates a direct connection between each -*DomainParticipant* and the *Domain* in which it operates. Additioanlly, from the +*DomainParticipant* and the *Domain* in which it operates. Additionally, from the :ref:`entities diagram ` it can be seen that *DomainParticipant* entities are contained within a *Process*. This is because a system process (referred to as a *Process* entity) executes an application using *Fast DDS*, instantiating *DomainParticipants*. The same applies to *DataReaders* and *DataWriters* instantiated by a @@ -57,7 +57,7 @@ a *Process*. This is because a system process (referred to as a *Process* entity DataWriter ---------- -*DataWriter* is the DDS entity reposible for publishing data. +*DataWriter* is the DDS entity resposible for publishing data. Each *DataWriter* is directly contained within a single *DomainParticipant*. In addition, since a *DataWriter* is associated with the *Topic* it publishes under, a direct containment relationship can be defined between the *DataWriter* and the *Topic*. @@ -75,7 +75,7 @@ DataReader *DataReader* is the DDS entity holding the subscribe function in the communication. As is the case with the *DataWriter*, each *DataReader* is directly contained within a single *DomainParticipant*. Furthermore, since a *DataReader* is associated to the *Topic* to which it is subscribed, -a direct containment relationship an be establisjed between the *DataReader* and the *Topic*. +a direct containment relationship an be established between the *DataReader* and the *Topic*. As a result, any *Topic* will contain all *DataReaders* subscribed to it. Therefore, each *DataReader* is directly connected to the *DomainParticipant* it belongs to, and with the *Topic* to which it is subscribed. diff --git a/docs/rst/getting_started/monitor.rst b/docs/rst/getting_started/monitor.rst index a79f7b90..571704ca 100644 --- a/docs/rst/getting_started/monitor.rst +++ b/docs/rst/getting_started/monitor.rst @@ -54,7 +54,7 @@ that could appear with the Simple Discovery Protocol and multicast. In configure this type of Domain monitoring, a string with different network addresses is required. This string consists of one or several network addresses in the format of ``ip_address:port``, where each address -represents the IP-port pair where a Discovery Server is listening. Multiple network addreses are separated with +represents the IP-port pair where a Discovery Server is listening. Multiple network addresses are separated with ``;``. It is only necessary to connect successfully to one of the specified addresses, as interconnected Discovery Servers create a redundant and robust network. However, connecting to all servers is not required. @@ -68,8 +68,8 @@ one in an external network in address ``8.8.8.8:12345``. In order to clarify how to set this parameter, please visit the `Discovery Server CLI tutorial `_. -The parameter of the Discovery Server *Init New Monitor* button in this application will be used additionally as the input -to the CLI command. +The parameter of the Discovery Server *Init New Monitor* button in this application will be used additionally as the +input to the CLI command. .. warning:: Due to the designed architecture for the communication of the Monitor application and the DDS entities,