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

Remove azimuthDirection from the target event

    XMLWordPrintable

Details

    Description

      We have agreed to remove the azimuthDirection field from trackTarget command of ATMCS and make the azimuth and rotator angles absolute in TPC-163. This ticket is to update the XML and the ATMCS Simulator.

      The ATMCS will also have to be updated.

      One question: which is indirectly related:

      • Should the azimuthCalculatedAngle field of the mountEncoders event be in the range 0, 360 or -270 to 270? We should make sure that the XML has the correct information.

      MTPtg and MTMount should probably get the same treatment, but on a different ticket. Whether we actually do it depends on what the MTMount vendor says (they may have already coded it this way!).

      Attachments

        Issue Links

          Activity

            No builds found.
            rowen Russell Owen created issue -
            rowen Russell Owen made changes -
            Field Original Value New Value
            Description I believe we have agreed to remove the azimuthDirection field from ATMCS and MTMCS (though I am not positive about the latter). This is intended to reduce confusion. The field is completely unnecessary because the azimuth itself can contain the wrap, e.g it can be in the range -270 to 270 and indeed the pointing component is likely computing it like that and then converting it to the present two fields.

            Before we do this we need to be sure the MCS vendors and pointing component vendors are on board. I suspect this will be easy for ATMCS but I have no idea about MTMCS. I will wait to start on this work until I get a firm go ahead from [~tribeiro]

            This ticket is for the following:
            * Remove the azimuthDirection field from the ATMCS and MTMCS XML (which is trivial)
            * Update the ATMCS simulator

            A broader Epic should include updating the ATMCS, ATPtg, MTMCS and MTPtg.

            One question: which is indirectly related:
            * Should the azimuthCalculatedAngle field of the mountEncoders event be in the range 0, 360 or -270 to 270? We should make sure that the XML has the correct information.
            I believe we have agreed to remove the {{azimuthDirection}} field from {{trackTarget}} command of ATMCS and MTMCS. This is intended to reduce confusion. The field is completely unnecessary because the azimuth itself can contain the wrap, e.g it can be in the range -270 to 270 and indeed the pointing component is almost certainly computing it that way internally before splitting it into azimuth and azimuthDirection components.

            Before we do this we need to be sure the MCS vendors and pointing component vendors are on board. I will wait to start on this work until I get a firm go ahead from [~tribeiro] or [~pingraham]

            This ticket is for the following:
            * Remove the azimuthDirection field from the ATMCS and MTMCS XML (which is trivial)
            * Update the ATMCS simulator

            A broader Epic should include updating the ATMCS, ATPtg, MTMCS and MTPtg.

            One question: which is indirectly related:
            * Should the azimuthCalculatedAngle field of the mountEncoders event be in the range 0, 360 or -270 to 270? We should make sure that the XML has the correct information.
            rowen Russell Owen made changes -
            Link This issue relates to DM-17909 [ DM-17909 ]
            rowen Russell Owen made changes -
            Epic Link DM-16920 [ 238253 ]
            rowen Russell Owen made changes -
            Sprint TSSW Sprint - Mar 04 - Mar 16 [ 847 ]
            rowen Russell Owen made changes -
            Status To Do [ 10001 ] In Progress [ 3 ]
            rowen Russell Owen made changes -
            Description I believe we have agreed to remove the {{azimuthDirection}} field from {{trackTarget}} command of ATMCS and MTMCS. This is intended to reduce confusion. The field is completely unnecessary because the azimuth itself can contain the wrap, e.g it can be in the range -270 to 270 and indeed the pointing component is almost certainly computing it that way internally before splitting it into azimuth and azimuthDirection components.

            Before we do this we need to be sure the MCS vendors and pointing component vendors are on board. I will wait to start on this work until I get a firm go ahead from [~tribeiro] or [~pingraham]

            This ticket is for the following:
            * Remove the azimuthDirection field from the ATMCS and MTMCS XML (which is trivial)
            * Update the ATMCS simulator

            A broader Epic should include updating the ATMCS, ATPtg, MTMCS and MTPtg.

            One question: which is indirectly related:
            * Should the azimuthCalculatedAngle field of the mountEncoders event be in the range 0, 360 or -270 to 270? We should make sure that the XML has the correct information.
            I believe we have agreed to remove the {{azimuthDirection}} field from {{trackTarget}} command of ATMCS and the corresponding {{cablewrap_orientation}} field from the {{trackTarget}} command of MTMount. This is intended to reduce confusion. The field is completely unnecessary because the azimuth itself can contain the wrap, e.g it can be in the range -270 to 270 and indeed the pointing component is almost certainly computing it that way internally before splitting it into azimuth and azimuthDirection components.

            Before we do this we need to be sure the MCS vendors and pointing component vendors are on board. I will wait to start on this work until I get a firm go ahead from [~tribeiro] or [~pingraham]

            This ticket is for the following:
            * Remove the azimuthDirection field from the ATMCS and MTMCS XML (which is trivial)
            * Update the ATMCS simulator

            A broader Epic should include updating the ATMCS, ATPtg, MTMCS and MTPtg.

            One question: which is indirectly related:
            * Should the azimuthCalculatedAngle field of the mountEncoders event be in the range 0, 360 or -270 to 270? We should make sure that the XML has the correct information.
            rowen Russell Owen made changes -
            Description I believe we have agreed to remove the {{azimuthDirection}} field from {{trackTarget}} command of ATMCS and the corresponding {{cablewrap_orientation}} field from the {{trackTarget}} command of MTMount. This is intended to reduce confusion. The field is completely unnecessary because the azimuth itself can contain the wrap, e.g it can be in the range -270 to 270 and indeed the pointing component is almost certainly computing it that way internally before splitting it into azimuth and azimuthDirection components.

            Before we do this we need to be sure the MCS vendors and pointing component vendors are on board. I will wait to start on this work until I get a firm go ahead from [~tribeiro] or [~pingraham]

            This ticket is for the following:
            * Remove the azimuthDirection field from the ATMCS and MTMCS XML (which is trivial)
            * Update the ATMCS simulator

            A broader Epic should include updating the ATMCS, ATPtg, MTMCS and MTPtg.

            One question: which is indirectly related:
            * Should the azimuthCalculatedAngle field of the mountEncoders event be in the range 0, 360 or -270 to 270? We should make sure that the XML has the correct information.
            I believe we have agreed to remove the {{azimuthDirection}} field from {{trackTarget}} command of ATMCS and the corresponding {{cablewrap_orientation}} field from the {{trackTarget}} command of MTMount. This is intended to reduce confusion. The field is completely unnecessary because the azimuth itself can contain the wrap, e.g it can be in the range -270 to 270 and indeed the pointing component is almost certainly computing it that way internally before splitting it into azimuth and azimuthDirection components.

            Before we do this we need to be sure the MCS vendors and pointing component vendors are on board. I will wait to start on this work until I get a firm go ahead from [~tribeiro] or [~pingraham]

            This ticket is for the following:
            * Remove the {{azimuthDirection}} field from the ATMCS {{trackTarget}} command in ts_xml.
            * Remove the {{cablewrap_orientation}} field from the {{trackTarget}} command of MTMount in ts_xml.
            * Update the ATMCS simulator

            A broader Epic should include updating the ATMCS, ATPtg, MTMount and MTPtg components.

            One question: which is indirectly related:
            * Should the azimuthCalculatedAngle field of the mountEncoders event be in the range 0, 360 or -270 to 270? We should make sure that the XML has the correct information.
            rowen Russell Owen added a comment - - edited

            I am dismayed by the extensive unnecessary differences between the ATMCS and MTMount XML. Given how expensive MTMount changes are I assume we will choose to live with most of them. But some seem unacceptable, for instance MTMount has no command to stop tracking (nor any command to stop motion).

            rowen Russell Owen added a comment - - edited I am dismayed by the extensive unnecessary differences between the ATMCS and MTMount XML. Given how expensive MTMount changes are I assume we will choose to live with most of them. But some seem unacceptable, for instance MTMount has no command to stop tracking (nor any command to stop motion).
            rowen Russell Owen added a comment - - edited
            rowen Russell Owen added a comment - - edited ts_xml pull request: https://github.com/lsst-ts/ts_xml/pull/72 ts_ATMCSSimulator pull request: https://github.com/lsst-ts/ts_ATMCSSimulator/pull/6
            tribeiro Tiago Ribeiro made changes -
            Remote Link This issue links to "Page (Confluence)" [ 19925 ]
            tribeiro Tiago Ribeiro made changes -
            Link This issue relates to TPC-163 [ TPC-163 ]
            rowen Russell Owen made changes -
            Description I believe we have agreed to remove the {{azimuthDirection}} field from {{trackTarget}} command of ATMCS and the corresponding {{cablewrap_orientation}} field from the {{trackTarget}} command of MTMount. This is intended to reduce confusion. The field is completely unnecessary because the azimuth itself can contain the wrap, e.g it can be in the range -270 to 270 and indeed the pointing component is almost certainly computing it that way internally before splitting it into azimuth and azimuthDirection components.

            Before we do this we need to be sure the MCS vendors and pointing component vendors are on board. I will wait to start on this work until I get a firm go ahead from [~tribeiro] or [~pingraham]

            This ticket is for the following:
            * Remove the {{azimuthDirection}} field from the ATMCS {{trackTarget}} command in ts_xml.
            * Remove the {{cablewrap_orientation}} field from the {{trackTarget}} command of MTMount in ts_xml.
            * Update the ATMCS simulator

            A broader Epic should include updating the ATMCS, ATPtg, MTMount and MTPtg components.

            One question: which is indirectly related:
            * Should the azimuthCalculatedAngle field of the mountEncoders event be in the range 0, 360 or -270 to 270? We should make sure that the XML has the correct information.
            We have agreed to remove the {{azimuthDirection}} field from {{trackTarget}} command of ATMCS and make the azimuth and rotator angles absolute in TPC-163. This ticket is to update the XML and the ATMCS Simulator.

            The ATMCS will also have to be updated.

            One question: which is indirectly related:
            * Should the azimuthCalculatedAngle field of the mountEncoders event be in the range 0, 360 or -270 to 270? We should make sure that the XML has the correct information.

            MTPtg and MTMount should probably get the same treatment, but on a different ticket. Whether we actually do it depends on what the MTMount vendor says (they may have already coded it this way!).
            rowen Russell Owen added a comment -

            I've implemented this. Please tell me when would be the best time to merge the ticket branches. The ts_ATMCSSimulator branch is needed to work with your tiagorib/ptkernel:new_xml container. However, I think the XML cannot be updated to work with that container (ATPtg isn't setting the field, but tiagorib/ptkernel:new_xml expects it to be there).

            rowen Russell Owen added a comment - I've implemented this. Please tell me when would be the best time to merge the ticket branches. The ts_ATMCSSimulator branch is needed to work with your tiagorib/ptkernel:new_xml container. However, I think the XML cannot be updated to work with that container (ATPtg isn't setting the field, but tiagorib/ptkernel:new_xml expects it to be there).
            rowen Russell Owen made changes -
            Reviewers Tiago Ribeiro [ tribeiro ]
            Status In Progress [ 3 ] In Review [ 10004 ]
            jbuffill James Buffill [X] (Inactive) made changes -
            Component/s ts_main_telescope [ 16710 ]
            jbuffill James Buffill [X] (Inactive) made changes -
            Team Alert Production [ 10300 ] Telescope and Site [ 13500 ]

            Reviewed code in GitHub.

            tribeiro Tiago Ribeiro added a comment - Reviewed code in GitHub.
            tribeiro Tiago Ribeiro made changes -
            Status In Review [ 10004 ] Reviewed [ 10101 ]
            jbuffill James Buffill [X] (Inactive) made changes -
            Resolution Done [ 10000 ]
            Status Reviewed [ 10101 ] Done [ 10002 ]
            rowen Russell Owen made changes -
            Resolution Done [ 10000 ]
            Status Done [ 10002 ] Reviewed [ 10101 ]
            rowen Russell Owen made changes -
            Comment [ Merged to develop. ]

            Merged ts_xml to develop.
            Merged ts_ATMCSSimulator to develop and master and released as v0.4.0.
            Served new ts_ATMCSSimulator docs to http://staff.washington.edu/rowen/ts_ATMCSSimulator/index.html

            rowen Russell Owen added a comment - Merged ts_xml to develop. Merged ts_ATMCSSimulator to develop and master and released as v0.4.0. Served new ts_ATMCSSimulator docs to http://staff.washington.edu/rowen/ts_ATMCSSimulator/index.html
            rowen Russell Owen made changes -
            Resolution Done [ 10000 ]
            Status Reviewed [ 10101 ] Done [ 10002 ]
            rowen Russell Owen made changes -
            Labels ts_ATMCSSimulator ts_xml ts_ATMCSSimulator ts_atmcssimulator ts_xml
            rowen Russell Owen made changes -
            Labels ts_ATMCSSimulator ts_atmcssimulator ts_xml ts_atmcssimulator ts_xml

            People

              rowen Russell Owen
              rowen Russell Owen
              Tiago Ribeiro
              Patrick Ingraham (Inactive), Rolando Cantarutti, Russell Owen, Tiago Ribeiro
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Jenkins

                  No builds found.