The XML for Rotator and Hexapod has some misfeatures I would like to fix if and when we are sure that we are writing our own CSCs. (Actually we could easily fix these even if we keep the vendor's code):

• The Hexapod inPosition event has no inPosition field, so there is no way to indicate "not in position". Note that the Rotator inPosition event is fine. I suggest also adding an array of 6 booleans to indicate if each actuator is in position, perhaps named actuatorInPosition.
• The Rotator tracking and trackLost events have no boolean value so cannot be output properly. They should be combined into a single event with a boolean flag.
• Some telemetry is not output. I will not output them yet, but keep them in mind for the future, should we decide we need them:
  • copley_fault_status_register; note that similar latching registers are output.
  • input_pin_states
• Several events are sent only when something (such as tracking, or a problem) starts, but not when it ends. We should send the event when the condition starts and when it ends, with suitable data (e.g. a boolean that is true if the condition is present).
• Most events and telemetry topics have a timestamp field. That is a waste of space because it duplicates private_sndStamp.
• The telemetry topic names are capitalized and so do not meet our current standards.

These are at least partly fixed in DM-21694:

• There is no detailed state event, even though that state is crucial for these CSCs. Fixed in DM-21694 by adding the controllerState event.
• The deviceError event has a code field that is a string, and as implemented by the vendor, that "code" describes a single error so the event is output once for each error condition that is present. In DM-21694 I improved this by adding an applicationStatus field to the new controllerState event that has the bit mask. In addition I output deviceError once for a given set of error conditions, with code set to a comma-separated list of descriptions of each error so the event only when the error conditions change. I hope we can get rid of the deviceError event as duplicated information, even though a string can be nice.

This task will also clean up the Jira tickets:

(1) DM-20969 and DM-20971 for the telemetry.

(2) CAP-362 and CAP-369 for the event.