Advanced Submap Architecture: NIA & IA Systems | Marvelmind

0:01 Hello colleagues, let's proceed with a deep and broad topic of building submaps. In the first part, we already covered the first items marked green. Now let's finish with basic hints and move further. An important part: how to align submaps. So when you build submaps, how basically do you do it? How do you build them? How to make sure that some maps are neighboring submaps actually matching the location? And there's a functionality which we call "M1M2," which is enabled by M1M2. So there's a button which activates this functionality. What it does—so for example, you have two beacons, two mobile beacons, one and two. And when you activate M1M2, the system is basically

1:01 enabling both opinions so from submap one and submap two. And when you have this activated and the submaps are not aligned, then instead of two mobile beacons you'll have four mobile beacons. And the alignment is super simple: you physically take it in the Dashboard and move one of the submaps against another submap, and then it's aligned. It's aligned like this. And of course you can zoom in, zoom out, but it's aligned to the centimeter level. And that's it. Of course you check it by moving. Of course, you must build the service zones and handover zones, but the checking and verification that submaps are aligned is done by moving in and out from one submap to another, crossing their handover zone.

2:00 It's possible to achieve the same without this M1M2 functionality, but with M1M2 it's much, much easier and faster. So effectively, you have two mobile beacons installed on whatever—half a meter, one meter distance—either two separate tripods or one tripod with some whatever horizontal part. And then you move this part along the submaps and put it into the handover zone, thus making the alignment. So in this particular demo, the handover zones and service zones were not built, so that was a partial mistake. But you put it inside the handover zone, and then you line it, align it, until four images of mobile beacon become two. Then they're aligned. Why two? Because in this case, if you have only one mobile beacon, then you have two

3:00 opinions. Then you align, but you still may have angular inaccuracy. With two, it's like a line. So if you line both of them and they have a distance of half a meter, one meter, that's sufficient, and they would be aligned on the position and on the angle. So use M1M2. It's a very, very powerful feature to make the alignment between the submaps very quick. Now let's discuss different architectures that we have. As was mentioned in the beginning, and you probably already know, we have Non-Inverse Architecture, Inverse Architecture, and Multi-Frequency Non-Inverse Architecture. The difference between them is very simple, and the key defining factor is very simple: who is emitting ultrasound? In Non-Inverse Architecture, the mobile beacon is emitting ultrasound, and the

3:58 stationary beacons are receiving ultrasound. In all cases, the Modem is a central controller defining their clocks, defining their timestamps, synchronizing, getting the telemetry data. All the beacons—station and mobiles—are talking to the Modem only. They don't talk over radio between each other. The radio talk to the Modem only. But in this presentation, we are not touching that because we are focusing on ultrasound. And when we are discussing building the submaps, it's mostly about ultrasound and ultrasound frequencies. So let's focus on that. So Non-Inverse Architecture: mobile beacons are emitting ultrasound, stationary beacons are receiving ultrasound. Since Super-Beacons, they can receive any and all ultrasound frequencies at the same time. So when you get your set or when you deploy it, it doesn't matter what

4:57 frequencies of Super-Beacon you have—it's valid only for Super-Beacons. It's not valid for beacons version Beacon HW v4.9 if you still have them, because hardware version 4.9 they were analog and they had a possibility—and they have had the possibility—to receive only a single frequency. So for example, you have a 31 kilohertz Beacon HW v4.9, then it can receive and transmit only 31 kilohertz. It cannot operate with 25 kilohertz at all. Super-Beacons are Super-Beacons, so this is why they are capable to transmit only their native frequency. So if you have, for example, a 25 kilohertz Super-Beacon, it can transmit only 25 kilohertz, but it can receive any—19, 22, 25, 28, 31, 34, 37, and 45—all our eight ultrasound frequencies we support

5:57 today. So remember about this. Inverse Architecture historically came later, and Inverse Architecture is in terms of internal structure significantly more complex than Non-Inverse Architecture. Why? The complexity stems from the fact that the mobile beacon is receiving ultrasound, and it must receive not a single ultrasound from stationary beacons but several different ultrasound frequencies at the same time. So for example, for a 3D submap, it must be at least four stationary beacons, and all four stationary beacons must have different ultrasound frequencies. So in this example, 19, 25, 31, and 37 kilohertz. It's very complex to get and receive and distinguish and filter four ultrasound frequencies at the same time. So this is why Inverse

6:56 Architecture is significantly more complex internally, and also it puts additional requirements to understand the details from the end users. For example, a typical mistake is to try to build Inverse Architecture with, you know, 19, 19, 19, 19—no, it will not work, because the system will not be able to distinguish between different beacons having the same ultrasound frequency. No, it is distinguishing based on the ultrasound frequency. So it means that in one submap, each beacon must have different ultrasound frequencies. And with complex maps, it becomes more complex because we have only eight frequencies and those frequencies must be reused like in cellular networks. There is a limited number of channels and they must be reused after some time. Very similar here: simply we have fewer frequencies, so the requirements are tougher, but it's doable. We will explain how, but remember

