Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-36872

MT rotator TRACK enabled substate command reports done before the rotator is ready to receive TRACK_VEL_CMD commands

    XMLWordPrintable

    Details

      Description

      The low-level MT rotator controller reports the TRACK enabled substate command as finished before the rotator is actually in the right state to receive TRACK_VEL_CMD commands.

      Also please consider increasing the time limit between then the rotator goes to "tracking" enabled substate, and when the first tracking command arrives.

      Once a tracking command arrives, it is important to keep sending them. But until the first tracking command arrives, the system is not moving, and so I would argue is not doing anything risky. We can afford to allow the client to wait a few seconds.

      I mention this because I tried to work around this bug by adding a 0.5 second delay after sending TRACK enabled substate command, and before sending the first TRACK_VEL_CMD. That caused the system to fault. I ended up using a 0.1 second delay, but it feels to me like the window of allowed sleep times for working around this bug is too small.

        Attachments

          Issue Links

            Activity

            Hide
            ttsai Te-Wei Tsai added a comment -

            Russell Owen, the delay time was requested to be hard-coded to be 0.25 second (5 lost tracking commands) at DM-25245. What is the time do you want now? Another option is to put it into the configuration file. Which way do you prefer?

            Show
            ttsai Te-Wei Tsai added a comment - Russell Owen , the delay time was requested to be hard-coded to be 0.25 second (5 lost tracking commands) at DM-25245 . What is the time do you want now? Another option is to put it into the configuration file. Which way do you prefer?
            Hide
            rowen Russell Owen added a comment -

            I suggest an initial delay (before the first tracking command arrives) of 5 second, preferably configurable. This delay is not important for safety because the rotator is not moving.

            Tracking commands may come as slowly as 10 Hz, so I suggest the maximum delay between tracking tracking commands be 0.5 seconds – though again, being configurable is useful. I hope the rotator extrapolates the last tracking command if the next one does not arrive in time (until the timer expires and the rotator faults and halts).

            Show
            rowen Russell Owen added a comment - I suggest an initial delay (before the first tracking command arrives) of 5 second, preferably configurable. This delay is not important for safety because the rotator is not moving. Tracking commands may come as slowly as 10 Hz, so I suggest the maximum delay between tracking tracking commands be 0.5 seconds – though again, being configurable is useful. I hope the rotator extrapolates the last tracking command if the next one does not arrive in time (until the timer expires and the rotator faults and halts).
            Hide
            ttsai Te-Wei Tsai added a comment -

            For the "rotator extrapolation" part, this will need to modify the MATLAB trajectory libraries by Tekniker.

            Show
            ttsai Te-Wei Tsai added a comment - For the "rotator extrapolation" part, this will need to modify the MATLAB trajectory libraries by Tekniker.
            Show
            ttsai Te-Wei Tsai added a comment - Please help to review the PRs: 1. https://github.com/lsst-ts/ts_mt_hexRot_simulink/pull/42 2. https://github.com/lsst-ts/ts_rotator_controller/pull/45 Thanks!
            Hide
            rowen Russell Owen added a comment -

            Your comment about the trajectory libraries surprises me a bit, because the TMA azimuth, elevation, and camera cable wrap are all willing to extrapolate the last position. But that's a different ticket and perhaps not needed.

            Show
            rowen Russell Owen added a comment - Your comment about the trajectory libraries surprises me a bit, because the TMA azimuth, elevation, and camera cable wrap are all willing to extrapolate the last position. But that's a different ticket and perhaps not needed.
            Hide
            rowen Russell Owen added a comment -

            Reviewed on github

            Show
            rowen Russell Owen added a comment - Reviewed on github

              People

              Assignee:
              ttsai Te-Wei Tsai
              Reporter:
              rowen Russell Owen
              Reviewers:
              Russell Owen
              Watchers:
              Russell Owen, Te-Wei Tsai
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Jenkins

                  No builds found.