I decided to also fix an issue with the mock controller: the time at which telemetry was computed did not quite match the timestamp in the telemetry header. This gives more accurate results and allows pickier unit tests.

Pull requests:

• https://github.com/lsst-ts/ts_hexrotcomm/pull/26
• https://github.com/lsst-ts/ts_mthexapod/pull/30
• https://github.com/lsst-ts/ts_mtrotator/pull/27
• https://github.com/lsst-ts/ts_xml/pull/390

The update looks good and the simulator's change is great!

Here is the full review, before my changes to hexrotcomm:

[rotator_commander.py]

1. Maybe add the doc string to format_dict() to explain the formated style:

https://github.com/lsst-ts/ts_mtrotator/pull/27/files?file-filters%5B%5D=.py#diff-0cd527a84bd148fd208dde64caff158f7272e94b88c646f3215bfd083743b149R65

2. What is the data type of "data" in _special_telemetry_callback()? Object?

https://github.com/lsst-ts/ts_mtrotator/pull/27/files?file-filters%5B%5D=.py#diff0cd527a84bd148fd208dde64caff158f7272e94b88c646f3215bfd083743b149R74

3. Maybe you could add the doc string of "data", which is a input of this tel_motors_callback():

https://github.com/lsst-ts/ts_mtrotator/pull/27/files?file-filters%5B%5D=.py#diff-0cd527a84bd148fd208dde64caff158f7272e94b88c646f3215bfd083743b149R90-R92

4. Maybe you could add the doc string of "data", which is a input of this tel_rotation_callback():

https://github.com/lsst-ts/ts_mtrotator/pull/27/files?file-filters%5B%5D=.py#diff-0cd527a84bd148fd208dde64caff158f7272e94b88c646f3215bfd083743b149R95-R97

[structs.py]

1. Just want to make sure you rememeber the followings are the names in rotator PXI:

CSC: https://github.com/lsst-ts/ts_mtrotator/pull/27/files?file-filters%5B%5D=.py#diff-cd5573f59d43fc8f71b4df4cc00afe65dda95449b18bb90817486380ae3ba2b0R64-R66
PXI: https://github.com/lsst-ts/ts_rotator_controller/blob/master/include/interface/telemetryStructure.h#L139-L149
You can see the PXI part has the "Cmd" word. Maybe you could explain the "demand" in CSC is the "Cmd" in PXI for the future's developer to understand?

My response:

Thank you for a helpful review.

[rotator_commander.py]

1: I have added more documentation, though not a full description because most of the formatting is handled by a different method.

2, 3, and 4: Excellent point. The problem is that these data arguments are DDS message types, which have no common base class. However, I have tried to expand the information as I could.

[structs.py]

1: An excellent suggestion. I have added several code comments explaining some of the fields, including the demand fields and pos_set.

I will note that I try to avoid the word "command" when talking about tracking because I find it hard to tell if that means the position the user commanded or the position the path generator wants. I try to stick to "target": the path or position the user has commanded and "demand": the path the path generator is trying to follow to get to the target.

Released:

• ts_hexrotcomm v0.12.0
• ts_mthexapod v0.11.0
• ts_mtrotator v0.10.0