You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At present when the system orchestrator receives a new Work Order (action goal), it implicitly assigns tasks within the Work Order to available workcells (see here).
However it would be better to refactor this logic into BT nodes for a number of reasons
Improve visibility on what the system orchestrator does by looking at the BT it executes. Right the workcell biding + assignment logic is embedded in the aclcpp_action callbacks within system_orchestrator.cpp while bidding and assigning transporter tasks are explicitly defined in the pick_and_place.xml BT .
To give more freedom to the user on when to bid for workcell assignments. Improve transparency in the main BT to execute by explicitly bundling bidding for workcells and transporters.
As we move towards integrating transporters as workcells, we can reuse these blocks to bid for transporters as well. This would help resolve https://github.com/osrf/nexus/pull/42/files#r1899919027 where a separate BT node was developed that creates a WorkcellTask for transporters and bids within this BT.
The text was updated successfully, but these errors were encountered:
At present when the system orchestrator receives a new Work Order (action goal), it implicitly assigns tasks within the Work Order to available workcells (see here).
However it would be better to refactor this logic into BT nodes for a number of reasons
aclcpp_action
callbacks withinsystem_orchestrator.cpp
while bidding and assigning transporter tasks are explicitly defined in thepick_and_place.xml
BT .WorkcellTask
fortransporters
and bids within this BT.The text was updated successfully, but these errors were encountered: