Tutorial: Adding end-to-end custom navigation capabilities to Nav2

[NOTMOVETON]

The tutorial will cover:

Making a custom Navigator to handle behavior trees
Building a new Task Server with custom interfaces
Writing Behavior Tree nodes for control (start, pause, cancel)
Writing the Behavior Tree itself
Connecting all parts into a working system
Making plugins for adding more features later

First, I will explain the problem I worked on. I will talk about the decisions I made about existing servers and other stuff. After i will start to adapt solution to open source, with all the new parts that have been implemented.

I will try to make everything work well with the official NAV2 project. In the end, someone learning from the guide should just clone my code and run it with their own config.

I also think it is a good idea to make several different examples of Behavior Trees and plugins. This will help cover all possible problems in the code and design.

I would like to know if you have any requests or ideas before I begin working.

[SteveMacenski]

I completely agree that that would be useful. The Task Server could point to the existing tutorial on the task server, but having an example of a new task server + integration into the system + the navigator to leverage it with a meaningfully changed high-level API would be useful. Opennav Coverage and another project I'm working on right now that will likely be open sourced are good examples of this -- but I think having a toy example that's more generic would be useful.

First, I will explain the problem I worked on.

A diagram when talking about the architecture would be really nice I think to show Action Message -> Navigator -> BT blackboard population / feedback / result / error codes -> BT node for calling the server using that information -> task server would be great.

I also think it is a good idea to make several different examples of Behavior Trees and plugins. This will help cover all possible problems in the code and design.

What did you have in mind?

[NOTMOVETON]

What did you have in mind?

I'll try to explain everything in detail. The answer regarding the behavior trees comes near the end of this message; first, I want to provide as much context about the task as possible.

The problem I was solving looked roughly like this: we have a predefined route (a path defined outside of NAV2) that the robot must follow. Replanning or significant deviation from this path is not allowed. At specific points along the path, the robot needs to perform certain non-navigation actions (e.g., turning on signal lights, setting a manipulator to a specific pose, or toggling onboard equipment).

Since the WaypointFollower is tied to specific waypoints rather than specific points along a continuous path, and (correct me if I'm wrong :)) it doesn't easily support defining multiple actions at a single point or different actions at various points, I decided to create a server capable of handling this. That is how CommanderServer was born.

Abstractly speaking, we needed a service that allows executing various combinations of actions (even simultaneously) while maintaining a unified communication interface.

CommanderServer does not track the path, the current waypoint, or the robots position. Its sole purpose is to provide a universal interface for performing non-navigation tasks - whether long-running or instantaneous - and execute them via Command plugins. Theoretically, CommanderServer could even be used without navigation, acting simply as an entity that executes actions.

To fully integrate with NAV2, I created a new .action message type that contains the path, the action execution points, and the actions themselves. Lets call it ManagedPath (this name will be changed when porting the code). I also created a new navigator plugin that accepts a request in this format, populates fields in the blackboard, and launches the required behavior tree.

Regarding the behavior trees: several nodes were implemented to support CommanderServer, specifically a call node, a cancel node, and a pause node. Handling a "true" pause (not just cancellation + recall) was also a requirement, so CommanderServer, its plugins, and the navigator itself support this operation.

Pausing the tree itself was initially implemented using a custom node and some janky logic beneath, but once the PausedResumeController became available, the trees were rewritten to use this control node. There are many nuances to pausing, especially for actions that are instantaneous in trigger but continuous in duration. For example, consider a lawnmower robot: when paused, it shouldnot just stop moving; it must also stop the blade rotor. Although my actual task was different, I think this example illustrates one of the use cases well.

Now we come to the logic for the original problem: executing actions at specific points along the path. Since CommanderServer acts purely as an executor and doesnot track the current position or action trigger points, the logic for tracking these points was moved into the main behavior tree loop. A special decorator node monitors the current progress along the path and calls CommanderServer if a designated action point is reached.

Thus, to answer your original question, different behavior trees can cover the following scenarios:

• Executing unknown actions along an unknown path at unknown points. This information becomes available only after the tree starts.
• Executing known actions along an unknown path at known points. This could happen before following the path, after, or at a specific point calculated, for example, by path completion percentage (10%, 50%, etc.). Again, this varies from implementation to implementation.
• Executing known actions along a predefined path at predefined points. For example: use a default tree to drive to a certain point, then launch a tree to move straight with the blade rotor on, and finally turn off the rotor at the end.

I have outlined the basic variations of the trees. If dig deeper, much more complex behavior could be obtained, such as parallel navigation and action execution. However, for the purpose of the tutorial, I think these examples are sufficient, as there is already a lot to cover. As a bonus, I can also describe the problems I encountered during development, as there were plenty of such cases

I should also mention that this design was originally conceived for future use within a "Mission" framework I am currently working on (a sequence of trees to perform a specific task). That is largely out of scope for now, but if you are interested, we can discuss it in more detail at any time.

I hope I explained this clearly. I look forward to your feedback and questions! :)

