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

Add Sensor/Detector Registration to Infrastructure Ambassador #152

Merged
merged 44 commits into from
Aug 8, 2023

Conversation

paulbourelly999
Copy link
Contributor

@paulbourelly999 paulbourelly999 commented Jul 27, 2023

PR Details

Description

Added additional information to the Infrastructure Registration Message including :

  • Port for transmitting relevant interactions
  • List of sensors/detectors to register for infrastructure instance

Added functionality to process new registration message, trigger sensors/detectors registration interactions to prompt creation of sensors/detectors.
Added functionality to process incoming Detected Object interactions from sensors and forward them via the new interactions port to registered infrastructure instances based on the sensor that reports the detection.

Related Issue

#211

Motivation and Context

New functionality will be used to create sensor in CARLA and retrieve detection information for the VRU use case

How Has This Been Tested?

Unit tested and Integration testing with XIL Cloud setup
Only tested that CDASim properly processes Infrastructure registration and still forwards time sync messages. Further testing for detection interaction processing is advised once CARLA Ambassador work completes.

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

@paulbourelly999 paulbourelly999 changed the title Initial Commit Add Sensor/Detector Registration to Infrastructure Ambassador Jul 31, 2023
@@ -41,7 +42,7 @@ public class CarmaV2xMessageReceiver implements Runnable {
private Queue<Tuple<InetAddress, CarmaV2xMessage>> rxQueue = new LinkedList<>();
private DatagramSocket listenSocket = null;
private int listenPort;
private boolean running = true;
private AtomicBoolean running = new AtomicBoolean(false);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same comment as with the InfrastructureMessageReceiver.

dan-du-car
dan-du-car previously approved these changes Aug 4, 2023
kjrush
kjrush previously approved these changes Aug 7, 2023
Copy link
Contributor

@kjrush kjrush left a comment

Choose a reason for hiding this comment

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

Few minor things, but overall looks good to me!

@@ -156,7 +223,7 @@ public void setTimeSyncPort(int timeSyncPort) {
* methods
*/
public void bind() throws IOException {
rxMsgsSocket = new DatagramSocket();
socket = new DatagramSocket();
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe connect is a better name or something along those lines? the primary reason - if I recall correctly - for having a separate method to init the DatagramSocket was to avoid a possible failure in the constructor (e.g. the ports are already in use) which is just a weird state to have. Not strongly attached to this implementation though.

* @param data The binary data to transmit
* @throws IOException If there is an issue with the underlying socket object or methods
*/
public void sendTimeSyncMsg(byte[] data) throws IOException {
Copy link
Contributor

Choose a reason for hiding this comment

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

Have we defined a class for the Time Sync message? I feel like it might be cleaner to have this (and the interaction one below) take in some type more meaningful than a byte[]. I think it make sense in the v2x message case because byte[] is actually the real type of a V2XMessage, but the time data and (I imagine) the interaction data are more higher-level than that.

* @param message java object containing message information
* @return bytes encoded from JSON string representation of object.
*/
private byte[] encodeMsg(Object message) {
Copy link
Contributor

Choose a reason for hiding this comment

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

To echo above, it's not a big deal, but I'm not a huge fan of how broad this function signature is. If I'm tinkering in this class in the future, this function signature doesn't do much to inform me what type of stuff we're usually encoding or need to encode. I'd generally prefer narrow function signatures where possible.

}

for (InfrastructureInstance currentInstance : managedInstances.values()) {
currentInstance.sendTimeSyncMsg(encodeMsg(message));
Copy link
Contributor

Choose a reason for hiding this comment

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

This is somewhere I think we could just make sendTimeSyncMsg consume InfrastructureTimeMessage like I noted prior, then the entire encodeMsg function is no longer needed (or at least not needed here) and then I think the API is a little clearer in terms of intended use.

@paulbourelly999 paulbourelly999 dismissed stale reviews from kjrush and dan-du-car via d3276a9 August 7, 2023 14:08
@sonarcloud
Copy link

sonarcloud bot commented Aug 8, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 5 Code Smells

73.5% 73.5% Coverage
1.1% 1.1% Duplication

warning The version of Java (11.0.19) you have used to run this analysis is deprecated and we will stop accepting it soon. Please update to at least Java 17.
Read more here

@kjrush kjrush merged commit a1590e2 into develop Aug 8, 2023
6 checks passed
@kjrush kjrush deleted the add_sensor_registration branch August 8, 2023 16:32
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.

3 participants