Submaps & Handover Zones: Scaling Indoor Maps | Marvelmind

0:00 Hello colleagues. Today I will be talking about submaps, service zones, and handover zones. More and more of our customers are building larger maps consisting of more than one submap, and we would like to address the basics. We do have detailed information in our operating manual, in our placement manual. Even we shot quite a few videos on how to build those submaps. But let's start from the basics. What are the submaps? What are the handover zones? What are the service zones? What are they? Today I will have my cheat sheet, basically Q and A that we usually answer, but I wanted to address them one by one. So what is the map in general? A map consists of submaps. Submaps is a small cell which can consist of one beacon if you want, or one or two beacons, and then you can have two submaps or three or more, up to four station beacons in one submap. And this submap is a cell, like a cell in a cellular network.

1:00 Then, if you want to build a large map, then you build additional submaps. So this submap would be, for example, covering this area, and another submap covering this area, and there would be two additional beacons, and then another submap covering this area. By default, each of the submaps have some service area, service zone as we call it. Service zone, if it's by default, it's 30 meters from there, from the furthest beacon. So for example, if you have their submap...

1:58 3D submap like this, so your default service zone would be up to 30 meters from this beacon, then up to 30 meters from this beacon, from this, et cetera. So it will be an overlapping of all 30-meter radiuses from each of these beacons. So the shape of the submap would be something like this, this, and this. By default, okay, maybe it doesn't seem well, but that's by default. It doesn't necessarily mean that's your optimal, because you may have another beacons, for example in this area, and you don't want this beacon to be serving this area because you already have beacons in this. So this is why you shall specify the...

2:57 Service zone for each of their submaps. For example, you had beacons here, here, here, here, and you say, okay, my service zones for this submap would be this. So to each of the submaps you define the service zone. It's basically the zone which you tell the submap to serve. So this is your area of responsibility. This is your—I will trust—it means their navigation system—I will trust most of all, or let's say at all, in this area to you beacons. And for example, this is another submap consisting of the same beacons and two more beacons. So these beacons belong to this submap and to this submap, and you say, okay, for you guys, this is my service zone. I will be trusting in this area only to you.

3:56 In this area I will be trusting, and you, and you. And this would be my handover zone. The handover zone is the zone where both service zones from previous submap and this submap are serving, and it's needed for the smooth handover. So it means that when the mobile beacon is moving from this until this zone, it is served only by this service zone or this submap. During this, it is allowed to be served by this and by this. And the system is already making the decision, combining the data, or still trusting this most, or trusting this more. There are several types of handovers, but in any case it's a smooth handover because in this zone, in their handover zone, the mobile beacon is traced by two submaps, by this submap and by this submap.

4:54 And this—you must have the handover zone even if you don't specify. The system will specify for you in any case, because in any case you'll have the service zone. Simply, sometimes when you specify them explicitly, it's much better. Because if you don't specify it explicitly, the system will say, make it huge, and this will be making huge, and it will be huge overlapping between the submaps. And the system will not know which one to use. It will try to select the right one, but doesn't necessarily would select their optimal, the best one. So for example, this beacon is very far from this area, but this area is still within 30 meters. You would be happily served in this area. It would be happily served by this because it's much closer, much better. But the system may try to serve by this beacon. Why not? Simply because you have not specified the service zone, and you haven't specified their handover zone. So please do specify.

5:54 About the number of beacons: you may have, as mentioned, for one 1D submap—for example, a tunnel—you might have only one station beacon per submap. For 2D submaps, you may have up to two station beacons per submap. For 3D submap, you may have one, two, three, or four. You cannot have more than four station beacons per submap. In this case, if you have more station beacons, then build just another submap. Is that intentionally because four is sufficient for 3D? It's actually three plus one redundancy already. And let's talk about the redundancy. For example, very often you are facing the issue of obstructions, and how to handle obstructions. No, the best and the easiest way to handle obstructions is redundancy. So what do you do?