[SteveMacenski]

it doesn't easily support defining multiple actions at a single point or different actions at various points

Ish. You could make a plugin that has itself plugins which does particular action triaging, but yeah the WPF is mostly demoware 👍

CommanderServer does not track the path, the current waypoint, or the robots position.
To fully integrate with NAV2, I created a new .action message type that contains the path, the action execution points, and the actions themselves.

Is this relatively similar to the Behavior Server then as a host of plugins sharing common expensive resources? What reasons do we have for a common server rather than allowing the path-actions to be decoupled - like do these share important attributes, resources, etc?

Also, why not have the server track progress or use information in the BT about the tracking state from onLoop feedback? In main now, we have tracking information to have the path, the robot pose, and the closest point on the path to the robot. So actually that information could just be passed through and/or used in the BT (for Rolling and newer).

Thus, to answer your original question, different behavior trees can cover the following scenarios:

I imagine the .action definition(s) need to cover all of these cases? Do you have examples for when we'd want to do each of those (and any other execution policies we should consider)? This would be good to explain not only here to me, but also in the tutorial for examples :-)

However, for the purpose of the tutorial, I think these examples are sufficient, as there is already a lot to cover

Agreed. At the end you could reference 'some ways you can use this in action' to hint at these.

I should also mention that this design was originally conceived for future use within a "Mission" framework I am currently working on (a sequence of trees to perform a specific task). That is largely out of scope for now, but if you are interested, we can discuss it in more detail at any time.

Please! Always interested and maybe something we can integrate into Nav2 / the ecosystem as well!

[NOTMOVETON]

> Ish. You could make a plugin that has itself plugins which does particular action triaging, but yeah the WPF is mostly demoware 👍

Yes, I came to a similar idea regarding changing controllers at runtime, but I havent implemented it yet. Overall, it sounds logical.

> Is this relatively similar to the Behavior Server then as a host of plugins sharing common expensive resources?

Yes, something like that. I considered offloading this task to the Behavior Server, but since we needed a unified interface for all actions, I couldn't figure out how to implement it other than by analogy with the Controller Server: where each plugin has different internal execution logic but accepts the same input format.
Literally while writing this response, I realize that I could have used the idea you suggested above — a "plugin containing plugins" for Behavior Server. That probably would have been more logical, but whats done is done. The analogy with the Behavior Server is good, and I remember relying on it during design, though I havent mentioned it here yet. Essentially, Commander Server is a Behavior Server that looks like a Controller Server: the server itself is an Action Server, and the plugins are different implementations of the execution logic. Something like that i would say.

> What reasons do we have for a common server rather than allowing the path-actions to be decoupled - like do these share important attributes, resources, etc?

