Fix Version/s: None
Sprint:TSSW Sprint - Nov 9 - Nov 23
Team:Telescope and Site
The main issue is that the application telemetry topic should report the generated path in its demand field, but when used in simulation mode it is reporting the target. Update the mock controller to fix this and rename the telemetry fields to clarify what's going on.
Also the ts_mtrotator commander shows a constants stream of rotation telemetry, at least when using simulation mode. The issue is that it includes a timestamp field, so the default filtering for tiny changes is not sufficient. Ignore the timestamp field when comparing old values to new values.
CAP-659 T&S catch-all for XML 7.1
Here is the full review, before my changes to hexrotcomm:
1. Maybe add the doc string to format_dict() to explain the formated style:
2. What is the data type of "data" in _special_telemetry_callback()? Object?
3. Maybe you could add the doc string of "data", which is a input of this tel_motors_callback():
4. Maybe you could add the doc string of "data", which is a input of this tel_rotation_callback():
1. Just want to make sure you rememeber the followings are the names in rotator PXI:
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?
Thank you for a helpful review.
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.
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.
- ts_hexrotcomm v0.12.0
- ts_mthexapod v0.11.0
- ts_mtrotator v0.10.0
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.