Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-25441

Remove the History of Trajectory after the Stop Command in the Tracking




      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.


        1. magnification.png
          137 kB
        2. testResetMemory.png
          102 kB
        3. trackStopBeforeSlewDone.png
          56 kB
        4. trackStopInitNew.png
          66 kB
        5. trackStopNewTarget.png
          79 kB
        6. trackStopPosTrack.png
          86 kB
        7. trackStopWithLatch.png
          66 kB
        8. trackWithStopAnd3rdTargetOfPosNowAndRewiteCmdPosAndVel.png
          63 kB

          Issue Links



              ttsai Te-Wei Tsai
              ttsai Te-Wei Tsai
              Russell Owen
              Russell Owen, Te-Wei Tsai
              0 Vote for this issue
              2 Start watching this issue


                Start date:
                End date:


                  No builds found.