OptSample: A Resilient Buffer Management Policy for Robotic Systems Based on Optimal Message Sampling
Modern robotic systems have become a substitute for humans when it’s necessary to perform risky or exhausting tasks. In such application scenarios, communications between robots and the control center are one of the major problems. The commonly used solution assumes that newer messages are more valuable. We find that it does not hold in many scenarios. In this paper, we propose a novel, resilient buffer management policy called OptSample. We make a new assumption that uniformly sampled messages are the most valuable and define an evaluation function to estimate the profit of the received message sequence. Our OptSample policy can uniformly sample messages and dynamically adjust the sample rate based on the run-time network situation. Our analysis and simulation shows that the OptSample policy can effectively prevent losing long segments of continuous messages and can improve the profit of the received messages. We implement the OptSample policy in ROS, without changing the interface or API for the applications. Our experiments show that the OptSample policy can improve the results of several application scenarios including surveillance, 3D reconstruction, and SLAM.
Modern robotic systems have become a substitute for humans when it’s necessary to perform risky or exhausting tasks such as military operations, exploration, rescue operations, surveillance, or large-scale cleaning operations. In such application scenarios, a control center through which humans can monitor and operate the whole system is usually needed. However, communication issues, such as unstable network connection and limited bandwidth, cause problems.
Network connections, especially wireless ones (e.g. over WiFi), are not always stable . Network connections could be temporarily broken when a robot moves out of range of wireless network, switches among network source points, or is shielded by obstacles. In this case, buffering some messages at the sender is a commonly used solution. When network connections are temporarily broken, new messages are put into a buffer to wait for future transmission. However, buffers are limited in size due to limited memory. When the buffer is full, one simple solution is to discard the oldest message to make room for the new message. This solution is called Drop Oldest policy . This policy is reasonable when newer messages are considered more valuable than older ones. For example, obstacle avoidance algorithms should be fed with messages as new as possible. Commonly used robotic middleware, such as Robot Operating System (ROS) , employ this policy. However, we find that the assumption does not hold for many application scenarios, such as surveillance, 3D reconstruction, and Simultaneous Localization and Mapping (SLAM). In these scenarios, adjacent messages provide similar information. When network disruption occurs, repeatedly discarding the oldest message leads to losing a long segment of frames and some information would be totally lost (see Fig. 1 as an example). In these scenarios, we make a new assumption that uniformly sampled messages are preferred over the newest messages.
Limited bandwidth is another issue. Current depth cameras are becoming increasingly higher-resolution. For example, an Intel Realsense D435 depth camera can capture RGB images at 30 fps (frames per second) and depth images at 90 fps. Transmitting these images will need about 2.6 Gbps bandwidth while commodity WiFi routers can only provide 54 Mbps bandwith. In this case, messages come to the buffer faster than they leave. Therefore, the buffer is always full, which makes the buffer management policy more vulnerable to temporary network disruption. Explicitly sampling images to a lower frame rate provides an easy solution. However, it is difficult to decide the frame rate since it is affected by various factors including image resolutions, compression algorithm and quality, network bandwidth, and number of robots. Higher frame rates will not relieve the problem and lower frame rates will waste more information. It is an important problem to automatically decide the good frame rates for different applications.
Main Results: In this paper, we present a novel resilient buffer management policy, OptSample. When temporary network disruption occurs, rather than discarding the oldest messages, we gradually decrease the sampling rate. Messages are sampled uniformly and the sample rate is decided with run-time situations. Thus, we can avoid losing a long, continuous segment of messages and instead lose multiple, short segments of messages. Experimental results show that our OptSample policy is suitable for many application scenarios such as surveillance, 3D reconstruction, and SLAM. The main contributions of this paper include:
(1) We propose a novel buffer management policy named OptSample, which is resilient against temporary network disruption.
(2) We define an evaluation function to estimate the profit of a message sequence. We prove and show with simulation that our OptSample policy can get results bounded close to the unfeasible optimal profit (see Lemma 6).
(3) We implement our OptSample policy in ROS. The implementation is transparent to the user and can be used with all the applications with the same API.
(4) We test our OptSample policy with several applications including surveillance, 3D reconstruction and SLAM. These experiments show that using our OptSample policy can effectively improve the results of these scenarios when network disruption occurs.
The rest of this paper is organized as follows. Section II discusses a motivating scenario. Section III discusses alternative solutions and related work. Section IV introduces our OptSample policy and formally analyzes its performance. Section V evaluates our OptSample policy with simulation and practical experiments. Finally, we conclude in Section VI.
Ii Motivating Scenario
Take the rescue scenario as an example. A rescue robot traverses the accident area, captures images at 30 fps, and sends them back to the control center. Suppose that the system suffers a temporary network disruption for 5 seconds. During this time, the robot is still capturing images and has to put them into the internal buffer. If the size of the internal buffer can save 30 images, we will have to discard 120 images. The trivial solution will result in discarding the oldest 120 images. In this case, the control center cannot get any information about those 4 seconds and we will have no idea if someone needs to be rescued during that time. What makes the situation worse, if a victim is out of range of the wireless network, the robot can “see” the victim, but the control center cannot.
In the above case, the assumption that newer messages are more valuable than older ones is not true. If we manage to discard 120 images uniformly from a range of 5 seconds, after the network connection is restored, the control center will still receive images as if the robot is capturing images at 6 fps. The control center can therefore be more confident that the robot did not miss any victims.
Similar requirements can be found in many scenarios, such as surveillance, 3D reconstruction, and SLAM. Information provided by an image (either RGB or depth) could be largely covered by its adjacent images. Therefore, if we have to discard 50 images from 100 images, it is better to discard one message from every two images, than to discard the first 50 images.
Overall, uniformly sampled messages are preferred over the newest messages in these scenarios. What we need is a new buffer management policy.
Iii Related Work
Iii-a Communication Issues in Robotic Systems
Communications among robots and the control center have been a major issue in many robotic systems. Saeedi et al. reviewed multiple-robot SLAM algorithms , concluding that communications is one of ten major problems in multiple-robot SLAM. There are a few important issues need to be considered when designing a multiple-robot system such as the availability and the quality of the communication channels, limited bandwidth and data rate, when and what to communicate, etc. There are two kinds of system framework, centralized system and decentralized system.
In a centralized robotic system, sampling input data is the most commonly used solution to relieve limited network bandwidth. Golodetz et al.  aimed to reconstruct dense 3D models with collaborative robots. They explicitly pointed out the communication problem between robots and the control center. Based on some experiments and evaluation, they compressed the sensor images and sampled the image frames to about 10 fps. Dong et al.  performed collaborative scanning for dense 3D reconstruction with multiple robots. They also sampled the sensor data. New sensor data were collected when the robot moved more than a given distance or rotated more than a given angle. The given distance and angle were decided by the speed of their robots. The sensor data were sampled to roughly 1 fps, which was the processing capability of OctoMap . In practice, deciding the sample rate requires considerable experimentation and parameter tweaking, and can not easily adapt to dynamic environments.
Many other researchers focus on the communication issues of decentralized robotic systems [20, 29, 19, 2, 23]. They assume that there are no network infrastructures that can connect all robots at the same time and robots can only communicate when they are in close proximity. These systems, however, need to store information on each robot for a long period of time, and there is a high level of communication when they are in close proximity . Due to limited memory and bandwidth, they can only communicate information about their estimated poses and it is not feasible to communicate information about the environment. To enable robots to communicate large amount of information with limited resources, the messages also need to be uniformly sampled, just like our assumption.
Iii-B Quality of Service Policies
Quality of Service (QoS) policies are designed to meet the needs of different scenarios. These growing needs such as real-time requirements in autonomous driving inspired the upgrade from ROS to ROS2 . ROS2 provides QoS policies by integrating with Data Distribution System (DDS) . Although it introduces performance issues such as increased communication latency , it is still used by many applications.
However, existing QoS policies are not suitable for our applications related to SLAM and 3D reconstruction. According to the specifications  and evaluations , the Reliability configuration decides the choice of UDP or TCP connections; the History and Depth configurations decide the queue size of the buffer; the Durability configuration decides whether publishers keep messages locally if there are no subscribers; the Deadline configuration describes the real time requirement; the Liveliness configuration decides whether heartbeat messages are employed; the LatencyBudget configuration decides the minimal interval between two messages. The LatencyBudget configuration is the most related policy because it implies the maximal frequency. In our motivating scenarios, however, deciding the maximal frequency needs more experiments  and is vulnerable to temporary network disruption.
Iii-C Buffer Management for Other Applications
Buffer management policies have been researched for the last decade. Practice networks are modeled as Delay Tolerant Networks (DTN)  or Opportunistic Networks . A sequence of simple drop schemes such as Drop Oldest, Drop Youngest, Drop Front, and Drop Last  has been proposed for the scenario when the buffer is full. Enhanced policies introduce the concept of profit and assume that each message has a different profit. The goal is to maximize the total profit of the remaining messages . According to the application scenarios, different types of messages may have different profits [17, 15, 32, 34, 16]. For example, when transmitting video frames , P message, B message, and I message will be will be assigned different profits. However, in our motivating scenarios, the profit of a message is not decided by itself but by the relative positions of the remaining messages in the sending message sequence. Therefore, we need a new evaluation function to estimate the profit of a message sequence.
Iv Design of The OptSample Policy
In this section, we first formally define our problem. After analyzing a naive solution, we give an overview of our resilient buffer manage policy.
Iv-a Notation and Symbols
For better understanding, we first define some notations and symbols.
denotes the number of messages during the network disruption. denotes the size of buffer, which is also the number of messages that will be received after the network disruption.
. Each message is assigned an integer number indicating its sending order. We use to denote the message number of the th message in a message sequence.
denotes a message sequence, i.e. . denotes the number of messages of , i.e. .
denotes the sequence that the user intend to send and denotes the sequence that is received. These sequences change with and we use and to denote the sequences with a certain . Note that and . Obviously, . The messages in are discarded by the buffer management policy.
denotes the extended version of sequence , i.e. .
denotes the difference between two adjacent messages in a sequence, i.e. . It helps evaluate the sequence.
denotes the evaluation function. In our design, it takes as input.
denotes the profit function. It takes a message sequence as input to estimate the profit of the sequence. The goal of our OptSample policy is to output an with higher profit .
Iv-B Problem Definition
We call a sequence uniformly sampled if all are equal. As we have described, we assume that uniformly sampled messages are the most valuable. To formally represent this assumption, we define the evaluation function and the profit function as Eq. 1.
The evaluation function can be replaced with any function that satisfies the two following properties:
Lemma 1: , . This indicates that receiving one more message between two messages is always better.
Lemma 2: , if and , then . This indicates that a message nearer to the middle of two other messages is better.
Thus, we can describe the transmission problem as follows.
Problem Statement: Knowing the buffer size , with increasing network disruption time , the buffer management policy computes the received sequence for higher profit with the following restriction.
Lemma 3: With any , . This indicates that the policy cannot re-find messages that have been discarded.
Iv-C The Oracle Policy
With the above definition, we can easily prove that the maximal profit when . In this case, all messages remain in the buffer during the network disruption. With practical , we can also prove that the maximal profit is met when all are the same. This conclusion confirms our assumption. In this case, , where . It is not feasible if is not an integer, but the optimal solution can be obtained with the nearest integers.
This optimal solution is still not feasible because it violates Lemma 3. For example, when , the optimal is and the optimal is . But, . This indicates that we have already discarded the message and at and we cannot re-find them when . Therefore, this optimal solution can only act as an Oracle policy.
Iv-D The ROS Policy
With the above definition, we can also evaluate the buffer management policy of ROS. ROS employs a naive buffer management policy called Drop Oldest . When a new message arrives and the buffer is full, the oldest message is discarded to make room for the new message. As a result, the buffer management policy of ROS chooses the newest messages to transmit. Therefore, the profit of these messages is . Note that the last part of the value represents the profit of the first received message, which is labeled .
Iv-E The -Sample Policy
This is a basic version of our OptSample policy. The basic idea of our OptSample policy is to uniformly sample the buffer. A direct policy can be described as follows. When the buffer becomes full, we will uniformly sample messages from the buffer so that messages remains. All changes from 1 to . Newer messages are also sampled at the same rate until the buffer becomes full again. When the buffer becomes full again, we again sample messages from the buffer so that messages remain. Thus, all becomes . We can repeat the above operations until messages are processed (either remain in the buffer or are discarded at some time). We call this policy the -Sample policy.
Here, is the key parameter that affects the result. Lower leads to discarding fewer input messages but also leads to more rounds of sampling messages from the buffer if is fixed. must be greater than 1 by its formulation, otherwise we cannot make any room for a new message.
It is easy to implement when we let which leads to the 2-Sample policy. Whenever the buffer is full and a new message arrives, we sample a message from every two messages and the sampling rate is doubled. Fig. 2 shows an example of this policy. As we can see, an obvious shortcoming of the 2-Sample policy is that half of the buffer is empty when .
Iv-F Our OptSample Policy
Our OptSample policy is one step forward based on the 2-Sample policy. To overcome the shortcoming of the 2-Sample policy, we should make only one room for new messages at a time. To avoid falling back to ROS policy of Drop Oldest, we must sample uniformly rather than simply discarding the first message in the buffer.
To achieve this, we record the position we will discard at the next time when the buffer is full and move it towards the end of the buffer. When the position is at the end of the buffer, the sample rate is increased and the position is moved to the beginning of the buffer. Fig. 3 shows an example. As long as no messages are taken from the buffer, the buffer is always full.
Iv-G Analysis and Comparison
We deduce the profit function for the above 4 policies and summarize into Table I.
We explain the formula of the profit of our OptSample policy. is the sample rate. With any , the distance is either or . The only exception is the distance between and . The number of is and the number of is . Therefore the first part of the profit . The profit of the last part comes from the distance between and .
We can prove that our OptSample policy can get higher profit than the 2-Sample policy and the ROS policy. Besides, the upper bound of the profit of the OptSample policy is the same with the Oracle policy, which is much better than that of the ROS policy. The lower bound of the profit of the OptSample policy can also be bounded with Lemma 6. Overall, we consider our OptSample policy nearly optimal.
Lemma 4: .
Lemma 5: .
Lemma 6: , with .
In this section, we show the advantage of our OptSample using simulation results and its applications to surveillance, 3D reconstruction, and SLAM.
In the simulation, we take and check the change in the profit, when a new message arrives. The result is shown in Fig. 4. From this figure, we can see that our OptSample policy performs almost the same as the ideal Oracle policy and exactly the same as some . This result confirms our profit functions in Table I and Lemma 4-6.
Note that increasing the buffer size will increase the lower bound and the upper bound of the profit. Therefore, increasing the buffer size will generally increase the profit.
V-B Implementation and Environment Setup
We implement the OptSample policy based on ROS. We modify the code of the class TransportSubscriberLink which is located at the ros_comm project  and is linked into libroscpp.so. The pseudo code is shown in Fig. 5. The Enqueue function is implemented as part of the TransportSubscriberLink::enqueueMessage method and the Dequeue function is implemented as part of the TransportSubscriberLink::startMessageWrite method.
Since we implement the policy at the roscpp level, it is totally transparent to the users and no user code needs to be modified. Note that when the network bandwidth is not a bottleneck and no temporary disruption occurs, the buffer is never full and the OptSample policy is not triggered. Therefore, our OptSample policy does not affect normal communications.
In the following experiment, the control center is equipped with Intel Core i7-8750H @2.20GHz 12x CPU, 16GB memory and GeForce GTX 1080 GPU. The control center and the robot are connected via a 54Mbps WiFi router. The ROS version is Lunar on Ubuntu 16.04. It is one of the most recent versions of ROS .
To make better comparisons, all sensor data (i.e. RGB images, depth images, and laser data) in the following experiments are recorded with rosbag and are replayed multiple times to get results with different policies.
V-C Application 1: Surveillance
The first application scenario is surveillance. Fig. 6 shows the software architecture. We deploy a laptop with a camera to monitor a “treasure.” It keeps sending compressed images to the control center at 20 fps. In this case, the needed network bandwidth is about 0.8 MB/s. A malicious attacker manages to disturb the wireless network for about 4 seconds and takes the treasure during this time. The buffer size of the publisher is set to 20.
The result is shown in Fig. 7. With native ROS, the attacker is not shown in any of the surveillance images received by the control center; with our OptSample policy, after the network disruption, the surveillance images that are captured during the network disruption arrive at the control center as if they were captured at 5 fps and the attacker is captured in a few images. Analysis tells us that with native ROS, the attacker has a time gap of about seconds to fulfill the theft. With OptSample, the attacker has to disturb the wireless network for about seconds to give him the same time gap to fulfill the theft. This is more difficult for the attacker than to disturb the wireless network for 4 seconds and we consider that our OptSample policy makes the theft much more difficult for the attacker.
V-D Application 2: 3D Reconstruction
The second application scenario is 3D reconstruction. Fig. 8 shows the software architecture. We employ InfiniTAM  as the reconstruction algorithm. InfiniTAM is a widely-used, vision-based reconstruction algorithm and very efficient when equipped with a modern GPU. We encapsulate InfiniTAM into an ROS node. RGB images and depth images are captured with Kinect on the robot side. These images are sent to the control center via two separate ROS topics at 10 fps. In this case, the needed network bandwidth is about 1 MB/s. The control center subscribes these two topics, synchronizes them, and uses them to reconstruct a 3D model. We cut the wireless network for 5 seconds on purpose to simulate a temporary network disruption. The buffer size of the publisher is set to 20.
The result is shown in Fig. 9. From Fig. 9(a), we can see that, in this scenario, adjacent images provide similar information and our assumption is true. With native ROS (Fig. 9(c)), a long segment of messages is lost, the reconstructed algorithm loses the correspondence of feature points, and the result does not appear good. With our OptSample policy (Fig. 9(d)), however, the reconstructed model seems to be unaffected by the network disruption. In fact, the resulting model of our OptSample policy is not as dense as the ground truth, but it seems good enough.
V-E Application 3: SLAM
The third application scenario is SLAM. Fig. 10 shows the software architecture. We employ RTAB-Map [18, 22] as the SLAM algorithm. RTAB-Map is one of the SLAM algorithms that has integrated with ROS as an ROS node or nodelet, and it can be visualized with rviz . RGB images, depth images, and laser scan data are collected on the robot side and published at about 8 fps. In this case, the needed network bandwidth is about 1.6 MB/s. The control center launches an RTAB-Map node, which subscribes and synchronizes these topics as input data. We purposefully cut the wireless network for 5 seconds for several times to simulate a temporary network disruption. The buffer size of the publisher is set to 20.
The result is shown in Fig. 1. From Fig. 1(a), we can see that, in this scenario, adjacent images provide similar information, and our assumption is true. With native ROS (Fig. 1(c)), the robot appears to stop and “teleport” at the control center and there are gaps in the mapped environment. However, with our OptSample policy (Fig. 1(d)), the path of the robot is more continuous and there are no obvious gaps in the mapped environment.
Overall, with three application scenarios, we have shown that our OptSample policy provides better resilience against network disruption. As long as the assumption that uniformly sampled messages are more valuable is true, there are more application scenarios. In addition, during the above experiments, no user code is modified. We can switch between native ROS and our OptSample policy by simply replacing the libroscpp.so.
From the view of data flow, the above experiments also show that our OptSample policy can be easily deployed to single topic (Surveillance), two synchronized topics (3D construction), and multiple synchronized topics (SLAM).
Vi Conclusion and Future Work
We have presented a novel buffer management policy called OptSample. By uniformly sampling the message buffer, our OptSample policy is more resilient against temporary network disruption. We explain that common solutions assume that newer messages are more valuable than older messages, but this assumption is not always true. We define an evaluation function that models the new assumption that uniformly sampled messages are more valuable. Based on this function, our analysis and simulation show that our OptSample policy is very close to the optimal Oracle policy.
We have integrated our OptSample policy with ROS. The implementation is transparent to users and no user code needs to be changed. Experimental results show that our OptSample policy is more resilient than native ROS in several application scenarios.
The main limitation of our OptSample policy comes from the assumption. We assume that uniformly sampled messages are the most valuable. Thus, we evaluate the profit of messages with their sequence numbers. If the content of actual messages is taken into account, the problem would be more complex but with wider adaptability.
In the following appendix, we will give the proof of the lemmas.
Appendix A Proof of The Lemmas
Lemma 1: , .
Lemma 2: , if and , then .
Lemma 4: .
For convenience, in the following proof, we abbreviate to and to .
There exist some integers and that satisfy:
Further, there exist some integers and that satisfy:
Let , and some integers and that satisfy:
Let , then:
Based on the above definition, we can rewrite as:
We define , then:
We will prove in 3 cases.
Case 1: When .
By their definition, we have:
When , . Since , we can conclude that for all in this case.
Case 2: When and .
Since , and . Therefore,
Case 3: When and .
In this case, , , and . Therefore:
We define . Then:
Which means is monotone increasing for both and . In this case, and . Therefore,
We define . Then and for . Therefore,
Overall, for all 3 cases, which means .
Lemma 5: .
We continue to use the definition of , , , , , , and in the proof of Lemma 4. For convenience, in the following proof, we abbreviate to and to .
To simplify the , we further define:
Thus, we can write as:
Let’s first analysis the relationship between and .
1) We have , because:
2) We have , because:
Overall, we have either or .
Case 1: The first case is satisfied when:
In this case , so and , and:
Case 2: When , we have:
Case 2.1: When is even, we have:
Since , , and , we have:
Case 2.2: Similarly, when is odd, we have:
Since , , and , we have:
Lemma 6: , with .
We continue to use the definition of , , , , , , and in the proof of Lemma 4. For convenience, in the following proof, we abbreviate to and to .
We first prove the left part:
Lemma 6.1: .
We can rewrite as:
Let . It is a monotone increasing function of . Because:
Therefore, . Put it into (6.1) and we get:
Let . It reaches a local minimal value when:
Put this into (6.2) and we get:
When , . Therefore,
We can also rewrite as:
When , we have:
And with growth, it tends to be:
Note that the ratio is a monotonic function, either increasing or decreasing depending on which of the two values is bigger, or . Therefore, we can conclude that:
Then, we continue to prove the right part:
Lemma 6.2: .
We can rewrite as:
We define and we have:
Note that . Let , then for and for . Therefore, gets its maximal value when or . We can prove that , because:
Put into (6.3), we have:
We further define , and we have already proved that is a monotone increasing function of . Since , we have:
Appendix B Alternative Evaluation Functions
As we have stated, any functions that satisfy Lemma 1 and Lemma 2 could be employed as the evaluation function. Using different evaluation functions will lead to different results. We have tried the following alternative evaluation functions.
We can neither explain the meaning of different evaluation functions, nor decide which is appropriate. But our OptSample policy performs the best as well.
-  (2000) Understanding the performance of TCP pacing. In Proceedings IEEE INFOCOM 2000, The Conference on Computer Communications, Nineteenth Annual Joint Conference of the IEEE Computer and Communications Societies, Reaching the Promised Land of Communications, Tel Aviv, Israel, March 26-30, 2000, pp. 1157–1165. External Links: Cited by: §I.
-  (2015) Decentralized active information acquisition: theory and application to multi-robot SLAM. In IEEE International Conference on Robotics and Automation, ICRA 2015, Seattle, WA, USA, 26-30 May, 2015, pp. 4775–4782. External Links: Cited by: §III-A.
-  (2013) Routing in delay/disruption tolerant networks: A taxonomy, survey and challenges. IEEE Communications Surveys and Tutorials 15 (2), pp. 654–677. External Links: Cited by: §III-C.
-  (2010) Rao-blackwellized particle filters multi robot SLAM with unknown initial correspondences and limited communication. In IEEE International Conference on Robotics and Automation, ICRA 2010, Anchorage, Alaska, USA, 3-7 May 2010, pp. 243–249. External Links: Cited by: §III-A.
-  (2016) An effective buffer management policy for opportunistic networks. In Collaborate Computing: Networking, Applications and Worksharing - 12th International Conference, CollaborateCom 2016, Beijing, China, November 10-11, 2016, Proceedings, pp. 242–251. External Links: Cited by: §I, §III-C.
-  (2016) Evaluating the resilience of ros2 communication layer. In ROSCon 2016 presentation, External Links: Cited by: §III-B.
-  (2019) Scanning the internet for ROS: A view of security in robotics research. In International Conference on Robotics and Automation, ICRA 2019, Montreal, QC, Canada, May 20-24, 2019, pp. 8514–8521. External Links: Cited by: §V-B.
-  (2019) Multi-robot collaborative dense scene reconstruction. ACM Trans. Graph. 38 (4), pp. 84:1–84:16. External Links: Cited by: §III-A.
-  (2019) ROS 2 quality of service policies. Note: http://design.ros2.org/articles/qos.html Cited by: §III-B.
-  (2010) A survey of buffer management policies for packet switches. SIGACT News 41 (1), pp. 100–128. External Links: Cited by: §III-C.
-  (2018) Collaborative large-scale dense 3d reconstruction with online inter-agent pose optimisation. IEEE Trans. Vis. Comput. Graph. 24 (11), pp. 2895–2905. External Links: Cited by: §III-A, §III-B.
-  (2019) Rviz - ros wiki. Note: http://wiki.ros.org/rviz Cited by: §V-E.
-  (2013) OctoMap: an efficient probabilistic 3d mapping framework based on octrees. Auton. Robots 34 (3), pp. 189–206. External Links: Cited by: §III-A.
-  (2016) Hierarchical voxel block hashing for efficient integration of depth images. IEEE Robotics and Automation Letters 1 (1), pp. 192–197. External Links: Cited by: Fig. 9, §V-D.
-  (2017) Frame rate control buffer management technique for high-quality real-time video conferencing system. In Advances in Computer Science and Ubiquitous Computing - CSA/CUTE 2017, Taichung, Taiwan, 18-20 December., pp. 777–783. External Links: Cited by: §III-C.
-  (2017) Buffer management policy based on message rarity for store-carry-forward routing. In 23rd Asia-Pacific Conference on Communications, APCC 2017, Perth, Australia, December 11-13, 2017, pp. 1–6. External Links: Cited by: §III-C.
-  (2008) Optimal buffer management policies for delay tolerant networks. In Proceedings of the Fifth Annual IEEE Communications Society Conference on Sensor, Mesh and Ad Hoc Communications and Networks, SECON 2008, June 16-20, 2008, Crowne Plaza, San Francisco International Airport, California, USA, pp. 260–268. External Links: Cited by: §III-C.
-  (2019) RTAB-map as an open-source lidar and visual simultaneous localization and mapping library for large-scale and long-term online operation. J. Field Robotics 36 (2), pp. 416–446. External Links: Cited by: Fig. 1, §V-E.
-  (2013) Multi-robot SLAM using condensed measurements. In 2013 IEEE/RSJ International Conference on Intelligent Robots and Systems, Tokyo, Japan, November 3-7, 2013, pp. 1069–1076. External Links: Cited by: §III-A.
-  (2010) Decentralized localization of sparsely-communicating robot networks: A centralized-equivalent approach. IEEE Trans. Robotics 26 (1), pp. 62–77. External Links: Cited by: §III-A.
-  (2016) Exploring the performance of ROS2. In 2016 International Conference on Embedded Software, EMSOFT 2016, Pittsburgh, Pennsylvania, USA, October 1-7, 2016, pp. 5:1–5:10. External Links: Cited by: §III-B.
-  (2019) Rtabmap_ros - ros wiki. Note: http://wiki.ros.org/rtabmap_ros Cited by: Fig. 1, §V-E.
-  (2019) Robust connectivity maintenance for fallible robots. Auton. Robots 43 (3), pp. 769–787. External Links: Cited by: §III-A.
-  (2003) OMG data-distribution service: architectural overview. In 23rd International Conference on Distributed Computing Systems Workshops (ICDCS 2003 Workshops), 19-22 May 2003, Providence, RI, USA, pp. 200–206. External Links: Cited by: §III-B.
-  (2009) ROS: an open-source robot operating system. In IEEE International Conference on Robotics and Automation, ICRA, Workshop on Open Source Software, Kobe, Japan, Cited by: §I.
-  (2019) About quality of service settings. Note: https://index.ros.org/doc/ros2/Concepts/About-Quality-of-Service-Settings/ Cited by: §III-B.
-  (2019) Ros_comm project. Note: https://github.com/ros/ros_comm Cited by: §V-B.
-  (2019) Transport_subscriber_link.cpp. Note: https://github.com/ros/ros_comm/blob/lunar-devel/clients/roscpp/src/libros/transport_subscriber_link.cpp#L205 Cited by: §IV-D.
-  (2013) Decentralized connectivity maintenance for cooperative control of mobile robotic systems. I. J. Robotics Res. 32 (12), pp. 1411–1423. External Links: Cited by: §III-A.
-  (2016) Multiple-robot simultaneous localization and mapping: A review. J. Field Robotics 33 (1), pp. 3–46. External Links: Cited by: §III-A.
-  (2016) Analysis of buffer management policies for opportunistic networks. In 25th International Conference on Computer Communication and Networks, ICCCN 2016, Waikoloa, HI, USA, August 1-4, 2016, pp. 1–8. External Links: Cited by: §III-C.
-  (2017) Towards optimal buffer management for streams with packet dependencies. Computer Networks 129, pp. 207–214. External Links: Cited by: §III-C.
-  (2013) DSVM: A buffer management strategy for video transmission in opportunistic networks. In Proceedings of IEEE International Conference on Communications, ICC 2013, Budapest, Hungary, June 9-13, 2013, pp. 2990–2994. External Links: Cited by: §III-C.
-  (2017) An optimal randomized online algorithm for qos buffer management. POMACS 1 (2), pp. 36:1–36:26. External Links: Cited by: §III-C.