There aren't any "heavy" resources like a costmap yet, but I can highlight the unified interface for calls (if that counts as a resource) and the shared hardware state. For example, turning on a lawnmower rotor is an instantaneous action (trigger), but the state of "being on" is continuous over time. When calling the Commander Server, the state of the executing plugin is preserved and used during pause/stop/resume events.
All these path-actions are essentially independent; they are just united by a single server (or rather, its interface) for convenience when working both within the BT and without it.

> Also, why not have the server track progress or use information in the BT about the tracking state from onLoop feedback?

Again, it all depends on the tree. I tried to design the BT node for calling CommanderServer so it could be used anywhere and in any way. If the server tracks progress, we become tied to the requirement that CommanderServer can only execute actions if a path exists.
Consequently, if we want the following behavior: "Turn on blades -> DriveOnHeading (5 meters) -> Turn off blades", we wouldn't be able to do this because CommanderServer would rely on path feedback, which DriveOnHeading does not generate.
That is precisely why I decided to split this into two nodes: an action node for the call and a decorator for point tracking. This expands capabilities and allows using Commander Server both while following a path and without one. Similarly, the tracking decorator allows triggering not only the Commander Server node but other nodes as needed. I’ll provide detailed examples below.

> In main now, we have tracking information to have the path, the robot pose, and the closest point on the path to the robot. So actually that information could just be passed through and/or used in the BT (for Rolling and newer).

As far as I recall, this functionality wasnt available in Humble yet (which is what I was working on), or perhaps I just missed it/didn't think of it at the time :)

> I imagine the .action definition(s) need to cover all of these cases? Do you have examples for when we'd want to do each of those (and any other execution policies we should consider)?

Essentially yes, but it does so in a generic way. I'll try to break down two types of trees completely: from task formation to the trees and CommanderServer plugins. And, of course, I will reflect all of this in the tutorial.

Let's start with the message definition. I've omitted some fields used in production to keep it clean:

# goal
string behavior # path to desired Behavior Tree file
nav_msgs/Path path
int64[] action_point_index # e.g. at point 1: [1, 1, 1] -> [InvokeCommand11, InvokeCommand12, InvokeCommand13]
vehicle_msgs/InvokeCommand[] action # just 2 int64s: command_id and command_value
---
# result
std_msgs/Empty result
uint16 error_code
string error_msg
---
# feedback
# Nothing for demo

I should mention that the interface for executing a single action is vehicle_msgs/InvokeAction[], and the interface for CommanderServer itself is vehicle_msgs/InvokeAction[] too, because there is actually some more functionality in Commander Server that i wouldnt talk about in this message. Briefly, some commands could be "grouped" to became like a single command. This was done due to the defined command interface - vehicle_msgs/InvokeAction, and this feature can be used for example to control 6DOF arm, if imagine that MoveIt2 doesnt exist.

Why is vehicle_msgs/InvokeAction just two integers? Those were the requirements: all commands are encoded by two values — an ID and a command value. It looks strange and inconvenient, and yes, it is. Better use a json.

So, the message itself may or may not contain a path, a location for the desired behavior tree, an array of points where actions need to be executed, and the actions themselves. You can also specify a single point multiple times, which means multiple actions will be executed at that point. All of this is grouped when calling the Navigator, and then the Blackboard is populated with these values. Theoretically, an empty message could arrive, in which case we take the default tree and execute (or not execute) something depending on that specific tree.
This message covers all the necessary cases for me, and all the logic is offloaded to the BT specified in the message.

Let's imagine we receive an external message in the following simplified (but hopefully clear) format:

behavior: drive_and_do.xml
path: [p1, p2, p3, p4, p5]
action_point_index: [1, 1, 4, 4, 4, 5]
action: [{0, 1}, {1, 1}, {0, 0}, {1, 0}, {15, 180}, {15, 0}]

Before explaining the logic, here is a bit about Commander Server configuration to help understand what it does (in YAML format):

