lsst.ts.mthexapod

https://img.shields.io/badge/ProjectMetadata-gray.svg https://img.shields.io/badge/SAL Interface-gray.svg https://img.shields.io/badge/GitHub-gray.svg https://img.shields.io/badge/Jira-gray.svg

Overview

The MTHexapod CSC controls the camera and M2 hexapods on the Simonyi Survey Telescope. Run one instance of the CSC for each hexapod, using index=1 for the camera hexapod and index=2 for the M2 hexapod.

User Guide

Start an MTHexapod CSC as follows:

run_mthexapod.py <index>

where <index> is 1 for the camera hexapod, 2 for the M2 hexapod

Then check that the CSC has control of the low-level controller, as follows:

  • Wait for the connected event to report command=True and telemetry=True. This should happen quickly; if it does not then check that the low-level controller is fully booted up and configured to use the correct IP address for the CSC.

  • Check the controllerState event. If it is state=Offline, offline_substate=PublishOnly, which is the state the low-level controller wakes up in, then you must use the EUI to enable DDS mode.

  • Check the commandableByDDS event. If state=False then you must use the EUI to enable DDS mode.

To use a hexapod for observing:

  • Check that the CSC has control of the low-level controller, as just described.

  • Enable the CSC.

  • Enable compensation mode with the setCompensationMode command.

  • Move to x=0, y=0, z=0, u=0, v=0, w=0 with the move command.

  • Apply offsets, as required, to improve collimation with the offset command (or specify absolute position with the move command).

Compensation Mode

The CSC is capable of applying compensation (correction) for mechanical changes induced by changes in gravity and temperature, in order to preserve collimation. Each effect is modeled independently; the corrections are added together to get the total compensation offset. The inputs to the model are telescope target elevation and azimuth, camera rotator target angle, and temperature. The CSC uses target positions in order to give the hexapods more time to get in position during a slew. The coefficients for the compensation model are specified in the CSC configuration.

The CSC starts with compensation disabled. To enable compensation: issue the setCompensationMode command with enable=True. Compensation is disabled when:

  • A user commands setCompensationMode with enable=False. This will remove the current compensation offset, which will move the hexapod by a small amount.

  • The CSC leaves the enabled state. This will not remove the current compensation offset.

  • An error occurs in the compensation loop. This will not remove the current compensation offset.

The move command specifies the uncompensated (aka nominal) position. Thus the specified position should produce (approximately) the same effect on collimation, regardless of the current telescope elevation, temperature, etc. If you wish to move the hexapod to a give mechanical position (with reproducible hexapod strut lengths), disable compensation before you command the move.

The compensated (aka corrected) position is the position sent to the low-level controller. If compensation is enabled but the CSC does not yet have all the inputs it needs for the compensation model (e.g. telescope target position or rotator target position), it will issue one warning logMessage event and keep trying. When all compensation inputs are available, compensation corrections will begin.

The compensation will continue to be updated in the background for changes in elevation, temperature, etc. In order to reduce heat generation in the hexapod, the configuration parameter min_compensation_adjustment specifies the smallest compensation offset the background compensation task will command. Compensation is only updated if abs(new_compensation_offset - current_compensation_offset) >= min_compensation_adjustment in any axis. Note that min_compensation_adjustment does not affect the move, offset, and setCompensationMode commands; these commands always apply compensation if compensation mode is enabled. Thus you can force a compensation update by issuing an offset command with x, y, z, u, v, and w all zero.

Relevant events:

  • uncompensatedPosition: the position commanded by the user. This event is output once in response to a move or offset command.

  • compensatedPosition: the compensated (corrected) position; the position sent to the low-level controller. This event is output once in response to a move or offset command and (if compensation is enabled) once each time the compensation loop applies a correction. This will match the uncompensated position if compensation is disabled or cannot be computed. In order to compute compensation a move must have been commanded since the MTHexapod CSC was started, and all inputs to the compensation model must have been published by the appropriate CSCs. Thus failure to compute a compensation correction is only likely when MTHexapod, or any of the CSCs that generate compensation inputs, have first been brought up.

  • compensation: inputs to the compensation model and the resulting compensation offset. Output when compensation is applied.

Configuration

Configuration is specified in ts_config_mttcs following this schema. The most important settings are:

Notes

  • To recover from the FAULT state (after fixing whatever is wrong) issue the clearError command. This will transition to the STANDBY state.

  • The low-level controller maintains the CSC summary state, so the CSC reports a summary state of OFFLINE until it receives telemetry from the low-level controller. Thus the CSC may transition from OFFLINE to almost any other state as it starts up.

  • Communication between the low-level controller and CSC is quite unusual:

    • The low-level controller connects to a TCP/IP server in the CSC. Thus the low-level controller must be configured with the TCP/IP address of the CSC.

    • The low-level controller does not acknowledge commands in any way. Thus the CSC must try to predict whether the low-level controller can execute a command and reject the command if not. Unfortunately this prediction cannot be completely accurate.

    • The connection uses two separate sockets, one for commands and the other for telemetry and configuration. Both are one-directional: the low-level controller reads commands on the command socket and writes configuration and telemetry to the telemetry socket.

Simulator

The CSC includes a simulation mode. To run using CSC’s internal simulator:

run_mthexapod.py <index> --simulate

Enable With the EUI

The control mode must be DDS in order for the CSC to control the low-level controller. If the control mode is GUI then you can use the EUI (aka GUI) to change it to DDS as follows:

  • In the main panel: change the state to state=Offline, offline_substate=Available.

  • Go to the Parameters panel to change the control mode to DDS.

Notes:

  • The EUI shows the control mode on the main panel, but that display is read-only. You must use the Parameters panel to change the control mode.

  • If you issue any hexapod command in the EUI, control mode will switch back to GUI. So if you want the CSC to retain control, please be careful what you touch when using the GUI.

Developer Guide

Version History