Create telemetry sub-folders in "iCub Telemetry" dictionary

[nunoguedelha]

The "iCubTelemetry" folder in the visualiser left pane has a long list of telemetry domain entries which make the search for any of those somewhat inefficient and difficult. This should be easily solved by grouping the entries in modalities adding some sub-folders.

Implemented in #149 .

[nunoguedelha]

After an initial analysis, we see that in order to freely add folders in the telemetry dictionaries, some refactoring of the dictionary-plugin, more precisely the implementation of the Object and Composition Providers refer to the API documentation:

• The composition provider only returns the array of identifiers directly under the dictionary root level (telemetryEntries field)
  • => there should be a search of identifiers based on a relative path under the input domain object for which the composition is requested.
  • => either we do a raw search of the domain object in the dictionary, either we use the namespace for locating it directly in the dictionary. this requires changing how we set the namespaces returned in the composition array of identifiers.
• The Object Provider builds either a folder domain object either a telemetry domain object, depending on the identifier key of the requested domain object, i.e. if the key matches the dictionary's, a folder domain object is built and returned.
  • => most probably, here we should directly check the type of the dictionary elements, which needs to be introduced.
• less critical improvements could be done in the Object Provider definition using smartly the instantiation of the respective class ObjectProvider in order to avoid some conditional branching within its implementation.

[nunoguedelha]

On the composition provider...

• either we use the namespace for locating it directly in the dictionary. this requires changing how we set the namespaces returned in the composition array of identifiers.

Actually this would compromise the current mapping used for selecting the dictionary depending on the namespace => we would have to parse the namespace, for instance keep the initial segment, for using it in the mapping.

Probably the best is to build a mapping [identifier -> path-in-the-dictionary-to-the-domain-object-properties-block] and leave the namespace intact.

On the ObjectProvider specificities w.r.t. the dictionary/namespace

In addition to use the class instantiation to select the processing depending on the namespace, the prior branching in the getDictionary function should be keep because the compositionProvider is not associated to a particular namespace (unfortunately).

[nunoguedelha]

Probably the best is to build a mapping [identifier -> path-in-the-dictionary-to-the-domain-object-properties-block]

A simple alternative, with the same effect and much less processing would be to set as identifier.key of a domain object the key path to the respective parameter block starting from the dictionary root. E.g:

• sens.legacyIMU key would become IMUsens.legacyIMU, considering the objects path [icubtelemetry dictionary root -> folder IMUsens -> telemetry entry legacyIMU] resulting in the structure path icubtelemetry.compposition.IMUsens.composition.legacyIMU and the final identifier.key to be icubtelemetry.IMUsens.legacyIMU[^1].
• the same way, sens.rightArmJointState would become icubtelemetry.encoders.rightArmJointState.

[^1]: We could omit icubtelemetry since it is unequivocally associated to the namespace, but we shall keep it since the namespace is not exchanged with the telemetry server (i.e. the servers.json config file). In addition, all the signal keys received through the websocket need to be unique, so all the identifier keys of the telemetry objects passed to the Open MCT API need to be unique whatever the dictionary.

[nunoguedelha]

Implementation Steps

Dictionaries

• [x] Some refactoring for allowing following steps.
• [x] Introduce a "type" field in the dictionaries.
• [x] Introduce folders where needed.

Object Provider

• [x] Some refactoring for allowing following steps.
• [x] Once the input domain object identifier is matched with an element in the dictionary:
  • [x] We check the respective "type".
  • [x] Depending on this type, we build a folder or a telemetry domain object to return to Open MCT API.
  • [x] Set as identifier.key of the returned domain object the key path to the respective parameter block starting from the dictionary root.
• [x] Minor improvements:
  • ~Use the class ObjectProvider instantiation to perform namespace dependent processing, avoiding additional conditional branching.~ => not an option anymore since, after the refactoring we only use a single namespace for all the dictionaries: YARPOPENMCT_DICTIONARY_PLUGIN_NAMESPACE.
  • [x] The existing conditional branching in the getDictionary function should be keep because the compositionProvider is not associated to a particular namespace.

Composition Provider

• [x] Some refactoring for allowing following steps.
• [x] Use the input domain object identifier key to locate the matching element in the dictionary for which the composition was requested.
• [x] Build the list of identifiers under that element.

[nunoguedelha]

Implemented in #149 .