Troubleshooting AWS RoboMaker - AWS RoboMaker

Troubleshooting AWS RoboMaker

The following sections provide troubleshooting advice for errors and issues that you might encounter when using AWS RoboMaker simulation, IDEs, or Simulation WorldForge. If you find an issue that is not listed here, use the Provide feedback link at the bottom of this page to report it.

You can find logs for your simulation job in the CloudWatch Logs console. By default, AWS RoboMaker uploads logs for simulation jobs as they are generated for your application. If streamOutputToCloudWatch is set to True, the same behavior is applied to tools. You can also configure uploads by Adding a custom upload configuration in your simulation job.

For more information, see Logging and monitoring in AWS RoboMaker.

Simulation jobs

Issue: Your simulation job failed.

Use the questions below to help identify the root cause and then take the suggested action.

Are your Amazon S3 resources in the same region as AWS RoboMaker?

Your robot application, simulation application, and output locations must be in the same Region as AWS RoboMaker. Verify your application sources and simulation job output locations.

Did your robot application exit abnormally?

There was a problem setting up your robot application for simulation. Review the robot application logs for the simulation job in Amazon CloudWatch.

Logs are accessed from the simulation job detail screen. Select Logs, and then select a log stream. To look for specific issues, use the filter. For example, WARNING or ERROR.

Is your application missing an .so file?

If your application crashed, it might be missing a dependent shared object (.so) file. Extract your application bundle in your environment and verify that the shared object libraries you need are in /usr/lib or /usr/local/lib. Make sure the dependency is added to your package .xml file.

Did you use the ARN of your role with the AWS CLI?

When you call create-simulation-job from the AWS CLI, use the full Amazon Resource Name (ARN) of the role and not just the role name.

Does your role have a trust policy for AWS RoboMaker?

If you are passing the full Amazon Resource Name (ARN) of the IAM role when you call create-simulation-job from the AWS CLI, your trust policy might have insufficient privileges. Check the role to make sure it has a trust relationship with robomaker.amazonaws.com as follows.

