step() accepts a full action on the launch step but uses three of its fields and drops the rest.
The launch branch sets rocket_launched, computes the initial state from launch_inclination_heading, and builds the Flight. It never reads action["tvc"], action["roll"] or action["throttle"]. Those are first read on the next call, in the else branch.
The action space presents all of them as one action for one timestep, and an agent has no way to tell that three of the fields it filled in went nowhere.
How much it actually costs
Not much, today. The launch step does not advance the flight either, so there is no simulated interval those commands could have applied to. The first interval that is simulated uses the next action, which the agent gets to choose. So nothing is silently mis-simulated; the contract is just unstated.
It matters more now that the actuators have first-order lag. A command history that starts one step later starts the filters one step later too, and that is the kind of thing worth pinning rather than leaving to be rediscovered.
Two ways to settle it
Transition only. Document the launch action as a state transition whose control fields are not used, and say so in the action space docs. Cheapest, and matches what happens.
Every action applies. Keep the launch action's control values as the pending command so they become the first simulated interval's input.
Either is defensible. What is not great is accepting the fields and discarding them without saying so.
A test with non-default throttle, tvc and roll on the launch action would pin whichever is chosen.
Found while reviewing #39 for the v0.1.0 release notes. Not a release blocker, and listed under known limitations there.
step()accepts a full action on the launch step but uses three of its fields and drops the rest.The launch branch sets
rocket_launched, computes the initial state fromlaunch_inclination_heading, and builds theFlight. It never readsaction["tvc"],action["roll"]oraction["throttle"]. Those are first read on the next call, in theelsebranch.The action space presents all of them as one action for one timestep, and an agent has no way to tell that three of the fields it filled in went nowhere.
How much it actually costs
Not much, today. The launch step does not advance the flight either, so there is no simulated interval those commands could have applied to. The first interval that is simulated uses the next action, which the agent gets to choose. So nothing is silently mis-simulated; the contract is just unstated.
It matters more now that the actuators have first-order lag. A command history that starts one step later starts the filters one step later too, and that is the kind of thing worth pinning rather than leaving to be rediscovered.
Two ways to settle it
Transition only. Document the launch action as a state transition whose control fields are not used, and say so in the action space docs. Cheapest, and matches what happens.
Every action applies. Keep the launch action's control values as the pending command so they become the first simulated interval's input.
Either is defensible. What is not great is accepting the fields and discarding them without saying so.
A test with non-default
throttle,tvcandrollon the launch action would pin whichever is chosen.Found while reviewing #39 for the v0.1.0 release notes. Not a release blocker, and listed under known limitations there.