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.
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_actioncallbacks withinsystem_orchestrator.cppwhile bidding and assigning transporter tasks are explicitly defined in thepick_and_place.xmlBT .WorkcellTaskfortransportersand bids within this BT.