2017 18th International Conference on Advanced Robotics (ICAR) 2017
DOI: 10.1109/icar.2017.8023654
|View full text |Cite
|
Sign up to set email alerts
|

Design of a cloud robotics middleware based on web service technology

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
1
1
1
1

Citation Types

0
6
0

Year Published

2018
2018
2022
2022

Publication Types

Select...
7

Relationship

0
7

Authors

Journals

citations
Cited by 8 publications
(6 citation statements)
references
References 9 publications
0
6
0
Order By: Relevance
“…Polling solutions are not feasible for low-level remote control (as teleoperation) [16] Based on the use of SpaceBrew It is not clear if visibility among agents is requested or managed by SpaceBrew. Some limitations are presented in the paper but not discussed [18] Communication based on a proxy virtual machine Listed results are limited to one robot [19] Based on three subsystems in the cloud environment: middleware subsystem, background tasks subsystem, and control subsystem Built upon the ROS Multimaster FKIE [20], which requires bi-directional visibility among all the agents in the system [21] Based on WebSocket protocol to guarantee the bi-directionality of the flow of data Visibility requirements between the agents not detailed. Still limited in an early developer program [10] New protocol, similar to rosbridge protocol Tests limited to few simulated robots…”
Section: Features Of the System Used Limitation Of The Presented Workmentioning
confidence: 99%
See 2 more Smart Citations
“…Polling solutions are not feasible for low-level remote control (as teleoperation) [16] Based on the use of SpaceBrew It is not clear if visibility among agents is requested or managed by SpaceBrew. Some limitations are presented in the paper but not discussed [18] Communication based on a proxy virtual machine Listed results are limited to one robot [19] Based on three subsystems in the cloud environment: middleware subsystem, background tasks subsystem, and control subsystem Built upon the ROS Multimaster FKIE [20], which requires bi-directional visibility among all the agents in the system [21] Based on WebSocket protocol to guarantee the bi-directionality of the flow of data Visibility requirements between the agents not detailed. Still limited in an early developer program [10] New protocol, similar to rosbridge protocol Tests limited to few simulated robots…”
Section: Features Of the System Used Limitation Of The Presented Workmentioning
confidence: 99%
“…The experimental setups differ from each other based on the number of agents (users and robots), network infrastructures and scenarios. For the works described in [10,18], the number of user-robot pairs is always equal to or higher than three.…”
Section: Experimentationmentioning
confidence: 99%
See 1 more Smart Citation
“…Architecture [6][7][8][9][10][11][12][13][14][15][16][17][18][19][20] Development of software Execution and round-trip communication architecture for heterogeneous time for SLAM and robotic manipulation robots to share sensor tasks. data between processing nodes for computationally intense algorithms.…”
Section: Work Contribution Metrics and Evaluation Techniquesmentioning
confidence: 99%
“…In order to alleviate the complexities associated with setup and configuration of majority of the cloud robotics systems, Hajjaj et al [11] proposed an alternative method called Port Forwarding which offers a private, secured and direct ROS-to-ROS connection, thus eliminating the requirement for a dedicated middleware. Luo et al [14] designed a cloud robotics middleware based on the Web service technology which parses the Cloud Robotics task request and schedules ROS nodes in a distributed network. In [15], the authos introduced an Open Mobile Cloud Robotics Interface (OMCRI) as a Robot-as-a-Service vision-based platform that offers a unified easy access to remote heterogeneous mobile robots.…”
Section: Cloud Robotics System Architecturesmentioning
confidence: 99%