Smart SAS Mod
- Thread starter pixelgaming579
- Start date
gniragnahur, in the settings there's a flip setting. So pick prograde then press the flip hotkey and it will do retrograde/prograde. It's really stupid how there isn't a retrograde option in the first place. Who even uses "none" when you can just unselect it in the first place. Poor UI design.
I've found SAS very useful.
However, there seems to be a bug that happens with prograde when the ship and prograde are close to pointing directly left. Prograde is slightly up and ship is slightly down. One is close to -180 deg and the other close to +180 deg not quite sure which is +180. What happens is that SAS directs the ship the wrong way round so it rotates anticlockwise instead of clockwise, overshoots the prograde direction and continues to spin.
The fix probably is that, if the difference between target and current is >180 - subtract 360 from it, and if < -180 - add 360 to it. That should ensure that it turns the right way.
The way I manually avoid overshooting the target direction with high inertia spacecraft is to turn off prograde when about 3/4 of the way to the target, let SAS stablise it until rotation stops, then turn prograde on again. Without letting SAS stablise it the correct position is 1/2 of the way to the target. Perhaps you could do something similar in the mod?
However, there seems to be a bug that happens with prograde when the ship and prograde are close to pointing directly left. Prograde is slightly up and ship is slightly down. One is close to -180 deg and the other close to +180 deg not quite sure which is +180. What happens is that SAS directs the ship the wrong way round so it rotates anticlockwise instead of clockwise, overshoots the prograde direction and continues to spin.
The fix probably is that, if the difference between target and current is >180 - subtract 360 from it, and if < -180 - add 360 to it. That should ensure that it turns the right way.
The way I manually avoid overshooting the target direction with high inertia spacecraft is to turn off prograde when about 3/4 of the way to the target, let SAS stablise it until rotation stops, then turn prograde on again. Without letting SAS stablise it the correct position is 1/2 of the way to the target. Perhaps you could do something similar in the mod?
'None' selected does not seem to be the same as no buttons selected. With nothing selected SAS seems to try to preserve the current direction. Try rotating a high inertia space craft with no buttons selected and again with 'None' selected. When you release the rotation key with no button selected it stops about 3 times faster then when 'None' is selected.
Yeah but that doesn't really make a difference because 1. the SAS doesn't save with different craft despite it saying it does.
And the reason it overshoots is because if the code recognises you to the left, it will KEEP PUSHING MAXIMUM right torque until it decides it needs to push left right as it crosses the barrier. So it just picks up speed until it's like "Oh! I need to go right now." as it's pushing left with lots of angular momentum so it just majorly overshoots everything. It's kind of the bad way it's coded.
And the reason it overshoots is because if the code recognises you to the left, it will KEEP PUSHING MAXIMUM right torque until it decides it needs to push left right as it crosses the barrier. So it just picks up speed until it's like "Oh! I need to go right now." as it's pushing left with lots of angular momentum so it just majorly overshoots everything. It's kind of the bad way it's coded.
Lemniscate Biscuit
ㅤㅤHelp DeskㅤㅤRL10 Expert
Modder
Team Judge
TEAM HAWK
Moon Maker
Atlas
Under Pressure
Registered
MOTY 2023
Lemniscate Biscuit
ㅤㅤHelp DeskㅤㅤRL10 Expert
Modder
Team Judge
TEAM HAWK
Moon Maker
Atlas
Under Pressure
Registered
MOTY 2023
Lemniscate Biscuit
ㅤㅤHelp DeskㅤㅤRL10 Expert
Modder
Team Judge
TEAM HAWK
Moon Maker
Atlas
Under Pressure
Registered
MOTY 2023
I don't think the issue is with low TWR (i've used it with a 0.02 TWR successfully). The problem seems to occur (when set to prograde) when the prograde direction is rotating clockwise and crosses 180. The space craft rotates in the wrong direction (anti-clockwise), overshoots the target and keeps on spinning. I've taken a look at the source code and might have a fix for the wrong direction issue. The overshoot is much more difficult to solve however. I've made a few attempts but they only seem to introduce other issues.
Lemniscate Biscuit
ㅤㅤHelp DeskㅤㅤRL10 Expert
Modder
Team Judge
TEAM HAWK
Moon Maker
Atlas
Under Pressure
Registered
MOTY 2023
Lemniscate Biscuit
ㅤㅤHelp DeskㅤㅤRL10 Expert
Modder
Team Judge
TEAM HAWK
Moon Maker
Atlas
Under Pressure
Registered
MOTY 2023
Your video seems to confirm the issue I found. Check the prograde direction - it is very close to -180 or 180 deg. The work around ro prever the spin is to
1) Turn SAS off when the prograde direction is close to this point.
2) Wait until the prograde direction passes this point.
3) Manually repoint to prograde, taking care to ensure the new orientation is both close to prograde and clockwise of 180/180
4) Turn SAS back on to keep the orientation.
The bug does not seem to be triggered by low thrust directly, but you are more likely to cross the critical direction with SAS set to prograde when using low thrust.
I made a fork of the source code to see if I could fix this. So far I have half a fix. Preventing the turn in the wrong direction was quite easy, preventing overshoot is much more difficult - you need to determine the angular acceleration (or whatever the correct term is) to decide when to reverse or switch off torque. I attempted to estimate the angular accelleration by the change in angular velocity between calls, but this was badly under-estimated sometimes. My first try seemed to work fairly well for high moment-of-inertia craft but introduced problems with low moment-of-inertia craft - they would either not rotate at all or spin.
More research is needed to try and find a better way to get the angular accelleration. There is a field/property in Rocket.rb2d called simply 'inertia'. Since there is already a 'mass' property it might be moment of inertia - will need to investigate. Also, there should be a way to get the torque from values in the parts. Once I can figure out the units used it should be possible to get a minimum angular accelleration. Another part that can generate torque is a swivelled engine - it might be possible to calculate this, but it looks difficult. A third way to generate torque is from assymetric engines but SAS cannot control this so I can probably ignore it.
The above looks like it could take too much time. I could try one of the following:
1) tidy up the code to remove the commented out 'overshoot prevention' attempts and create a github pull request (the first time I have tried this) so pixelgaming579 can merge in the changes if he wants to.
2) Alternatively, I could try and package the fork with its tiny fix and post the link here (again the first time I've tried to do this).
3) Wait until I have plenty of time and attempt the complete fix.
Ideas?
1) Turn SAS off when the prograde direction is close to this point.
2) Wait until the prograde direction passes this point.
3) Manually repoint to prograde, taking care to ensure the new orientation is both close to prograde and clockwise of 180/180
4) Turn SAS back on to keep the orientation.
The bug does not seem to be triggered by low thrust directly, but you are more likely to cross the critical direction with SAS set to prograde when using low thrust.
I made a fork of the source code to see if I could fix this. So far I have half a fix. Preventing the turn in the wrong direction was quite easy, preventing overshoot is much more difficult - you need to determine the angular acceleration (or whatever the correct term is) to decide when to reverse or switch off torque. I attempted to estimate the angular accelleration by the change in angular velocity between calls, but this was badly under-estimated sometimes. My first try seemed to work fairly well for high moment-of-inertia craft but introduced problems with low moment-of-inertia craft - they would either not rotate at all or spin.
More research is needed to try and find a better way to get the angular accelleration. There is a field/property in Rocket.rb2d called simply 'inertia'. Since there is already a 'mass' property it might be moment of inertia - will need to investigate. Also, there should be a way to get the torque from values in the parts. Once I can figure out the units used it should be possible to get a minimum angular accelleration. Another part that can generate torque is a swivelled engine - it might be possible to calculate this, but it looks difficult. A third way to generate torque is from assymetric engines but SAS cannot control this so I can probably ignore it.
The above looks like it could take too much time. I could try one of the following:
1) tidy up the code to remove the commented out 'overshoot prevention' attempts and create a github pull request (the first time I have tried this) so pixelgaming579 can merge in the changes if he wants to.
2) Alternatively, I could try and package the fork with its tiny fix and post the link here (again the first time I've tried to do this).
3) Wait until I have plenty of time and attempt the complete fix.
Ideas?
Lemniscate Biscuit
ㅤㅤHelp DeskㅤㅤRL10 Expert
Modder
Team Judge
TEAM HAWK
Moon Maker
Atlas
Under Pressure
Registered
MOTY 2023
I think I've managed to fix (or at least reduce) to overshoot problem. I made a fork of the mod in github and amended it. I've been play testing it for a while and haven't found any problems - apart from turning being a bit slow.
I added a turn rate limiter control to the UI to set the 'strength' of the turn rate limiting:
A value of 0 switches off new feature entirely. Higher values (up to 9) reduce the overshoot and the expense of the maximum turn rate. A value of 5 seems the best compromise. It seems to work well with RCS turning - use higher values to conserve fuel.
I also forked "Info Overload" to display some extra values I needed for debugging this:
I put in a pull request for both these changes about a month ago, but no response yet. This is the first time I've attempted a pull request on github - it is possible I've missed something.
Since these are very small changes to an existing mod it does not seem right to create a build and post it here.
I added a turn rate limiter control to the UI to set the 'strength' of the turn rate limiting:
A value of 0 switches off new feature entirely. Higher values (up to 9) reduce the overshoot and the expense of the maximum turn rate. A value of 5 seems the best compromise. It seems to work well with RCS turning - use higher values to conserve fuel.
I also forked "Info Overload" to display some extra values I needed for debugging this:
I put in a pull request for both these changes about a month ago, but no response yet. This is the first time I've attempted a pull request on github - it is possible I've missed something.
Since these are very small changes to an existing mod it does not seem right to create a build and post it here.
My fix is not exactly a PID controller (I don't think so anyway I haven't quite grasped how a PID controller works). It uses the maximum angular accelleration (calculated as torque/mass - SFS does not seem to use moment of inertial) to check if it can stop in time and turn off the torque being applied if it cannot.
There were a couple of issues: There is some sort of constant needed to adjust for the time step length - but I could not determine what it is so I added the turn rate limiter control to set this constant. I also needed it to stick with a decision (on whether to slow rotation or not) for a short time (I used 20 ticks) otherwise it would turn on and off so rapidly that it would never go anywhere.
There were a couple of issues: There is some sort of constant needed to adjust for the time step length - but I could not determine what it is so I added the turn rate limiter control to set this constant. I also needed it to stick with a decision (on whether to slow rotation or not) for a short time (I used 20 ticks) otherwise it would turn on and off so rapidly that it would never go anywhere.