6:54 You basically say, okay, this is my 2D map, and my service zone would be this. So I'm putting this on my wall. Okay, it's facing this direction, so I'm actually putting them like this. And then this is my service zone for this 2D. But I have a column here or another column or something like this. Wow, so it means that this would create a shadow in this area. Is it a problem? Yes, it would be a problem, because in this area you may expect interruption in the tracking. How to recommend? Oh wow, it's very easy. You do another submap, also 2D submap, and you specify the service zone for this submap exactly the same but this direction. And notice there is an arrow showing which direction it will be...

7:51 Served. It's also here, so it means that you will have two completely overlapping submaps. And this submap is serving from this direction, and this submap is serving from this direction. What happens in this case? The system will automatically choose which submap to use because you know there are many algorithms how to select the right signal. And when you are in this zone, it will select based on your coordinates. But it will select based on your previous historical data and based on some quality data of the signal. And then it will be using the data available from this direction. And that's not the problem. So it means that when you are here, this submap would be serving you, but when you are here, then this is a shadow of the column, this will be serving you. So that's the overall logic: use fully overlapping submaps.

8:48 To serve when you have obstructions—in three plus one redundancy it happens already automatically because you need only three beacons for trilateration for 3D. But you have four beacons, and there are several triangles, and the system is automatically choosing the best one. It doesn't necessarily choose always the best one. This one you still need to apply some intelligence, but still it tries to choose the best. Just a very short hint: you see we are putting this kind of in the volume, in the plane. You cannot build, for example, a 3D submap by placing them like this because you don't have the volume. Actually, you have only a line in this case. Yes, you have four beacons, but no, you cannot build a 3D submap with placing station beacons like this. You must do it in, you know, a plane. Many questions ask: is it possible to put the beacons on different heights? Yes, it's possible.

9:48 stationary beacon, but always provide the height of this beacon. So they don't necessarily need to be on the same ceiling. No, it can be on different heights, but you must provide the heights always—particularly, particularly when you have them not on the plane, one on different height. When you have it on the plane, you may sometimes skip it, but in this case you will have a fixed Z error. What else? Today we support up to 250 beacons and up to 250 submaps. So it means that you can have, for example, a map consisting of 250 small submaps, and each submap is up to 30 meters. So it means 30 meters times 250. So as you can see, you can cover a huge tunnel or you can cover a very large warehouse, for example. That's sufficient.

10:45 volume. When you have two beacons in the submap, it would be automatically 2D. So you don't need to switch in this particular 2D mode or something—it would be automatically 2D. We're going to have three or more beacons, three or four, in this case it would automatically be 3D. But there is a special tick in the Dashboard, so you can switch three or four beacons into 2D mode, but it's kind of a little bit more advanced. So usually it's much better to have either two beacons for 2D, or two and two with their full overlapping submaps for 2D. Many questions are like: if we install more beacons, would it give more accuracy? No, it wouldn't give more accuracy, because if you have good coverage, then two beacons provide the same type of accuracy as three or four beacons. In fact, in many cases, three or four may

11:44 provide even worse because they will be kind of minority reports and minority opinions. No, it's much better to have sufficient. But what is better is redundancy—let's say resiliency against obstructions. As mentioned, certainly two beacons will be more prone to obstruction than four beacons. But this is not for beacons—it's two plus two on different and overlapping submaps. So yes, you have obstructions. Please use two plus two beacons, not four beacons. Special cases we do have: 2D submaps, 1D submaps for tunnels. Tunnels we have. 3D submaps when you have a volume—for example, you have a copter flying. But we have also special cases. Those special cases are

12:42 vertical. So sometimes, for example, when I have a tunnel—oh sorry, tunnel—a warehouse, and inside the warehouse you have very narrow aisles. And very often it's simply inconvenient or a bit too costly to build. So this is your shelves—this is your shelves. I don't know, 12 meters height, just 3 meters here. Often it doesn't matter where you are here in this Y direction. It is important where you are in the X direction, and it's important where you are in the Z direction. So it means that instead of building a 3D submap with very narrow angles—and we have a particular video about that, please check YouTube channel—sometimes it's convenient to build a 2D submap. But that would not be X-Y submap