7:56 in Inverse Architecture, the mobile beacon is receiving ultrasound, and in Non-Inverse Architecture, the mobile beacon is transmitting ultrasound. In Inverse Architecture, stationary beacons are transmitting ultrasound on different frequencies, and in Non-Inverse Architecture, stationary beacons are receiving ultrasound, and they can be on different frequencies. Those Super-Beacons, because they do not transmit, it does matter, and they can receive any frequency. Multi-Frequency Non-Inverse Architecture is the latest. It can actually be introduced—it's still Non-Inverse Architecture because the mobile beacon is emitting ultrasound. And the difference between Non-Inverse Architecture and Multi-Frequency Non-Inverse Architecture is that in Multi-Frequency Non-Inverse Architecture

8:54 when you have more than one mobile beacon, they can operate on different frequencies. For example, in Non-Inverse Architecture, if you have one mobile beacon and it's whatever 25 kilohertz, and in Multi-Frequency Non-Inverse Architecture you have one beacon which is 25 kilohertz, there's no difference—it's the same Non-Inverse Architecture. But when you have more than one mobile beacon, then in Non-Inverse Architecture both must be on 25 kilohertz, and the drawback is that you can serve only one mobile beacon at a time in Non-Inverse Architecture because one, two, one, two, one, two, one, two—they must jump in time slots. So now you are serving mobile beacon number one, and the second time slot, which is one eighth of the second, for example, with a typical update rate of eight hertz, you will be serving the second mobile beacon. But in Multi-Frequency Non-Inverse Architecture, you have up to eight

9:53 Mobile beacons deconstruct at the same time, so you have one mobile beacon on 19 kilohertz and another mobile beacon on 25 kilohertz. They both will be meeting at the same time; they both will be getting update rate. So effectively, for eight mobile beacons, the update rate per beacon for Multi-Frequency Non-Inverse Architecture will be eight times higher, which is absolutely great. Then for Non-Inverse Architecture—for Inverse Architecture, it's a different story because Inverse Architecture works very much like GPS. For Inverse Architecture, mobile beacons are receiving ultrasound and you can have 200 beacons at the same time receiving location updates rate and calculating it, and they all will know location update at the same time. So this is why, if you have 100, if you need hundreds and hundreds of mobile beacons—typically it's Inverse Architecture. The drawback of Inverse Architecture is only one: the mobile beacon that is receiving ultrasound.

10:52 So it means that if, for example, you have noisy objects like drones, Inverse Architecture most likely will not work. So we do not recommend Inverse Architecture—at least today—for drones because drones will produce very high noise. This noise is wideband noise which goes from acoustic and audible noise to ultrasound as well, and it will limit the range of Inverse Architecture to maybe a few meters or maybe three to five meters or something even smaller. It depends on the drone. So Inverse Architecture doesn't work with noisy mobile objects like drones, but it's absolutely fine for people, for robots, for forklifts, even in a very noisy environment because it's still not so noisy as a drone 20 centimeters away. When you have not hundreds of objects, but let's say eight or even sixteen drones, then...

11:52 Multi-Frequency Non-Inverse Architecture is your choice in applicability to building submaps. What are those differences? Already mentioned: Non-Inverse Architecture may have three Super-Beacons on any frequency. So this is why we recommend you start with Non-Inverse Architecture. If you mess up—you know, you don't know all these details—you install Super-Beacons, they will work in Non-Inverse Architecture. But in Inverse Architecture, no, it will not work because you must have circuit beacons on well-specific frequencies. For example, if you have 19, 19, 25—no, it will not work. If you have 19 and 25—yes, it will work. If you have 25 and 25—no, it will not work. Once again, in Inverse Architecture, because the basic rule is not met. It's not a complex rule, but when you are novice to the system, it's very easy to...

12:52 ...make the mistake. There's another reason—quite a few reasons we will discuss about them—like dynamic range. If you are too close to the stationary beacon and at the same time too far from another stationary beacon in Inverse Architecture, the close beacon will be overshouting. It's like if, for example, I have a mobile beacon and my stationary beacons are basically shouting pulses too loud. So it means that this mobile beacon must listen at the same time to a signal from a close stationary beacon—from me, there—one of the stationary beacons and from a distant beacon. And since I'm too close related to that beacon, that beacon will not be heard because the dynamic range of distances is too high. We'll discuss a bit later. So in general, if you want to deploy a basic starter set—for example, then IA...

