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

Fix the Bugs of Trajectory If No Track Command Received In the Tracking

    XMLWordPrintable

Details

    Description

      The path generator will continuously update the demand position even if there is no new track command received in the SlewAndTrack sub-state. The initial suspect is that this comes from the non-zero target velocity in the final received track command. This will continue to update the position command. The initial idea to fix this is to reset the velocity command to be zero if no new track command received.

      The following figure (x-axis: time in seconds, y-axis: value such as position in degree) shows this problem. There are two targets (positions = 1.2 degree and 3 degree. velocity = 0.01 deg/sec and -0.01 deg/sec). The track command does not continue after the time equals 6 seconds. We could see the rotator position is at 3 degree when time is at 8 seconds but the demand position is decreasing after time=8 seconds (rotator's position keeps the same) because of the second target has the velocity of -0.01 deg/sec.

       

      Attachments

        Issue Links

          Activity

            rowen Russell Owen added a comment - - edited

            If the controller's path generator interpolates between (position, velocity, time) track commands then it probably should not extrapolate at all. I certainly hope that is how the path generator works, as I find it hard to believe it can produce a nice motion profile otherwise.

            As per DM-25245 I hope that the low-level controller will go into FAULT state if track commands do not come often enough. I don't know how that relates to this ticket, but I think it crucial that rotator never stop if a track command is late, then start moving again when the track command arrives. That would lead to a silently unacceptable motion profile.

            I added more comments on DM-25245

            rowen Russell Owen added a comment - - edited If the controller's path generator interpolates between (position, velocity, time) track commands then it probably should not extrapolate at all. I certainly hope that is how the path generator works, as I find it hard to believe it can produce a nice motion profile otherwise. As per DM-25245 I hope that the low-level controller will go into FAULT state if track commands do not come often enough. I don't know how that relates to this ticket, but I think it crucial that rotator never stop if a track command is late, then start moving again when the track command arrives. That would lead to a silently unacceptable motion profile. I added more comments on DM-25245
            ttsai Te-Wei Tsai added a comment - - edited

            Update the module of "Track Mod Cmd Gen" in rotator controller to let the velCmd to be zero if NewCommandReceived==0. However, the result keeps the same and I suspect I forgot to consider the slew and overshoot of posCmd. To approve this, I test the condition to let the second target to track for some time and stop the sending of new track command to see the result.

            In the module of slewAndTrackingParameters, if NewCommandReceived==0, the system will interpolate the new command from the old command. The calculated position error will compare the value with a threshold to decide to put the system into the track mode or not.

            ttsai Te-Wei Tsai added a comment - - edited Update the module of "Track Mod Cmd Gen" in rotator controller to let the velCmd to be zero if NewCommandReceived==0. However, the result keeps the same and I suspect I forgot to consider the slew and overshoot of posCmd. To approve this, I test the condition to let the second target to track for some time and stop the sending of new track command to see the result. In the module of slewAndTrackingParameters, if NewCommandReceived==0, the system will interpolate the new command from the old command. The calculated position error will compare the value with a threshold to decide to put the system into the track mode or not.
            ttsai Te-Wei Tsai added a comment -

            Updated slewAndTrackingParameters of deciding the slew and track state if no new track command received. Tested the conditions that have only one track command of second target and some of them as the following:

            It looks like there is some difference between the position and position command in the second figure that has no new track command after some time:

            ttsai Te-Wei Tsai added a comment - Updated slewAndTrackingParameters of deciding the slew and track state if no new track command received. Tested the conditions that have only one track command of second target and some of them as the following: It looks like there is some difference between the position and position command in the second figure that has no new track command after some time:
            ttsai Te-Wei Tsai added a comment -

            In the test, it looks like the "trackLost" and "trackSuccess" do not match with each other. The same thing for "slewComplete" and "trackState".

            ttsai Te-Wei Tsai added a comment - In the test, it looks like the "trackLost" and "trackSuccess" do not match with each other. The same thing for "slewComplete" and "trackState".
            rowen Russell Owen added a comment -

            A note on determining that a slew has ended: I have found it necessary to check that position and velocity errors are both small before declaring that slewing has ended and tracking begun. If you only check position then it is easy to be fooled, for instance if the slew overshoots.

            rowen Russell Owen added a comment - A note on determining that a slew has ended: I have found it necessary to check that position and velocity errors are both small before declaring that slewing has ended and tracking begun. If you only check position then it is easy to be fooled, for instance if the slew overshoots.
            ttsai Te-Wei Tsai added a comment -

            The algorithm of slew is the same as the point-to-point movement that the velocity and acceleration will be zero when the slew completes. The requested velocity is reached in the track state.

            ttsai Te-Wei Tsai added a comment - The algorithm of slew is the same as the point-to-point movement that the velocity and acceleration will be zero when the slew completes. The requested velocity is reached in the track state.
            rowen Russell Owen added a comment - - edited

            Oh dear. That sounds like it could be a problem. Are you saying that the rotator slews and stops, then starts tracking? When does it report that tracking has begun? Only after it is properly up to speed and tracking the commanded trajectory, or as soon as the rotator stops at the end of the slew?

            In any case it adds an extra acceleration to the rotator, which is likely to shake the camera.

            I strongly suspect we will need to change the software so that the slew ends with motion at the velocity that matches the target.

            tribeiro were you aware of this?

            rowen Russell Owen added a comment - - edited Oh dear. That sounds like it could be a problem. Are you saying that the rotator slews and stops, then starts tracking? When does it report that tracking has begun? Only after it is properly up to speed and tracking the commanded trajectory, or as soon as the rotator stops at the end of the slew? In any case it adds an extra acceleration to the rotator, which is likely to shake the camera. I strongly suspect we will need to change the software so that the slew ends with motion at the velocity that matches the target. tribeiro were you aware of this?
            ttsai Te-Wei Tsai added a comment -

            I try to track the targets at the negative direction and the simulation stuck. The detail is at DM-25249.

            ttsai Te-Wei Tsai added a comment - I try to track the targets at the negative direction and the simulation stuck. The detail is at DM-25249 .
            ttsai Te-Wei Tsai added a comment -

            rowen The tracking process contains two states: slew and track. Assume the rotator's initial position is x_rot_0. The requested position and velocity of targets are x_target and v_target. If abs(x_rot_0 - x_target) > threshold, the controller will put the system into the slew state. The calculation of path generator is the same as the poinit-to-point movement that the velocity command will be zero (cmd_vel=0)  when the slew is done.

            However, it is noted that the cmd_vel will superimpose with v_target and the output is cmd_vel' = cmd_vel + v_target all the time. After  abs(x_rot_0 - x_target) < threshold, the system will enter the track state. The output cmd_vel'=v_target if there is new track command received. This process will adjust the rotatar's velocity to reach v_target.

            If there is no new track command in the track state, the cmd_vel'=0. This is updated by me to stop the updating of position command cmd_pos.

            Therefore, I believe the software slews ends with motion at the velocity that matches the target.

            ttsai Te-Wei Tsai added a comment - rowen The tracking process contains two states: slew and track. Assume the rotator's initial position is x_rot_0. The requested position and velocity of targets are x_target and v_target. If abs(x_rot_0 - x_target) > threshold, the controller will put the system into the slew state. The calculation of path generator is the same as the poinit-to-point movement that the velocity command will be zero (cmd_vel=0)  when the slew is done. However, it is noted that the cmd_vel will superimpose with v_target and the output is cmd_vel' = cmd_vel + v_target all the time. After  abs(x_rot_0 - x_target) < threshold, the system will enter the track state. The output cmd_vel'=v_target if there is new track command received. This process will adjust the rotatar's velocity to reach v_target. If there is no new track command in the track state, the cmd_vel'=0. This is updated by me to stop the updating of position command cmd_pos. Therefore, I believe the software slews ends with motion at the velocity that matches the target.
            ttsai Te-Wei Tsai added a comment - - edited

            If we issue a stop command when the rotator is slewing, the rotator will continue to do the slew. In the following, the final track command is at time=6.05 second. One has the stop command at time=7 second and trackStart command at time=9 second. The other one has the stop command at time=14 second and trackStart command at time=16 second.

            Need to update the code of stop command in tracking mode to let the rotator stop totally.

            Use the same condition for the left image with the third target of position=0.5 deg, velocity=-0.01 deg/sec, and time=8.85 sec, I have the following image:

            Although the simulation crashes at time~12 second, the rotator does turn to the third target. This implies the above left figure is a misleading of Simulink restriction that holds the previous data (the second target).

            I test another condition with the third target that has position=1.85 deg, velocity=0 deg/sec and the time=8.85 sec. The position of 1.85 deg is roughly the same as the rotator's position at the stop. I get the following figure:

            At this time, the rotator can stop correctly. Does this imply I need to update the lsstCmdSet at the rotator controller code instead of the Simulink model?

            Another choice is to rewrite the commanded position and velocity once the stopComplete==1. However, the system will reuse the existed commanded position and velocity once put the system back to the SlewAndTrack sub-state (by tarckStart command) as the following:

            Therefore, it looks like to rewrite the global variable of  LsstCmdSet in commanding.c is the only way to go.

            ttsai Te-Wei Tsai added a comment - - edited If we issue a stop command when the rotator is slewing, the rotator will continue to do the slew. In the following, the final track command is at time=6.05 second. One has the stop command at time=7 second and trackStart command at time=9 second. The other one has the stop command at time=14 second and trackStart command at time=16 second. Need to update the code of stop command in tracking mode to let the rotator stop totally. Use the same condition for the left image with the third target of position=0.5 deg, velocity=-0.01 deg/sec, and time=8.85 sec, I have the following image: Although the simulation crashes at time~12 second, the rotator does turn to the third target. This implies the above left figure is a misleading of Simulink restriction that holds the previous data (the second target). I test another condition with the third target that has position=1.85 deg, velocity=0 deg/sec and the time=8.85 sec. The position of 1.85 deg is roughly the same as the rotator's position at the stop. I get the following figure: At this time, the rotator can stop correctly. Does this imply I need to update the lsstCmdSet at the rotator controller code instead of the Simulink model? Another choice is to rewrite the commanded position and velocity once the stopComplete==1. However, the system will reuse the existed commanded position and velocity once put the system back to the SlewAndTrack sub-state (by tarckStart command) as the following: Therefore, it looks like to rewrite the global variable of  LsstCmdSet in commanding.c is the only way to go.
            ttsai Te-Wei Tsai added a comment - - edited

            If I issue two targets:
            (1) position = 1.2 deg, velocity = 0.01 deg/sec
            (2) position = 0.7 deg, velocity = -0.01 deg/sec

            with the stop and startTrack commands in between, I have the following image:

            This implies two things:
            1. The rotator Simulink model should be able to do the tracking of multiple targets as long as the rotator position and target's position >= 0 deg. Maybe the plant model really has the problem.
            2. The stop command does not stop the slewing of unfinished target.

            ttsai Te-Wei Tsai added a comment - - edited If I issue two targets: (1) position = 1.2 deg, velocity = 0.01 deg/sec (2) position = 0.7 deg, velocity = -0.01 deg/sec with the stop and startTrack commands in between, I have the following image: This implies two things: 1. The rotator Simulink model should be able to do the tracking of multiple targets as long as the rotator position and target's position >= 0 deg. Maybe the plant model really has the problem. 2. The stop command does not stop the slewing of unfinished target.
            ttsai Te-Wei Tsai added a comment - - edited

            The behavior of "stop" command is different between the point-to-point movement and track. For the former, a trigger of newPt2PtCommand is needed in the state machine. The positionSet command will set the trigger to 1 and the value will be 0 once the system enters the MovingPt2Pt sub-State (the logic of trigger=0 is at Pt2PtMove block). This is why the rotator can not move again after the stop in the movement (positionSet = 1.5 happens at time=0.5 sec):

            For the track, there is no such trigger of newSlewCommand. Therefore, the stop command behaves more like a pause command actually. It looks like the track process can not use the same method as the point-to-point movement to erase the history. The MOOG developer also left the following comment in MATLAB script: "NOTE: slews must be completed before new slew?".

            ttsai Te-Wei Tsai added a comment - - edited The behavior of "stop" command is different between the point-to-point movement and track. For the former, a trigger of newPt2PtCommand is needed in the state machine. The positionSet command will set the trigger to 1 and the value will be 0 once the system enters the MovingPt2Pt sub-State (the logic of trigger=0 is at Pt2PtMove block). This is why the rotator can not move again after the stop in the movement (positionSet = 1.5 happens at time=0.5 sec): For the track, there is no such trigger of newSlewCommand. Therefore, the stop command behaves more like a pause command actually. It looks like the track process can not use the same method as the point-to-point movement to erase the history. The MOOG developer also left the following comment in MATLAB script: "NOTE: slews must be completed before new slew?".
            ttsai Te-Wei Tsai added a comment - - edited

            After the tests of Simulink model, to solve the problem of stop command in track, the only way is to rewrite the data of "LsstCmdSet" after the stop completes (Flags_stopComplete).

            There are two ways to do this:
            (1) Update the rotator controller code once Flags_stopComplete == 1.
            (2) Let rotator CSC do by sending the new track command. However, there is no way for rotator CSC to know this at this moment. In addition, we prefer to use the command acknowledgement to know the stop command is finished or not in a latter time.

            Therefore, only the option 1 can work as a temporary solution at this moment. Another possibility is to add a reset command or something similar to let the rotator_controller update the position and velocity of LsstCmdSet after the stop command is done. It looks like ts_rotator has the telemetry of flags_stop_complete already. This might be used as a temporary solution as well.

            I do not prefer the option 1 because there will be multiple places to write the data into the global variable of LsstCmdSet.

            ttsai Te-Wei Tsai added a comment - - edited After the tests of Simulink model, to solve the problem of stop command in track, the only way is to rewrite the data of "LsstCmdSet" after the stop completes (Flags_stopComplete). There are two ways to do this: (1) Update the rotator controller code once Flags_stopComplete == 1. (2) Let rotator CSC do by sending the new track command. However, there is no way for rotator CSC to know this at this moment. In addition, we prefer to use the command acknowledgement to know the stop command is finished or not in a latter time. Therefore, only the option 1 can work as a temporary solution at this moment. Another possibility is to add a reset command or something similar to let the rotator_controller update the position and velocity of LsstCmdSet after the stop command is done. It looks like ts_rotator has the telemetry of flags_stop_complete already. This might be used as a temporary solution as well. I do not prefer the option 1 because there will be multiple places to write the data into the global variable of LsstCmdSet.
            ttsai Te-Wei Tsai added a comment - - edited

            Please help to review the PRs:

            1. https://github.com/lsst-ts/ts_mt_hexRot_simulink/pull/6
            2. https://github.com/lsst-ts/ts_rotator_controller/pull/5

            The comments of second link has the details of code update. Thanks!

            PS. I will create another Jira ticket for the stop command in the tracking mode. The remove of trajectory's history can be done in the rotator controller or rotator CSC. I think it is better for us to discuss first. Thanks!

            The ticket to solve the problem of stop command is DM-25441.

            ttsai Te-Wei Tsai added a comment - - edited Please help to review the PRs: 1.  https://github.com/lsst-ts/ts_mt_hexRot_simulink/pull/6 2.  https://github.com/lsst-ts/ts_rotator_controller/pull/5 The comments of second link has the details of code update. Thanks! PS. I will create another Jira ticket for the stop command in the tracking mode. The remove of trajectory's history can be done in the rotator controller or rotator CSC. I think it is better for us to discuss first. Thanks! The ticket to solve the problem of stop command is DM-25441 .

            Approved on github

            rowen Russell Owen added a comment - Approved on github

            People

              ttsai Te-Wei Tsai
              ttsai Te-Wei Tsai
              Russell Owen
              Russell Owen, Te-Wei Tsai, Tiago Ribeiro
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Jenkins

                  No builds found.