So TLW, at the end of the day, all your objections are in the form of “this method isn’t perfect” or “this method will have issues that are fundamental theorems”.
And you’re right. I’m taking the perspective of, having built smaller scale versions of networked control systems, using a slightly lossy interface and an atomic state update mechanism, “we can make this work”.
I guess that’s the delta here. Everything you say as an objection is correct. It’s just not sufficient.
At the end of the day, we’re talking about a collection of vehicles. Each is somewhere between the size of a main battle tank and a human sized machine that can open doors and climb stairs. All likely use fuel cells for power. All have racks of compute boards, likely arm based SOCs, likely using TPUs or on-die coprocessors. Hosted on these boards is a software stack. It is very complex but at a simple level it does :
perception → state state representation → potential action set → H(potential action set) → max(H) → actuators.
That H, how it evaluates a potential action, takes into account (estimates of loss, isActionAllowed, gain_estimate(mission_parameters), gain_estimate(orders)).
It will not take an action if not allowed. (example, if weapons disabled it will not plan to use them). It will avoid actions with predicted loss unless the gain is high enough. (example it won’t normally jump out a window but if $HIGH_VALUE_TARGET is escaping around the corner, the machine should and will jump out a window, firing in midair before it is mission killed on impact, when the heuristic is tuned right)
So each machine is fighting on it’s own, able to kill enemy fighters on it’s own, assassinate VIPs, avoid firing on civilians, unless the reward is high enough [it will fire through civilians if the predicted gain is set high enough. These machines are of course amoral and human operators setting “accomplish at all costs” for a goal’s priority will cause many casualties].
The coordination layer is small in data, except for maybe map updates. Basically the “commanders” are nodes that run in every machine, they all share software components where the actual functional block is ‘stateless’ as mentioned. Just because there is a database with cached state and you send (delta, hash) each frame in no way invalidates this design. What stateless means is that the “commander” gets (data from last frame, new information) and will make a decision based only on the arguments. At an OS level this is just a binary running in it’s own process space that after each frame, it’s own memory is in the same state it started in. [it wrote the outputs to shared memory, having read the inputs from read only memory]
This is necessary if you want to have multiple computer redundancy, or software you can even debug. FYI I actually do this, this part’s present day.
Anyways in situations where the “commander” doesn’t work for any of the reasons you mention...this doesn’t change a whole lot. Each machine is now just fighting on it’s own or in a smaller group for a while. They still have their last orders.
If comm losses are common and you have a much larger network, the form you issue orders in—that limits the autonomy of ever smaller subunits—might be a little interesting.
I think I have updated a little bit. From thinking about this problem, I do agree that you need the software stacks to be highly robust to network link losses, breaking into smaller units, momentary rejoins not sufficient to send map updates, and so on. This would be a lot of effort and would take years of architecture iteration and testing. There are some amusing bugs you might get, such as one small subunit having seen an enemy fighter sneak by in the past, then when the units resync with each other, fail to report this because the sync algorithm flushes anything not relevant to the immediate present state and objectives.
So TLW, at the end of the day, all your objections are in the form of “this method isn’t perfect” or “this method will have issues that are fundamental theorems”.
And you’re right. I’m taking the perspective of, having built smaller scale versions of networked control systems, using a slightly lossy interface and an atomic state update mechanism, “we can make this work”.
I guess that’s the delta here. Everything you say as an objection is correct. It’s just not sufficient.
At the end of the day, we’re talking about a collection of vehicles. Each is somewhere between the size of a main battle tank and a human sized machine that can open doors and climb stairs. All likely use fuel cells for power. All have racks of compute boards, likely arm based SOCs, likely using TPUs or on-die coprocessors. Hosted on these boards is a software stack. It is very complex but at a simple level it does :
perception → state state representation → potential action set → H(potential action set) → max(H) → actuators.
That H, how it evaluates a potential action, takes into account (estimates of loss, isActionAllowed, gain_estimate(mission_parameters), gain_estimate(orders)).
It will not take an action if not allowed. (example, if weapons disabled it will not plan to use them). It will avoid actions with predicted loss unless the gain is high enough. (example it won’t normally jump out a window but if $HIGH_VALUE_TARGET is escaping around the corner, the machine should and will jump out a window, firing in midair before it is mission killed on impact, when the heuristic is tuned right)
So each machine is fighting on it’s own, able to kill enemy fighters on it’s own, assassinate VIPs, avoid firing on civilians, unless the reward is high enough [it will fire through civilians if the predicted gain is set high enough. These machines are of course amoral and human operators setting “accomplish at all costs” for a goal’s priority will cause many casualties].
The coordination layer is small in data, except for maybe map updates. Basically the “commanders” are nodes that run in every machine, they all share software components where the actual functional block is ‘stateless’ as mentioned. Just because there is a database with cached state and you send (delta, hash) each frame in no way invalidates this design. What stateless means is that the “commander” gets (data from last frame, new information) and will make a decision based only on the arguments. At an OS level this is just a binary running in it’s own process space that after each frame, it’s own memory is in the same state it started in. [it wrote the outputs to shared memory, having read the inputs from read only memory]
This is necessary if you want to have multiple computer redundancy, or software you can even debug. FYI I actually do this, this part’s present day.
Anyways in situations where the “commander” doesn’t work for any of the reasons you mention...this doesn’t change a whole lot. Each machine is now just fighting on it’s own or in a smaller group for a while. They still have their last orders.
If comm losses are common and you have a much larger network, the form you issue orders in—that limits the autonomy of ever smaller subunits—might be a little interesting.
I think I have updated a little bit. From thinking about this problem, I do agree that you need the software stacks to be highly robust to network link losses, breaking into smaller units, momentary rejoins not sufficient to send map updates, and so on. This would be a lot of effort and would take years of architecture iteration and testing. There are some amusing bugs you might get, such as one small subunit having seen an enemy fighter sneak by in the past, then when the units resync with each other, fail to report this because the sync algorithm flushes anything not relevant to the immediate present state and objectives.