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

Fix the Following Error in the Rotator Simulink Model

    XMLWordPrintable

    Details

      Description

      Fix the following error in the rotator Simulink model. There is the problem of physical model in plant that the rotator's position will differ from the related position command gradually until the trigger of followingError (the difference >= threshold) and this stops the motion of rotator. According to the observation, this happens if the rotator moves in the negative direction.

      In the following figure, there are two targets: (1) position=1.2 deg and velocity=0.01 deg/sec and (2) position=1.5 deg and velocity=-0.01 deg/sec. The total simulation time is 20.1 sec. There is no big difference between the position command and position. The error of noNewTrackCmdError after the slew of the second target is triggered as expected.

      However, if the second target has position=-1.5 deg and velocity=-0.01 deg/sec, the following error is triggered while the rotator turns the direction to slew to the second target:

        Attachments

        1. 2016-06-01 LSST CDR - Control System Design and Analysis_1.pptx
          25.09 MB
        2. DahlModel.nb
          36 kB
        3. moveNegativePosition.png
          moveNegativePosition.png
          54 kB
        4. movePositivePosition.png
          movePositivePosition.png
          52 kB
        5. moveToNegativeFromNonZeroPoint.png
          moveToNegativeFromNonZeroPoint.png
          58 kB
        6. moveToNegativeFromNonZeroPointNoCoulombFriction.png
          moveToNegativeFromNonZeroPointNoCoulombFriction.png
          56 kB
        7. moveWithLowCoulombFriction.png
          moveWithLowCoulombFriction.png
          57 kB
        8. neg_slew_failed.jpg
          neg_slew_failed.jpg
          82 kB
        9. trackAdapNoNewTrackCmd.png
          trackAdapNoNewTrackCmd.png
          62 kB
        10. trackFollowingError.png
          trackFollowingError.png
          46 kB
        11. trackPosAndNegTargets.png
          trackPosAndNegTargets.png
          59 kB
        12. trackPosAndNegTargets2.png
          trackPosAndNegTargets2.png
          51 kB
        13. trackSolverAdap.png
          trackSolverAdap.png
          73 kB

          Issue Links

            Activity

            No builds found.
            ttsai Te-Wei Tsai created issue -
            ttsai Te-Wei Tsai made changes -
            Field Original Value New Value
            Epic Link DM-23800 [ 431613 ]
            ttsai Te-Wei Tsai made changes -
            Link This issue relates to DM-25249 [ DM-25249 ]
            ttsai Te-Wei Tsai made changes -
            Attachment trackFollowingError.png [ 44528 ]
            Attachment trackSolverAdap.png [ 44529 ]
            ttsai Te-Wei Tsai made changes -
            Attachment trackFollowingError.png [ 44528 ]
            ttsai Te-Wei Tsai made changes -
            Attachment trackAdapNoNewTrackCmd.png [ 44530 ]
            ttsai Te-Wei Tsai made changes -
            Description Fix the following error in the rotator Simulink model. Fix the following error in the rotator Simulink model. There is the problem of physical model in plant that the rotator's position will differ from the related position command gradually until the trigger of following error (the difference >= threshold) and stop the rotator. This happens if the rotator moves in the negative direction.

            In the following figure, there are two targets: (1) position=1.2 deg and velocity=0.01 deg/sec and (2) position=1.5 deg and velocity=-0.01 deg/sec. The total simulation time is 20.1 sec. There is no big difference between the position command and position.
            !trackAdapNoNewTrackCmd.png|thumbnail!

            However, if the second target is position=-1.5 deg and velocity=-0.01 deg/sec, the following error is triggered:
            !trackSolverAdap.png|thumbnail!
            ttsai Te-Wei Tsai made changes -
            Description Fix the following error in the rotator Simulink model. There is the problem of physical model in plant that the rotator's position will differ from the related position command gradually until the trigger of following error (the difference >= threshold) and stop the rotator. This happens if the rotator moves in the negative direction.

            In the following figure, there are two targets: (1) position=1.2 deg and velocity=0.01 deg/sec and (2) position=1.5 deg and velocity=-0.01 deg/sec. The total simulation time is 20.1 sec. There is no big difference between the position command and position.
            !trackAdapNoNewTrackCmd.png|thumbnail!

            However, if the second target is position=-1.5 deg and velocity=-0.01 deg/sec, the following error is triggered:
            !trackSolverAdap.png|thumbnail!
            Fix the following error in the rotator Simulink model. There is the problem of physical model in plant that the rotator's position will differ from the related position command gradually until the trigger of following error (the difference >= threshold) and stop the rotator. This happens if the rotator moves in the negative direction.

            In the following figure, there are two targets: (1) position=1.2 deg and velocity=0.01 deg/sec and (2) position=1.5 deg and velocity=-0.01 deg/sec. The total simulation time is 20.1 sec. There is no big difference between the position command and position. The error of *noNewTrackCmdError* is triggered as expected.
             !trackAdapNoNewTrackCmd.png|thumbnail!

            However, if the second target is position=-1.5 deg and velocity=-0.01 deg/sec, the following error is triggered:
             !trackSolverAdap.png|thumbnail!
            ttsai Te-Wei Tsai made changes -
            Description Fix the following error in the rotator Simulink model. There is the problem of physical model in plant that the rotator's position will differ from the related position command gradually until the trigger of following error (the difference >= threshold) and stop the rotator. This happens if the rotator moves in the negative direction.

            In the following figure, there are two targets: (1) position=1.2 deg and velocity=0.01 deg/sec and (2) position=1.5 deg and velocity=-0.01 deg/sec. The total simulation time is 20.1 sec. There is no big difference between the position command and position. The error of *noNewTrackCmdError* is triggered as expected.
             !trackAdapNoNewTrackCmd.png|thumbnail!

            However, if the second target is position=-1.5 deg and velocity=-0.01 deg/sec, the following error is triggered:
             !trackSolverAdap.png|thumbnail!
            Fix the following error in the rotator Simulink model. There is the problem of physical model in plant that the rotator's position will differ from the related position command gradually until the trigger of *followingError* (the difference >= threshold) and this stops the motion of rotator. According to the observation, this happens if the rotator moves in the negative direction.

            In the following figure, there are two targets: (1) position=1.2 deg and velocity=0.01 deg/sec and (2) position=1.5 deg and velocity=-0.01 deg/sec. The total simulation time is 20.1 sec. There is no big difference between the position command and position. The error of *noNewTrackCmdError* after the slew of the second target is triggered as expected.
             !trackAdapNoNewTrackCmd.png|thumbnail!

            However, if the second target has position=-1.5 deg and velocity=-0.01 deg/sec, the following error is triggered while the rotator turns the direction to slew to the second target:
             !trackSolverAdap.png|thumbnail!
            ttsai Te-Wei Tsai made changes -
            Epic Link DM-23800 [ 431613 ] DM-25674 [ 436565 ]
            ttsai Te-Wei Tsai made changes -
            Epic Link DM-25674 [ 436565 ] DM-23800 [ 431613 ]
            ttsai Te-Wei Tsai made changes -
            Epic Link DM-23800 [ 431613 ] DM-25674 [ 436565 ]
            ttsai Te-Wei Tsai made changes -
            Sprint TSSW Sprint - Jun 22 - Jul 6 [ 1028 ] TSSW Sprint - Jul 6 - Jul 20 [ 1031 ]
            ttsai Te-Wei Tsai made changes -
            Status To Do [ 10001 ] In Progress [ 3 ]
            ttsai Te-Wei Tsai made changes -
            Attachment neg_slew_failed.jpg [ 44857 ]
            Hide
            ttsai Te-Wei Tsai added a comment -

            Mike Warner found there is the problem of torque in the plant/load dynamics block. He put the scopes in the torque input, Gravity Compensation, and Friction/Damping Compensation, and noticed that the sum of both Compensations is similar to the maximum torque, and there is no torque left to get a motion started (marked as TTorque, see the following figure:

            To fix it, he inserted a gain of 0.5 to the Coulomb Friction output and the system seems to work fine.

            He has no idea what the friction value should be, maybe this is something we need to bring up with MOOG, as the sum of both compensations exceeds the available torque in this particular situation. He contacted Ghavimi, Ali to see he could help this or not.

            I asked the following questions and Mike Warner replied:

            1. What will happen for the positive point-to-point movement (positionSet 1.5)? It looks like this gain value will affect all control modes globally.

            This change should have a minimal effect in the performance of the system, Coulomb Friction, also called Stiction, is usually destabilizing in a control loop, if anything the system should be more stable, I tried the positive motion with no problems.

            2. Why is this an asymmetric behavior? I thought the plant model should be symmetric. But why it is not?

            The system is not really symmetrical, as it includes a gravity compensation, which sometimes might push/pull the system in one direction, in this case a positive motion it helped, and a negative motion it was pulling, and it needed more torque that was available causing the failure.

            3. If there is no other concern, should we just put this gain=0.5 correction and claim the bug is fixed? Will it affect other subsystem's behavior in the plant model? I do not understand the meaning of Coulomb friction here. Can you explain to me what is that? And what will happen if we assume the Coulomb friction was original half?

            I have no concerns, as the real hardware was tested and seems to work fine, maybe we can get telemetry and refine the actual Coulomb Friction model eventually, the values used in the model could be an unrealistic worst case.

            Show
            ttsai Te-Wei Tsai added a comment - Mike Warner found there is the problem of torque in the plant/load dynamics block. He put the scopes in the torque input, Gravity Compensation , and Friction/Damping Compensation , and noticed that the sum of both Compensations is similar to the maximum torque, and there is no torque left to get a motion started (marked as TTorque , see the following figure: To fix it, he inserted a gain of 0.5 to the Coulomb Friction  output and the system seems to work fine. He has no idea what the friction value should be, maybe this is something we need to bring up with MOOG, as the sum of both compensations exceeds the available torque in this particular situation. He contacted Ghavimi, Ali to see he could help this or not. I asked the following questions and Mike Warner replied: 1. What will happen for the positive point-to-point movement (positionSet 1.5)? It looks like this gain value will affect all control modes globally. This change should have a minimal effect in the performance of the system, Coulomb Friction, also called Stiction, is usually destabilizing in a control loop, if anything the system should be more stable, I tried the positive motion with no problems. 2. Why is this an asymmetric behavior? I thought the plant model should be symmetric. But why it is not? The system is not really symmetrical, as it includes a gravity compensation, which sometimes might push/pull the system in one direction, in this case a positive motion it helped, and a negative motion it was pulling, and it needed more torque that was available causing the failure. 3. If there is no other concern, should we just put this gain=0.5 correction and claim the bug is fixed? Will it affect other subsystem's behavior in the plant model? I do not understand the meaning of Coulomb friction here. Can you explain to me what is that? And what will happen if we assume the Coulomb friction was original half? I have no concerns, as the real hardware was tested and seems to work fine, maybe we can get telemetry and refine the actual Coulomb Friction model eventually, the values used in the model could be an unrealistic worst case.
            ttsai Te-Wei Tsai made changes -
            Attachment movePositivePosition.png [ 44860 ]
            Attachment moveNegativePosition.png [ 44861 ]
            Hide
            ttsai Te-Wei Tsai added a comment - - edited

            Add gain=0.5 to output load in 'Coulomb Friction' subsystem. Test the point-to-point movement in the positive and negative directions:

            I tried to track two targets (1.2 and -1.5 degrees) and still get the following error:

            However, I do not get this following error if I do the point-to-point movement:

            But the curve of rotator position looks weird. If I put the gain=0, I have the following:

            Although the position command matches the rotator's position, this should be wrong because if there is no friction, the actuator should not be able to move.

            Remove the use of gain. Use the low Coulomb friction (50 N, original: 277 N) to have the good result:

            Show
            ttsai Te-Wei Tsai added a comment - - edited Add gain=0.5 to output load in 'Coulomb Friction' subsystem. Test the point-to-point movement in the positive and negative directions: I tried to track two targets (1.2 and -1.5 degrees) and still get the following error: However, I do not get this following error if I do the point-to-point movement: But the curve of rotator position looks weird. If I put the gain=0, I have the following: Although the position command matches the rotator's position, this should be wrong because if there is no friction, the actuator should not be able to move. Remove the use of gain. Use the low Coulomb friction (50 N, original: 277 N) to have the good result:
            ttsai Te-Wei Tsai made changes -
            Attachment trackFollowingError.png [ 44862 ]
            ttsai Te-Wei Tsai made changes -
            Attachment moveToNegativeFromNonZeroPoint.png [ 44866 ]
            ttsai Te-Wei Tsai made changes -
            ttsai Te-Wei Tsai made changes -
            Attachment DahlModel.nb [ 44886 ]
            Hide
            ttsai Te-Wei Tsai added a comment -

            Worked on the Mathmatica notebook of Dahl model: DahlModel.nb.

            Show
            ttsai Te-Wei Tsai added a comment - Worked on the Mathmatica notebook of Dahl model:  DahlModel.nb .
            ttsai Te-Wei Tsai made changes -
            Attachment moveWithLowCoulombFriction.png [ 44897 ]
            ttsai Te-Wei Tsai made changes -
            Attachment trackPosAndNegTargets.png [ 44902 ]
            Hide
            ttsai Te-Wei Tsai added a comment - - edited

            The rotator can track the positive and negative targets now:

            It works fine even though the second target is at -3 deg:

            Show
            ttsai Te-Wei Tsai added a comment - - edited The rotator can track the positive and negative targets now: It works fine even though the second target is at -3 deg:
            Hide
            ttsai Te-Wei Tsai added a comment -
            Show
            ttsai Te-Wei Tsai added a comment - Document the  Coulomb Friction in Rotator Plant Model .
            ttsai Te-Wei Tsai made changes -
            Attachment trackPosAndNegTargets2.png [ 44904 ]
            Hide
            ttsai Te-Wei Tsai added a comment -

            Add the unit test for data bus and model.

            Show
            ttsai Te-Wei Tsai added a comment - Add the unit test for data bus and model.
            Hide
            ttsai Te-Wei Tsai added a comment -

            Please help to review the PR:
            https://github.com/lsst-ts/ts_mt_hexRot_simulink/pull/10

            You could see the Dahl model in the following page:
            https://confluence.lsstcorp.org/pages/viewpage.action?spaceKey=LTS&title=Coulomb+Friction+in+Rotator+Plant+Model

            Feel free to modify the confluence page directly.

            You could just base on the ticket comment to see the result of model update. Or I can show you the update remotely.

            Thank you!

            Show
            ttsai Te-Wei Tsai added a comment - Please help to review the PR: https://github.com/lsst-ts/ts_mt_hexRot_simulink/pull/10 You could see the Dahl model in the following page: https://confluence.lsstcorp.org/pages/viewpage.action?spaceKey=LTS&title=Coulomb+Friction+in+Rotator+Plant+Model Feel free to modify the confluence page directly. You could just base on the ticket comment to see the result of model update. Or I can show you the update remotely. Thank you!
            ttsai Te-Wei Tsai made changes -
            Reviewers Tiago Ribeiro [ tribeiro ]
            Status In Progress [ 3 ] In Review [ 10004 ]
            wvreeven Wouter van Reeven made changes -
            Sprint TSSW Sprint - Jul 6 - Jul 20 [ 1031 ] TSSW Sprint - Jul 6 - Jul 20, TSSW Sprint - Jul 20 - Aug 3 [ 1031, 1034 ]
            ttsai Te-Wei Tsai made changes -
            Link This issue relates to DM-26020 [ DM-26020 ]
            Hide
            tribeiro Tiago Ribeiro added a comment -

            Can you clarify one thing for me please? How does the model compute the gravity compensation? I imagine it will need to know the inclination of the system to be able to compute it. If this is the case, where this information is coming from on the model and on the real system? 

            Show
            tribeiro Tiago Ribeiro added a comment - Can you clarify one thing for me please? How does the model compute the gravity compensation? I imagine it will need to know the inclination of the system to be able to compute it. If this is the case, where this information is coming from on the model and on the real system? 
            ttsai Te-Wei Tsai made changes -
            Hide
            ttsai Te-Wei Tsai added a comment -

            Tiago Ribeiro Please see the page 3, 18, and 19 for the discussion of gravity in:
            2016-06-01 LSST CDR - Control System Design and Analysis_1.pptx

            These are the only information I could found.

            Thanks!

            Show
            ttsai Te-Wei Tsai added a comment - Tiago Ribeiro  Please see the page 3, 18, and 19 for the discussion of gravity in: 2016-06-01 LSST CDR - Control System Design and Analysis_1.pptx These are the only information I could found. Thanks!
            Hide
            tribeiro Tiago Ribeiro added a comment -

            Uhm, ok... but none of them specify where the inclination is coming from. I think it is ok for now but we should probably investigate this to make sure the model and the real thing are getting and using this information properly. 

             

            Show
            tribeiro Tiago Ribeiro added a comment - Uhm, ok... but none of them specify where the inclination is coming from. I think it is ok for now but we should probably investigate this to make sure the model and the real thing are getting and using this information properly.   
            Hide
            ttsai Te-Wei Tsai added a comment -

            I totally agree with this comment because the information of MOOG documents is very limited. I should document it when I do the debug of the gravity model (I do not know when it will be). Thanks!

            Show
            ttsai Te-Wei Tsai added a comment - I totally agree with this comment because the information of MOOG documents is very limited. I should document it when I do the debug of the gravity model (I do not know when it will be). Thanks!
            Hide
            tribeiro Tiago Ribeiro added a comment -

            Great work done by TeWei and Mike on this ticket. I think it's good to go, we will have some additional work to follow up but it is looking good. 

            Show
            tribeiro Tiago Ribeiro added a comment - Great work done by TeWei and Mike on this ticket. I think it's good to go, we will have some additional work to follow up but it is looking good. 
            tribeiro Tiago Ribeiro made changes -
            Status In Review [ 10004 ] Reviewed [ 10101 ]
            ttsai Te-Wei Tsai made changes -
            Resolution Done [ 10000 ]
            Status Reviewed [ 10101 ] Done [ 10002 ]

              People

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

                Dates

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

                  Jenkins

                  No builds found.