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

CDAR-756: Update UDPSockets to listen at higher frequency #579

Merged
merged 6 commits into from
Feb 6, 2024

Conversation

paulbourelly999
Copy link
Contributor

@paulbourelly999 paulbourelly999 commented Feb 6, 2024

PR Details

Description

When running a simulation with CARMA Streets, the position data in the SDSMs appear to lag the ground truth significantly.
In the included image, the square inside the blue circle indicates the VRU’s reported position in the SDSM. The blue square is its actual position. They yellow circle shows CARMA’s reported SDSM position with the green rectangle showing its actual position.

image

Based on a visualization of carla-sensor-lib’s logs for the pedestrian (actor 221), it appears that the position data does get updated at some point. The image below is a timestamp vs. x position graph.
After further investigation, there is a difference in time stamps between the SDSMs and external objects.
image

It was found that is was largely due to the CDASimAdapter only consuming detection data at 10 hz (wall time). When running at real-time speed, the simulation can generate detection data at significantly higher frequency. This PR updates the consuming frequency to 200 Hz. This fix should be sufficient until the number of simultaneous detection exceeds 10 objects of 100Hz frequency.

Improved delay shown below:

screenshot

Related Issue

CDAR-756
#589

Motivation and Context

Fix detection data delay for SDSM data

How Has This Been Tested?

CDASim Deployment

Types of changes

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

Checklist:

  • 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.
  • I have read the CONTRIBUTING document.
    V2XHUB Contributing Guide
  • I have added tests to cover my changes.
  • All new and existing tests passed.

@paulbourelly999 paulbourelly999 requested review from dan-du-car and removed request for dan-du-car February 6, 2024 14:18
@paulbourelly999 paulbourelly999 marked this pull request as ready for review February 6, 2024 16:17
@paulbourelly999 paulbourelly999 marked this pull request as draft February 6, 2024 16:26
@paulbourelly999 paulbourelly999 marked this pull request as ready for review February 6, 2024 16:34
Copy link
Contributor

@MishkaMN MishkaMN left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a little concern whether if we are introducing large frequency unnecessarily. 200hz seems high when the detections are coming in at 10hz, which we would need only 20Hz for. However, it is that high because all objects don't come at once, and if 5 objects are detected, they would need at least 100Hz (10Hz * 5 objects * 2 nyquist). Our current assumption is that the lidar or camera would provide objects in this way due to event driven action.

@MishkaMN MishkaMN merged commit 623713b into develop Feb 6, 2024
9 checks passed
@MishkaMN MishkaMN deleted the cdar-756-fix-cdasimadapter-consumer-interval branch February 6, 2024 19:28
@MishkaMN MishkaMN self-assigned this Feb 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants