Fog Robotics: A Summary, Challenges and Future Scope

Benjamin Johnston; Mary-Anne Williams; Siva Leela Krishna Chand Gudi

REVIEW 3 major objections 6 minor 1 cited by

Fog Robotics: A Summary, Challenges and Future Scope

T0 review · 3 major / 6 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Fog Robotics, by placing a fog robot server close to robots, cuts latency from hundreds of milliseconds to tens of milliseconds, making time-critical robot tasks feasible.

desk verdict A plausible but thinly documented latency comparison; the measured cloud numbers are real, the fog numbers are simulated, and the paper never makes that mismatch explicit. read the letter →

arxiv 1908.04935 v1 pith:7AKSQ2ZH submitted 2019-08-14 cs.RO cs.DC

Siva Leela Krishna Chand Gudi , Benjamin Johnston , Mary-Anne Williams This is my paper · ORCID

classification cs.ROcs.DC

keywords FogRoboticsCloudlatencyedgecomputingrobotarchitecturesdevice-to-devicecommunicationiSimhuman-robotinteraction

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper seeks to establish Fog Robotics as a practical answer to Cloud Robotics' latency problem. It argues that robots sharing maps, images, and processing power through distant cloud servers suffer from high latency, so a nearby fog robot server should handle time-sensitive data locally. Using a rescue-robot scenario, the paper reports that fog-layer latency stays roughly in the 8–20 ms range while cloud latency ranges from about 208 ms to 1,086 ms across AWS regions. A sympathetic reader should take this as a feasibility check: if the reported latency numbers hold, fog layers can support near-real-time robot behaviour that cloud-only processing cannot.

What carries the argument

The central objects are the three Fog Robotics architectures: Case A with a single fog robot server (FRS) serving multiple robots, Case B which adds device-to-device (D2D) communication between nearby robots, and Case C with multiple FRSs that allow handovers as robots move. The mechanism that carries the argument is the FRS itself: a nearby intermediary that processes robot data locally, queries the cloud only when data is unavailable, and hands robots over to adjacent FRSs in the multi-server case. In the evaluation, the iFogSim toolkit supplies the fog and D2D latency predictions, while real packet measurements with a Pepper robot and AWS servers supply the cloud baseline.

What would settle it

Measure end-to-end packet latency in a real deployment of Case C with at least two fog robot servers and a Pepper-class robot moving through a handover, using the same AWS regions as the paper. If fog latency rises into the hundreds of milliseconds once handovers and multi-hop FRS links are included, the claimed general advantage fails.

Watch

Extended reading notes

Core claim

The paper claims that Fog Robotics deserves to be treated as its own field, not merely as Fog Computing applied to robots, because robot tasks demand high storage, powerful CPUs and GPUs, mobility with handovers, and hard real-time interaction. It then reports that all three Fog Robotics architectures reduce latency dramatically compared with Cloud Robotics: in the iFogSim evaluation, fog latency rose from 8.58 ms to 10.73 ms, and D2D latency from 3.82 ms to 6.75 ms, while measured cloud latency ranged from about 208 ms in Sydney to 1,086 ms in São Paulo. This latency gap is the paper's evidence that fog layers can keep robot response times in the millisecond range.

Load-bearing premise

The whole latency advantage rests on the iFogSim simulator's unstated parameters faithfully representing the architectures, and on a single local fog server standing in for all three cases, including the multi-server Case C with handovers.

Editorial extensions

If this is right

Fog layers become a practical way to keep robot response times in the millisecond range for time-sensitive tasks such as rescue mapping and victim detection.
Architecture choice matters in deployment: D2D links give the lowest latency when robots are close, while multiple fog robot servers provide wider coverage with handovers.
Cloud servers remain useful as a fallback and coordination layer, since the fog server queries the cloud only when local data is unavailable.
The large latency gap supports treating Fog Robotics as its own field, with requirements such as mobility, high bandwidth, and hard real-time interaction that generic Fog Computing does not meet.
The measured spread of cloud latency across AWS regions means the fog advantage is larger the farther the robot is from the cloud.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

