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

Please refine the MT hexapod low-level commands

    XMLWordPrintable

    Details

      Description

      The current low-level MT hexapod controller has a few issues that I would love to have cleaned up, if you can find the time:

      • Commanding a motion requires two separate commands: SET_POSITION followed by MOVE (and something similar for offsets). This introduces a potential race condition if two users are trying to command the hexapod. It is also a nuisance. I believe it was originally chosen because of the MOVE_LUT command, but we don't use that anymore.
      • Remove the unused MOVE_LUT command and any associated code that is easy to pull out. That includes removing the LUT tables and no longer reporting the LUT values in the configuration (making the configuration data much shorter).

      Please also also consider removing the offset command. The CSC isn't using it (it supports offsets, but implements them by commanding absolute moves).

      The hexapod EUI will be affected by this ticket and need to do the related modification.

        Attachments

          Issue Links

          is triggering

          Story - Created by Jira Software - do not edit or delete. Issue type for a user story. DM-29664 Update the Hexapod CSC for DM-29577

          • Won't Fix

          Story - Created by Jira Software - do not edit or delete. Issue type for a user story. DM-29720 Support the Command Queue in Low-Level Hexapod Controller

          • Invalid
          relates to

          Story - Created by Jira Software - do not edit or delete. Issue type for a user story. DM-29578 Please improve TCP/IP communications for the MT rotator and hexapod low-level controllers

          • Done

          Story - Created by Jira Software - do not edit or delete. Issue type for a user story. DM-29769 Update MTHexapod and MTRotator for changes to the low-level controllers

          • Done

            Activity

            Ascending order - Click to sort in descending order
            Hide
            Permalink
            ttsai Te-Wei Tsai added a comment - - edited

            Removed the hexapod LUT in Simulink model.
            Removed the moveLUT in commanding.c.
            Removed the LUT related items in ddsConfigTelemetryStreamStructure_t. This triggers the DM-29664.
            Remove the "LUT invalid" in the application status of EUI.

            Show
            ttsai Te-Wei Tsai added a comment - - edited Removed the hexapod LUT in Simulink model. Removed the moveLUT  in commanding.c . Removed the LUT related items in ddsConfigTelemetryStreamStructure_t . This triggers the DM-29664 . Remove the "LUT invalid" in the application status of EUI.
            Hide
            Permalink
            rowen Russell Owen added a comment - - edited

            Wonderful. As far as the MOVE command goes: making it a single command may require a bit of subtlety because of the "sync" flag. Commands only support 6 parameters (other than the command code) and we need all six for x, y, z, u, v, w. Two ways out of this are:

            • Have separate commands for "synchronized move" vs "non-synchronized move". This doesn't scale well if there are many move commands, but might be acceptable for one (move only) or two (move and offset). It is probably the simpler solution. If it's OK with you, I suggest it.
            • Add a command parameter. I have no idea how invasive that would be. Does it matter if the command format is different for the hexapods than for the rotator?
            Show
            rowen Russell Owen added a comment - - edited Wonderful. As far as the MOVE command goes: making it a single command may require a bit of subtlety because of the "sync" flag. Commands only support 6 parameters (other than the command code) and we need all six for x, y, z, u, v, w. Two ways out of this are: Have separate commands for "synchronized move" vs "non-synchronized move". This doesn't scale well if there are many move commands, but might be acceptable for one (move only) or two (move and offset). It is probably the simpler solution. If it's OK with you, I suggest it. Add a command parameter. I have no idea how invasive that would be. Does it matter if the command format is different for the hexapods than for the rotator?
            Hide
            Permalink
            ttsai Te-Wei Tsai added a comment -

            Refactor the EUI for the command.

            Show
            ttsai Te-Wei Tsai added a comment - Refactor the EUI for the command.
            Hide
            Permalink
            ttsai Te-Wei Tsai added a comment -

            Based on the EUI code, I realized it might not be a good idea to combine the POSITION_SET and MOVE. The first thing is that this is inconsistent with the design of Simulink model. In addition, the EUI needs to support the moves of hexapod position (x, y, z, rx, ry, rz) and raw position (distance for each actuator). The above two movements have the synchronic and asynchronic movements. In EUI's viewpoint, it is easier to separate these two commands.

            Show
            ttsai Te-Wei Tsai added a comment - Based on the EUI code, I realized it might not be a good idea to combine the POSITION_SET  and MOVE . The first thing is that this is inconsistent with the design of Simulink model. In addition, the EUI needs to support the moves of hexapod position (x, y, z, rx, ry, rz) and raw position (distance for each actuator). The above two movements have the synchronic and asynchronic movements. In EUI's viewpoint, it is easier to separate these two commands.
            Hide
            Permalink
            ttsai Te-Wei Tsai added a comment - - edited

            For the possible race condition (although there should be no two users to command the hexapod in the same time), this will be fixed after I rewrite the low-level controller to support the queue of command (DM-29720).

            Show
            ttsai Te-Wei Tsai added a comment - - edited For the possible race condition (although there should be no two users to command the hexapod in the same time), this will be fixed after I rewrite the low-level controller to support the queue of command ( DM-29720 ).
            Hide
            Permalink
            ttsai Te-Wei Tsai added a comment -

            Please help to review the PRs:
            1. https://github.com/lsst-ts/ts_hexapod_controller/pull/9
            2. https://github.com/lsst-ts/ts_hexapod_gui/pull/5
            3. https://github.com/lsst-ts/ts_mt_hexRot_simulink/pull/14

            Thanks!

            Show
            ttsai Te-Wei Tsai added a comment - Please help to review the PRs: 1. https://github.com/lsst-ts/ts_hexapod_controller/pull/9 2. https://github.com/lsst-ts/ts_hexapod_gui/pull/5 3. https://github.com/lsst-ts/ts_mt_hexRot_simulink/pull/14 Thanks!
            Hide
            Permalink
            rowen Russell Owen added a comment -

            Looks great! Thank you for doing this.

            Show
            rowen Russell Owen added a comment - Looks great! Thank you for doing this.

              People

              Assignee:
              ttsai Te-Wei Tsai
              Reporter:
              rowen Russell Owen
              Reviewers:
              Russell Owen
              Watchers:
              Bo Xin [X] (Inactive), Russell Owen, Te-Wei Tsai, Tiago Ribeiro
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Start date:
                End date:

                  Jenkins

                  No builds found.