This project is going to have to go on hold for a bit as my computer monitor decided that it didn't like me and blew it's transformer. I've looked but been unable to find a good replacement transformer, so I have to wait until pay day to get a new monitor. I posted this from my wife's laptop, but I've never been able to get the hang of coding from here...
Project Universal Fly By Wire - Progress Report in first post
- Thread starter lassombra
- Start date
Hi lassombra,
Sorry I didn't get back to you sooner - I get distracted easily.
I had actually been thinking of implementing something similar, myself. Namely, attempting to hook all thruster related methods and re-implementing them using the RCS class - would be kinda cool to be able to maneuver docked vessels using their thrusters as a single unit
I think you might be being a little ambitious, however. There are some things on your list which I think are just not possible or, at least, very difficult to achieve with very little gain.
For instance, thruster pulsing - where your thrusters are either 100% on or 100% off - will be problematic if you require a pulse of a shorter duration than the current simulation time step! You could fake it by setting a reduced thruster level which delivers the equivalent force - but that leaves you back where you were do begin with :lol:
Having said that, since I was playing around with some of the same ideas, I would be happy to share any code which overlaps with your goals, though I'm not sure if I want to commit myself to the project code-wise just yet. I'd be more than happy to discuss ideas and implementation techniques, though. We could perhaps get new ideas and perspectives off each other.
Sorry to hear about your computer. Laptop coding isn't that bad once you get used to it! Thought my laptop is running Ubuntu, so I need to switch to the Windows PC when I want to against Orbiter. One of the reasons the RCS class is so decoupled from Orbiter is so I could do most of the development on the laptop
Sorry I didn't get back to you sooner - I get distracted easily.
I had actually been thinking of implementing something similar, myself. Namely, attempting to hook all thruster related methods and re-implementing them using the RCS class - would be kinda cool to be able to maneuver docked vessels using their thrusters as a single unit
I think you might be being a little ambitious, however. There are some things on your list which I think are just not possible or, at least, very difficult to achieve with very little gain.
For instance, thruster pulsing - where your thrusters are either 100% on or 100% off - will be problematic if you require a pulse of a shorter duration than the current simulation time step! You could fake it by setting a reduced thruster level which delivers the equivalent force - but that leaves you back where you were do begin with :lol:
Having said that, since I was playing around with some of the same ideas, I would be happy to share any code which overlaps with your goals, though I'm not sure if I want to commit myself to the project code-wise just yet. I'd be more than happy to discuss ideas and implementation techniques, though. We could perhaps get new ideas and perspectives off each other.
Sorry to hear about your computer. Laptop coding isn't that bad once you get used to it! Thought my laptop is running Ubuntu, so I need to switch to the Windows PC when I want to against Orbiter. One of the reasons the RCS class is so decoupled from Orbiter is so I could do most of the development on the laptop
Nice. I use Gentoo mostly myself, but as you say, Orbiter is strictly windoze which isn't so bad. I virtualize windows when I can in linux, and virtualize linux in windows when I can't.
The reason for the pulse concept is because it is something that is provided by every single Nasa space craft from Apollo on and I suspect vessels before that used it to. Astronauts use it regularly during docking operations, and I can't really see a good reason to not implement it.
In the real thing the pulse is implemented by providing a specific amount of fuel to the rcs pods. The same effect can be created using time and thruster level to ensure it burns a specific amount of fuel and the same amount every time. The advantage is that 5 pulses nose up can be precisely zeroed with 5 pulses nose down. Right now, in orbiter, we often require quite a bit more RCS allowance than real astronauts have because our control system is highly inefficient. Most new pilots (and some experienced ones) perform attitude changes by holding the turn key for a bit, and then slamming the kill rot key when aligned (too late) and then waste more fuel going back and forth.
I have my heart set on providing a pulse mode. I've already done 2/3 of the implementation of that in my head anyways. I generally am ambitious with my projects, and perhaps the wishlist will be whittled down some, but I think for the most part, it's there to stay.
Finally I hope I don't have to compete with you project wise, as I guarantee I wouldn't win. I am hoping that with the breadth of this project, I'll see some interest in it, but at the same time, I'm not expecting anything too special. As of right now, I have for this project a single MFD which spits out useful information for development, and a controller which captures inputs for the craft which was active when the simulation started. More details on my trac whenever I can keep it up (it's hosted on my computer which since it doesn't have a screen is hard to diagnose issues...).
The reason for the pulse concept is because it is something that is provided by every single Nasa space craft from Apollo on and I suspect vessels before that used it to. Astronauts use it regularly during docking operations, and I can't really see a good reason to not implement it.
In the real thing the pulse is implemented by providing a specific amount of fuel to the rcs pods. The same effect can be created using time and thruster level to ensure it burns a specific amount of fuel and the same amount every time. The advantage is that 5 pulses nose up can be precisely zeroed with 5 pulses nose down. Right now, in orbiter, we often require quite a bit more RCS allowance than real astronauts have because our control system is highly inefficient. Most new pilots (and some experienced ones) perform attitude changes by holding the turn key for a bit, and then slamming the kill rot key when aligned (too late) and then waste more fuel going back and forth.
I have my heart set on providing a pulse mode. I've already done 2/3 of the implementation of that in my head anyways. I generally am ambitious with my projects, and perhaps the wishlist will be whittled down some, but I think for the most part, it's there to stay.
Finally I hope I don't have to compete with you project wise, as I guarantee I wouldn't win. I am hoping that with the breadth of this project, I'll see some interest in it, but at the same time, I'm not expecting anything too special. As of right now, I have for this project a single MFD which spits out useful information for development, and a controller which captures inputs for the craft which was active when the simulation started. More details on my trac whenever I can keep it up (it's hosted on my computer which since it doesn't have a screen is hard to diagnose issues...).
Interesting - I hadn't thought of that. Have you tested it in Orbiter to see if it works as expected?
I'm trying to correct that
Thanks for the vote of confidence, but you don't have to worry! I'm more or less just experimenting - I doubt it will ever be a finished product. If anything, I'm more interested in creating code that can be re-used in other peoples projects. I'm currently playing around with some autopilot code which could ease the creating of MFDs requiring autopilot functionality.
Interesting... how are you doing this? My plan was to stuff all attitude thrusters into a user thruster group, and create my own attitude thrusters for interception purposes. For it to be robust, I'd need to also hook thruster management functions... not sure if I will have any luck there.
I have to a limited extent. I'm right now more working on the input stuff.
You and me both apparently.I'm trying to correct that
Add-ons for Add-ons... I like it.
That's pretty much exactly what I did. It actually works pretty well.
Similar threads
