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
Nexus relies on the service IsTaskDoable to query which workcell can perform a specific task.
The task itself is made of both a plain string type and a YAML payload. However, in the current implementation, the workcell orchestrator only checks whether a behavior tree exists with the requested type and doesn't do anything with the payload.
There might be cases where multiple workcells can perform the same type of task and the differentiating factor is in the payload itself, or cases in which a a workcell might be able to support a wide category of tasks but only a subset of payloads.
It should be possible to configure the function that checks whether a workcell can perform a task and implement more complex behaviors.
The text was updated successfully, but these errors were encountered:
Some context for this, there were some discussion on this. In general there are 2 paths that we can take
A DIY approach where you have some table/database of which workcell can do which task with which payload etc. This should be low-code/no-code, users shouldn't have to compile anything.
An automatic approach where each node/hardware driver can examine the payload and report if it can do the task. The biggest problem with this is that payloads must have a predefined schema, and there are too many variables for us to create a standard format.
These 2 approach are not mutually exclusive so we can have a mix of both.
I'd like to rely on plugins which the orchestrator can load to decide whether the task can be performed. ie, plugins would implement a can_perform_task() like method. Checking whether the bt file exists in the local filesystem can be one such implementation. We can also define other plugins as described by @koonpeng above.
Nexus relies on the service IsTaskDoable to query which workcell can perform a specific task.
The task itself is made of both a plain string
type
and a YAMLpayload
. However, in the current implementation, the workcell orchestrator only checks whether a behavior tree exists with the requestedtype
and doesn't do anything with the payload.There might be cases where multiple workcells can perform the same type of task and the differentiating factor is in the payload itself, or cases in which a a workcell might be able to support a wide category of tasks but only a subset of payloads.
It should be possible to configure the function that checks whether a workcell can perform a task and implement more complex behaviors.
The text was updated successfully, but these errors were encountered: