Revision history [back]

Hi, developer/maintainer on Nav2 here.

Yeah, sorry about that. On the grand scheme of things a block diagram has been low priority. Also things have been changing and still subject to changes so we didn’t want to produce misinformation. Comments below represent the current state of things but also are subject to change.

The ins and outs of the move base diagram are the same. We need some map (from map server, slam, etc), some sort of positioning (TF) and various sensor data streams.

Now rather then a FSM move base, we use behavior trees (BT). Look more into BTs if you’re not familiar but they’re what you’d think. Trees of “stuff” to do rather than a loop with finite states. The BT navigator is the package containing the navigation implementation of a BT. This calls the nav2_{recoveries, planner, controller} servers. These servers host a map of plugins which have some algorithm implemented.

For the simplest case, the servers will have a single plugin like DWB or NavFn that will do control or planning. For more complex applications you can have different plugins for contextual needs.

The lifecycle manager just runs all the nodes through the managed nodes lifecycle. That’s subject to near term removal in favor of the launch system.

Hi, developer/maintainer on Nav2 here.

Yeah, sorry about that. On the grand scheme of things a block diagram has been low priority. Also things have been changing and still subject to changes so we didn’t want to produce misinformation. Comments below represent the current state of things but also are subject to change.

The ins and outs of the move base diagram are the same. We need some map (from map server, slam, etc), some sort of positioning (TF) and various sensor data streams.

Now rather then a FSM move base, we use behavior trees (BT). Look more into BTs if you’re not familiar but they’re what you’d think. Trees of “stuff” to do rather than a loop with finite states. The BT navigator is the package containing the navigation implementation of a BT. This calls the nav2_{recoveries, planner, controller} servers. These servers host a map of plugins which have some algorithm implemented.

For the simplest case, the servers will have a single plugin like DWB or NavFn that will do control or planning. For more complex applications you can have different plugins for contextual needs.

The lifecycle manager just runs all the nodes through the managed nodes lifecycle. That’s subject to near term removal in favor of the launch system.

Hi, developer/maintainer on Nav2 here.

Yeah, sorry about that. On the grand scheme of things a block diagram has been low priority. Also things have been changing and still subject to changes so we didn’t want to produce misinformation. Comments below represent the current state of things but also are subject to change.

The ins and outs of the move base diagram are the same. We need some map (from map server, slam, etc), some sort of positioning (TF) and various sensor data streams.

Now rather then a FSM move base, we use behavior trees (BT). Look more into BTs if you’re not familiar but they’re what you’d think. Trees of “stuff” to do rather than a loop with finite states. The BT navigator is the package containing the navigation implementation of a BT. This calls the nav2_{recoveries, planner, controller} servers. These servers host a map of plugins which have some algorithm implemented.

For the simplest case, the servers will have a single plugin like DWB or NavFn that will do control or planning. For more complex applications you can have different plugins for contextual needs.

The lifecycle manager just runs all the nodes through the managed nodes lifecycle. That’s subject to near term removal in favor of the launch system.

Costmaps exist in their respective servers, though again long term that may not be true. Moreover the concepts of a costmap are likely to be depreciated (by me) in the next year.

Hi, developer/maintainer on Nav2 here.

Yeah, sorry about that. On the grand scheme of things a block diagram has been low priority. Also things have been changing and still subject to changes so we didn’t want to produce misinformation. Comments below represent the current state of things but also are subject to change.

The ins and outs of the move base diagram are the same. We need some map (from map server, slam, etc), some sort of positioning (TF) and various sensor data streams.

Now rather then a FSM move base, we use behavior trees (BT). Look more into BTs if you’re not familiar but they’re what you’d think. Trees of “stuff” to do rather than a loop with finite states. The BT navigator is the package containing the navigation implementation of a BT. This calls the nav2_{recoveries, planner, controller} servers. These servers host a map of plugins which have some algorithm implemented.

For the simplest case, the servers will have a single plugin like DWB or NavFn that will do control or planning. For more complex applications you can have different plugins for contextual needs.

The lifecycle manager just runs all the nodes through the managed nodes lifecycle. That’s subject to near term removal in favor of the launch system.

Costmaps exist in their respective servers, though again long term that may not be true. Moreover the concepts of a costmap are likely to be depreciated in the next year.

Hi, developer/maintainer on Nav2 here.

Yeah, sorry about that. On the grand scheme of things a block diagram has been low priority. Also things have been changing and still subject to changes so we didn’t want to produce misinformation. Comments below represent the current state of things but also are subject to change.

The ins and outs of the move base diagram are the same. We need some map (from map server, slam, etc), some sort of positioning (TF) and various sensor data streams.

