Fix Version/s: None
Sprint:TSSW Sprint - Jun 22 - Jul 6
Team:Telescope and Site
Remove the history of trajectory after issuing the stop command in the tracking. The Simulink model uses the LsstCmdSet object to get the time, position, and velocity of tracking target. If the user issues the stop command before the finish of slew, the rotator stops without the update of LsstCmdSet. This means if the user issues the trackStart command, the rotator will transition to the SlewingAndTracking sub-state and try to track the unfinished target based on LsstCmdSet.
In the following figure, there are two targets: (1) position=1.2 deg, velocity=0.01 deg/sec, and (2) position=3.0 deg, velocity=-0.01 deg/sec. The final track command is at time=6.05 second. Issue the stop command at time=7 second and trackStart command at time=9 second. We can see the rotator tries to finish the second target after it is back to the SlewingAndTracking sub-state.
To solve this problem, we need to update the LsstCmdSet object to set the position to be the rotator's position or position command, and the velocity to be 0 after the stop completes (Flags_stopComplete ==1.0) as the following:
There are four possible options to do this:
(1) Update the LsstCmdSet object in ts_rotator_controller once Flags_stopComplete==1.0.
(2) Let ts_rotator update the LsstCmdSet object by sending the new track command once Flags_stopComplete==1.0. However, we prefer to use the command acknowledgement to know the stop command is finished or not in a latter time.
(3) Add a reset command or something similar in ts_rotator and ts_rotator_controller to let the rotator controller updates the position and velocity of LsstCmdSet.
(4) Update the Simulink model to add a latch to determine when to use the new track command. This will add the complexity to the Simulink model because it is not designed in that way originally. It may not be easy to debug in a latter time. However, this will not affect the ts_rotator and ts_rotator_controller at all.
I do not prefer the option 1 because there will be multiple places to write the data into the global variable of LsstCmdSet. Originally, it is updated by ts_rotator only. Or more accurately, the ts_rotator issues the track command to update the LsstCmdSet in commanding.c in ts_rotator_controller. If the option 1 is chosen, I need to let the actuator.c to be able to update the LsstCmdSet object. Think more deeply, for the option 3, it is the same thing. The only benefit for option 3 is that the CSC user knows the LsstCmdSet is changed. But if the CSC user does not care about this, maybe the option 1, 2, or 4 is better. If we consider the coherence of code, maybe the option 1 or 4 is the best solution.
Add the 'switchPosAndVelCmd' subsystem in 'Command Profile' subsystem as a proof of concept. The 'sample and hold' block is used as a latch. In the following figure, the rotator tracks two targets: (1) position=1.2 deg, velocity=0.01 deg/sec, and (2) position=3.0 deg, velocity=-0.01 deg/sec. The final track command is at time=6.05 sec. I stop the rotator at time=7 second, and put back the SlewingAndTracking sub-state at time=9 second. The rotator stops at the second target, and put into the Fault state after no new track command error as expected.
However, this test does not consider the reset of new track command. It does not consider the LsstCmdSet in point-to-point movement as well.
I noticed maybe there is the problem of calculation of NewCommandReceived in the 'Time Calculation' subsystem. There is a Reset block in the 'Command Generator Overview' subsystem. This might reset the result of 'Unit Delay' that connects to CommandedTime. This will make the calculation of NewCommandReceived wrong.
I added the 'isNewCommandReceived' subsystem in the 'Command Profile'. This will calculate the NewCommandReceived and periodFromLastCmdReceived. This calculates the event of NewCommandReceived correctly. I think this should work with the previous 'switchPosAndVelCmd' subsystem to switch the value of relay.
Use the 'updatePosAndVelCmd' subsystem to replace the 'switchPosAndVelCmd' and write the internal logic to simplify it.
Add the loadInterruptFile.m and related test cases.
Simulate the rotator to track 3 targets that have the positions of 1.2, 3.0, and 2.1 degree individually. Issue the stop command when the rotator is slewing to the second target at time=7 second, and the rotator stops at position=1.8 degree. At time=9 second, issue the trackStart command followed by the track command of the third target. Stop the track command of the third target in the slewing. After the slew is done, the rotator will be put into the Fault state because there is no new track command within 0.25 seconds (= 5 times of track command). The result is:
This shows the rotator has no previous unfinished tracking history anymore.
Notice the magnification region:
When the rotator is put back to SlewingAndTracking substate and do not have the new track command yet, the CommandGenerator_ReceivedCmd telemetry will be the rotator's position at that time instead of the unfinished slew target.
Simulation the rotator to track 2 targets that have the position of 1.2 and 2.1 degree. Before the finish of the first slew, issue the stop command at time=2 second. The rotator stops at 0.75 degree. Use the positionSet command to set the target position of 1.5 degree. Put the rotator back to SlewingAndTracking substate at time=8 second. The rotator slews to the second target, and enters Fault state because there is no new track command. The figure is in the following:
Consider the constVelComplete tag in 'updatePosAndVelCmd' subsystem. Create the test manager of rotator Simulink model and add the test of 'isNewCommandReceived' subsystem.
I realized the support of constVelComplete will fail at this moment because the Simulink uses the "goto" tag now. Give up this at this moment. Create another ticket (
DM-25771) to support this.
Please help to review the following PRs:
You may need to do the review based on the comment. Or I could go through the update with you. Thanks!
Approved based on your description and test results. Thank you for fixing this nasty problem.
I decided to try the option 4 to hack the rotator Simulink model first.
There is a reset block in the Command Generator Overview subsystem, which contains the path generator. I tested the memory block and realized the value in hold will be reset if the reset block is triggered:
Therefore, if I want to hold the value of LsstCmdSet, I could not do this in the Command Generator Overview subsystem.