Request Bursts of RCS

[Koloss]

Dear all,

Yesterday I thought about the following:
Would it be possible to write an MFD or an add-on that changes the behaviour of the RCS thrusters?

Now the RCS thrusters just fire as long as you hold the button.
I would love to have an add-on which sends only a short burst out of the thrusters. It doesn't matter how long you hold down the button - it just goes "PFFT" and that's it.
Perhaps you - as a user - could even tell the add-on how long the burst should be.

Perhaps something like this is available? I didn't find anything in the Hangar.

What do you think?
I am only a user with absolutely no experience in C++ or C+ or I don't know what you use

:edit:
If you ask for the reason: It's a pain in the *ss to stop the rotation of a vessel without using KillRot.
It would be great to use the vessel like this: "Ok, I give three bursts rotation to the right.... done. Now three bursts to the left. No rotation!"

 

[Urwumpe]

Not sure if it can be implemented good in a MFD, but its not impossible for a vessel. Essentially, you would just need to reset a thruster after a given time and allow it to set again after cool-down period.

 

[4throck]

Some add-ons work like that (Project Mercury) so yes, certainly possible.

Another option might be to configure key-press repeat on Windows.
Don't know if the settings allow for a large enough delay:hmm:

 

[martins]

If you ask for the reason: It's a pain in the *ss to stop the rotation of a vessel without using KillRot.
It would be great to use the vessel like this: "Ok, I give three bursts rotation to the right.... done. Now three bursts to the left. No rotation!"

When implementing this, it is important to remember that Orbiter always applies thruster settings over an entire time step, and that step lengths can be variable. So in order to guarantee that "three left + three right = 0" you need to simulate sub-step resolution by instead modulating the thruster level in those intervals that should only have partial thruster action.

 

[Koloss]

When implementing this, it is important to remember that Orbiter always applies thruster settings over an entire time step, and that step lengths can be variable. So in order to guarantee that "three left + three right = 0" you need to simulate sub-step resolution by instead modulating the thruster level in those intervals that should only have partial thruster action.

So, because of my absolute lack of understanding of the internal mechanics of Orbiter: Is it possible? :lol:
I hope you didn't misunderstand my "pain in the *ss". I just wanted to say that it's almost impossible to stop a vessel from rotating without pressing KillRot.

 

[martins]

So, because of my absolute lack of understanding of the internal mechanics of Orbiter: Is it possible? :lol:

Yes, absolutely. I believe this has already been implemented in the Soyuz simulator built at IRS/Uni Stuttgart.
http://www.irs.uni-stuttgart.de/forschung/Soyuz-Simulator/index.en.html. I don't know if their codebase is public, but it might be worth asking.

I hope you didn't misunderstand my "pain in the *ss". I just wanted to say that it's almost impossible to stop a vessel from rotating without pressing KillRot.

No, I think it's a good idea.

 

[Thorsten]

Algorithmically it's not difficult. The solution I have chosen for the FG Shuttle is as follows (normalized control stick input is assumed to be between -1 and 1)

* sample-hold simulation time when the control is moved out of detent (i.e. away from zero)
* build the difference between current and sampled time
* if the difference is smaller than the pulse duration, send a 1, otherwise a zero
* release the sample/hold to current time when control is back in detent

-> you get a nice pulse signal whenever you move the control out of detent, to repeat the pulse you move it back into detent and repeat

(the actual algorithm is a bit more involved, as it sends a continuous firing signal when the stick is moved more than 50%, and the signal doesn't go to the thruster but just down one control layer, but that's the gist of it)

I can't help much with Orbiter coding, as I have no insight into where this would have to be done.

 

[boogabooga]

Everything the OP asks for exists already (for more than 5 years) here:
[ame="http://www.orbithangar.com/searchid.php?ID=4889"]Precession MFD[/ame]

"Precession MFD" is the worst named MFD in all of Orbiterhangar, IMHO. It is really a Swiss Army Knife of usefull utilities, most of which have nothing to do with "precession." The title does not do justice to all that it does. But, it is one of my favorite MFDs.

Unfortunatly, it is for Orbiter 2010 only.

 

[Face]

Everything the OP asks for exists already (for more than 5 years) here:
Precession MFD

"Precession MFD" is the worst named MFD in all of Orbiterhangar, IMHO. It is really a Swiss Army Knife of usefull utilities, most of which have nothing to do with "precession." The title does not do justice to all that it does. But, it is one of my favorite MFDs.

Unfortunatly, it is for Orbiter 2010 only.

The source code is included, but it is all rights reserved AFAICS. A recompile should be possible, but no re-distribution without contacting the author(s) first. Anybody know if these folks are still around?

 

[Koloss]

Everything the OP asks for exists already (for more than 5 years) here:
Precession MFD

"Precession MFD" is the worst named MFD in all of Orbiterhangar, IMHO. It is really a Swiss Army Knife of usefull utilities, most of which have nothing to do with "precession." The title does not do justice to all that it does. But, it is one of my favorite MFDs.

Unfortunatly, it is for Orbiter 2010 only.

If "my" idea is included in the MFD - perfect!
On the weekend I'll have a look, thanks a lot!

 

[boogabooga]

I don't think we've heard from Wishbone in years, and IIRC someone tried a recompile and it didn't work:
http://www.orbiter-forum.com/showthread.php?p=541034&postcount=27

 

[Face]

I don't think we've heard from Wishbone in years, and IIRC someone tried a recompile and it didn't work:
http://www.orbiter-forum.com/showthread.php?p=541034&postcount=27

Well, I've tried that too and got it going just fine. You need CSPICE, euler, KOST (modified a bit), nlopt and a bit of reverse-engineering for the missing bitmap header.
I had to fight a bit with the Eigen part, until I realized that it is not necessary at all. Looks like the code-base was a bit of a playground.

Runs nice in 2016, but without the author's permission it's all mood, anyway.

 

[N_Molson]

There is something like that implemented in Thorton's Soyuz-TMA addon.