The vision configuration currently happens per plugin. This might lead to unwanted scenarios, e.g. if two plugins configured the same camera (type and ID match), but with different parameters. Depending on which plugin is loaded first the results might differ. Additionally the values for cameras are spread over multiple trees in the configuration.

To solve this problem, the base vision will become the central place where cameras are defined. These cameras get canonical names, which are then used by the plugins to open the camera. The base vision will define one configuration tree, where cameras are configured as a mapping of a canonical name (e.g. "nao") to a list of camera argument strings. Only this canonical name is then configured per plugin.

The configuration in the base vision should allow for different configurations of the same physical camera, only one being active at a time. This can happen by creating one configuration tree per physical camera, with sub-values with a second level of canonical names that actually define the camera argument strings. If there is more than one configuration an "active" value determines which configuration to use. A simple scenario where this might be useful is defining different camera parameters for different locations (e.g. different robot soccer fields) or times of the day (i.e. morning, afternoon etc.).