Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: ts_main_telescope
-
Story Points:3
-
Sprint:TSSW Sprint - Jul 6 - Jul 20, TSSW Sprint - Jul 20 - Aug 3
-
Team:Telescope and Site
-
Urgent?:No
Description
Fix the following error in the rotator Simulink model. There is the problem of physical model in plant that the rotator's position will differ from the related position command gradually until the trigger of followingError (the difference >= threshold) and this stops the motion of rotator. According to the observation, this happens if the rotator moves in the negative direction.
In the following figure, there are two targets: (1) position=1.2 deg and velocity=0.01 deg/sec and (2) position=1.5 deg and velocity=-0.01 deg/sec. The total simulation time is 20.1 sec. There is no big difference between the position command and position. The error of noNewTrackCmdError after the slew of the second target is triggered as expected.
However, if the second target has position=-1.5 deg and velocity=-0.01 deg/sec, the following error is triggered while the rotator turns the direction to slew to the second target:
Attachments
Issue Links
Activity
Add gain=0.5 to output load in 'Coulomb Friction' subsystem. Test the point-to-point movement in the positive and negative directions:
I tried to track two targets (1.2 and -1.5 degrees) and still get the following error:
However, I do not get this following error if I do the point-to-point movement:
But the curve of rotator position looks weird. If I put the gain=0, I have the following:
Although the position command matches the rotator's position, this should be wrong because if there is no friction, the actuator should not be able to move.
Remove the use of gain. Use the low Coulomb friction (50 N, original: 277 N) to have the good result:
Worked on the Mathmatica notebook of Dahl model: DahlModel.nb
.
The rotator can track the positive and negative targets now:
It works fine even though the second target is at -3 deg:
Document the Coulomb Friction in Rotator Plant Model.
Add the unit test for data bus and model.
Please help to review the PR:
https://github.com/lsst-ts/ts_mt_hexRot_simulink/pull/10
You could see the Dahl model in the following page:
https://confluence.lsstcorp.org/pages/viewpage.action?spaceKey=LTS&title=Coulomb+Friction+in+Rotator+Plant+Model
Feel free to modify the confluence page directly.
You could just base on the ticket comment to see the result of model update. Or I can show you the update remotely.
Thank you!
Can you clarify one thing for me please? How does the model compute the gravity compensation? I imagine it will need to know the inclination of the system to be able to compute it. If this is the case, where this information is coming from on the model and on the real system?
Tiago Ribeiro Please see the page 3, 18, and 19 for the discussion of gravity in:
2016-06-01 LSST CDR - Control System Design and Analysis_1.pptx
These are the only information I could found.
Thanks!
Uhm, ok... but none of them specify where the inclination is coming from. I think it is ok for now but we should probably investigate this to make sure the model and the real thing are getting and using this information properly.
I totally agree with this comment because the information of MOOG documents is very limited. I should document it when I do the debug of the gravity model (I do not know when it will be). Thanks!
Great work done by TeWei and Mike on this ticket. I think it's good to go, we will have some additional work to follow up but it is looking good.
Mike Warner found there is the problem of torque in the plant/load dynamics block. He put the scopes in the torque input, Gravity Compensation, and Friction/Damping Compensation, and noticed that the sum of both Compensations is similar to the maximum torque, and there is no torque left to get a motion started (marked as TTorque, see the following figure:
To fix it, he inserted a gain of 0.5 to the Coulomb Friction output and the system seems to work fine.
He has no idea what the friction value should be, maybe this is something we need to bring up with MOOG, as the sum of both compensations exceeds the available torque in this particular situation. He contacted Ghavimi, Ali to see he could help this or not.
I asked the following questions and Mike Warner replied:
1. What will happen for the positive point-to-point movement (positionSet 1.5)? It looks like this gain value will affect all control modes globally.
This change should have a minimal effect in the performance of the system, Coulomb Friction, also called Stiction, is usually destabilizing in a control loop, if anything the system should be more stable, I tried the positive motion with no problems.
2. Why is this an asymmetric behavior? I thought the plant model should be symmetric. But why it is not?
The system is not really symmetrical, as it includes a gravity compensation, which sometimes might push/pull the system in one direction, in this case a positive motion it helped, and a negative motion it was pulling, and it needed more torque that was available causing the failure.
3. If there is no other concern, should we just put this gain=0.5 correction and claim the bug is fixed? Will it affect other subsystem's behavior in the plant model? I do not understand the meaning of Coulomb friction here. Can you explain to me what is that? And what will happen if we assume the Coulomb friction was original half?
I have no concerns, as the real hardware was tested and seems to work fine, maybe we can get telemetry and refine the actual Coulomb Friction model eventually, the values used in the model could be an unrealistic worst case.