-
Notifications
You must be signed in to change notification settings - Fork 98
Cloudsim Architecture
AWS g3.4xlarge instances are used for running simulation and for each robot solution. A g3.4xlarge
instance has 1 GPU with 8 GiB of GPU memory, and 16 vCPUs with 122 GIB of CPU memory. The Amazon Machine Image (AMI) deployed on these instances supports CUDA 10 with nvidia-docker2. Communication between EC2 instances relies on Ignition Transport and the ROS communication is isolated to each robot EC2 instance, as shown above.
There are two docker containers running on each robot EC2 instance. The Bridge Container; which cannot be modified by a competitor, is responsible of starting the VPN client, the ROS master, and the ROS1 Ignition Transport bridge. The Solution Container, consists of a competitor’s control code for the robot and the competitor can submit one docker image per robot; where each image can be different or identical.
Each Robot EC2 instance runs a firewall on the host; which blocks all network traffic except for a VPN tunnel to the Bridge Container. This will prevent the Solution Container from communicating directly with other robots and the outside world. The firewall, VPN client, and docker networking will be established according to this guidance.
Ignition Transport is be used between the Bridge Container and Simulation Container. This allows each robot to run a ROS master, thereby avoiding a ROS multi-master setup and the need to block specific ROS topics. Filtering of Ignition Transport topics is performed by the ROS1 Ignition bridge. The filtering will expose only the topics needed by the robot associated with the Robot EC2 instance.
Gazebo state information and server console messages are logged on the Ignition Gazebo instance. ROS console messages are captured in the Bridge Container on each Robot instance.