System level parameters class

[pv33]

Consider making a base/core System parameters class that has the outer components defined. All other instances should be derived classes. This part has the "source" field and the "output" field, plus any other fields that make sense. These fields can be augmented in the subclasses.

Importantly, since filename specifications can be done using user relative paths with "~/xxxx" and python file operations do not recognize or interpret the "~" character, the expansion needs to be made for all files. The new implementation of yacs-based yaml loading undid the code that was added in the specification.py class.

For example in utils/specifications.py there are the lines of code:

if 'rosbag' in self.source: self.source.rosbag = os.path.expanduser(self.source.rosbag) if 'puzzle' in self.source: self.source.puzzle = os.path.expanduser(self.source.puzzle)

to perform path expansion. That has been lost and now specialize code needs to be added to recover correct implementation. Make sure that the expansion process is performed as needed. See the specifications.py file.

The intent is that deployment/ROS/testing/rbtScene can run without the lines involving the variable rosbagfile because the string parameters were already processed when loaded.

In the future, you should consider understanding the code that you replace to make sure that no capabilities were lost.

[yiyeChen]

Got it. Will update the CfgNode class to do this.

[pv33]

1. Agreed that there will be a core components yaml file in default location.
2. There will be individual runtime configuration files in default location with override by specified file.

[yiyeChen]

Parameter passing updated in the commit e08a3feb4a734a3ddad027c83a9eae93a209e3e4. The Surveillence/utils/configs.py contains the unit test to demonstrate the functionalities.

[pv33]

@yiyeChen Question: There are now two default files. One for the core components, one for the runtime configuration.

If core components specifications are put in the runtime configuration yaml file, will these specifications override the core components? I have my own preferences for the background GMM. Trying to figure out if they build on each other or if they are separate/distinct.

[yiyeChen]

@pv33

Yes. You can put new configurations for any part of the system (for now, core or runtime) in your custom yaml file. It will override the defaults.

Every configuration files are loaded in a sequential manner. If the same key appears again then value will be overwritten, and if new key appears then new config is created in the CfgNode. The default files are also loaded in that way, but automatically by the classes. Custom configuration file will be the last one to load from the script, hence it will override existing default configurations regardless of the source.