WEBVTT 00:00.050 --> 00:05.690 Before going to the definition of a topic, I will give you a real life analogy, so it will be much 00:05.690 --> 00:07.100 easier for you to understand. 00:07.130 --> 00:13.010 I will make an analogy with a radio transmitter and receiver as this is a simplified example. 00:13.010 --> 00:18.140 Not everything I will say about radio will be correct, but the point here is to make you understand 00:18.170 --> 00:19.730 Ross two topics. 00:19.730 --> 00:23.300 Let's suppose we have one radio transmitter. 00:23.330 --> 00:29.600 This radio transmitter will send some data on a given frequency and for people to easily remember, 00:29.600 --> 00:32.030 this is represented by a number. 00:32.030 --> 00:38.900 For example here 98.7 we can think of 98.7 also as a name. 00:38.900 --> 00:45.140 So you know that if you want to receive music from the radio station, you need to connect your device 00:45.140 --> 00:47.000 to 98.7. 00:47.000 --> 00:48.800 You can see the green box here. 00:48.800 --> 00:53.090 So the box with 98.7 has a Ross topic. 00:53.090 --> 00:57.560 And the radio transmitter is a publisher on that topic. 00:57.560 --> 01:03.570 So for this case a data stream is sent over the 98.7 topic. 01:03.570 --> 01:07.020 Now, maybe you want to listen to the radio station from your phone. 01:07.020 --> 01:11.670 What you will do is to ask your phone to listen to 98.7. 01:11.670 --> 01:16.140 In this case, the phone is a subscriber on the topic. 01:16.140 --> 01:22.980 To play the music on your phone from the radio transmitter, you also need to send and receive the same 01:22.980 --> 01:24.690 kind of signal here. 01:24.690 --> 01:30.960 If the radio transmitter is sending an FM signal over the topic, and if on your phone you are trying 01:30.960 --> 01:34.560 to decode an Am signal, then it will not work. 01:34.560 --> 01:41.340 That's why you need to make sure that both the publisher and subscriber are sending messages with the 01:41.340 --> 01:43.230 same data structure. 01:43.230 --> 01:49.920 So to recap here, you can see the radio transmitter as a publisher, which will publish on the 98.7 01:49.920 --> 01:52.440 topic with an FM signal. 01:52.440 --> 01:59.400 The phone will subscribe from the 98.7 topic and will also decode FM signal. 01:59.430 --> 02:04.440 Okay, so both sides need to agree on using the same name and the same data type. 02:04.470 --> 02:10.020 Now to continue with this example, maybe you also want to listen to the radio station from another 02:10.020 --> 02:11.940 device or from your car. 02:11.970 --> 02:19.710 Then, as you know, you just need to listen to 98.7 and also both your device and your car should decode 02:19.950 --> 02:20.970 FM signal. 02:21.000 --> 02:27.810 You have now an example with one publisher and three subscribers, so we can have many subscribers on 02:27.810 --> 02:28.380 the topic. 02:28.380 --> 02:33.090 But on the other side, we can also have many publishers for one topic. 02:33.120 --> 02:40.170 Imagine another radio transmitter, which is also publishing an FM signal on 98.7. 02:40.170 --> 02:42.270 It can be the same radio station. 02:42.270 --> 02:44.310 It can also be another one. 02:44.340 --> 02:50.400 Sometimes when you are driving, you can arrive in a zone where two radio stations are broadcasting 02:50.400 --> 02:56.460 on the same frequency, and in this case, here you have two publishers on the 98.7 topic. 02:56.460 --> 03:00.870 All the subscribers will receive the messages from both publishers. 03:00.900 --> 03:03.660 Now you can see all the blue boxes. 03:03.660 --> 03:05.440 Here are nodes. 03:05.440 --> 03:06.940 You have the radio transmitter. 03:06.970 --> 03:09.250 Node one the radio transmitter. 03:09.280 --> 03:10.150 Node two. 03:10.180 --> 03:15.700 And then you have a node for the smartphone, another one for the radio player and another one for the 03:15.700 --> 03:16.180 car. 03:16.210 --> 03:21.430 Some nodes contain a publisher to the topic and some nodes contain a subscriber. 03:21.430 --> 03:27.070 As you can notice, all publishers and subscribers are sending and receiving the same kind of data. 03:27.070 --> 03:33.550 And as you can guess, a subscriber is not aware of the other subscribers and is not aware of who is 03:33.550 --> 03:34.750 publishing the data. 03:34.750 --> 03:39.970 It only knows that it is receiving data from the 98.7 topic. 03:40.000 --> 03:46.210 On the publisher side, a publisher is not aware of the other publishers on the topic and is also not 03:46.210 --> 03:49.240 aware of who is receiving the data. 03:49.240 --> 03:53.080 It only publishes the data to the topic and that's it. 03:53.080 --> 04:00.760 So each node which is either publishing or subscribing to the topic, is totally independent and anonymous, 04:00.760 --> 04:02.950 and any combination is possible. 04:02.950 --> 04:08.110 For example, you could have three subscribers on the topic, and no publisher in this case. 04:08.110 --> 04:11.830 Well, it's working, but the subscribers will just receive nothing. 04:11.830 --> 04:17.470 If you have, on the other hand, two publishers on the topic and no subscriber, the data is just sent, 04:17.470 --> 04:19.360 but nobody receives it. 04:19.390 --> 04:20.950 Here's another combination. 04:20.950 --> 04:28.630 You have only one radio transmitter, which is publishing on the 98.7 topic, and only the radio player 04:28.630 --> 04:30.400 is subscribing to the topic. 04:30.400 --> 04:31.870 Well, I guess you see the point. 04:31.870 --> 04:38.950 So for now, we saw that you can publish data on a topic and subscribe to it to receive the data, but 04:38.980 --> 04:41.740 a Rosetta node is not limited to that. 04:41.740 --> 04:45.700 In fact, a node can publish on many different topics. 04:45.730 --> 04:53.560 Let's say that the radio transmitter node two is publishing an FM signal on the 98.7 topic, and an 04:53.560 --> 04:56.470 Am signal on the 101.3 topic. 04:56.500 --> 05:03.190 The driver of the car just chose to listen to the 101.3 frequency, so the car is now subscribing to 05:03.220 --> 05:09.080 that topic and decoding an Am signal, and thus it will receive the data from the radio. 05:09.110 --> 05:09.890 Number two. 05:09.920 --> 05:15.380 So a node can contain multiple publishers but also subscribers and any combination. 05:15.410 --> 05:21.200 Actually imagine that the car, while listening to the radio is publishing its coordinates to a car 05:21.200 --> 05:22.340 location topic. 05:22.370 --> 05:31.160 The car node now has one subscriber to the 101.3 topic, and one publisher on the car location topic. 05:31.190 --> 05:36.950 The computer node on the other side is subscribing to the car location topic, and for the communication 05:36.950 --> 05:42.320 to be successful, both nodes are sending and receiving the same kind of message. 05:42.320 --> 05:44.060 Well, that's it for the analogy. 05:44.090 --> 05:49.670 Now you should have a better comprehension of what is the topic and when it is useful. 05:49.670 --> 05:52.460 Here is a quick recap with more information. 05:52.460 --> 05:59.210 So according to the Ros documentation, a topic is a named bus over which nodes exchange messages. 05:59.240 --> 06:05.300 Note that for the previous real world analogy, we used numbers with dots as topic names. 06:05.300 --> 06:09.480 That was just to provide you with an easy example, but this is not valid. 06:09.510 --> 06:15.600 Okay, a topic name must start with a letter and then it can have letters, numbers, underscores, 06:15.630 --> 06:17.220 tildes and slashes. 06:17.250 --> 06:19.590 And we're going to come back to this later in this course. 06:19.590 --> 06:26.160 And technically speaking the messages are sent with DS which is the Ros2 middleware. 06:26.190 --> 06:32.880 But the Ros2 client libraries that you will use on your code, for example, RCL, CPP, and CLP will 06:32.880 --> 06:38.100 provide you with enough abstraction so you don't have to deal with the DS at all. 06:38.100 --> 06:43.050 Then when to use a topic is often when you need to send a data stream. 06:43.050 --> 06:50.070 The data stream is unidirectional, so nodes can publish on the topic and some nodes can subscribe to 06:50.100 --> 06:50.820 the topic. 06:50.820 --> 06:53.790 There is no response from a subscriber to a publisher. 06:53.820 --> 06:56.430 The data is only going one way. 06:56.460 --> 06:59.250 For example, this is quite useful for sensors. 06:59.250 --> 07:05.850 You have a node that reads the data from a sensor and publishes it to a topic, which is then available 07:05.850 --> 07:08.010 for all the other nodes to listen to. 07:08.040 --> 07:11.100 Publishers and subscribers are anonymous. 07:11.130 --> 07:18.240 A publisher only knows it is publishing to a topic, and a subscriber only knows it is subscribing to 07:18.270 --> 07:19.920 a topic and nothing more. 07:20.310 --> 07:27.240 A topic has a name, but also a message type, and all publishers and subscribers on this topic must 07:27.240 --> 07:31.020 use the message type associated with the topic. 07:31.020 --> 07:37.200 Now, as you already know, you can write a node in multiple languages using, for example, the Clcp 07:37.200 --> 07:45.630 library for C plus plus and CLP library for Python, while those libraries also include the topic functionality 07:45.630 --> 07:53.160 so you can create a publisher or subscriber in any Rosetta supported language directly inside your nodes. 07:53.190 --> 08:00.180 And finally, a node can contain many publishers and subscribers for many different topics. 08:00.210 --> 08:06.330 To conclude here, you can see that you can easily separate your code into independent nodes, and then 08:06.330 --> 08:11.310 you can make your nodes communicate with data streams sent over topics.