Quote from: OTV Booster on 02/28/2023 09:50 amWhile writing the two posts above it struck me that if the depot and other ship are physically tightly bound the control systems had also better be tightly bound.Would it be best if the Depot completely took over and controlled both ships? Every cooperative arrangement that I come up with for settling thrust and attitude control seems to get more complicated the deeper I get into it. The last thing we want is the two ships fighting each other because of minor calibration issues.It seems like it would be a relatively straightforward thing to use the IMU's and star trackers from one ship to feed the control computers in both. AFAIK, they use Ethernet protocol networking to communicate within the vehicle, getting one of the flight computers to poll the network on the other ship shouldn't be that difficult. They generally seem to prefer to keep the control computers as close as physically possible to the thing they'll be controlling (for example, the engine controller is mounted directly to the side of each engine), so I think it's unlikely they would want to send commands across the ship-ship link. For simplicity they could also just have one ship be operating dumb, just providing a fixed amount of ullage thrust while the other handles orientation.
While writing the two posts above it struck me that if the depot and other ship are physically tightly bound the control systems had also better be tightly bound.Would it be best if the Depot completely took over and controlled both ships? Every cooperative arrangement that I come up with for settling thrust and attitude control seems to get more complicated the deeper I get into it. The last thing we want is the two ships fighting each other because of minor calibration issues.
A SpaceX example of the Master/Slaving of the Guidance computer sets is the F9/D2 stack. The Dragon is the master of everything until separation. Once a stage separates away it is then its own master. The SS and SH will likely operate similar to F9 in the implementation of the software. The question would be which of the two vehicles Tanker/Depot would have all the added software loaded to run as a super master of a pair of SS with the other having software to be SS slave. The SS operating as a slave would not be a normal as it is currently software set on a SS. That software would probably look very similar to the software on the SH to enable it to be a slave to the SS.SpaceX has successfully done it before on F9 so doing it for the Depot/Tanker case should not prove that difficult. Especially once they prove out the software for the Master/Slave full stack Starship launch software packages.
Quote from: OTV Booster on 02/28/2023 09:50 amWhile writing the two posts above it struck me that if the depot and other ship are physically tightly bound the control systems had also better be tightly bound.Would it be best if the Depot completely took over and controlled both ships? Every cooperative arrangement that I come up with for settling thrust and attitude control seems to get more complicated the deeper I get into it. The last thing we want is the two ships fighting each other because of minor calibration issues.It will certainly be true that the coupled pair of ships (tanker/depot, depot/target, or even tanker/target) will form a single controlled system. Whether one ship acts as the master or they operate cooperatively is too far in the weeds even for me.However, this has a direct impact on the physical coupling of the pair. I doubt that it's advisable to have the pair tandem free-flying and get this to work--the control loop is just too diffuse, and even the kinematics of the pair will get weird. Even a loosely coupled but flexible berthing will induce unpredictable oscillations that may be hard to damp out.This is why I expect the berthing to be capable of handling decent-sized loads between the two ships with minimal flex and oscillation.Just to review the bidding on things we've talked about for attitude control, prox ops, and ullage acceleration. From smallest torques/translations to largest:1) CMGs (I think you guys have convinced me that this might be useful).2) Cold gas RCS, fed from ullage pressure only.3) Cold gas RCS, fed from supercritical COPVs.4) Combusting gas RCS/thrusters, fed from supercritical COPVs.I'm pretty sure you need #4 no matter what, if for no other reason than ullage acceleration needs more impulse than can be readily generated without the enthalpy of combustion, and SpaceX likely has to develop them for lunar landing and takeoff ops. Then the question becomes what combination of #1-#3 is needed for fine attitude control, both coupled (during refueling) and uncoupled (during attitude maintenance to minimize boil-off).Just remember that the minimum impulse bit for any thrusters can be relatively large for Starship, because the total mass and moments of inertia are so large.
ISTM that depot should be the master. Presumably it's the one with mission specific hardware. Why do differently for the mission specific software? The mission in this case is propellant transfer.
I'm pretty much in agreement but think about decision by committee. Committees are good at finding the questions to ask (and a lot of irrelevant questions) and defining responses that are unacceptable, but making decisions? LoL. Everything would boil off before the two ships reach consensus.
Quote from: OTV Booster on 02/28/2023 08:40 pmISTM that depot should be the master. Presumably it's the one with mission specific hardware. Why do differently for the mission specific software? The mission in this case is propellant transfer.Shouldn't make a bit of difference. It's a computer network. Which bits get twiddled by which CPU is an almost arbitrary choice. If I were doing it, I'd let both CPUs be either master or slave. No doubt you make one the preferred choice, but either one should be able to take over in the event of a failure.The more interesting choices are how you separate the CPUs from the various I/O systems. Do you let a master on one vehicle reach across and tweak I/O (i.e., directly command thrusters or CMGs) on the other vehicle, or do you relay commands through the slaved CPU? Keeping everybody in sync, so any element can take over in the event of a failure, is hard.Quote from: OTV Booster on 02/28/2023 09:18 pmI'm pretty much in agreement but think about decision by committee. Committees are good at finding the questions to ask (and a lot of irrelevant questions) and defining responses that are unacceptable, but making decisions? LoL. Everything would boil off before the two ships reach consensus.It's not a committee. It's a set of coupled FSMs that are carefully coordinated by defining a protocol containing the events needed to keep the system behaving properly. Yes, master/slave is often a very simple (and very effective) basis for writing your state machines and defining the events. But think about this more like cloud computing than two people arguing over the best course of action.
In the pair of SS case it is correct to think that either computer set could do the work of the first 2 levels but only the local computers can do the last 2 levels since the control loops need to be tight and reliable. It is that which keeps the general initial stability of the pair. The higher levels must deal with control loop interference patters by 2 vehicles doing active stabilization. Fortunately it may be possible to cheat some here in that the torques involved are mostly small and slow to build to being problems. Allowing the higher level to then dampen them out.Active control systems are a headache.
A SpaceX example of the Master/Slaving of the Guidance computer sets is the F9/D2 stack.
The Dragon is the master of everything until separation. Once a stage separates away it is then its own master.
. . . think about decision by committee. Committees are good at finding the questions to ask (and a lot of irrelevant questions) and defining responses that are unacceptable, but making decisions? LoL. Everything would boil off before the two ships reach consensus.
Quote from: OTV Booster on 02/28/2023 09:18 pm . . . think about decision by committee. Committees are good at finding the questions to ask (and a lot of irrelevant questions) and defining responses that are unacceptable, but making decisions? LoL. Everything would boil off before the two ships reach consensus.When you use "committees" of computers, it's called distributed computing. There has been a great deal of work done to resolve the problem of making such a system reach consensus. In the most general case, this is a fiendishly difficult problem. Algorithms like Paxos are used to solve it, and they are not easy to wrap your head around. They also tend to be relatively slow, so you normally only use these to let a set of contending processors elect a leader. For example, when I was at Microsoft on the project now called Bing, we had to coordinate thousands of servers which individually had half-lives of a year or so. To oversimplify a bit, we used Paxos to let them elect a leader, and, if the leader failed, to replace it. For all the problems we had with Bing over the years, Paxos never failed us. Individual servers failed, but the ensemble was immortal.With one or more Starships trying to do formation flying, it doesn't seem like there would be all that many processors involved, so something like Paxos would probably be overkill, but it proves there is at least a solution that is known to work.
Quote from: Greg Hullender on 03/16/2023 05:00 pmQuote from: OTV Booster on 02/28/2023 09:18 pm . . . think about decision by committee. Committees are good at finding the questions to ask (and a lot of irrelevant questions) and defining responses that are unacceptable, but making decisions? LoL. Everything would boil off before the two ships reach consensus.When you use "committees" of computers, it's called distributed computing. There has been a great deal of work done to resolve the problem of making such a system reach consensus. In the most general case, this is a fiendishly difficult problem. Algorithms like Paxos are used to solve it, and they are not easy to wrap your head around. They also tend to be relatively slow, so you normally only use these to let a set of contending processors elect a leader. For example, when I was at Microsoft on the project now called Bing, we had to coordinate thousands of servers which individually had half-lives of a year or so. To oversimplify a bit, we used Paxos to let them elect a leader, and, if the leader failed, to replace it. For all the problems we had with Bing over the years, Paxos never failed us. Individual servers failed, but the ensemble was immortal.With one or more Starships trying to do formation flying, it doesn't seem like there would be all that many processors involved, so something like Paxos would probably be overkill, but it proves there is at least a solution that is known to work.As you said, figuring out which node is authoritative is an extensively solved problem.What's considerably more difficult is the distributed control problem. The difference between a properly controlled system and one that isn't is often determined by command and feedback lag. That lag may often be determined by how many layers of mediation the control loop has to go through to execute a command.If you can get a master on one Starship to directly control thrusters and read sensors on the other Starship, without having a slaved controller to mediate the commands, the control loop can be tightened up substantially. But you need to have a very good handle on things like dropped packets and failover for that to be a viable strategy.There was a discussion over on the Artemis thread about the Gateway Docking System Specification using time-triggered ethernet, which allows a synchronous, congestion-free channel to co-exist with vanilla switched ethernet. Something like that would be a key enabler in letting one master reach deep into the I/O network of another spacecraft to shorten control lags.I still think formation flying is nuts. But the same problem applies to pairs of Starships that are docked and need to coordinate ullage and attitude burns.
Do flocks of geese fly together by controlling each other or by having a central authority control them all?No, they follow the vortices of the goose in front of them. That in turn naturally makes a V formation.No reason why such emergent behavior can't be done for mating fuel tanks in orbit. The math for this is still a bit obscure but I bet SpaceX knows it.
Once things are lashed up and coms latency becomes important it's essentially a point to point connection. If each ship controls its own hardware the com link would be unrouted and only pass instructions like "rotate 2degrees Y+. NETBIOS over ARCnet? It'd be PDQ.
Quote from: OTV Booster on 03/18/2023 07:13 pmOnce things are lashed up and coms latency becomes important it's essentially a point to point connection. If each ship controls its own hardware the com link would be unrouted and only pass instructions like "rotate 2degrees Y+. NETBIOS over ARCnet? It'd be PDQ.Jeez, you must be as old as I am. The 80's called and they want their PHY and transport API back. (I wrote an ARCnet driver for CP/M, and I implemented a NetBIOS that used an XNS transport. How's that for a geezer smackdown?)Seems like everything's switched ethernet today, and there's this time-triggered ethernet which will provide isochronous performance.But I don't think you can message something like "rotate x degrees". First of all, that command doesn't mean anything if the other ship is rotating x degrees at the same time. Second of all, you need closed-loop control with a very, very short delay between sensor input and thruster output. Otherwise, you'll oscillate, which consumes lots of prop if you're lucky and kills you if you're unlucky.This is why I was suggesting that, while distributed quorum-sensing is a necessary condition, I doubt it's sufficient. If I were doing this, I'd use quorum-sensing to designate a master GN&C CPU to seize control of the relevant I/O strings on both spacecraft, and to read sensors and command thrusters as if it were all one big system.I don't know how tight the control loop needs to be, though. If it's ~100ms, you can pretty much do anything you want. But if it's <1ms, dropped packets (not an uncommon occurrence in a noisy environment) can make things weird.
IIRC, STS had 5 computers. Four were similar and worked in concert. If there was no consensus, decision making was shifted to the 5th computer which was dissimilar and completely independent. I am sure someone else will have better recall than I.
In a more serious vein, the data environment before and after lash up are very different. Pre lash up, ISTM that keeping one ship passive while the other maneuvers keeps the risk low. Passive in this case doesn't mean dead. It means holding attitude but not otherwise maneuvering.After lash up the rules change. Both ships need to (probably) work together for ullage settling and attitude control. But...If the depot has CMG's and can thrust off axis with TVC on the settling engine, it should be able to handle everything. And, once they're lashed up they can have a physical low noise data connection. As you suggested, the second ships sensors would become an extension of the depot. Control systems could be tied in too if necessary.Some questions:- What are the chances the sensors and controls on SS are a data buss sharing network?- Can off axis thrust be made a virtue during transfer? It imposes a certain type of order on slosh.
