Check positioner motion when constructing TargetsAvailable. #264
Conversation
The TargetsAvailable class stores the initial list of targets to consider for each positioner. This is before any checks for collisions or the remaining obs for each target. Previously, the check for whether these targets are physically reachable was done at the same time as collision checks during assignment. This work moves that "physically reachable" check to the earlier step when computing TargetsAvailable. So now the available targets that are written to the output include this constraint. Closes #263.
|
It's clear what you're trying to do so it largely looks good to me. Maybe Stephen can still verify. |
|
A clarification note since it wasn't clear to me: previously FAVAIL / POTENTIAL_ASSIGNMENTS HDUs included targets that were close enough to consider even if upon further inspection it turned out that they weren't physically reachable. This PR updates that so that only physically reachable targets are included (which are the ones we care about for the HDU). |
|
That's correct. The decision of physically reachable has now been moved before the FAVAIL HDU is defined and therefore included in that decision. Before, it was a decision based solely on the arm lengths. So, e.g. for the reduced reach in SV data (that was implemented by theta, phi restrictions) objects that were in FAVAIL were very much not reachable. |
The TargetsAvailable class stores the initial list of targets
to consider for each positioner. This is before any checks for
collisions or the remaining obs for each target. Previously,
the check for whether these targets are physically reachable was
done at the same time as collision checks during assignment.
This work moves that "physically reachable" check to the earlier
step when computing TargetsAvailable. So now the available targets
that are written to the output include this constraint.
Closes #263.