Multiple custom sensor questions

[RobShewagaUHN]

Hi all, multiple questions about creating custom sensors below. All relevant to running in developer mode (i.e. in Unity Editor).

1. After building a custom sensor, the bundle is placed in simulator/AssetBundles/Sensors (e.g. 'sensor_MyCustomSensor'). It then has to be uploaded to the web UI, and when used in the simulator within Unity, the sensor will be downloaded to %AppData%\LocalLow\LGElectronics\SVLSimulator\Sensors using a different file name (e.g. '82f-2af'). Even if you place your built sensor file (sensor_MyCustomSensor) in the AppData folder, the simulator will redownload the bundle due to it not having the expected modified file name (82f-2af). Is there a way to know what this modified filename will be so the user can rename and directly move their local built sensor files to the AppData folder on, for example, a fully-offline simulator setup?

2. When multiple sensors are placed in the External/Sensors folder like below:

   Sensors/MyCustomSensor1 Sensors/MyCustomSensor2

If only MyCustomSensor2 is selected in the Simulator/Build window, the sim still seems to try to build MyCustomSensor1 first. Why is this? Furthermore, if MyCustomSensor1 has an issue and doesn't get built, it seems like the sim won't attempt to continue and build MyCustomSensor2 at all.

3. Building a custom sensor with a [SensorParameter] public Vector2 m_resolution=new Vector2(1920,1200); causes issues in the web UI as the web UI can't seem to support a Vector2. Only a float/int can be entered. This causes the sim to crash on start with the error:

   Exception: Unknown M_resolution parameter for MyCustomSensor sensor on Jaguar2015XE vehicle

I see for example CameraSensorBase gets around this by separating the width/height into separate int parameters, though can Vector2 be supported in the future?

4. Is there a way for multiple custom sensors to share code? For example, I have a CommonCode.cs file that has a class defined that is needed by both MyCustomSensor1 and MyCustomSensor2, like in Q2 above. In order for each sensor to find and use that class, CommonCode.cs needs to be in that sensor's folder when built. When building MyCustomSensor1, I need to manually move CommonCode.cs into the Sensors/MyCustomSensor1 folder, and when building MyCustomSensor2, move it into that sensor's folder. Is there a way around this? This issue is made worse by the issue from Q2 above, as all sensors need to be valid and without issue upon building any single one of them.

Thanks all

[RobShewagaUHN]

Follow up to Q3: The variable name has to match (case sensitive) to whatever is shown on the web UI. If the variable is _mresolution but web UI displays _Mresolution, error will be thrown if any of the sensor's parameters are modified from default.

[zelenkovsky]

@RobShewagaUHN Vector2 is a complex type. Complex types are not supported. You can use strings, integers, floats, booleans.

You still can use structures and arrays, BUT it will be visualized as JSON editor. Please look at ColorCameraSensor example to see how complex PostProcessing attributes are defined:

https://github.com/lgsvl/ColorCameraSensor/blob/master/ColorCameraSensor.cs#L18 https://github.com/lgsvl/simulator/blob/master/Assets/Scripts/Sensors/CameraSensorBase.cs#L77

[lemketron]

Follow up to Q3: The variable name has to match (case sensitive) to whatever is shown on the web UI. If the variable is _mresolution but web UI displays _Mresolution, error will be thrown if any of the sensor's parameters are modified from default.

Hi @RobShewagaUHN,

Regarding Q3: I'm trying to understand where the case mismatch is coming from... Can you check your plug-in files to see if the "M" version appears anywhere (e.g. manifest, etc.)? There was previously a bug where uploading a new asset bundle did not re-register parameters, so if you changed the case somewhere along the way, we apologize for this. The suggestion would be to upload a new plug-in and see if the problem goes away (now that we've fixed the registration issue).

Regarding Q4: There is unfortunately no way to share code between plug-ins now. You might want to incorporate a version of the shared code in each plug-in (which might resolve the issue mentioned in your second question) or consider merging the two camera plug-ins into a single one that differentiates behavior through an additional runtime parameter.

[thisisdavidfrank]

Hey @RobShewagaUHN,

Regarding Q4 (about using a common class for multiple sensors), can you try the symlink approach as discussed here:

https://forum.unity.com/threads/using-links-sym-hard-to-create-a-common-folder-for-all-unity-projects.104374/

[RobShewagaUHN]

Hi @lemketron,

Q3: I've checked both the error "m" version and correct "M" version of the sensor manifest.json files by extracting the built sensors, and both manifests show the variable correctly. I.e. the variable case sensitivity is respected properly in the manifest, whichever way is written in the script.

I ran into that exact bug about uploading a new sensor version not catching the fix right away just a few days ago. I just tested it again by uploading a fresh bugged sensor, then updating to a fixed version, and the sim is happy now and the updated/fixed sensor version works.

I have noticed in the web UI that the sensor's main page lists parameters case sensitivity as written in the script. Here I'm using the lower case version.

But case sensitivity is not displayed properly on the vehicle sensor configuration screen (should be "m_width")

[RobShewagaUHN]

1. Is there a way to know what this modified filename

For anyone reading, I did not realize (and haven't seen in documentation) that built sensor files can be unzipped. Inside has the version of the sensor with the downloaded filenames. I assume if you copy-paste your custom sensor into the AppData folder and rename it to the downloaded filename, it'll be recognized by the sim without having to download the sensor from the web.

[thisisdavidfrank]

@RobShewagaUHN, in regards to this:

But case sensitivity is not displayed properly on the vehicle sensor configuration screen (should be "m_width")

It might be because the sensor configuration still has the old plugin data in it. Can you try:

1. Removing the plugin from the sensor configuration, hitting save, and then re-adding the plugin?
2. Maybe the data is just cached on your browser. Can you try a hard-refresh?

[RobShewagaUHN]

@thisisdavidfrank

Regarding Q4 (about using a common class for multiple sensors), can you try the symlink approach

Tried a number of things and none are a workable solution. The setup is below: Assets/CommonScripts/Common.cs Assets/External/Sensors/SensorA Assets/External/Sensors/SensorB

1. Creating a soft link to the Common.cs file within Sensors/SensorA will clear compile errors, but building the sensor will fail because the common file isn't in the sensor's folder directly.
2. Placing Common.cs within External/Sensors gives the same result as 1.
3. If both /SensorA and /SensorB folders have a hard link to Assets/CommonScripts/Common.cs, SensorB will post an error about duplicate definitions for everything in that common file, as it's 'technically' duplicated in two folders.
4. Creating a Directory Junction within both /SensorA and /SensorB folders to Assets/CommonScripts clears compile errors, however upon Unity reimporting assets it gets stuck in an infinite loop importing the Directory Junction.

[lemketron]

consider merging the two camera plug-ins into a single one that differentiates behavior through an additional runtime parameter

Are the two camera sensors similar enough that you could combine them into a single sensor?

[RobShewagaUHN]

In this case it isn't actually two cameras, it's one Master sensor I'm using to load common files from StreamingAssets (warping frustums, config.jsons, etc) and another Projector sensor that uses those common files loaded to set up multi-display output and camera warping.

In this simple 2 sensor solution it would be easy to merge them or alternatively have the Projector sensor be responsible for loading the files it needs, though I foresee issues where multiple sensors need to load the same files and have a shared understanding of any manipulations. For now I'm more planning ahead to future sensors I'll need to make (Matlab communicator, CarSim integration, post-processing/performance optimization sensor, etc) that will create a web of dependencies. From an architecture perspective I'd like to keep functionality separated into multiple sensors and have them be as plug and play as possible instead of one monolithic sensor, though that may not be possible at the moment.