13:51 ...or Inverse Architecture is almost equal to Non-Inverse Architecture. But if you discuss, for example, a huge warehouse, then to build a large Non-Inverse Architecture map is about one-tenth of the complexity of a large Inverse Architecture map. Again, it's doable, not a problem, but simply you need to follow and to need to understand much deeper details with Inverse Architecture because it's more capable, but at the same time more demanding to you as a person deploying the system. So this is why the basic recommendation—you know, lengthy explained in this step-by-step guide—is: start with Non-Inverse Architecture, basic 2D, achieve perfect tracking, and then move to a bit more complex, like 3D, still Non-Inverse Architecture, and then from 3D, if you wish, move to Inverse Architecture 3D, et cetera. But move in small steps at a time.

14:50 Don't try to jump to the end. So that's the key message. Let's now discuss those samples—examples of building submaps. There are many, many ways we will cover some of them. Some of them probably will be missed; we will add them later in some additional presentations. But let's discuss, in short, so this is the most simple 2D submap that we recommend you to build when you get, for example, Super-Beacon starter set. So this is the most simple one: 2D, one mobile beacon, and one Modem. As I said, more than this we are not discussing because it's somewhere—it can be placed anywhere; it doesn't matter. So two stationary beacons: one stationary beacon is on one wall, and on the same wall another stationary beacon. And they have the same frequency—so the same color, the same frequency—and this is the mobile. That's it, basic, perfect. It can be different...

15:48 ...frequency for Non-Inverse Architecture because they do not emit ultrasound when tracking is done; they receive ultrasound. So it's not relevant to talk about the frequency of stationary beacons in Non-Inverse Architecture because they're receiving. Super-Beacons can receive any frequency. We are not talking about Beacon HW v4.9 because they are applicable to Non-Inverse Architecture only and they are pretty mature. So when I'm talking about beacons, keep in mind that I'm basically referring to Super-Beacon or Industrial Super-Beacon, which is the same in terms of technology—simply more protected. 3D submap is very similar to 2D, but instead of 2 beacons, you have 4 beacons. Again, these beacons in Non-Inverse Architecture can be any frequency, but they must be placed to make kind of a rectangle or similar. They must not be placed on one line.

16:47 Because it will be not a volume; it will be not 3D; it will be line. So effectively, it would be—I mean, 2D submap consisting of four beacons. This will be math; it will not work. So always do the volume; place on another wall. It can be on different height; it doesn't matter. You anyway must enter the height for stationary beacons always. For 3D, the minimum number of beacons is three, but it's too easy to have obstruction like an obstacle. And in this case, for example, this beacon hardly can see. So you can see it's almost in the shadow. This beacon can see, this beacon can see, but this stationary beacon is already near their obstruction against the mobile beacon. So this is why we have three plus one redundancy: at least three out of four must be seen by the mobile beacon. In this case, the tracking...

17:44 ...will continue almost in 99—in the majority of cases. Like here, still all four beacons are seen. So then the system is basically choosing the best triangle: one, two, three—one combination; one, two, three—another combination; one, two, three—third combination; there must be fourth combination anyway. So therefore combinations of triangles, and the system is automatically choosing based on some criteria parameters which one is the best and using it. Sometimes it's using a combination of all those, but it's all possible only when you have redundancy. If you had three beacons and one is blocked, that's it; you'll have no tracking because for 3D you must have three stationary beacons. So this is why a 3D set has four beacons included and three plus one redundancy by default, and we strongly recommend it to you. Service zones is a good to have when you have a single submap. Why is it good to have? Because service zones...

18:43 ...define the area where the beacon will be served. If you don't define the service zone, there is always a service zone—implicit service zone—which is 30 meters from each of the beacons. So you have a huge submap anyway. But if you have a huge submap, ultrasound will travel longer. If it travels longer, then it takes more time, and then the update rate will be lower, of course. Regularly, typically, you want to have as high update rate as possible. So define the service zone, and it always helps. Now let's discuss a more complex area: when you have several submaps in Non-Inverse Architecture. As was mentioned, Non-Inverse Architecture is simpler. So this is one submap—you just build it in the previous case, okay? In this case, this one submap, another submap, third submap. How to build submaps? We have an...

19:42 There's an article about this, so the links are there. So build one by one: how to build one submap, freeze it, and even shut down all the beacons, you know, just remove them even from the network. Then build this submap like this. This submap doesn't exist—build it as a standalone submap again. Achieve perfect tracking. When I'm saying build submap, it means that you build the beacon, you build the table of distances, and you proved by tracking inside the service zone of this submap. This tracking is good. So in this case, you confirmed that the submap is good and it can be frozen. Freeze it and forget about it, even disable the beacon or send it to sleep. This one is commonly used in this submap as well. Do this submap like all other submaps.

