Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Evaluation timing verification #13

Open
osrf-migration opened this issue Oct 4, 2019 · 2 comments
Open

Evaluation timing verification #13

osrf-migration opened this issue Oct 4, 2019 · 2 comments

Comments

@osrf-migration
Copy link

Original report (archived issue) by Brian Bingham (Bitbucket: brian_bingham).


Currently the run_trial.bash script does the following in order:

  • Starts up the vrx-server container
  • Waits a fixed amount of time (9 seconds)
  • Then starts the team’s container

We should verify that this timing won’t cause any problems. I believe it is done this way b/c if we start the team’s container first, it will not have a ROS master on the network which could cause problems.

This seems to have the potential for the simulation to start (and proceed towards Running state) before the team’s code gets up and running, especially if the team’s container takes significant time to spin up.

Also, Tyler left notes in the source to check on this, so wanted to get it into our list.

@M1chaelM
Copy link
Collaborator

May want to look into client image and check whether it's started, or else investigate whether docker compose will handle this.

@M1chaelM
Copy link
Collaborator

This is a duplicate of issue #7, which includes Tyler's write up. Currently, the way we check for this is indirect, by making the testing infrastructure available to the teams and conducting the dress rehearsal.

We can avoid having to wait an arbitrary, fixed about of time by switching to Docker compose and using the depends_on flag. This is an easy way of making sure the team's container doesn't run until the vrx-server is up. It still doesn't prevent the competitor from starting while the team's container is getting ready.

There are some good suggestions for improving our approach here: https://docs.docker.com/compose/startup-order/

We can probably add a script that waits for the competitor container to be running before we start the initial_state_duration timer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants