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

XMLWordPrintable

#### Details

• Type: Story
• Status: Done
• Resolution: Done
• Fix Version/s: None
• Component/s:
• Labels:
• 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.

#### Activity

No builds found.
Te-Wei Tsai created issue -
Field Original Value New Value
Attachment track_v0_1_long_enterFault.png [ 44216 ]
 Description The path generator will continuously update the demand position even if there is no new track command 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 shows this problem. There are two targets (positions = 1.2 degree and 3 degree). The track command does not continue after the time=6 second. We could see the rotator position is at 3 degree but the demand position is decreasing because of the second target has the velocity of -0.01 deg/sec. The path generator will continuously update the demand position even if there is no new track command 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 shows this problem. There are two targets (positions = 1.2 degree and 3 degree). The track command does not continue after the time=6 second. We could see the rotator position is at 3 degree but the demand position is decreasing because of the second target has the velocity of -0.01 deg/sec. !track_v0_1_long_enterFault.png|thumbnail!
 Description The path generator will continuously update the demand position even if there is no new track command 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 shows this problem. There are two targets (positions = 1.2 degree and 3 degree). The track command does not continue after the time=6 second. We could see the rotator position is at 3 degree but the demand position is decreasing because of the second target has the velocity of -0.01 deg/sec. !track_v0_1_long_enterFault.png|thumbnail! 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 shows this problem. There are two targets (positions = 1.2 degree and 3 degree). The track command does not continue after the time=6 second. We could see the rotator position is at 3 degree but the demand position is decreasing because of the second target has the velocity of -0.01 deg/sec. !track_v0_1_long_enterFault.png|thumbnail!
 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 shows this problem. There are two targets (positions = 1.2 degree and 3 degree). The track command does not continue after the time=6 second. We could see the rotator position is at 3 degree but the demand position is decreasing because of the second target has the velocity of -0.01 deg/sec. !track_v0_1_long_enterFault.png|thumbnail! 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 suspection 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 shows this problem. There are two targets (positions = 1.2 degree and 3 degree). The track command does not continue after the time=6 second. We could see the rotator position is at 3 degree but the demand position is decreasing because of the second target has the velocity of -0.01 deg/sec. !track_v0_1_long_enterFault.png|thumbnail!
 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 suspection 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 shows this problem. There are two targets (positions = 1.2 degree and 3 degree). The track command does not continue after the time=6 second. We could see the rotator position is at 3 degree but the demand position is decreasing because of the second target has the velocity of -0.01 deg/sec. !track_v0_1_long_enterFault.png|thumbnail! 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 shows this problem. There are two targets (positions = 1.2 degree and 3 degree). The track command does not continue after the time=6 second. We could see the rotator position is at 3 degree but the demand position is decreasing because of the second target has the velocity of -0.01 deg/sec. !track_v0_1_long_enterFault.png|thumbnail!
 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 shows this problem. There are two targets (positions = 1.2 degree and 3 degree). The track command does not continue after the time=6 second. We could see the rotator position is at 3 degree but the demand position is decreasing because of the second target has the velocity of -0.01 deg/sec. !track_v0_1_long_enterFault.png|thumbnail! 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 shows this problem. There are two targets (positions = 1.2 degree and 3 degree). The track command does not continue after the time=6 second. We could see the rotator position is at 3 degree when time is at 8 seconds but the demand position is decreasing because of the second target has the velocity of -0.01 deg/sec. !track_v0_1_long_enterFault.png|thumbnail!
 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 shows this problem. There are two targets (positions = 1.2 degree and 3 degree). The track command does not continue after the time=6 second. We could see the rotator position is at 3 degree when time is at 8 seconds but the demand position is decreasing because of the second target has the velocity of -0.01 deg/sec. !track_v0_1_long_enterFault.png|thumbnail! 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 shows this problem. There are two targets (positions = 1.2 degree and 3 degree). 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 because of the second target has the velocity of -0.01 deg/sec. !track_v0_1_long_enterFault.png|thumbnail!
 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 shows this problem. There are two targets (positions = 1.2 degree and 3 degree). 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 because of the second target has the velocity of -0.01 deg/sec. !track_v0_1_long_enterFault.png|thumbnail! 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). 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 because of the second target has the velocity of -0.01 deg/sec. !track_v0_1_long_enterFault.png|thumbnail!
 Epic Link DM-23800 [ 431613 ]
 Link This issue relates to DM-25045 [ DM-25045 ]
 End date 11/Jun/20 Sprint TSSW Sprint - Jun 8 - Jun 22 [ 1024 ] Start date 08/Jun/20 Story Points 3 Team Telescope and Site [ 13500 ] Labels HexRot MainTelescope
 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). 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 because of the second target has the velocity of -0.01 deg/sec. !track_v0_1_long_enterFault.png|thumbnail! 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 because of the second target has the velocity of -0.01 deg/sec. !track_v0_1_long_enterFault.png|thumbnail!
 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 because of the second target has the velocity of -0.01 deg/sec. !track_v0_1_long_enterFault.png|thumbnail! 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. !track_v0_1_long_enterFault.png|thumbnail!
