NASA published the field-test writeup on September 15. The summer exercise asked whether the fleet could pursue human-set goals, react to a new finding, reassign work, and keep the original task from dying.
That matters for uncrewed outer-planet missions and for lunar or Martian terrain that is too risky for astronauts. Communications delay makes joystick science a fantasy; the useful test is priority, risk, and fallback.
NASA did not publish a numeric success rate, latency, or how much of the stack is learned versus rule-based. Read this as architecture under field conditions, not as flight-ready autonomy.
If you build robot software, the checklist from this test is concrete: a shared world model, explicit risk and priority policies, operator override, and logs that explain why a task changed.
NASA’s ASTRA team — Adaptive Sensing Technology for Responsive Autonomy — field-tested a three-robot fleet at the Virginia Tech Transportation Institute in Blacksburg. A drone chose an area of interest from human science goals; the fleet then decided which robot should investigate.
The robots kept checking for hazards, revised the plan as new information arrived, and reported back. The point is not a demo of driving. It is whether a machine team can act like a science team when Earth is too far away to talk in real time.