20:41 Do not exist. Repeat with all the submaps you wish, and so forth. In architecture, as mentioned, the beacons can be any frequency. We do recommend to always order beacons with different frequencies as many as you can have. Why? Because it gives you freedom. Today you deployed NIA, but tomorrow you may change. You might say, "Oh, I love it. I want Inverse Architecture. That's great." But you already have the beacons which would support your Inverse Architecture only because of this. So this is why typically you can use whatever frequencies, but we recommend deploy like you would be deploying Inverse Architecture because then you can update the software and you may have already deployed Inverse Architecture system without much tuning or no tuning at all. Service zones is a must in this case. Why? Now imagine that this is a distance of, whatever, 15 meters. This is a distance of 5 meters. This is a distance of another 5 meters.

21:40 If you don't define the service zone, each beacon still has a limitation of distance. You know, default limitation distance is set to 30 meters. 30 meters means that this beacon will try to get the data from, or to get the ultrasound signal from this beacon because it still will be below 30 meters. But that's not great because obviously it's much easier to track by these beacons. You know, distances are closer, the angle is better, everything is better. But this beacon will try to say, "Yeah, yeah, I know the distance. I know it." It will report to the system. The system will have to pick up from six stationary beacons because it's more than enough. You know, if you need only two, it will collect the data from six. But it may collect the data from further beacons, and you will have poorer results because

22:39 you know, longer distance. There are still more possibilities for the signal to become weaker or obstructed or anyway. So chances that the location from the beacon will be poorer than from the closer beacons are much higher, obviously. So this is why limit those opinions by making submaps. Submaps are basically saying—oh, sorry—submap service zones. Service zones are basically saying, "This is your responsibility, dear submap number one. This is your area of responsibility. This is submap number two. This is your area of responsibility. Submap number three, kind of, do not try to share your opinion when it's far. In normal conditions, when you have a large warehouse you typically deploy systems like 20, 30 meters between the beacons, and it's physically not capable to listen there. But in small areas like

23:38 museums or rooms, it's very easy to have submaps of much smaller size, like five meters, I don't know, two meters, 10 meters. And some maps might try to share opinions, which will create a mess. So always use service zones. Service zones is a must. Again, in NIA, ultrasound frequencies of Super-Beacons can be any because it's not irrelevant. Ultrasound station beacons listen to ultrasound, so what ultrasound transmitting frequencies they have is simply not relevant. So we were talking about, in this case, three plus one redundancy. But sometimes you remember in the beginning we had three reasons to have submaps. One is extend range. And in this case, we're basically

24:37 extending the range. So you can extend it more and more and more submaps, and then you can cover one kilometer, for example. If the Modem is capable enough and has directional antennas, you can cover 500 meters in that direction, 500 meters in that direction, and you can cover whatever tunnel of one kilometer long. And this submap is 20, 25, 30 meters. Okay, you can extend it further, further, further, further. So that's the first reason. Second reason we already discussed: if you have rooms, in each room you must have at least two stationary beacons for 2D and three or four stationary beacons for 3D in order to cover each of the rooms. Check the placement manual. That's when you have static walls. But sometimes you have either this kind of static wall in the middle or mobile obstructions—I don't know, people moving or forklift is moving. And forklift creates a shadow to whom? To the mobile beacon or to people around? Not a problem. So, for example, you have a room

25:35 and you place two stationary beacons on one room, or one side of the room, one wall, and another side of the wall. And we have two submaps facing each other—one is facing this direction and another facing this direction. And service zones are fully overlapping submaps. So we call them fully overlapping submaps. And what it does, it basically—if here we were saying we would like to avoid the second opinion, in this case we say, "Yeah, yeah, we want the second opinion." So when both beacons and both submaps are seen, then both submaps are saying, "Okay, I know the location of this mobile beacon is X, Y, Z." Another submap is saying, "Yeah, yeah, we know that the location of this beacon is X1, Y1," which is very, very similar. It will be almost the same spot, you know. If there's

26:33 a maps—a line. But if, for example, this mobile beacon is moving a bit further, it will be in the shadow of this obstacle. In this case, this submap will not be able to provide this location data. Okay, not a problem, because this one will still have—so we intentionally do end redundancy. And in this case, obstacles are not a problem because if one of the submaps is not able to serve, another submap will serve. So that's the reason for using fully overlapping submaps. And there is a video—please check it. It's very, very useful. So the same logic can be extended even further. This could be, this could be some maps, so it's kind of four overlapping submaps. It's also possible. It's not today supported because typically two submaps are covering 99 percent of cases. Now let's move to the most complex area

27:31 which is Inverse Architecture. Again, it's more than doable if you do it step by step. If you understand the basic logic, you don't try to jump, and follow this understanding of the requirements, then it's very simple. But since there are a few requirements, if you miss any of those or violate any of those, then it will not work. So this is why it's more complex than NIA. And this is why, as soon as you master NIA, move to Inverse Architecture. So let's start with the mistake first. The mistake is very, very simple: station beacons are the same frequency. If they have the same frequency, it will not work because the mobile beacon is receiving ultrasound. And if two beacons are transmitting the same frequency, the system will not be able to distinguish this ultrasound frequency—whatever, what was the frequency? 22 kilohertz, 22.22? The system will not be able to distinguish from which of the beacons

