Shuttle-A (an orbiter stock model) unable to turn cleanly to prograde, retrograde, et

[LeePalmer]

Shuttle-A (an orbiter stock model) unable to turn cleanly to prograde, retrograde, etc.
It wallows to position. It is overshooting and struggles to achieve the correct attitude.

This also happens with the Attitude RCS MFD.
Framerates are at 40-50 whilst testing.
MFD rate:0.05secs

Scenario: Shuttle-A/ISS approach

Looking at Attitude RCS mfd code.
1. I believe that the shuttle-A's PMI has not been factored correctly.
It may be that its defined PMI is wrong.

Also the time acceleration fudge factor looks a little interesting.

Lee Palmer

 

[PhantomCruiser]

I just gave this a look. It's been a while since I've flown a Shuttle-A...

I only went up to 100x time acceleration, but it didn't wallow very much for me.

Right after loading the scenario I hit the prograde button, there was a maybe 5 degree overshoot, but it came back to heading and didn't move from it until I commanded retrograde. Again a 5-10 degree overshoot then steady on. Same with Orbit Normal and Anti-normal.

I did it again with a station module docked on the nose and it was truly all over the place. I'd use manual rotation until I got close, then engaged the autopilot.

 

[LeePalmer]

My

My bad. I was not clear.

These are two separate issues.
1.
In normal time the Shuttle-A 'wallows' going almost anywhere. Using the prograde, retrograde buttons. Compare it to the DG. It lands on target.
The Shuttle-A does not. It wastes propellant!!!

2.
If RCS attitude is used, it wallows even more.

In the code for the MFD RCS attitude. I can see that the is PMI not used in the setting of the attitude thrusters. Hence the wallowing, well maybe.

Also the time step is used to adjust the damping. It seems not right?

If there is a commonality between the c++ code (standard buttons) and the lua code in the MFD, then maybe the both mishandle the PMI bit.


Regards Lee

 

[PhantomCruiser]

I can't reproduce your issue with RCS or autopilot with the -A. But you are right about the DG being more responsive.

In an instrument mechanic by trade. Perhaps 1/4 wave damping is something I don't notice anymore?

 

[Face]

In the code for the MFD RCS attitude.

Perhaps the MFD mode you are using is the culprit for the wonky behavior you've observed.

 

[PhantomCruiser]

Are you using this?
https://www.orbithangar.com/searchid.php?ID=3165

 

[LeePalmer]

I have used it, but it is not currently engaged.

Attitude MFD is not active in the modules.


Attitude RCS is in luacode. And appears to have used the PMI the wrong way. I was testing with craft other than the stock DG. Even the DG behaves slightly wonky when using this MFD.
But the _A is it much worse.

Face:
Attitude RCS is used by orbiter core?

That is my question, are the normal Prograde, Retro, functions,
tuned to the DG only. I will test other ships ability to home on target.

They should all lock to prograde-retrograde like the DG. Slower turning moments maybe, but hit prograde on the nose.

I don't believe I have tweeked the _A in any way, so it should come to heel like the DG. Slower, but with just as much accuracy.

 

[Face]

I have used it, but it is not currently engaged.

Attitude MFD is not active in the modules.


Attitude RCS is in luacode. And appears to have used the PMI the wrong way. I was testing with craft other than the stock DG. Even the DG behaves slightly wonky when using this MFD.
But the _A is it much worse.

Face:
Attitude RCS is used by orbiter core?

That is my question, are the normal Prograde, Retro, functions,
tuned to the DG only. I will test other ships ability to home on target.

They should all lock to prograde-retrograde like the DG. Slower turning moments maybe, but hit prograde on the nose.

I don't believe I have tweeked the _A in any way, so it should come to heel like the DG. Slower, but with just as much accuracy.

I think we have some terminology mismatches here.

Orbiter uses internal compiled algorithms to implement the usual prograde-retrograde autopilots. Those work fine on my end, even for the Shuttle_A. Yes, the systems on that vessel class are slushy, but that's correct for the workhorse it is. After one or two overshoots, it is rock solid on the selected attitude, even at x10.

You are talking about some lua code. This is not what I understand under core autopilots. You may be running some attitude control script from the Orbiter distro's /Script/ folder in a lua MFD, but this is not the core autopilot. It could well be that whatever script you are running is unstable for certain vessel classes.

IMHO, lua scripts often suffer from that kind of problems. Perhaps lua is not suited for these jobs due to its interpreted nature?

About the "it should" part: it is not easy to create a perfect control-loop that only controls simulated actuators to achieve a simulated attitude in a simulated world that works for all kinds of simulated PMIs and thruster configurations. OTOH, it would be easy to simulate that perfect control-loop: just gradually bring the nose into the expected position.

You will have to define what you want: do you want a game with perfectly working automated systems, or do you want a simulator where systems are realistically controlled? I think Orbiter's compromise here is a good one.

 

[LeePalmer]

Orbiter is amazing.

I am busy carpeting huge areas of Mars caynons using
meshs, then trying induce wrinkles, folds and lumps in the meshs that look
semi-natural. Then dropping a moonbus down the canyon at night for the hell of it.
Lighting is not perfect but it is fun when a whole set run down the valley.
It is a success if one them stays upright!



https://www.orbithangar.com/searchid.php?ID=1932

Terminology is getting in way.


"OTOH, it would be easy to simulate that perfect control-loop: just gradually bring the nose into the expected position."

Indeed from trillion ton asteriod to 30 kg space hopper they should all end with their noses on the mark. Its motion should be a one great circle arc from start attitude to finish attitude. It is in space, it is frictionless. Overshooting or missing the target indicates an issue?

Thank confirming that the core prograde, retro is not using 'attitude RCS'

Finding that the luascript 'Attitude RCS' is relatively wafty. I went back to core prograde,retro functions, to discover the shuttle_a does not behave
like the DG. I believe it should. A trillion tonner is not going to turn like the DG. But overshoot or missing the attitude might not look good to a professional. I wonder how many keel haulings you would get.

Kind Regards

Lee

 

[Face]

Terminology is getting in way.

For me, terminology is essential in engineering communication. If you can't agree on short words acting as placeholders for complex and often abstract concepts, you'd be lost pretty quickly. I see this basic principle violated often in my professional life, where marketing twists a well established term until nobody knows what you are even talking about anymore. It is especially painful if they even forbid you to ever use the previous term again. :lol:

A trillion tonner is not going to turn like the DG. But overshoot or missing the attitude might not look good to a professional. I wonder how many keel haulings you would get.

Well, I'm a professional automation engineer, specialized in software development. IMHO, creating a hardware/software combination to control a real-world vehicle is already a hard problem with a given scenario. E.g. creating a controller to auto-pilot an Airbus 321 is not trivial.

Now creating a controller to control ANY arbitrary real-world vehicle out-of-the-box just as good as the dedicated controller does for one specific vehicle in one specific scenario is almost impossible. You can create generic algorithms/hardware to be almost perfect on a given set, but never on everything-and-its-kitchen.

So you have to decide: should Orbiter pretend to have found the perfect controller for every vessels class and fake the perfect attitude operation, or should it use a generic algorithm that actually controls the simulated thrusters? Personally, I'm happy with the later.

A middle way would be possible, too: change the stock system to use a generic, but parameterized algorithm and add functions to the API to set the parameter-set for every vessel class individually. This would mean that developers have to tune those parameters, which would not be too different from implementing a dedicated algorithm for the class in the first place.

So as I said: I think Orbiter made a reasonable compromise.