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

XMLWordPrintable

#### Details

• Story
• Status: Done
• Resolution: Done
• None
• 3
• TSSW Sprint - Jun 8 - Jun 22
• Telescope and Site
• No

#### 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.

#### Activity

Te-Wei Tsai added a comment - -

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.

Te-Wei Tsai added a comment - - 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.
Te-Wei Tsai added a comment - -

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?".

Te-Wei Tsai added a comment - - 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?".
Te-Wei Tsai added a comment - -

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.

Te-Wei Tsai added a comment - - 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.
Te-Wei Tsai added a comment - -

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.

Te-Wei Tsai added a comment - - 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

Russell Owen added a comment - Approved on github

#### People

Te-Wei Tsai
Te-Wei Tsai
Russell Owen
Russell Owen, Te-Wei Tsai, Tiago Ribeiro