13:42 no, that would be X-Z submap—so-called vertical submap. And we have a description about this. So yes, it's possible. Sometimes it's convenient—not only, but in this case. But for example, you have a wall and have something flying. You don't need X—actually, you would be able even to provide 3D, but in this case it will be kind of vertical 3D. So think about this: you know, not X-Y, that's horizontal, but vertical—but from the side. So when you turn the pyramid 90 degrees, you would be able to still track XYZ. And sometimes it's more convenient for various reasons. It really depends on your architecture. So about the service zones—as I mentioned, service zones are important. Service zones

14:39 are there. Always specify them or not specify—they are there. Simply, very often it's not possible to build a large map without explicitly defining the service zones. Simply because if you don't do this, the system will do it for you, but not necessarily optimally. So the very typical case: I have a large territory, I want to have 2D coverage. How to build? Well, fine example: I have, I don't know, an office like, I don't know, 15 meters wide and 200 meters long. So you install the beacons up to, let's say, up to 20 meters. In this case, the maximum distance would still be less than 30 meters, and that would be your service zone for this submap.

15:38 Then I have another 20 meters and have another service zone, and I have another service zone, and so forth. So as mentioned, you can have up to 250 submaps and up to 250 service zones and so forth. About the handover zones: how large shall they be? Basically, thumb rule, one meter. You know, if you don't know anything, you don't have time and stuff to do it, around one meter—that would be okay. It's not too much, it's not too small. But where is this coming from? It's coming from two things: one is your update rate—location update rate—and another one is speed of your mobile object. For example, your mobile object is moving from this direction

16:36 and for example, your mobile object has eight Hertz update rate. So it means that if you have one meter—one meter—during this one meter, you shall expect eight location updates, which is great because in this case it would be served eight times in this area from this service zone or from this submap and from this submap, and it would be a very smooth handover. If your object is moving, for example, faster than that—two meters per second—then you can expect only four location updates. This is still fine, but it's already less than eight. And, for example, if you have not eight Hertz but only four Hertz update rate, then you would have only two location updates, and that's already critical because you must have at least one or two—two is the very minimum recommended location updates in the service

17:36 in the handover zone. Otherwise, the handover may be not smooth, and it may be a hard handover—not soft handover, but hard handover. Why? No, for example, something happened and you miss this one, and then you have only one, but one may not be sufficient for the real-time player to make it smooth. No, don't risk it. So it meant that if you have lower location updates or you have fast-moving objects, then you may have, you know, larger service zones—so wider, sorry, wider handover zones. But it doesn't necessarily have to be the best because, as mentioned, in this case this beacon may be trying and officially entitled to serve in this fat area, which is much, much better to be served this way. So it means that you must have the service or the handover zone as wide as you need, but not more than that because otherwise again the tracking may be degraded—not

18:33 much—but still, a few words about other things, more complex things. But let me touch on this because many people are asking: in this same context, what is TDMA? What is it for? Since you are already building more complex submaps—and sorry, more complex maps—you may have two issues with those. One which you need to take care of the most is, of course, obstructions. Because if you have obstructions, you don't see your satellites—means your stationary beacons—then you may not have a proper tracking in the shadows. So this area would not be tracked, and this area wouldn't be tracked.

19:32 I already mentioned full overlappings of overlapped submaps, but sometimes you can do this not in the same time slot. For example, in Inverse Architecture, because they emit at the same time and surface at the same time, in NIA you may try to use it in different time slots. So it means that in this location update, it's serving from this direction. In the next location update, it serves from this direction. It allows more robustness because the system is not forced to combine confidently wrong area with potentially good data. Because this is wrong data, it cannot serve. For example, here, here we know it, but the system still doesn't know, but we try to combine this with potentially good data from this direction. The system will try and in majority of cases will successfully combine this data, but doesn't.

