Closed nunoguedelha closed 2 years ago
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:
telemetryEntries
field)
namespace
for locating it directly in the dictionary. this requires changing how we set the namespaces returned in the composition array of identifiers.type
of the dictionary elements, which needs to be introduced.ObjectProvider
in order to avoid some conditional branching within its implementation.
- 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.
ObjectProvider
specificities w.r.t. the dictionary/namespaceIn 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).
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].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.
identifier.key
of the returned domain object the key path to the respective parameter block starting from the dictionary root.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.getDictionary
function should be keep because the compositionProvider
is not associated to a particular namespace.Implemented in #149 .
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 .