bt_navigator: ...
controller_server: ...

commander_server:
  ros__parameters:
    controller_frequency: 10.0 # Internal plugin loop frequency, similar to Controller Server
    command_plugins: ["ControlRotor", "ControlSignalLights", "SetCameraYaw"]
    ControlRotor:
      plugin: "custom_commander_plugins::UniversalSerial"
      instant: true # If true, the plugin's completion function isn't waited on (like isGoalReached in Controller Server). We know it's instant.
      action_id: 0 # Used for identification and sending to Serial. The plugin knows 0 == rotor.
    ControlSignalLights:
      plugin: "custom_commander_plugins::UniversalSerial"
      instant: true
      action_id: 1
    SetCameraYaw:
      plugin: "custom_commander_plugins::ControlServo"
      instant: false # Runs until the target is reached by the plugin. Duration unknown.
      action_id: 15
      some_other_parameter_for_this_plugin: "something"

Now, decoding the message: at point 1, turn on the rotor and signal lights; at point 4, turn them off, and also at point 4, rotate the camera to position 180; at point 5, return camera to position 0.
The message says nothing about what 180 or 1 means (degrees, bananas?). Each plugin interprets this in its own way.

When called, the Navigator updates variables in the Blackboard. I won't describe all fields, just the ones necessary for the tree.
point_commands is formed by decorator to pass relevant commands, path is path field.

Example A: Unknown actions / unknown points (Reactive Approach)

<root BTCPP_format="4" main_tree_to_execute="MainTree">
  <BehaviorTree ID="MainTree">

  <!-- To ensure the call reaches Commander Server at the right moment, 
       I use a ReactiveSequence and place the action call before the movement -->
  <ReactiveSequence>
    <!-- Decorator node for path tracking -->
    <CommandUpdater global_frame="map" robot_base_frame="base_link" point_commands="{point_commands}">
      <!-- Node calling CommanderServer -->
      <MakeCommand point_commands="{point_commands}"/>
    </CommandUpdater>
    
    <FollowPath path="{path}" controller_id="FollowPath" goal_checker_id="goal_checker_loose"/>

  </ReactiveSequence>

  </BehaviorTree>
</root>

At start, as long as robot starting from index 0 of the path, the server is called with the corresponding actions from point_commands field. Then movement along the path occurs. At points 4 and 5, actions are also executed. Non-instant actions block the execution of FollowPath, causing the robot to stop. For my specific task, this was the desired behavior, though this approach might need refinement for other use cases.

Thus, we have defined a message and a tree to solve the "unknown actions along an unknown path at unknown points" scenario.

Example B: Known actions / Predefined points

For scenarios like "known actions along a predefined path at predefined points," we can specify a different tree (do_predefined.xml):

<root BTCPP_format="4" main_tree_to_execute="MainTree">
  <BehaviorTree ID="MainTree">

  <Sequence>
    <!-- "0;1;1;1" represents [{command_id, command_value}, {command_id, command_value}] -->
    <MakeCommand point_commands="0;1;1;1"/>
    
    <DriveOnHeading dist_to_travel="5.0" speed="0.2" time_allowance="30"/>

    <MakeCommand point_commands="0;0;1;0"/>

  </Sequence>

  </BehaviorTree>
</root>

Even if we sent a path and points in the message, if do_predefined.xml is specified, neither the path nor the points from the message will be used, as everything is determined by the tree. So yes, the .action message covers all cases, and the logic depends on the user input and the tree itself.

I also want to add that one of the reasons for implementing this behavior within Nav2 was simply that we don't have our own BT execution engine, and Nav2's is ready-made and quite convenient :)

Regarding Navigators: we use different plugins for different task types to group available trees and bind them to specific Navigators. Since we need many trees with different Blackboard requirements, doing everything in one "God-object" Navigator would be complex, slow, and illogical to me, so adding another one was not a problem.