28:29 this 22 kilohertz frequency came. So it will not work. In NIA, in Inverse Architecture, this will work because this is 22 and this is whatever frequency—different anyway. System will know, "Okay, I received 25, for example, it's 25 kilohertz, and the distance was, I know, two meters. I received signal from 22 kilohertz, and the distance was, I know, seven meters." Okay, so this is my location. That's it. That's here. I'm about—beacon's location done. Everything is done. So remember, the first and the most important: each station beacon in the submap must have a different ultrasound frequency. Now let's discuss when you have more than a single submap. The same story: one submap, another submap, third submap. The same case with NIA. But now Inverse Architecture, it's a bit more complex. Why? Because

29:28 You need to, first of all, provide in each separate submap frequencies different. So you see, this was 36, 34, and 22. This was 22 and 25. This was 25 and 45. Okay, first rule: in each submap, a pair of beacons have different frequencies. But that's not the only rule. Imagine—okay, I guess we are discussing this in this area. Imagine that you made a mistake. You see the difference? No, this one they already touched the same—the same frequency in one of the submaps. Violation. It will not work. So this is a good one. This is not a good one because one of the submaps have

30:24 frequency the same. But this is a basic one again, difficult to miss, but some people do. This is a more complex one because you see, each of the submaps they have different frequencies. Okay, 34, 22—not a problem. In this submap, 22, 34—not a problem. Will it work? No, it will not work. Why? Because in the same map, in the same time slot, you have two beacons or two submaps with the same combination of frequencies. It will not work because imagine if this mobile beacon receives this signal. In this particular case, it may even work. Okay, let's guess now. It may work, it may not work.

31:22 Because, for example, it received their signal. We don't know where it's placed now because we are trying to determine the location, but what we know is that in this time slot, it received the signal from 34 kilohertz, and it was roughly, I don't know, four meters, for example. And it received the signal from 22 kilohertz, and that was, I know, 10 meters. Okay, fine. But let's now imagine this submap. In this submap, no, I think in this submap it wouldn't be possible. In the system, even though it was a mistake, the system will try to compensate for your mistake and say, "Yeah, yeah, it's a mistake." But the system will still be able to find the location based on distances. There's a mistake because you have two submaps with the same frequency combination, but it still would be able to distinguish between this and this because this combination of distances is not possible in this

32:21 because the shape of their submap is different. But let's imagine that this would be here. In this case, it would be five meters and five meters. Okay, but the same is possible here, so also five meters and five meters. In this case, the system would not be able to distinguish: is this mobile beacon receiving the signal from this beacon or from this beacon? From this beacon or from this? So is this in this submap or in this submap? So if it's, for example, in the middle, then five and five. In this case, it's also five and five. So system doesn't work. And their solution for this is very simple, as already discussed: use their ultrasound pairs of different combinations—very many. We used to have only five frequencies. It was more demanding. Now we have eight

33:20 frequencies, and it's pretty easy to achieve even for very large networks to have a unique combination of frequencies. So this is the mistake. One of this must be replaced with one of the not-yet-used ultrasound frequencies. So this is once again why we are saying: get as many different ultrasound frequencies as possible, so you have much freedom when you build the network. What is this? Ah, okay. So in this case, you do not violate yet. You have a larger network, and this is the problem that I mentioned. The solution is very simple: you can use TDMA.

34:19 What does TDMA mean? You use TDMA. It means that this submap and this submap don't transmit at the same time. In this case, yes, it's sub-optimal, but it will work. So it means that time slot means that if, for example, you have eight times per second update rate, and this submap will transmit in odd time slots, and this will transmit in even time slots, so they will not work at the same time. So there will be no ambiguity about the location. You see, submap is exactly the same in terms of combination of frequencies, but there will be no ambiguity because at each moment we will know which submap is serving. In odd time slots one, three, five, et cetera, this

35:16 will be serving, and in even—second, fourth, sixth, et cetera—this will be serving. So if their mobile beacon is receiving this and these frequencies in the even part, we know that it's here, and the location is here, not here, because in even, this map simply doesn't transmit, and the beacon—this particular beacon—doesn't emit. So the mobile beacon cannot hear this frequency at this time. But it's sub-optimal. Why? Because TDMA comes with a drawback, and the drawback is reduced update rate because you do not transmit eight times per second this submap, but only four times per second. So yes, it's possible, but it's sub-optimal. If you don't employ TDMA, then it's a mistake. It will be this kind of mistake. It's simply not okay. So this is why if you use TDMA, it's sub-optimal. Because you can still use some other frequencies,