Hide
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.

Show
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
 Link This issue relates to DM-25245 [ DM-25245 ]
 Link This issue relates to DM-25249 [ DM-25249 ]
 Status To Do [ 10001 ] In Progress [ 3 ]
Hide
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.

Show
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.
 Labels HexRot MainTelescope HexRot MainTelescope ccw-rotator-integration-test
 Watchers Russell Owen, Te-Wei Tsai [ Russell Owen, Te-Wei Tsai ] Russell Owen, Te-Wei Tsai, Tiago Ribeiro [ Russell Owen, Te-Wei Tsai, Tiago Ribeiro ]
 Attachment trackWithoutNewTrackCmd.png [ 44349 ] Attachment trackWithSomeNewTrackCmdAndNoCmd.png [ 44350 ] Attachment trackWithSomeNewTrackCmdAndNoCmdMagnify.png [ 44351 ]
Hide
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:

Show
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:
Hide
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".

Show
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".
Hide
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.

Show
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.
Hide
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.

Show
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.
Hide
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.

Tiago Ribeiro were you aware of this?

Show
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. Tiago Ribeiro were you aware of this?
Hide
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.

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

Russell Owen 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.

Show
Te-Wei Tsai added a comment - Russell Owen 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.
 Attachment trackStopBeforeSlewDone.png [ 44359 ] Attachment trackStopAfterSlewDone.png [ 44360 ]
Hide
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.

Show
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.
 Attachment trackWithStopAndSecondTargetSmaller.png [ 44401 ]
Hide
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.

Show
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.
 Attachment trackWithStopAndSecondTargetSmaller.png [ 44402 ]
 Attachment moveWithStop.png [ 44403 ]
Hide
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?".

Show
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?".
 Attachment moveWithStop.png [ 44403 ]
 Attachment moveWithStop.png [ 44404 ]
 Attachment trackWithStopAnd3rdTarget.png [ 44408 ]
 Attachment trackWithStopAnd3rdTargetOfPosNow.png [ 44409 ]
 Attachment trackWithStopAnd3rdTargetOfPosNowAndRewiteCmdPosAndVel.png [ 44415 ]
Hide
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.

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

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.

Show
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 .
 Reviewers Russell Owen [ rowen ] Status In Progress [ 3 ] In Review [ 10004 ]
 Link This issue relates to DM-25441 [ DM-25441 ]
Hide
Russell Owen added a comment -

Approved on github

Show
Russell Owen added a comment - Approved on github
 Status In Review [ 10004 ] Reviewed [ 10101 ]
 Resolution Done [ 10000 ] Status Reviewed [ 10101 ] Done [ 10002 ]
 Link This issue relates to DM-25795 [ DM-25795 ]

#### People

Assignee:
Te-Wei Tsai
Reporter:
Te-Wei Tsai
Reviewers:
Russell Owen
Watchers:
Russell Owen, Te-Wei Tsai, Tiago Ribeiro
0 Vote for this issue
Watchers:
3 Start watching this issue

#### Dates

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

#### Jenkins

No builds found.