The above is a simplified version. In reality, there are many other factors to consider, as well as additional functions we only touched upon, like pause and resume.

> Please! Always interested and maybe something we can integrate into Nav2 / the ecosystem as well!

I plan to start a separate repository for this concept soon. May I tag you there once I've described the architecture and the idea itself? I would be very pleased to hear your opinion.

I am slowly starting to port the code, and soon I will be able to publish it so you can see what is actually under the hood. Naturally, I will simplify most of it so the tutorial isnt too tedious to read.

Do you have any remaining questions? Id like to finalize the vision for the tutorial and start working, but if you feel some things need clarification, I'm all ears!

[SteveMacenski]

Hi,

First off - I appreciate the enthusiasm to help to provide all the detail. I think perhaps you should distill thoughts a bit more for me, this is a difficult amount to read and respond to which will affect my ability to give you feedback or address concerns in a timely manner.

---

a "plugin containing plugins" for Behavior Server. That probably would have been more logical, but whats done is done.

I think what you did is better than putting in the Behavior Server; separation of concerns is also good. The purpose of this tutorial as well is integrating a new task server so that wouldn't meet the purpose either :-)

For example, turning on a lawnmower rotor is an instantaneous action (trigger), but the state of "being on" is continuous over time. When calling the Commander Server, the state of the executing plugin is preserved and used during pause/stop/resume events. All these path-actions are essentially independent; they are just united by a single server (or rather, its interface) for convenience when working both within the BT and without it.

But not fully independent, if states are being shared between them like the "being on" state?

Consequently, if we want the following behavior: "Turn on blades -> DriveOnHeading (5 meters) -> Turn off blades", we wouldn't be able to do this because CommanderServer would rely on path feedback, which DriveOnHeading does not generate.

Doesn't your .action goal require a path? How would this example look functionally speaking in your .action file without a path?

As far as I recall, this functionality wasnt available in Humble yet (which is what I was working on), or perhaps I just missed it/didn't think of it at the time :)

Correct, but that information is readily available for you now :-)

int64[] action_point_index # e.g. at point 1: [1, 1, 1] -> [InvokeCommand11, InvokeCommand12, InvokeCommand13]
vehicle_msgs/InvokeCommand[] action # just 2 int64s: command_id and command_value

I think we should discuss this for clarity, but this is details work for later in a PR review -- I think. But maybe we have a message that groups the IDX + the command array together, so the message is an array of these grouped IDX + command(s). Also, if we make the action points as coordinates, then it could either be pose members of the path or freespace coordinates in general. Though the 20%-30%-40% I'm not sure.

I thought you said that you could support not just path IDX but actual poses, 50% through the path, etc. I don't see how that's represented here (at least cleanly).

May I tag you there once I've described the architecture and the idea itself?

Sure thing :-)

---

Something I'm thinking about while reading through this is maybe this is better as a straight-up nav2 contribution that we can do a proper design architecture and integration with the stack for. Maybe there's a simpler example we can show end users for the tutorial, because this has alot going on in it of itself to explain that is separate from the tutorial's mission in general.

A server framework for executing arbitrary use-case specific actions at particular points along a path, at freespace coordinates, etc seems generally useful in Nav2 or at least Nav2 Auxiliary. If we did this for the tutorial only, I think maybe we should strip down the action definition and complete flexibility a bit to be more straight forward.

[NOTMOVETON]

First off - I appreciate the enthusiasm to help to provide all the detail. I think perhaps you should distill thoughts a bit more for me, this is a difficult amount to read and respond to which will affect my ability to give you feedback or address concerns in a timely manner.

Ok, sorry about that :)

But not fully independent, if states are being shared between them like the "being on" state?

One plugin = one piece of the system\device. I think I am confusing both myself and you at this point, so I will try to provide the full code by the start of next week so you can see it for yourself. Also, I plan to use a lawnmower robot as the example, is that cool?