Now rather then a FSM move base, we use behavior trees (BT). Look more into BTs if you’re not familiar but they’re what you’d think. Trees of “stuff” to do rather than a loop with finite states. The BT navigator is the package containing the navigation implementation of a BT. This calls the nav2_{recoveries, planner, controller} servers. These servers host a map of plugins which have some algorithm implemented.

For the simplest case, the servers will have a single plugin like DWB or NavFn that will do control or planning. For more complex applications you can have different plugins for contextual needs.

The lifecycle manager just runs all the nodes through the managed nodes lifecycle. That’s subject to near term removal in favor of the launch system.

Costmaps exist in their respective servers, though again long term that may not be true. Moreover the concepts of a costmap are likely to be depreciated in the next year.

Edit: also, simple navigator is already dead.

Hi, developer/maintainer on Nav2 here.

Yeah, sorry about that. On the grand scheme of things a block diagram has been low priority. Also things have been changing and still subject to changes so we didn’t want to produce misinformation. Comments below represent the current state of things but also are subject to change.

The ins and outs of the move base diagram are the same. We need some map (from map server, slam, etc), some sort of positioning (TF) and various sensor data streams.

Now rather then a FSM move base, we use behavior trees (BT). Look more into BTs if you’re not familiar but they’re what you’d think. Trees of “stuff” to do rather than a loop with finite states. The BT navigator is the package containing the navigation implementation of a BT. This calls the nav2_{recoveries, planner, controller} servers. These servers host a map of plugins which have some algorithm implemented.

For the simplest case, the servers will have a single plugin like DWB or NavFn that will do control or planning. For more complex applications you can have different plugins for contextual needs.

The lifecycle manager just runs all the nodes through the managed nodes lifecycle. That’s subject to near term removal in favor of the launch system.

Costmaps exist in their respective servers, though again long term that may not be true. Moreover the concepts of a costmap are likely to be depreciated in the next year.

Edit: also, simple navigator is already dead.

Edit thrice: you asked and brought my laziness to an end. See attached diagram that either this or a derivative of this will be placed in documentation for Navigation2.

C:\fakepath\diagram.png

Hi, developer/maintainer on Nav2 here.

Yeah, sorry about that. On the grand scheme of things a block diagram has been low priority. Also things have been changing and still subject to changes so we didn’t want to produce misinformation. Comments below represent the current state of things but also are subject to change.

The ins and outs of the move base diagram are the same. We need some map (from map server, slam, etc), some sort of positioning (TF) and various sensor data streams.

Now rather then a FSM move base, we use behavior trees (BT). Look more into BTs if you’re not familiar but they’re what you’d think. Trees of “stuff” to do rather than a loop with finite states. The BT navigator is the package containing the navigation implementation of a BT. This calls the nav2_{recoveries, planner, controller} servers. These servers host a map of plugins which have some algorithm implemented.

For the simplest case, the servers will have a single plugin like DWB or NavFn that will do control or planning. For more complex applications you can have different plugins for contextual needs.

The lifecycle manager just runs all the nodes through the managed nodes lifecycle. That’s subject to near term removal in favor of the launch system.

Costmaps exist in their respective servers, though again long term that may not be true. Moreover the concepts of a costmap are likely to be depreciated in the next year.

Edit: also, simple navigator is already dead.

Edit thrice: you asked and brought my laziness to an end. See attached diagram that either this or a derivative of this will be placed in documentation for Navigation2. Navigation2 whenever another burst of non-laziness occurs.

Hi, developer/maintainer on Nav2 here.

Yeah, sorry about that. On the grand scheme of things a block diagram has been low priority. Also things have been changing and still subject to changes so we didn’t want to produce misinformation. Comments below represent the current state of things but also are subject to change.

The ins and outs of the move base diagram are the same. We need some map (from map server, slam, etc), some sort of positioning (TF) and various sensor data streams.

Now rather then a FSM move base, we use behavior trees (BT). Look more into BTs if you’re not familiar but they’re what you’d think. Trees of “stuff” to do rather than a loop with finite states. The BT navigator is the package containing the navigation implementation of a BT. This calls the nav2_{recoveries, planner, controller} servers. These servers host a map of plugins which have some algorithm implemented.

For the simplest case, the servers will have a single plugin like DWB or NavFn that will do control or planning. For more complex applications you can have different plugins for contextual needs.

The lifecycle manager just runs all the nodes through the managed nodes lifecycle. That’s subject to near term removal in favor of the launch system.

Costmaps exist in their respective servers, though again long term that may not be true. Moreover the concepts of a costmap are likely to be depreciated in the next year.

Edit: also, simple navigator is already dead.

Edit thrice: you asked and brought my laziness to an end. See attached diagram that either this or a derivative of this will be placed in documentation for Navigation2 whenever another burst of non-laziness occurs. Don't say I never did a favor for ya ;-)