Fix Version/s: None
Sprint:TSSW Sprint - Aug 3 - Aug 17, TSSW Sprint - Aug 17 - Aug 31
Team:Telescope and Site
The Rotator low-level controller will output velocity information as of
DM-25994. Update the Rotator CSC accordingly.
- https://github.com/lsst-ts/ts_xml/pull/351 (merged)
- https://github.com/lsst-ts/ts_xml/pull/355 (add timestamp field, follows earlier merged pull request)
All changes look good to me. The unit tests of ts_rotator are failing because of
AttributeError: 'Rotator_rotation_2371acfc' object has no attribute 'timestamp'
which I though the Jenkinsfile shoujld be able to resolve if the changes to the code and ts_xml are done in the same branch as is the case with this change. In any case, as soon as the changes get merged into develop, these errors should disappear.
The unit test failure was probably a sequencing issue – I may have pushed the ts_xml changes after the ts_hexapod and ts_rotator changes. I was able to git commit --amend and git push --force ts_hexapod and ts_rotator and then the tests passed. (Actually that failed the first time but deleting the ts_idl branch and reopening it and then repeating the amend/force push did finally make them pass. I have no idea what that was all about.)
Merged all code to develop.
Released ts_idl v1.4.0
I cannot release new versions of ts_hexapod and ts_rotator until ts_xml 6.1 is released.
DM-26416 to track this.
Changes to the C structs (see https://github.com/lsst-ts/ts_rotator_controller/pull/9):
ddsTelemetryStreamStructure_t is the only C struct used for TCP/IP communications that changed. The changes are as follows:
The other thing that is wanted is a combined actual velocity computed from ChA_RateFb and ChB_RateFb. It is not completely obvious how to compute this, but based on Te-Wei Tsai's graphs in
DM-25994(especially the last graph) it looks like some filtering to reduce noise would be helpful. The measured velocity is oddly different than the demand velocity at low speeds, with a weird jump. I fear we may be stuck with that since at some level we have to trust the encoders (though I believe the encoders are on the two linear actuators, so there is some math in the low-level controller to convert those readings to rotation). I wonder if that jump might indicate hysteresis in the connection between the linear actuators and the rotator.
One other small change I made was to fix the spelling of SAFETY in an enum in the Rotator and Hexapod XML and the corresponding enums in ts_idl. The old misspelled names also work, for now. I filed
DM-26367to get rid of the misspelled versions later.