20:31 Necessarily will do. In other cases, so you may try to use TDMA mode. So it will mean that in time slot 1, this will be the serving submap, and in time slot 2, this will be the serving submap. And then what you will have is this, this, this, this, and then this from this submap. It would be skipped because instead of this, it would be somewhere here, here, and some jumps. So this will be lost, this will be lost, this will be lost, but this will be constantly okay. And then you apply their real-time player, which will be making a smooth thing because it will be simply canceling these strange jumping locations when the TDMA gives this submap the serving time.

21:28 TDMA of full overlapped submaps are used when you have the abstractions. So it's served for abstractions, but that's only one of their needs. For the TDMA, another one is for Inverse Architecture. It's not used for Non-Inverse Architecture, but for Inverse Architecture. As you know, in Inverse Architecture we have only five frequencies currently: 19 kilohertz, 25 kilohertz, 31 kilohertz, which is 77 kilohertz, and 45. But when you build a large submap, you run out of combinations pretty quickly, especially when you have a complex warehouse with, you know, horizontal and vertical lanes and aisles, et cetera, et cetera. You run out pretty quickly of the options and you cannot build a larger map anymore, so you have to move some of their

22:26 submaps to one time slot and another to another time slot. It's kind of, you know, they leave, they leave in two different times. So this submap is live in this time, and these mapping or submaps in this time. So they kind of coexist but not at the same time, and it gives you freedom to build as large maps as you wish—effectively, you know, unlimited size of the maps. But it's kind of additional complexity, and of course, there's a trade-off. Because since it's the TDMA, so it means that some time it's not served. So it means that if you have regular 8 hertz and TDMA of type 2, so it means that you always say no, type two, but two slots in TDMA. So it means that you will have location update of only four hertz because one is served in this, another one is sourced only. So you lose some location update rate, but you know, you enable another dimension.

23:26 Thus, you can build a very, very large submap—sorry, very large map—because you can build many, many submaps, and you are not anymore limited by the number of frequencies. The last word about how to build: we addressed this already several times, but since we are talking about pretty complex maps, the royal logic is very, very simple. Build simple things at once, achieve the perfect tracking in their submap. So let me basically spell it out, one by one. You want to build a large submap consisting of a large map consisting of 100 submaps? Build one submap, define the server zones, achieve a perfect tracking in it, send it to sleep—like really send it to sleep. Then wake up this submap again, specify the server zone, achieve a perfect tracking in this area.

24:24 Don't think that you have other. Don't care, just build this submap. As soon as I have two independently perfectly working submaps and taking this is defined as well, then you are ready for the handover zone. So you effectively, you build this handover zone already, but you wake up this beacon, this beacon, and this beacon. You have, you know, 100 more beacons—it doesn't matter. You have only three beacons currently enabled. Always say woken up. Use them, and you have a smooth tracking here because you already built them in this. You may expect some jump because, for example, their submaps are not perfectly aligned. To do something, you know, correct—because you can build a complex service zone with the complex handover zone shape, et cetera. Adjust them, move them. Maybe sometimes even adjust slightly distances if the distances were not measured correctly. Until you have a perfect smooth handover on this side, then you know exiting, and then from this direction.

25:24 And you do these adjustments until you have a perfect smooth handover. That's it. You've done with two submaps. You know, once again, send them to sleep, enable this one, achieve the perfect trick in this one, and make a smooth handover between these two, and forget about them. And do this one by one, by one, by one, by one, until you build this first single submaps. Then pair submaps, and then you kind of grow one by one, add one by one. Never jump over submaps. Never enable all the beacons and try to build, you know, huge map, not achieving a perfect tracking in each and single submap prior to that. If you do follow this, then it will be very easy to build large maps because effectively you build small submaps, and then you just adjust them and you make sure that the smooth handover. Then it's very, very, very easy. If you try to build it, you know,

26:22 everything at once, then you will struggle because it's too complex. It's not clear why the problem comes from and where. Just don't do that. So, again, submaps is a combination of beacons. Service zone is a property of each submap which is specifying where this submap is serving. Handover zone is an overlapping between two adjusting server zones. Thank you very much.