[Feature request]: Consider having a `~/plan/action` component
Maintainers usually reply within 15 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- python
- Domain
- distributed-systems
Research direction
Start by reading the plan message's trajectory segment fields and how plan_executor handles departure_action and arrival_action. The issue proposes an Action and ActionProgress component on ~/plan/action/, with custom executors publishing progress on ~/plan/action/progress; identify the message definitions and execution entry points before estimating the design. Done means an action can be dispatched to an executor and its progress reported, but the issue leaves the interface details open.
Written by the indexing model from the issue text.
Description
Before proceeding, is there an existing issue or discussion for this?
- I have done a search for similar issues and discussions.
Description
In the plan message each trajectory segment generally consists of a departure_action and an arrival_action. These are meant to be workflows which you execute. Ideally, we would use crossflow, but as we want to be flexible as to what executor can use we should perhaps use an RPC call from our plan_executor to the relevant process execution node. For this we should consider adding a ~/plan/action node.
Implementation Considerations
One option is to directly extend the Progress message with an additional field. This would make sense if the agent is the one executing an action. It makes a lot less sense when the executor may be used to orchestrate multiple devices centrally.
The better option IMO would be to introduce an Action and ActionProgress field which publishes on the ~/plan/action/ component so we could have custom executors that listen for Action messages execute them and publish the progress of the execution on the ~/plan/action/progress topic.
Alternatives
No response
Additional information
No response
- Dominant language
- Python
- Stars
- 10
- Forks
- 9
- Avg merge
- 3h 21m
- Merged PRs (30d)
- 1
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from open-rmf/next_gen_prototype
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 8/100
open-rmf/next_gen_prototype#81 ·
Maintainers usually reply within 15 days
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 35/100
open-rmf/next_gen_prototype#66 ·
Maintainers usually reply within 15 days
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 15/100
open-rmf/next_gen_prototype#65 · 2 comments ·
Maintainers usually reply within 15 days
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 42/100
open-rmf/next_gen_prototype#57 ·
Maintainers usually reply within 15 days
-
enhancement
Difficulty 3/5 1-2 days Newbie friendliness 68/100
open-rmf/next_gen_prototype#52 ·
Maintainers usually reply within 15 days
All issues in open-rmf/next_gen_prototype
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
deepchem/deepchem#5289 · 1 comment ·
Maintainers usually reply within 2 days
-
Difficulty 1/5 Under an hour Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 60/100
UKGovernmentBEIS/inspect_evals#2892 · 1 comment ·
Maintainers usually reply within 1 day
-
Versioning docs: say that no output from the 0.46 warning check means nothing is affectedPossibly taken @grelinfo claimed this today. Opendocumentation priority:low size:S
Difficulty 1/5 Under an hour Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
alphacrack/readme2demo#293 ·