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

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.

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:

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

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.

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?

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

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.

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.

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.

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