36:15 you used only five or six frequencies. You have eight different frequencies, so you can use it. But with TDMA, it's possible to use it still, but it's sub-optimal. If you don't employ TDMA, it's not okay. It will not work. It will be a mistake, and the system will report the beacon either here or here, and they will be jumping. There will be all kinds of mistakes. Hopefully it's clear now. Let's talk about even more complex areas, which is 3D Inverse Architecture. Again, it's complex because more beacons and more frequencies, but the logic is absolutely the same. So in each 3D submap, you must have four stationary beacons—again, three at minimum, and sometimes if you have two severe frequency limitations or it's impossible, three is kind of okay, but we do not recommend. We always recommend to use three plus one redundancy, meaning four frequencies.

37:13 But four frequencies means what? Particularly for 3D, it's very quickly becoming all frequencies are used. So for example, one, two, three, four—you used another submap. Already six. Another submap—oops—all eight frequencies have been used in just three submaps. What to do? You must reuse the frequencies. So for example, this frequency is already the same. Okay, this frequency is already the same. Is it a problem? No, it's not a problem. Again, first you check that each submap has unique combination of our frequencies. So this, this, this, and this. Check whether any of the submaps have the same combination of frequencies. There is no such submap. Second, you must not have enabling submaps the same frequency. For example, this—this—whatever color—must not be this

38:12 one. Otherwise, it will be a mistake. So check that as well. So this is exactly why Inverse Architecture is a bit complex because there are many layers you need to check, and it's very difficult to make a mistake if you are inaccurate or not deep enough. But otherwise, as soon as you comply with those basic rules, Inverse Architecture is not impossible. It's not complex. It's simply more demanding layers. And their final requirement is that ultrasound signal is not propagating to the distance. So for example, this one, you know, more than 50 meters. Okay, the signal from this beacon will come here, but it will be already attenuated too much, and it will not hurt. The signal from this ultrasound beacon will come to this, but it will be attenuated because it's, you know, more than 50 meters, so it will be a weak one, and it will not be noticed. It will be

39:10 Below the noise, so it will be below, etc. So it will not harm. So when it's large submaps, large map, and large submaps, this will work. For example, huge warehouse. So this is a good 3D submap or 3D map. But this one is not good. You see the distance? It was 50 meters. But now we have a smaller area, like, I don't know, museum. You know, many small areas, and you need to place many beacons. And the distances are much smaller—not 50 meters, but 10, 5, 15 meters. So what happens? It happens that, for example, this beacon in this area is virtually the same. You see, it's the same. So there's no violation in terms of frequencies, in terms of frequency combinations, etc. It's fine. So the first rule is met: all submaps have different combinations of frequencies. The second rule: that

40:09 neighboring beacons, they don't have the same ultrasound. So the system may distinguish between also that. But the third rule—the distances are large enough—so the ultrasound system is attenuated. Or ultrasound signal is attenuated while reaching. That is not met because, you see, you are still in this server's zone. So this, this, and this, and this are serving beacons. So their service area. But this beacon is, you know, close, you know, whatever 10 meters away. And the signal is not attenuated. And this beacon and this beacon are emitting at the same time. So this ultrasound signal will simply come sooner than this because it was built in such a sub-optimal way. It will come sooner, and it means that by the time when this

41:09 signal comes, and you basically define a server zone, but kind of who cares? Because this ultrasound signal will propagate to this. Even though you say, okay, this is my server zone, that's fine. You cannot stop the ultrasound signal. It means that in this area you will not listen, and you will not pay attention to this. But in terms of ultrasound frequency at this point, it will not be possible to distinguish between this frequency or, let's say, frequency—let's say ultrasound signal from this beacon on this frequency and ultrasound signal from this beacon on the same frequency. It's not possible. Even more, this will come sooner than this one. So the system will not work. What are the solutions? There are several. Now, first of all, you could place this beacon somewhere like it was before, like in this area. So this placement is very important. Second, you can change the frequencies. You can align beacons differently. You can move this beacon to whatever it is, and this, and then it will

42:08 emit in that direction. So you can realign in different directions in order to meet all those requirements. Another option is, of course, to employ TDMA. If they confuse, don't let them live in the same time slot. But as mentioned, TDMA is always a solution. But TDMA brings lower update rate. But the whole idea of Inverse Architecture is to have the highest update rate possible for multiple, multiple mobile beacons. But when you have very large networks, most likely you'll have to use TDMA. It's only a matter of how many time slots you have. Two time slots in normal conditions have only one time slot, and everyone emits in the same time slot. When the map is too complex and some maps have too many, and you cannot avoid it—you, you know, you tried all the options, impossible—okay, TDMA two means that two time slots: one, two, one, two, one, two. Sometimes, when it's too complex, too small submaps, you may have three slots.