Editorial inference: if the latency advantage generalizes, the same three-tier fog pattern should apply to other time-critical robot domains, such as surgical teleoperation, warehouse fleets, and drone swarms, where a nearby compute node can close the control loop.
Editorial inference: a stronger test would measure task-level outcomes, such as victims found or rooms searched, rather than raw packet latency, because lower latency may not always translate into better task performance if the fog server's compute is weaker than the cloud's.
Editorial inference: the application comparison implies fog robotics infrastructure may need its own hardware standards, with high CPU/GPU cores and storage, rather than reusing existing fog-computing nodes; whether commodity fog nodes can supply that is left open.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

The genuinely new thing here is the latency data: real ping-style measurements from a Pepper robot to AWS endpoints across nine regions, plus an iFogSim simulation of the three fog architectures from the authors' earlier paper. The AWS region spread is a nice touch, and the observation that a local fog server beats a distant cloud server is physically unsurprising but still worth measuring once. The table contrasting Fog Robotics with generic Fog Computing is also useful for positioning the subfield. On those grounds the paper earns a careful read.

The soft spots are real and mostly in the evaluation. The cloud numbers are measured; the fog numbers are simulated with iFogSim, and no calibration against the real Pepper-to-fog path is reported. No simulation parameters are given (topology, link bandwidth, propagation delay, queueing model, number of runs), so the 50–100x gap could be partly a simulator artifact. The real measurement of the fog path is reported as a single "local server" with no trial count, no dispersion beyond max/avg/min, and no network details. Architecture C, the multi-server with handover case, is only ever simulated, so the general claim that fog robotics reduces latency significantly is not actually backed by end-to-end measurements for the more interesting architecture. This is the apples-to-oranges concern: a careful reader cannot tell how much of the headline result is physics and how much is iFogSim defaults.

The paper is honest about taking the architectures from prior work and frames itself as a summary, so the novelty is incremental rather than opening a new direction. The central conclusion is very likely true in the tested setting, but the evidence as presented is too thin to support the general statement in the abstract. That said, the work is not sloppy in its own terms, and the methodology is the kind a determined referee could fix: add trial counts, describe the network, validate the simulator against the real fog path, and report the fog simulation parameters.

Bottom line: I'd send this to a workshop or a systems venue with a request for major revision before acceptance. It deserves referee time, but not a quick pass. I probably wouldn't cite it as evidence for the latency claim in my own work—not yet.

Referee Report

3 major / 6 minor

Summary. The paper advocates for Fog Robotics (FR) as a distinct research field rather than a special case of Fog Computing. It motivates this distinction through an application-level comparison, presents three FR architectures (basic, with D2D communication, and with multiple fog robot servers), and describes a rescue-robot scenario. The main quantitative contribution is a latency evaluation: real-world latency measurements from a Pepper robot to AWS cloud regions and to a local fog server are reported, and iFogSim is used to predict latency for the FR architectures. The paper claims that Fog Robotics reduces latency significantly compared to Cloud Robotics, and it closes with advantages, challenges, and future scope.

Significance. If the quantitative latency claim were fully established, the paper would provide a useful empirical demonstration in favor of deploying fog layers in robot systems for time-sensitive tasks. The paper has notable strengths: it names a concrete scenario (Pepper robot, AWS endpoints, a local FRS), it addresses latency as a primary and relevant metric, and it explicitly compares multiple architectural variants. However, the current evidence is considerably weaker than the abstract's claim, because the fog-side numbers come from an uncalibrated simulator while the cloud-side numbers are real measurements, and the real measurement protocol is underdocumented. The qualitative direction of the result is unsurprising and plausible, but the specific magnitude of the latency advantage is not established by the reported experiments.

major comments (3)