Doesn't your .action goal require a path? How would this example look functionally speaking in your .action file without a path?

No, actually the .action goal requires nothing.The Behavior Tree determines if they are required or ignored. If the BT needs a path (drive_and_do.xml): The client must provide it. If path is empty, the Controller Server inside the tree will return an error. If the BT implies no path (do_predefined.xml): The path field in the message can be empty. The Navigator simply sets whatever it received to the blackboard. If empty, then empty. As always - it all depends on the specific tree.

Also, if we make the action points as coordinates, then it could either be pose members of the path or freespace coordinates in general.

Agreed, great idea. I will do it like that. Pose + action.

I thought you said that you could support not just path IDX but actual poses, 50% through the path, etc. I don't see how that's represented here (at least cleanly).

Yeah, it might not be as clear as it should be. I think the best way is to rework the current implementation slightly because it is a bit funny to use right now. But if we use the CommandUpdater decorator, it would look something like this:

<root BTCPP_format="4" main_tree_to_execute="MainTree">
  <BehaviorTree ID="MainTree">
  <Sequence>
    <!-- New node here, but it exists in my solution. Custom parser for vector<InvokeActionArray[]> in bt_conversions.hpp-->
    <PathToManagedPath input_path="{path}" 
                         triggers="0.2; 0.5; 0.9" 
                         commands="0,1,1,1; 0,0,1,1; 15,180"
                         output_managed="{managed_path}"/>
    <ReactiveSequence>
      <!-- implicitly use managed_path variable-->
      <CommandUpdater global_frame="map" robot_base_frame="base_link" point_commands="{point_commands}">
        <MakeCommand point_commands="{point_commands}"/>
      </CommandUpdater>
      <FollowPath path="{path}" controller_id="FollowPath" goal_checker_id="goal_checker_loose"/>
    </ReactiveSequence>
  <Sequence>
  </BehaviorTree>
</root>

I will try to make working with CommanderServer as clear as possible, but it will require some time.

Sure thing :-)

Great, thank you :)

maybe this is better as a straight-up nav2 contribution that we can do a proper design architecture and integration with the stack for

Yes, I was thinking about this too. I think it is a wonderful opportunity. Should I create an issue in the main Nav2 repository?

Maybe there's a simpler example we can show end users for the tutorial, because this has alot going on in it of itself to explain that is separate from the tutorial's mission in general.

Agreed, otherwise the tutorial would be too large and all-encompassing. On the other hand, I personally missed having something like this when learning. In any case, I agree that the tutorial shouldnt be made too large or overly complex.

Wondering how to simplify the .action msg and the pipeline itself.
So - list of some reworkings:

• Message for "posed" action
• Cant imagine how to get rid of decorator node, so probably leave it but modify to work with positions instead of idx.
• Pause/Resume functionality will be cut out
• Simple navigator that checks that request has all attributes (path basically)
• Simplified tree for path following and making commands
• BT nodes that explicitly use some fields, and maybe some modifications to MakeCommand node

In general I have assumed that tutorial would cover a lot of things, but you're right that there is actually too much going on, and it is better as separate instance in NAV2 or NAV2 Auxiliary. And also probably it would be easy to make some other sort of tutorial based on this as part of NAV2. What do you think?

[SteveMacenski]

Also, I plan to use a lawnmower robot as the example, is that cool?

Very cool :-)

If empty, then empty. As always - it all depends on the specific tree.

Got it. There may be some value in being more formal with this (i.e. have the action notify the system what is provided so that it can proactively reject if the needed components are not available, split into multiple navigators dependent on inputs and navigation styles, etc). Having one message to rule-them-all that is unclear as to the field meanings, which are required when, how they're parsed when the content means different things, etc is not a great user design experience for general purpose use IMO.

I'm going to ignore the BT for now, but it seems like this design in general could use some more formality / strictness.

Should I create an issue in the main Nav2 repository?

