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.

Sign up for GitHub

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

Jump to bottom

CDASim Time Synchronization is non-time-regulating #540

Open
paulbourelly999 opened this issue Jun 6, 2023 · 0 comments
Open

CDASim Time Synchronization is non-time-regulating #540

paulbourelly999 opened this issue Jun 6, 2023 · 0 comments
Labels
enhancement New feature or request

Comments

@paulbourelly999
Copy link
Contributor

Summary

Currently the time synchronization implemented in the CDASimAdapter is incomplete because it is non-time-regulating. What this means is that there is no mechanism currently implemented that will track whether V2X-Hub or infrastructure software is ready for the next time step. This means that if simulation time begins to increment too fast for V2X-Hub logic to keep up, V2X-Hub plugins will begin to lag behind the most current simulation time. This can cause incorrect control behavior.

  • [ ]

Version

4.3.0 (Current)

Expected Behavior

The CDASimAdapter will notify CDASim when all V2X-Hub logic has completed calculation for current time and is ready for the next time step to avoid CDASim from incrementing time too fast for V2X-Hub to keep up with the most current simulation time.

Actual Behavior

Currently the CDASimAdapter time synchronization logic is non-time regulating meaning V2X-Hub plugins can fall behind the most current simulation time if it is incrementing to fast for V2X-Hub to keep up.

Steps to Reproduce the Actual Behavior

  1. Run a CDASim scenario with no configured SUMO delay between time steps.
  2. V2X-Hub/CARMA-Streets components will fall behind simulation time.

Related Work

No response
@paulbourelly999 paulbourelly999 added bug Something isn't working anomaly labels Jun 6, 2023
@paulbourelly999 paulbourelly999 mentioned this issue Aug 9, 2023
Merged
8 tasks
paulbourelly999 added a commit to usdot-fhwa-stol/cdasim that referenced this issue Aug 9, 2023
@paulbourelly999
Added configuration files for sumo GUI settings (#154)
be4391d 
Set Delay to 1000 ms per second to startup SUMO running at approximately
real-time to avoid time sync issues with simulation and infrastructure

<!-- Thanks for the contribution, this is awesome. -->

# PR Details
## Description

<!--- Describe your changes in detail -->
Due to this issue (usdot-fhwa-OPS/V2X-Hub#540)
the current time synchronization between infrastructure (V2X-Hub) and
CDASim is non-time regulating, meaning Infrastructure does not currently
have a way of notifying CDASim when it is ready for time to advance in
simulation. Due to this, is simulation is running faster than real time,
Infrastructure can begin to fall behind. To avoid this, this PR adds a
GUI settings file to the SUMO GUI, which is used to play/pause/step
through the simulation. In this settings file, we can configure the
delay, a sumo GUI feature that controls how long, if at all, between
time steps SUMO will wait before inform proceeding to the next time.
Since SUMO's integration with CDASim is time regulating, this delay
feature allow a use to modify the maximum speed at which the simulation
can run. The new settings file configures this value to be 1000ms per 1s
(~ real-time) at startup to avoid the need for manual configuration at
start up
## Related Issue

<!--- This project only accepts pull requests related to open issues -->
<!--- If suggesting a new feature or change, please discuss it in an
issue first -->
<!--- If fixing a bug, there should be an issue describing it with steps
to reproduce -->
<!--- Please link to the issue here: -->

## Motivation and Context

<!--- Why is this change required? What problem does it solve? -->
Avoid (usdot-fhwa-OPS/V2X-Hub#540)
## How Has This Been Tested?
XIL-Cloud deployment
<!--- Please describe in detail how you tested your changes. -->
<!--- Include details of your testing environment, and the tests you ran
to -->
<!--- see how your change affects other areas of the code, etc. -->

## Types of changes

<!--- What types of changes does your code introduce? Put an `x` in all
the boxes that apply: -->

- [x] Defect fix (non-breaking change that fixes an issue)
- [x] New feature (non-breaking change that adds functionality)
- [ ] Breaking change (fix or feature that cause existing functionality
to change)

## Checklist:

<!--- Go over all the following points, and put an `x` in all the boxes
that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're
here to help! -->

- [ ] I have added any new packages to the sonar-scanner.properties file
- [ ] My change requires a change to the documentation.
- [] I have updated the documentation accordingly.
- [x] I have read the **CONTRIBUTING** document.
[CARMA Contributing Guide](Contributing.md) 
- [ ] I have added tests to cover my changes.
- [x] All new and existing tests passed.
@paulbourelly999 paulbourelly999 added enhancement New feature or request and removed bug Something isn't working anomaly labels Mar 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@paulbourelly999