[Section IV, Figs. 4-6] The central claim that Fog Robotics reduces latency significantly compared to Cloud Robotics rests on comparing real AWS latency measurements (Fig. 4) with iFogSim predictions for the FR architectures (Figs. 5 and 6). No iFogSim parameters are reported: topology, link bandwidth, propagation delays, queueing model, packet size, task model, and number of simulation runs are all absent, and no calibration of iFogSim against the actual Pepper-to-FRS path is described. Consequently, the apparent 50-100x gap could be an artifact of simulator defaults rather than a measured property of fog deployment. The authors should provide the full simulation configuration and validate the simulator by reproducing the measured local-FRS latency for the same workload.
[Section IV, Fig. 4 and accompanying text] The real-time latency measurement methodology is too thin to support the quantitative conclusion. The paper does not state the number of trials (only 'several attempts' is mentioned), the packet size or protocol (ICMP, TCP, or UDP), the network type at the robot and FRS, the hardware and location of the local FRS beyond 'local', or the time window of the tests. Only max, average, and min values are reported, without error bars, quantiles, or any measure of dispersion. A reproducible experimental protocol with full statistics is needed before the latency values can be used as a benchmark against simulation.
[Section IV.A/B/C] Architecture C, which includes multiple fog robot servers and handovers, is evaluated only through iFogSim; the real experiment uses a single local FRS and does not exercise handover or multi-server coordination. Therefore the claim that FR generally reduces latency compared with Cloud Robotics is not validated for the most complex architecture. The authors should either run a real multi-FRS/handover experiment or explicitly restrict the conclusion to the basic and D2D architectures (Cases A and B).

minor comments (6)

[Section IV, text near Fig. 3] There are several typos and garbled phrases that should be corrected, such as 'Jet us consider' instead of 'Let us consider', 'Cloud sever' instead of 'Cloud server', and the malformed value '26 L.85' in the description of the South Korea latency values.
[Section IV.A] The sentence 'the latency of FR raised from 8.58ms to 10.73ms hiking to 19.51ms' does not clearly indicate which robot counts produce which values. The authors should provide a table or explicit mapping of the reported latencies to the 1-5 robot scenarios.
[Fig. 1 caption] The caption text appears garbled (e.g., 'M1htary Robots') and should be corrected; the figure should also be checked for legibility, since the printed architecture diagram is hard to read in the manuscript.
[Table I] Several qualitative entries in the comparison between Fog Robotics and Fog Computing (e.g., CPU/Number of Cores, Mobility, and Latency/Jitter) are asserted without citation or measurement. If the table is meant as a position statement, that should be stated; otherwise each row should be supported by a reference.
[Section II] The statement that FR systems are 'always assumed as hard real-time systems' is stronger than typical robot task constraints, since many robot tasks are soft real-time. Qualifying this claim would avoid overstating the latency requirements.
[References] Reference [48] appears to be incomplete, as it lacks publication venue, year, and page numbers; it should be completed or removed.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity: the latency claim is supported by direct measurement and independent simulation, with only a minor non-load-bearing self-citation for the architectures.

full rationale

The paper's central claim is an experimental comparison, not a derivation. Section IV measures Pepper-to-AWS latencies in real time (Fig. 4) and uses the iFogSim toolkit [47] to simulate the three fog architectures (Figs. 5-6) without fitting any parameter to force the conclusion. The fog latency numbers are outputs of an external simulator, and the cloud numbers are direct measurements, so the latency advantage is not equivalent by construction to the paper's inputs. The authors cite their own prior work [11] for the three architectures and for the earlier claim that FR outperforms CR under an assumed latency value, but the current paper's real-time measurement campaign supersedes that assumption rather than inheriting it as a theorem. There is no uniqueness theorem, no definition of latency in terms of the conclusion, and no fitted input renamed as a prediction. Some experimental details (iFogSim parameters, calibration against the real FRS, and a real multi-server test for architecture C) are missing, which is a reproducibility and validity concern for a correctness review, not a circularity defect.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The paper introduces no new physical entities or fitted parameters. It relies on domain assumptions about robot real-time constraints, the representativeness of the test setup, and the fidelity of the iFogSim simulator. The free-parameter list is empty because latency values are measured, not fitted.

