Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: ts_main_telescope
-
Story Points:3
-
Sprint:TSSW Sprint - Jun 8 - Jun 22
-
Team:Telescope and Site
-
Urgent?: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.
Attachments
Issue Links
- relates to
-
- Done
-
- Done
-
- Done
-
- Done
-
- Done
Activity
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?".
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.
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
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.