Create telemetry sub-folders in "iCub Telemetry" dictionary
Closed this issue · 5 comments
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 .
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.
- => most probably, here we should directly check the
- 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.
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).
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 becomeIMUsens.legacyIMU
, considering the objects path [icubtelemetry
dictionary root -> folderIMUsens
-> telemetry entrylegacyIMU
] resulting in the structure pathicubtelemetry.compposition.IMUsens.composition.legacyIMU
and the finalidentifier.key
to beicubtelemetry.IMUsens.legacyIMU
1.- the same way,
sens.rightArmJointState
would becomeicubtelemetry.encoders.rightArmJointState
.
Footnotes
-
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. theservers.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. ↩
Implementation Steps
Dictionaries
- Some refactoring for allowing following steps.
- Introduce a "type" field in the dictionaries.
- Introduce folders where needed.
Object Provider
- Some refactoring for allowing following steps.
- Once the input domain object identifier is matched with an element in the dictionary:
- We check the respective "type".
- Depending on this type, we build a folder or a telemetry domain object to return to Open MCT API.
- Set as
identifier.key
of the returned domain object the key path to the respective parameter block starting from the dictionary root.
- Minor improvements:
Use the class=> not an option anymore since, after the refactoring we only use a single namespace for all the dictionaries: YARPOPENMCT_DICTIONARY_PLUGIN_NAMESPACE.ObjectProvider
instantiation to perform namespace dependent processing, avoiding additional conditional branching.- The existing conditional branching in the
getDictionary
function should be keep because thecompositionProvider
is not associated to a particular namespace.
Composition Provider
- Some refactoring for allowing following steps.
- Use the input domain object identifier key to locate the matching element in the dictionary for which the composition was requested.
- Build the list of identifiers under that element.
Implemented in #149 .