43:07 Even four slots. But in this case, your update rate will drop four times, which is still okay in many cases. For example, you have eight Hertz update rate per system today. Four means that per beacon, it will be two Hertz, which is sufficient for people. Taking for the majority. But again, everything which brings additional complication brings additional, you know, chances for something to mismatch. Something will work because your service zone or, Honduras must be longer because the update rate is smaller. And if your object is moving too fast anyway, so it brings some additional complexities which you need to take care of. So this is why TDMA is always a solution. And this is why using TDMA and service zone and eight Hertz, you can build as large maps as you wish because after 50 meters, you can reuse the same frequencies. But

44:06 employ TDMA as a last resort because it's not free. Um, now about the dynamic range of distances. I already briefly mentioned it. What is this? Inverse Architecture relies on a mobile beacon receiving two or more ultrasound frequencies at the same time. Of course, it's digital technology, etc., but still, you as a mobile beacon must receive two pretty close ultrasound frequencies. For example, 22 and 25 kilohertz—just three years difference. You must receive two of them at the same time. And when they're, uh, you are very close to one of the stationary beacons and another stationary beacon is far, it's very difficult or even impossible to do so. Again, it depends on many parameters, but our basic rule of recommendation is the following: if you have

45:03 19 and 25, 25 to 31—so six kilohertz difference—then dynamic range of differences, or distance ratio, is one to ten. So, for example, if you have the maximum distance of 20 meters, then the closest you can be to their closest beacons is two meters. If you have 30 meters, then the closest would be three meters. So it's kind of a rule of thumb. It depends on many other parameters, but kind of rule of thumb is one to ten. If you have eight frequencies, not five but eight frequencies, in this case it's more demanding because it's very, very close. And our recommendation is one to three, which is already pretty limiting. But in reality, not really. Why? Because typically you place the beacons at a height like five meters. So imagine if you place the beacon at five meters and you track people—let's say at two meters—so the very minimum distance between

46:03 a person would be three meters. And in this case, even one to three, it's like 10 meters on the distance. So, but again, it's not a rule of thumb. It's, uh, it's not science. It's more than a rule of thumb. So it means that in practice, if you put, for example, the beacon at six meters or ten meters, in this case the minimum distance would be seven and the maximum distance would be 21 meters, which is okay. In this case, it's typically 20 meters inside the warehouse. So place it. It may be less than. So it may be one to four, one to five. It depends—depends on the frequency, depends on the external noise, depends on anything. So it's more, uh, is again, it's a guidance. And remember to use: you cannot come with the mobile beacon just next to the stationary beacons because stationary beacon will be emitting sound and it will be basically overloading the microphone and overloading the filters. And those filters would be able to you

47:03 know, receive this signal which is close. But at the same time, won't be able to distinguish the signal from their father beacon. If the frequencies are very, very similar, so remember about this. It's probably the last one—important, not so critical—but it also depends on what, you know, specific application you have. TDMA, we already mentioned about TDMA. So TDMA is the last resort. It's obviously used in complex maps. So, for example, like this one—we already discussed. See, this submap and this submap intentionally have the same frequency. For example, you have a huge, huge, huge, huge map. And at some sort, at some time, you will have a combination of frequencies that are the same. So one, one, two, two, three, three, four, four—intentionally. So the system, uh, without—in the system has many layers like history.

48:02 For example, like this has this shape, this has this shape. But the system still may confuse. So the first rule: beacons inside the submap must have different combination of frequencies. So this first rule is not met. So do not rely on other rules in order for the system not to be confused. So as soon as I have this combination, the recommended way is to employ TDMA. So TDMA stands for Time Division Multiple Access. So this submap and this submap do not live in the same time slot. They are living in different time slots. So this is in different time slots. What it does: so this is configuration in my odd slots—slot one, slot three, slot five—and this is my configuration in second slot, in fourth slot, and fifth slot.

49:00 It's all the time jumps between them, and in this case there is no problem because you see there is no similar configuration. But look, this is my mobile beacon. So my mobile beacon will not be served during this time because there is no submap in this area. So it means that the update rate for my mobile beacon will actually drop to one-half of my regular update rate. If my regular update rate is around eight hertz, so my effective update rate per mobile beacon will be only four hertz in this kind of configuration. But TDMA is an extremely powerful feature, and employing multiple frequencies and building properly and employing TDMA, you can build as large maps as you wish. Now, about their service zones, we already mentioned