assumptions (4)

domain assumption Robots operate as hard real-time systems for which latency is unacceptable and must be minimized.
Section II argues that FR requires low latency because robot tasks are hard real-time. This assumption justifies choosing latency as the primary evaluation metric and frames cloud latency as a problem.
domain assumption A local fog robot server with one-hop topology is representative of FR architectures A and B.
Section IV uses a single local server as FRS and compares to AWS cloud; this simplification ignores architecture C (multiple FRS) and network handoffs, yet the conclusion is applied to FR generally.
ad hoc to paper The iFogSim simulator accurately models the FR architectures and network latency.
Section IV uses iFogSim to predict latency for the architectures, but the simulator configuration is not specified and no validation against the real measurements is shown.
domain assumption The comparison of a local server to geographically distributed AWS regions is a fair baseline for Cloud Robotics.
The experiment places the robot in Sydney with FRS likely in Sydney, while cloud servers are on other continents. This maximizes the latency gap and may not represent real deployments where cloud servers are also local.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Fog Robotics: A Summary, Challenges and Future Scope." pith.science (2026). https://pith.science/paper/7AKSQ2ZH

@misc{pith2026190804935,
  author       = {Pith},
  title        = {Pith review of: Fog Robotics: A Summary, Challenges and Future Scope},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7AKSQ2ZH}},
  note         = {Machine review of arXiv:1908.04935}
}

read the original abstract

Human-robot interaction plays a crucial role to make robots closer to humans. Usually, robots are limited by their own capabilities. Therefore, they utilise Cloud Robotics to enhance their dexterity. Its ability includes the sharing of information such as maps, images and the processing power. This whole process involves distributing data which intend to rise enormously. New issues can arise such as bandwidth, network congestion at backhaul and fronthaul systems resulting in high latency. Thus, it can make an impact on seamless connectivity between the robots, users and the cloud. Also, a robot may not accomplish its goal successfully within a stipulated time. As a consequence, Cloud Robotics cannot be in a position to handle the traffic imposed by robots. On the contrary, impending Fog Robotics can act as a solution by solving major problems of Cloud Robotics. Therefore to check its feasibility, we discuss the need and architectures of Fog Robotics in this paper. To evaluate the architectures, we used a realistic scenario of Fog Robotics by comparing them with Cloud Robotics. Next, latency is chosen as the primary factor for validating the effectiveness of the system. Besides, we utilised real-time latency using Pepper robot, Fog robot server and the Cloud server. Experimental results show that Fog Robotics reduces latency significantly compared to Cloud Robotics. Moreover, advantages, challenges and future scope of the Fog Robotics system is further discussed.

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

Edge Computing and its Application in Robotics: A Survey
cs.RO 2025-07 conditional novelty 3.0 of 10

A survey of edge robotics research from 2015 to 2025 that classifies recent work into seven application areas and identifies open challenges.

Reference graph

Works this paper leans on

5 extracted references · 5 canonical work pages · cited by 1 Pith paper

[3]

For Cloud, we considered Amazon Web Services (A WS) servers [46] from various locations of the world. They include Australia (Sydney), South Korea (Seoul), Singapore, India (Mumbai), Germany (Frankfurt), United Kingdom (London), South America (Sao Paulo), United States of America (Ohio) and Canada (Central) while a local server is regarded as FRS. Usually...

work page
[4]

For validation purpose, only the highest, average and lowest latency of particular countries are considered

Based on the obtained latency results of cloud sever concerning the robot, we can observe different latency values across various countries. For validation purpose, only the highest, average and lowest latency of particular countries are considered. As an average after several attempts, we can see that South America (Sao Paulo) has the highest latency of ...

work page
[5]