Yes - I think we should have a design overview and especially narrow in on the action definitions and formality of fields.

Also probably it would be easy to make some other sort of tutorial based on this as part of NAV2. What do you think?

Yeah I think so. Maybe something vastly more concise like a task server to follow a precomputed path (which gives you the custom navigator bit) and along the path perform action(s) at particular points of interest (BT nodes, custom server). Less catch-all framework, more specific implementation. Open doors, turn on lights/implement, take a picture, etc. Basically the waypoint executors from the WPF. Maybe you can make this a server of plugins yet, but be formal and do the one thing specifically rather than trying to do many things with many triggers through a single .action interface -- for tutorial value.

We have other servers in Nav2 that are basically complications on the tutorials (i.e. RPP vs Pure Pursuit) so there's good heritage for that. Maybe also this simpler one would help us in flushing out the formality bits to add in the additional complications of the various triggers and event information encoding.

For example, rather than 2x ints for the action ID and data payload, we can have a more general purpose message:

std_msgs/Header header

# Named implement identifier (e.g., "blade", "arm", "lights")
string action_name

# Continuous values (levels, positions, speeds, etc.)
# Key examples: "height", "angle", "flow_rate", "speed"
float32[] float_states

# Discrete boolean states
# Key examples: "enabled", "lights_on", "active"
bool[] bool_states

# Integer states (modes, gear positions, etc.)
# Key examples: "mode", "gear", "tool_id"
int32[] int_states

# String states (codes, semantics, etc.)
# Key examples: "barn", "image_name"
string[] string_states

Even if most fields were not used, the overhead of this message is tiny in comparison to even a nav_msgs/Path of any meaningful length (> 5 poses).

---

I'm not saying to do this, but a motivational idea: If, for example, the NavigateThroughPoses used those BT nodes / server, then at waypoints you could also trigger those behaviors. So the tutorial-based code could have a life of its own later for user extensions. They'd just need to pipe in their actions (via modifications to the navigator / .action or simply another BT node that subscribes to an events-at-poses topic).

[SteveMacenski]

PS I have this graphic I use in presentations that may be useful

[NOTMOVETON]

Having one message to rule-them-all that is unclear as to the field meanings, which are required when, how they're parsed when the content means different things, etc is not a great user design experience for general purpose use IMO.

I agree. The generic "rule-them-all" message was too ambiguous. Your proposed structure with named and typed fields (float_states, bool_states, etc.) is much better for UX and type safety. I will adopt that design.

Yes - I think we should have a design overview and especially narrow in on the action definitions and formality of fields.

Great. I will open a Design Overview issue in the ros-navigation/navigation2 repository by the end of this week. For futher, let's call this server Operation Server?

Maybe you can make this a server of plugins yet, but be formal and do the one thing specifically rather than trying to do many things with many triggers through a single .action interface -- for tutorial value.

Understood. For the tutorial, I will aim for a specific, concise implementation.

They'd just need to pipe in their actions (via modifications to the navigator / .action or simply another BT node that subscribes to an events-at-poses topic).

That is an interesting perspective regarding the "events-at-poses" topic. It makes a lot of sense.

I will get to work on the architecture design. I'll reply here with the link to the Issue once I open it, and then we can move the technical discussion there.

At this point i will respond here when the tutorial (fully or partly) and code for it would be completed.

[SteveMacenski]

Operation Server

Maybe just Operations Server

[NOTMOVETON]

A quick update: things took a bit longer than expected, high load on main work. Now I am ready for review.

I did encounter the issue regarding blocking vs. non-blocking actions that you mentioned. I think I know how to solve it, but it feels like it falls out of the scope of this tutorial, and i should leave things as it is. It probably makes sense to discuss it in the issue, especially since the tutorial is already becoming quite lengthy

Here is the link to repo with source code and tutorial itself.

[NOTMOVETON]

@SteveMacenski
Please check it out