49:59 this, but this is more specific. For example, why we strongly recommend to use the service zone even for single submaps. How the system works: the system anyway has to listen to some time. What time? It's a default limitation of distance, which is 30 meters. So it will listen to 30 meters divided by speed of sound, which is around 340 meters per second. So it will listen about 100 milliseconds. So if it listens to 100 milliseconds, you will not be able even in theory to have an update rate more than, let's say, ten hertz. In practice we need time for radio, for calculation, for filtering, et cetera, et cetera. So a date rate will be not ten hertz but like five or six hertz if they have the full distance. But if your submap is only, I know, five by five meters, what's the point to have 30 meters? Build it five by five.

50:58 Specify the service zone. In this case you're basically saying this is your area of responsibility and do not listen more than five divided by 340 meters. So don't listen more than, whatever, 16 milliseconds. There's no point because all other will be not our signal. And in this case you can increase your update rate significantly, times two, three times, easily, simply because you specify the service zone. So it's very useful and always use the service zone when you build, even a single submap, because it will increase your update rate. So this is a good service zone and this is bad service zone because it's too large. There's no point because this is your room, for example. There are many special cases: one D submap. If you have a long corridor or long tunnel, sometimes you don't need that. You don't need Y. You need only

51:56 along the route. That's good because we typically say the maximum distance of a one D submap, or let's say offset map, is 30 meters. But for one D you can employ the horn. With horn you can have up to 100 meters. So you can have very, very long submap if you install one horn on one side, another on another side, whatever ten meters overlapping. So you effectively can cover up to 200 meters tunnel with only two station beacons. Now it's a very strong thing. Vertical two D: you know, for example, you have a palette. You don't care so much about the person or this kind of—so in this case your X Y, which is typically horizontal, becomes vertical because you care where you put

52:54 their palette. So your X would be this and Y would be instead of that. So this is vertical two D submap. You don't care about this height because you care where you put your palette. The same, for example, if you want to draw this paint on your huge wall. So you have two D, but this two D is vertical. So this is vertical two D. It's not complex. You can build it. But a special case: there's even a video where we are showing how to combine one D, two D, three D, and vertical two D in the same submap. Is it possible? Yes, it's possible, of course. There will be some kind of distortion when the mobile deck is moving from one D to two D, from two D to three D, from three D back to vertical two D. Some sort of distortion. But it will depend on the particular case, on how well you align

53:53 the maps, et cetera. But it's possible to have different dimensions or submaps of different dimensions in the same map. Besides that is a special case for drones. For example, sometimes when the drone is flying inside the building, inside hangar, and then flies away. So and you want to use the system, for example, to land the drone. Is it possible? Yes, it is possible. But you have two options. One option is that you install the station beacons on the floor and your landing pad for the drone is in the middle. Will it work? It will work perfectly for X Y, but for that in this floor area it will not work. Again, we have a specific video. Check it. We have a specific description in the replacement manual why the problem is. There is also another video about too

54:52 wide and too narrow. Check that. So this particular case is too wide. So the set will be imprecise. X Y will be precise. How to avoid it? Use precise configurations. We'll have four beacons on the floor and two beacons on some height. In this case, when it's low, it will be using these four beacons—one, one, one, one—so four beacons for that only. And these four beacons will be used for X Y. In this case you will have precise X Y from one submap and precise also X Y, but for this vertical three D submap it will be X Y, but for this beacon it will be that. So this data will be taken and combined with this. So you will have that from this submap and X Y from this submap. But we need six beacons. How to avoid it? It's very simple. Place

55:50 the station beacons on the ceiling. But in this case you must not fly above this ceiling because with the same story of this crossing line connecting beacons in two D, you must not cross the plane connecting beacons in three D because otherwise the system will not be able to distinguish between two different three D points with four beacons only. So it means that if you fly the drones only inside and you want to build it as simple as possible, place them on the ceiling and fly them from the floor to the ceiling, but not next to the ceiling, you know? Leave some distance so it will be still not too wide over there. A few examples: so similarly we discussed the theory, but there are some practical examples. For example, this particular our

56:50 robot is moving inside the warehouse or assembly plant. And how it was built, how many submaps, why, what frequencies, the real performance, et cetera. And another example for people tracking: so a huge—not so huge but nevertheless—a factory, a real life factory. How many beacons, why they are placed there, where they are placed, how many submaps effectively you need. It's very noisy environment, so like real real-life examples. So as a summary: start with Non-Inverse Architecture. It's a very simple one. It's difficult to make mistakes. Start with it and increase one step at a time the complexity. In this case, you know, from two D to three D, from two D, for example, in Non-Inverse Architecture to Inverse Architecture. This way you can build even huge Inverse Architecture maps consisting of

57:48 multiple submaps. But don't jump to the end, you know? Increase one by one. Maps can be virtually any size. We already showed how it can be done. Update those rules and you can, you know, build and beep and build as many as you wish. So today we support 250 submaps in each map. If you need more, it's also possible. Supermap is there. Just let us know by writing to info at Marvelmind online.com. Thank you very much. We hope that you will be able to build submaps and maps properly. Thank you.