{"Version": "2012-10-17", "Statement": {"Effect": "Allow", "Principal": { "Service": "robomaker.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": {"StringEquals": {"aws:SourceAccount": "account#" // Account where the simulation job resource is created }, "StringEquals": {"aws:SourceArn": "arn:aws:robomaker:region:account#:simulation-job/*" } } } }

Condition keys prevent an AWS service from being used as a confused deputy during transactions between services. See SourceAccount and SourceArn for additional information about condition keys.

See Modifying a role for more information about viewing role access and adding a trust policy to an IAM role.

Does your role have permissions to publish to Amazon S3?

If you specify an output Amazon S3 bucket for a simulation job, your role must have write permissions to the bucket. Update your trust policy to include write permissions. The following example trust policy adds read, list, and write permissions to an Amazon S3 bucket.

{"Action": "s3:ListBucket", "Resource": [ "my-bucket/*" ], "Effect": "Allow" },{"Action": [ "s3:Get*", "s3:List*" ], "Resource": [ "my-bucket/*" ], "Effect": "Allow" },{"Action": "s3:Put*", "Resource": [ "my-bucket/*" ], "Effect": "Allow" }

Does your role have permission to publish to CloudWatch?

Update the permissions policies of your IAM role with CloudWatch access.

{"Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents", "logs:DescribeLogStreams" ], "Resource": "*" }

Does your application have a mismatched entity tag?

The entity tag (ETag) is a hash of the Amazon S3 object provided while creating the simulation. The ETag reflects changes only to the contents of an object, not its metadata. If you change the content of the robot application or simulation bundle in Amazon S3 before AWS RoboMaker has consumed it, there will be a version mismatch.

To resolve this, create a new robot application or simulation application version and provide the key location for the updated application bundle. For more information, see Creating a robot application version or Creating a simulation application version.

Is your subnet elastic network interface (ENI) limit exceeded?

AWS RoboMaker uses one ENI for each concurrent simulation job in the subnet in which the simulation job is run. Each of these must be assigned an IP address. To resolve this, you can:

Delete unused ENIs to free up IP addresses in the subnet. To delete an unused ENI, see Deleting a network interface.

Using the AWS Management Console, request a service limit increase for ENIs in a specific AWS Region.

Is the launch command properly configured?

A simulation job can take a few minutes to launch if your simulation is complex or if the container image is large. If AWS RoboMaker spends more than 25 minutes preparing the simulation job, there might be a problem with the launch command. Cancel the job and then create a new simulation job. If the problem persists, contact AWS support.

You can use CloudWatch Logs to check the simulation and robot application execution logs for errors. You can also add a customized tool of terminal to connect and troubleshoot the running simulation job.

Are your subnets in zones that AWS RoboMaker supports?

Provide subnets in two of the AWS availability zones supported by AWS RoboMaker. API response contains a list of supported AWS availability zones.

Are your world file model references correct?

Use CloudWatch Logs to verify all of the models in your world file are correct. If a model cannot be located, you will see the following errors.

[Wrn] [ModelDatabase.cc:340] Getting models from[http://models.gazebosim.org/]. This may take a few seconds. [Wrn] [ModelDatabase.cc:212] Unable to connect to model database using [http://models.gazebosim.org//database.config]. Only locally installed models will be available. [Err] [ModelDatabase.cc:414] Unable to download model[model://model_name] [Err] [SystemPaths.cc:429] File or path does not exist[""] Error [parser.cc:581] Unable to find uri[model://model_name]

Simulation WorldForge

Issue: My world generation job failed.

If your world generation job did not complete, make sure your world count, floorplanCount * interiorCountPerFloorplan, is greater than 1 and less than 50.

Issue: Why did my world export job fail?

Use the questions below to help identify the root cause and then take the suggested action.

Do you have a trust policy for AWS RoboMaker?

If you are passing the full Amazon Resource Name (ARN) of the IAM role when you call create-world-export-job from the AWS CLI, your trust policy might have insufficient privileges. Check the role to make sure it has a trust relationship with robomaker.amazonaws.com as follows.

{"Version": "2012-10-17", "Statement": {"Effect": "Allow", "Principal": { "Service": "robomaker.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": {"StringEquals": {"aws:SourceAccount": "account#" // Account where the simulation job resource is created }, "StringEquals": {"aws:SourceArn": "arn:aws:robomaker:region:account#:simulation-job/*" } } } }

Condition keys prevent an AWS service from being used as a confused deputy during transactions between services. See SourceAccount and SourceArn for additional information about condition keys.

Does your role have permissions to publish to Amazon S3?

If you specify an output Amazon S3 bucket for a export job, your role must have permissions to the bucket. Update your trust policy to include the following permissions:

{"Effect": "Allow", "Action": [ "s3:AbortMultipartUpload", "s3:GetObject", "s3:PutObject" ], "Resource": "my-bucket" }

Did you modify or remove the bucket specified for the export job?

If you update your bucket during the export job, you may get a ResourceNotFound error from export job.

Issue: There's a problem with the world image.

Use the questions below to help identify the root cause and then take the suggested action.

Why is there no door in my doorway?

You can only add doors using a Version 2 template or later. You can update a Version 1 template to a later version. For more information, see Simulation world template versions, features, and changes.

Because AWS RoboMaker Simulation WorldForge creates worlds that are unique and random, the door configuration that you've specified might not exist in the world when you generate it. For example, you might specify a door between a living room and a kitchen in your template, but there might be an open wall between those rooms. Because there's an open wall instead of a doorway, you wouldn't be able to add a door there.

Why does my door block the entrance to my room?

The door blocking the entrance to a room is a circumstance that you can use to challenge your robots. To create a world that doesn't present this challenge to your robots, you can do one of the following:

Generate another world from your world template. The door generated in the new world might not block the entrance.

Change the open percentage of the door in the world template.

Why are the walls in my world image shorter than the walls in my simulation job or exported world?

AWS RoboMaker allows you to see your Simulation WorldForge worlds without it being obscured by walls by truncating the walls in the world image. The walls have the height that you specify in your world template in the worlds that you create.

For worlds generated by the Version 2 template or later, the door models are not truncated in the world images. The height of the doors in the world image are the same as the height of the doors in the worlds you create.