177038208.7 10.73 •• 0 500 1000 4000 1500 3500 ? 2500 C C1I 5 7000 -3000 .,, E Fig

Results of Architecture A/B Scenarios 5000 • Fog • Cloud (Sao Paulo) • Cloud (Seoul) • Cloud (Sydney) 4S00 433618 1086.4 zo 10.73 15 3844.05 10.73 2859 78 10.73 10 Number of Fog Robot Servers 1087.59 5 1541.93 209.89 1073 1. 177038208.7 10.73 •• 0 500 1000 4000 1500 3500 ? 2500 C C1I 5 7000 -3000 .,, E Fig

work page
[6]

Software: Practice and Experience, vol. 47, no. 9, pp. 1275-1296, 2017. [48] R. M. I. Mykhalchychyna and L. Buchhold,

Results of Architecture C Scenario architectures are as shown below. A. FR Architectures(AIB) For evaluating the Fog Robotics (FR) architectures (A/B), we chose to validate the latency with a variation of 1-5 robots. These robots send packets of data to Fog Robot Server and the Cloud. Upon measuring the latency w.r.t architecture description, we can say t...

work page 2017
[25]

Another issue that is concerned about Fog Robotics (FR) system is the need for a high amount of storage with more number of CPU/GPU cores due to its data usage

[26]. Another issue that is concerned about Fog Robotics (FR) system is the need for a high amount of storage with more number of CPU/GPU cores due to its data usage. In contrast, general applications of Fog Computing (FC) does not require such high computing requirements. Also, most robots that are currently available in the market comprise of low-level ...

work page

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.

[1] [3]

For Cloud, we considered Amazon Web Services (A WS) servers [46] from various locations of the world. They include Australia (Sydney), South Korea (Seoul), Singapore, India (Mumbai), Germany (Frankfurt), United Kingdom (London), South America (Sao Paulo), United States of America (Ohio) and Canada (Central) while a local server is regarded as FRS. Usually...

work page

[2] [4]

For validation purpose, only the highest, average and lowest latency of particular countries are considered

Based on the obtained latency results of cloud sever concerning the robot, we can observe different latency values across various countries. For validation purpose, only the highest, average and lowest latency of particular countries are considered. As an average after several attempts, we can see that South America (Sao Paulo) has the highest latency of ...

work page

[3] [5]

177038208.7 10.73 •• 0 500 1000 4000 1500 3500 ? 2500 C C1I 5 7000 -3000 .,, E Fig

Results of Architecture A/B Scenarios 5000 • Fog • Cloud (Sao Paulo) • Cloud (Seoul) • Cloud (Sydney) 4S00 433618 1086.4 zo 10.73 15 3844.05 10.73 2859 78 10.73 10 Number of Fog Robot Servers 1087.59 5 1541.93 209.89 1073 1. 177038208.7 10.73 •• 0 500 1000 4000 1500 3500 ? 2500 C C1I 5 7000 -3000 .,, E Fig

work page

[4] [6]

Software: Practice and Experience, vol. 47, no. 9, pp. 1275-1296, 2017. [48] R. M. I. Mykhalchychyna and L. Buchhold,

Results of Architecture C Scenario architectures are as shown below. A. FR Architectures(AIB) For evaluating the Fog Robotics (FR) architectures (A/B), we chose to validate the latency with a variation of 1-5 robots. These robots send packets of data to Fog Robot Server and the Cloud. Upon measuring the latency w.r.t architecture description, we can say t...

work page 2017

[5] [25]

Another issue that is concerned about Fog Robotics (FR) system is the need for a high amount of storage with more number of CPU/GPU cores due to its data usage

[26]. Another issue that is concerned about Fog Robotics (FR) system is the need for a high amount of storage with more number of CPU/GPU cores due to its data usage. In contrast, general applications of Fog Computing (FC) does not require such high computing requirements. Also, most robots that are currently available in the market comprise of low-level ...

work page