-
Notifications
You must be signed in to change notification settings - Fork 13
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
Conversation
Added DetectedObject and Sensor Updated Infrastructure Registration to include Sensors Added interact for both DetectedObject and Sensor registration Removed Infrastructure Time interface and moved functionality to Infrastructure Instance manager
replace List with ArrayList in method signature/ class members
Renamed Sensor to detector
Moved unit tests for mosiac objects into object lib
Added unit test for DetectedObject Fixed DetectionType label
…yncMessage to InfrastructureInstanceManager
+ Fixed stop call for Registration and Message Receiver
@@ -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); |
There was a problem hiding this comment.
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.
...e/src/main/java/org/eclipse/mosaic/fed/infrastructure/ambassador/InfrastructureInstance.java
Show resolved
Hide resolved
...e/src/main/java/org/eclipse/mosaic/fed/infrastructure/ambassador/InfrastructureInstance.java
Show resolved
Hide resolved
...lation/lib/mosaic-carma-utils/src/main/java/gov/dot/fhwa/saxton/CarmaV2xMessageReceiver.java
Outdated
Show resolved
Hide resolved
...lib/mosaic-objects/src/main/java/org/eclipse/mosaic/lib/objects/detector/DetectedObject.java
Show resolved
Hide resolved
...lib/mosaic-objects/src/main/java/org/eclipse/mosaic/lib/objects/detector/DetectedObject.java
Show resolved
Hide resolved
...lib/mosaic-objects/src/main/java/org/eclipse/mosaic/lib/objects/detector/DetectedObject.java
Show resolved
Hide resolved
.../lib/mosaic-objects/src/main/java/org/eclipse/mosaic/lib/objects/detector/DetectionType.java
Outdated
Show resolved
Hide resolved
...ation/lib/mosaic-objects/src/main/java/org/eclipse/mosaic/lib/objects/detector/Detector.java
Show resolved
Hide resolved
...e/src/main/java/org/eclipse/mosaic/fed/infrastructure/ambassador/InfrastructureInstance.java
Show resolved
Hide resolved
...ain/java/org/eclipse/mosaic/fed/infrastructure/ambassador/InfrastructureInstanceManager.java
Show resolved
Hide resolved
...ain/java/org/eclipse/mosaic/fed/infrastructure/ambassador/InfrastructureInstanceManager.java
Show resolved
Hide resolved
...ain/java/org/eclipse/mosaic/fed/infrastructure/ambassador/InfrastructureInstanceManager.java
Show resolved
Hide resolved
...ain/java/org/eclipse/mosaic/fed/infrastructure/ambassador/InfrastructureInstanceManager.java
Show resolved
Hide resolved
...ain/java/org/eclipse/mosaic/fed/infrastructure/ambassador/InfrastructureInstanceManager.java
Outdated
Show resolved
Hide resolved
...n/lib/mosaic-objects/src/main/java/org/eclipse/mosaic/lib/objects/detector/DetectorType.java
Outdated
Show resolved
Hide resolved
...on/lib/mosaic-objects/src/main/java/org/eclipse/mosaic/lib/objects/detector/Orientation.java
Show resolved
Hide resolved
...imulation/lib/mosaic-objects/src/main/java/org/eclipse/mosaic/lib/objects/detector/Size.java
Show resolved
Hide resolved
...-objects/src/main/java/org/eclipse/mosaic/lib/objects/detector/gson/DetectorTypeAdapter.java
Show resolved
Hide resolved
...b/mosaic-objects/src/test/java/org/eclipse/mosaic/lib/objects/detector/DetectorTypeTest.java
Show resolved
Hide resolved
...e/src/main/java/org/eclipse/mosaic/fed/infrastructure/ambassador/InfrastructureInstance.java
Show resolved
Hide resolved
There was a problem hiding this 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(); |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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.
...ain/java/org/eclipse/mosaic/fed/infrastructure/ambassador/InfrastructureInstanceManager.java
Show resolved
Hide resolved
* @param message java object containing message information | ||
* @return bytes encoded from JSON string representation of object. | ||
*/ | ||
private byte[] encodeMsg(Object message) { |
There was a problem hiding this comment.
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)); |
There was a problem hiding this comment.
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.
…nd send appropriate messages
Kudos, SonarCloud Quality Gate passed! 0 Bugs 73.5% Coverage 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. |
PR Details
Description
Added additional information to the Infrastructure Registration Message including :
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
Checklist:
CARMA Contributing Guide