Feature/filter controls #61
Conversation
src/cc/util/FilterControls.java
Outdated
| for (byte[] yId : oIds) | ||
| { | ||
| createFilePath(sBuf, yId); | ||
| // Path oInGeo = Paths.get(sInputDir + "geolanes/" + sBuf.toString()); |
There was a problem hiding this comment.
Are these lines necessary at all?
README.md
Outdated
| @@ -122,6 +122,22 @@ Example: | |||
| > x<sub>(n-2)</sub><sub>0</sub>,y<sub>(n-2)</sub><sub>0</sub>,x<sub>(n-2)</sub><sub>1</sub>,y<sub>(n-2)</sub><sub>1</sub>,x<sub>(n-2)</sub><sub>2</sub>,y<sub>(n-2)</sub><sub>2</sub>,x<sub>(n-2)</sub><sub>3</sub>,y<sub>(n-2)</sub><sub>3</sub> | |||
| > x<sub>(n-1)</sub><sub>0</sub>,y<sub>(n-1)</sub><sub>0</sub>,x<sub>(n-1)</sub><sub>1</sub>,y<sub>(n-1)</sub><sub>1</sub>,x<sub>(n-1)</sub><sub>2</sub>,y<sub>(n-1)</sub><sub>2</sub>,x<sub>(n-1)</sub><sub>3</sub>,y<sub>(n-1)</sub><sub>3</sub> | |||
|
|
|||
| ## Testing Considerations | |||
|
|
|||
| Upon startup, CARMA Cloud automatically creates traffic controls for later sending to CARMA platform by reading XML OpenDrive files placed in its XODR work folder, e.g. <tomcat_home>/work/xodr. This can result in thousands of traffic controls that are mostly uninteresting for testing purposes. The cc.util.FilterControls command-line application accepts a list of traffic control identifiers, and creates a much smaller and more manageable subset of traffic controls that can be saved along with their respective teting scenarios. | |||
|
|
||
| The FilterControls application takes the source work folder name, the destination work folder name, and a space-separated list of at least one 16-byte hexadecimal encoded text traffic control id. | ||
| ``` | ||
| <java_home>/bin/java -cp <path_to_carmacloud_classes>:<path_to_carmacloud_lib>/keccakj.jar cc.util.FilterControls <source_path> <destination_path> <id1> <id2> ... <idN> |
There was a problem hiding this comment.
I highly recommend that in the future we start packaging dependencies into our built JAR files so we don't have to do things like this and so each JAR is independently executable.
| ``` | ||
| For example: | ||
| ``` | ||
| <java_home>/bin/java -cp <path_to_carmacloud_classes>:<path_to_carmacloud_lib>/keccakj.jar cc.util.FilterControls <tomcat_home>/work/carmacloud <tomcat_home>/work/filtered 00109ab6d542f12ca8942b436c9c9d8d |
There was a problem hiding this comment.
Is this tool compiled using the regular CARMA-Cloud build scripts or does it have to be compiled separately.
There was a problem hiding this comment.
Since it's in the CARMA Cloud source, it gets compiled by the build script.
|
|
||
| Upon startup, CARMA Cloud automatically creates traffic controls for later sending to CARMA platform by reading XML OpenDrive files placed in its XODR work folder, e.g. <tomcat_home>/work/xodr. This can result in thousands of traffic controls that are mostly uninteresting for testing purposes. The cc.util.FilterControls command-line application accepts a list of traffic control identifiers, and creates a much smaller and more manageable subset of traffic controls that can be saved along with their respective teting scenarios. | ||
|
|
||
| After CARMA Cloud has been started for the first time in a testing scenario, XODR files will have been processed, and the tester can login to CARMA Cloud to add traffic controls for his testing needs. Executing an ls -lrt in the traffic controls folder, typically <tomcat_home>/work/carmacloud/traf_ctrls, will put the newly created traffic controls at the bottom of the list. The hexadecimal encoded text for the 16-byte traffic control ids to be kept can then be derived from three levels of folder paths and the traffic control filename. |
There was a problem hiding this comment.
This seems like a very tedious and technical process. I would assume under normal functionality CARMA-Cloud would consider everything in the xodr as baseline or uninteresting to requesters and just store additionality configured traffic controls separately to provide those right.
My understanding is the CARMA-Cloud isn't responsible for providing a vehicle with all traffic controls that make up some area of travel but instead just custom/temporary ones added for construction or other purposes.
There was a problem hiding this comment.
The original scope of CARMA Cloud is to provide all traffic controls. XODR traffic controls use time 0 as the start of their schedule. In real-world test beds, CARMA Platform requests controls created within the last few days from wall-clock time. In simulation testing, both the traffic control times and traffic control requests are near the epoch.
PR Details
Description
Added FilterControls utility application used to filter automatically created traffic controls from XODR and create a subset of traffic controls used for testing scenario needs.
Related GitHub Issue
Related Jira Key
Motivation and Context
Eliminates the need to manage large compressed files of thousands of traffic controls or managing thousands of individual traffic control files for testing purposes.
How Has This Been Tested?
Town04.xodr was used to create thousands of traffic controls. Then a test traffic control was added. The new traffic control identifier was determined, and used with the FilterControls utility, to produce a single traffic control configuration. CARMA Cloud was then tested with the single traffic control, and only one was presented on the UI.
Types of changes
Checklist: