diff --git a/docs/_static/images/diagrams/component.jpg b/docs/_static/images/diagrams/component.jpg deleted file mode 100644 index 2d6de61..0000000 Binary files a/docs/_static/images/diagrams/component.jpg and /dev/null differ diff --git a/docs/_static/images/diagrams/component_dark.png b/docs/_static/images/diagrams/component_dark.png new file mode 100644 index 0000000..e8487a8 Binary files /dev/null and b/docs/_static/images/diagrams/component_dark.png differ diff --git a/docs/_static/images/diagrams/component_light.png b/docs/_static/images/diagrams/component_light.png new file mode 100644 index 0000000..c52bb95 Binary files /dev/null and b/docs/_static/images/diagrams/component_light.png differ diff --git a/docs/_static/images/diagrams/events_actions_config.jpg b/docs/_static/images/diagrams/events_actions_config.jpg deleted file mode 100644 index c000c5e..0000000 Binary files a/docs/_static/images/diagrams/events_actions_config.jpg and /dev/null differ diff --git a/docs/_static/images/diagrams/events_actions_exec.jpg b/docs/_static/images/diagrams/events_actions_exec.jpg deleted file mode 100644 index 57d700c..0000000 Binary files a/docs/_static/images/diagrams/events_actions_exec.jpg and /dev/null differ diff --git a/docs/_static/images/diagrams/fallbacks.jpg b/docs/_static/images/diagrams/fallbacks.jpg deleted file mode 100644 index 1830185..0000000 Binary files a/docs/_static/images/diagrams/fallbacks.jpg and /dev/null differ diff --git a/docs/_static/images/diagrams/multi_process.jpg b/docs/_static/images/diagrams/multi_process.jpg deleted file mode 100644 index c6469ec..0000000 Binary files a/docs/_static/images/diagrams/multi_process.jpg and /dev/null differ diff --git a/docs/_static/images/diagrams/multi_process_dark.png b/docs/_static/images/diagrams/multi_process_dark.png new file mode 100644 index 0000000..8cd74a2 Binary files /dev/null and b/docs/_static/images/diagrams/multi_process_dark.png differ diff --git a/docs/_static/images/diagrams/multi_process_light.png b/docs/_static/images/diagrams/multi_process_light.png new file mode 100644 index 0000000..40c44f1 Binary files /dev/null and b/docs/_static/images/diagrams/multi_process_light.png differ diff --git a/docs/_static/images/diagrams/multi_threaded.jpg b/docs/_static/images/diagrams/multi_threaded.jpg deleted file mode 100644 index e9a10b3..0000000 Binary files a/docs/_static/images/diagrams/multi_threaded.jpg and /dev/null differ diff --git a/docs/_static/images/diagrams/multi_threaded_dark.png b/docs/_static/images/diagrams/multi_threaded_dark.png new file mode 100644 index 0000000..18318ac Binary files /dev/null and b/docs/_static/images/diagrams/multi_threaded_dark.png differ diff --git a/docs/_static/images/diagrams/multi_threaded_light.png b/docs/_static/images/diagrams/multi_threaded_light.png new file mode 100644 index 0000000..01a4e1e Binary files /dev/null and b/docs/_static/images/diagrams/multi_threaded_light.png differ diff --git a/docs/_static/images/diagrams/system_components.jpg b/docs/_static/images/diagrams/system_components.jpg deleted file mode 100644 index 65daa26..0000000 Binary files a/docs/_static/images/diagrams/system_components.jpg and /dev/null differ diff --git a/docs/_static/images/diagrams/system_graph.jpg b/docs/_static/images/diagrams/system_graph.jpg deleted file mode 100644 index 4536d45..0000000 Binary files a/docs/_static/images/diagrams/system_graph.jpg and /dev/null differ diff --git a/docs/advanced/components.md b/docs/advanced/components.md deleted file mode 100644 index 59a317c..0000000 --- a/docs/advanced/components.md +++ /dev/null @@ -1 +0,0 @@ -# Creating custom components diff --git a/docs/advanced/design.md b/docs/advanced/design.md index 0e7bf38..0492f86 100644 --- a/docs/advanced/design.md +++ b/docs/advanced/design.md @@ -6,23 +6,52 @@ Kompass is designed using [ROS Sugar](https://automatika-robotics.github.io/ros- Check the design concepts in detail by referring to ROS Sugar [documentation](https://automatika-robotics.github.io/ros-sugar) ``` -:::{figure-md} fig-comp -Kompass Component +```{figure} ../_static/images/diagrams/component_dark.png +:class: only-dark +:alt: Kompass Component +:align: center Component Structure -::: +``` + +```{figure} ../_static/images/diagrams/component_light.png +:class: only-light +:alt: Kompass Component +:align: center -:::{figure-md} fig-multi-thread +Component Structure +``` + +```{figure} ../_static/images/diagrams/multi_threaded_dark.png +:class: only-dark +:alt: Kompass Multi-threaded execution +:align: center + +Multi-threaded execution +``` -Multi-threaded execution +```{figure} ../_static/images/diagrams/multi_threaded_light.png +:class: only-light +:alt: Kompass Multi-threaded execution +:align: center Multi-threaded execution -::: +``` -:::{figure-md} fig-multi-process -Multi-process execution +```{figure} ../_static/images/diagrams/multi_process_dark.png +:class: only-dark +:alt: Kompass Multi-process execution +:align: center Multi-process execution -::: +``` + +```{figure} ../_static/images/diagrams/multi_process_light.png +:class: only-light +:alt: Kompass Multi-process execution +:align: center + +Multi-threaded execution +``` diff --git a/docs/design/actions.md b/docs/design/actions.md deleted file mode 100644 index 338b783..0000000 --- a/docs/design/actions.md +++ /dev/null @@ -1,58 +0,0 @@ -# Actions - -Actions are methods or routines executed by a component or by the system monitor. - -Actions can either be: -- Actions paired with Events: in this case the Action is executed by a system monitor when an event is detected (see more details in [Monitor](monitor.md), [Launcher](launcher.md)) -- Actions paired with Fallbacks: in this case the Action is executed by a Component when a failure is detected - -Actions are defined with: -- method to be executed (Callable) -- args: Arguments to be passed to the method when executing the action -- kwargs: Keyword arguments to be passed to the method when executing the action - -## Usage Example: -```python - from kompass.components.component import Component - from kompass.config import ComponentConfig - import logging - - def function(): - logging.info("I am executing an action!") - - my_component = Component(component_name='test_component') - new_config = ComponentConfig(loop_rate=50.0) - action1 = Action(method=my_component.start) - action2 = Action(method=my_component.reconfigure, args=(new_config, True),) - action3 = Action(method=function) -``` - -## Available Defined Actions: - -Kompass comes with a set of pre-defined component level actions and system level actions - -### Component-level Actions: -- stop: Deactivate the lifecycle Component -- start: Activate the lifecycle Component -- restart: stop then start -- reconfigure: Send new ComponentConfig class object to the Component -- update_parameter: Update the value of one parameter in the ComponentConfig -- update_parameters: Update the value of a set of parameters in the ComponentConfig - -### System-level Actions: -- log: Log a message -- publish_message: Publish a ROS2 message to a given topic -- send_srv_request: Send a ROS2 service request -- send_action_goal: Send a ROS2 action goal - -:::{tip} The previous pre-defined Actions are all keyword only -::: - -### Usage Example: -```python - from kompass.actions import Actions - - my_component = BaseComponent(component_name='test_component') - action1 = Actions.start(component=my_component) - action2 = Actions.log(msg="I am executing a cool action!") -``` diff --git a/docs/design/component.md b/docs/design/component.md deleted file mode 100644 index 1bdc8d9..0000000 --- a/docs/design/component.md +++ /dev/null @@ -1,93 +0,0 @@ -# Components - -A Component is the main execution unit in Kompass, every Component is equivalent to a ROS2 Lifecycle Node comprising of: - -- [Input and Outputs](#inputs-and-outputs) -- [Health Status](#health-status) -- [Fallbacks](#fallbacks) - -:::{figure-md} fig-comp - -Kompass Component - -Component Structure -::: - -Each Component must serve one main functionality which can be executed in different modes or RunType (Example below), additionally the Component can offer any number of additional services. Available RunType are: - -```{list-table} -:widths: 20 20 50 -:header-rows: 1 -* - RunType (str) - - RunType (enum) - - Description - -* - **Timed** - - RuntType.TIMED - - Executes main functionality in a timed loop while active - -* - **Event** - - RuntType.EVENT - - Executes main functionality based on a trigger topic/event - -* - **Server** - - RuntType.SERVER - - Executes main functionality based on a ROS2 service request from a client - -* - **ActionServer** - - RuntType.ACTIONSERVER - - Executes main functionality based on a ROS2 action server request from a client -``` - -The run type can be configured using 'run_type' attribute in the component config class, or directly using 'run_type' property: - -```python -from kompass.config import ComponentRunType, ComponentConfig -from kompass.components import Component - -config = ComponentConfig(run_type=ComponentRunType.EVENT) - -# Can directly pass a string -config = ComponentConfig(run_type="Event") - -# Can set from Component -comp = Component(component_name='test') -comp.run_type = "Server" # or ComponentRunType.SERVER - -``` - -:::{tip} All the functionalities implemented in ROS2 nodes can be found in the Component. -::: - -## Inputs and Outputs - -Components in Kompass are defined to accept only restricted types of inputs/outputs to help lock the functionality of a specific Component implementation. Each input/output is associated with a unique keyword name and is set to accept one or many types of ROS2 message types. Additionally, the input/output keyword in the Component can define a category of Topics rather than a single one. To see an example of this check the [DriveManager](../navigation/driver.md) Component. In this component the input [sensor_data](../navigation/driver.md/#inputs) defines any proximity sensor input (LiDAR, Radar, etc.) and can optionally take up to 10 Topics of such types to fuse it internally during execution. - -Configuring an input/output of a Component is very straightforward and can be done in one line in your Python script. Below is an example for configuring the previously mentioned DriveManager: - -```python - from kompass.components import DriveManager - - driver = DriveManager(component_name="driver") - - # Configure an input - driver.inputs(sensor_data=[Topic(name='/scan', msg_type='LaserScan'), - Topics(name='radar_data', msg_type='Float64')]) - - # Configure an output - driver.outputs(emergency_stop=Topic(name='alarm', msg_type='Bool')) - -``` - -:::{seealso} Check Inputs/Outputs in the advanced section to learn how you can configure the allowed inputs/outputs for your custom component. -::: - -## Health Status - -Each Components comes with an associated health status to express the well or mal-function of the component. Health status is always available internally and can in the component by associating failure status to a [Fallback](#fallbacks) behavior allowing the component to self-recover. Component also have the option to declare the status back to the system by publishing on a Topic. This can be configured in the [ComponentConfig](../apidocs/Kompass/Kompass.config.md) class. - -Learn more on using health status in the component [here](status.md). - -## Fallbacks - -Component fallbacks are aet of techniques to be applied internally in case of failure to allow self-recovery within the component. Check the fallbacks [dedicated page](fallbacks.md) to learn how to use and configure your own fallbacks. diff --git a/docs/design/events.md b/docs/design/events.md deleted file mode 100644 index 02c0bec..0000000 --- a/docs/design/events.md +++ /dev/null @@ -1,120 +0,0 @@ -# Events - -Events are created to alert a robot software stack to any dynamic change at runtime. An Event is defined by a change in a ROS2 message value on a specific topic. - -Events are used by matching them to 'Actions'; an Action is meant to be executed at runtime once the Event is triggered. - -## Available Events: -- [OnEqual](#onequal-event) -- [OnDifferent](#ondifferent-event) -- [OnChange](#onchange-event) -- [OnChangeEqual](#onchangeequal-event) -- [OnGreater](#ongreater-event) -- [OnLess](#onless-event) - -## OnEqual Event - -OnEqual Event is triggered when a given topic attribute value is equal to a given trigger value. - -*Example usage scenario:* -- Event when the detection id (object type) in an object detection topic is equal to a specific object (to raise an event on detecting another robot, a human, etc.) - -```python -from kompass.event import OnEqual -from vision_msgs.msg import Detection2D - -example_person_id_from_db : int = 3 - -# Raise event as long as a person is detected -person_detected = OnEqual( - "person_detected", - Topic(name="/person_detection", msg_type=Detection2D), - example_person_id_from_db, - ("results", "id"), -) -``` - -## OnDifferent Event -OnDifferent Event is triggered when a given topic attribute value is different from a given trigger value. - - -## OnChange Event -OnChange Event is triggered when a given topic attribute changes in value from any initial value to any new value. The target attribute value is registered on the first recept of a message on the target topic, then the event is triggered on a change in that value. After a change the new value is registered and the event is triggered again on any new change, ...etc. - -*Example usage scenario:* -- Event on a change in the number of detected people of the robot by a vision system to play a friendly message. - -```python -from kompass.event import OnChange - -# Raise event when the number of detected people change -number_people_change = OnChange( - "number_people_change", - Topic(name="/people_count", msg_type="Int"), -) -``` - -## OnChangeEqual Event -OnChangeEqual Event is a combination of OnChange and OnEqual events. OnChangeEqual is triggered when a given topic attribute changes in value from any initial value to *given trigger goal* value. - -:::{note} The difference between using OnChangeEqual as opposite to OnEqual or OnChange is that: -- OnEqual will keep getting triggered every time a new message value is received that is equal to the trigger. -- OnChange will keep getting triggered every time a new message value is received that is different from a previous value -- OnChangeEqual will get triggered once when the topic message value reaches the trigger, making it convenient for many applications -::: - -*Example usage scenarios:* -- Event on the robot reaching a navigation goal point: reach_end Boolean topic OnChangeEqual to True (triggered once when reaching, does not trigger again if the robot is static and staying in 'goal reaching' state) -- Event on an Enum value of a message attribute to detect reaching a given state. -- Event of reaching 100% charge level of a robot to end charging. - - -```python -from kompass.event import OnChangeEqual - -# Raise event when end is reached -reached_end = OnChangeEqual( - "reached_end", - Topic(name="/reach_end", msg_type="Bool"), - True, - ("data") -) -``` - -## OnGreater Event - -OnGreater Event is triggered when a given topic attribute value is greater than a given trigger value. - -*Example usage scenario:* -- Event when a drone is higher than a certain allowed elevation (location z coordinate > elevation level), to bring the drone down into allowed limits. - -```python -from kompass.event import OnGreater - -# Raise event when elevation is more than 100 meters -crossed_100m_elevation = OnGreater( - "crossed_elevation", - Topic(name="/odom", msg_type="Odometry"), - 100.0, - ("pose", "pose", "position", "z") -) -``` - -## OnLess Event - -OnLess Event is triggered when a given topic attribute value is less than a given trigger value. - -*Example usage scenario:* -- Event when the robot battery level falls under a certain low limit, to go back to the charging station, for example. - -```python -from kompass.event import OnLess - -# Raise event when battery is low -low_battery = OnLess( - "low_battery", - Topic(name="/battery_level", msg_type="Int"), - 15, - ("data") -) -``` diff --git a/docs/design/fallbacks.md b/docs/design/fallbacks.md deleted file mode 100644 index 0da6abd..0000000 --- a/docs/design/fallbacks.md +++ /dev/null @@ -1,51 +0,0 @@ -# Fallbacks - - Components Fallbacks contain the set of [Actions](actions.md) to be executed when a failure [status](status.md) is detected. Fallbacks are defines with an Action or a list of Actions to be executed in sequence. Each Action in the list is retried until max_retries is reached. - -:::{figure-md} fig-fallbacks - -Fallbacks and Health Status - -Fallbacks and Health Status -::: - -## Fallbacks Categories: - -Each component has 3 built-in possible fallbacks categories along with the possibility to set a behavior for "any failure" and a "giveup" behavior that is executed when all failure actions are exhausted. - -- on_component_fail -- on_algorithm_fail -- on_system_fail -- on_any_fail -- on_giveup - - -The first three are designed to correspond to the three different [Health Status](status.md) a Component can take other than "Healthy" status. 'on_any_fail' is used to define a fallback policy regardless of the failure category. Finally, 'on_give' is the final Action the Component will execute when all the fallbacks and retries are exhausted. - - -## Default behavior in a Component: - -The default behavior in a Component is for the component to broadcast the status on any detected failure. By default the component sets 'on_any_fail' Fallback to 'Action(self.broadcast_status)' with 'max_retries=None'. - -Action(s) set for 'on_any_fail' is executed for *any* failure for which no fallback action is defined. - -:::{note} Each Component already owns its own ComponentFallback configured to the previous default behavior. The only thing required is to configure the Actions executed at each (or any) failure type. -::: - - -## Usage in a Component: -```python - from kompass.components.component import Component - from kompass.actions import Actions - - my_component = Component(component_name='test_component') - - # Set fallback for component failure to restart the component - my_component.on_component_fail(fallback=Actions.restart(component=my_component)) - - # Change fallback for any failure - my_component.on_fail(fallback=Action(my_component.restart)) - - # First broadcast status, if another failure happens -> restart - my_component.on_fail(fallback=[Action(my_component.broadcast_status), Action(my_component.restart)]) -``` diff --git a/docs/design/index.md b/docs/design/index.md deleted file mode 100644 index 3da62a3..0000000 --- a/docs/design/index.md +++ /dev/null @@ -1,39 +0,0 @@ -# Design Concepts - -Kompass is designed using [ROS Sugar]() concepts. A [Component](component.md) is the main execution unit in Kompass, each component is configured with [Inputs/Outputs](topics.md) and [Fallback](fallbacks.md) behaviors. Additionally, each component updates its own [Health Status](status.md). Components can be handled and reconfigured dynamically at runtime using [Events](events.md) and [Actions](actions.md). Events, Actions and Components are passed to the [Launcher](launcher.md) which runs the set of components as using multi-threaded or multi-process execution. The Launcher also uses an internal [Monitor](monitor.md) to keep track of the components and monitor events. - -:::{figure-md} fig-comp - -Kompass Component - -Component Structure -::: - -:::{figure-md} fig-multi-thread - -Multi-threaded execution - -Multi-threaded execution -::: - -:::{figure-md} fig-multi-process - -Multi-process execution - -Multi-process execution -::: - - -```{toctree} -:maxdepth: 1 -:caption: Design Concepts - -component -topics -status -events -actions -fallbacks -launcher -monitor -``` diff --git a/docs/design/launcher.md b/docs/design/launcher.md deleted file mode 100644 index 09aa2bf..0000000 --- a/docs/design/launcher.md +++ /dev/null @@ -1,108 +0,0 @@ -# Launcher - -[Launcher](../apidocs/Kompass/Kompass.launcher.md) is a class created to provide a more pythonic way to launch and configure ROS nodes. - -Launcher starts a pre-configured component or a set of components as ROS2 nodes using multi-threaded or multi-process execution. Launcher spawns an internal [Monitor](./monitor.md) node in a separate thread in both execution types. - -:::{figure-md} fig-multi-thread - -Multi-threaded execution - -Multi-threaded execution -::: - -:::{figure-md} fig-multi-process - -Multi-process execution - -Multi-process execution -::: - -Launcher can also manage a set of Events-Actions through its internal Monitor node (See Monitor class). - -## Available options: -- Enable/Disable events monitoring -- Enable/Disable multi-processing, if disabled the components are launched in threads -- Select to activate one, many or all components on start (lifecycle nodes activation) - -Launcher forwards all the provided Events to its internal Monitor, when the Monitor detects an Event trigger it emits an InternalEvent back to the Launcher. Execution of the Action is done directly by the Launcher or a request is forwarded to the Monitor depending on the selected run method (multi-processes or multi-threaded). - -:::{note} While Launcher supports executing standard [ROS2 launch actions](https://github.com/ros2/launch). Launcher does not support standard [ROS2 launch events](https://github.com/ros2/launch/tree/rolling/launch/launch/events) for the current version. -::: - -## Usage Example - -```{code-block} python -:caption: launcher test -:linenos: - -from kompass.components import Planner, Controller -from kompass.actions import Actions -from kompass.event import OnLess -from kompass_interfaces.action import PlanPath -from geometry_msgs.msg import Pose -from kompass_interfaces.msg import PathTrackingError - -# Create your components -planner = Planner(component_name='test_planner') -controller = Controller(component_name='test_controller') - - -# Configure your components here -# .... -planner.run_type = "ActionServer" - -# Create your events -low_battery = OnLess( - "low_battery", - Topic(name="/battery_level", msg_type="Int"), - 15, - ("data") -) - -# Charging station location -charging_location = Pose() -charging_location.position.x = 10.0 - -# Tolerance for reaching charging station -end_tolerance = PathTrackingError() -end_tolerance.orientation_error = 0.1 -end_tolernace.lateral_distance_error = 0.05 - -action_goal = PlanPath.Goal() -action_goal.end_tolerance = end_tolerance -action_goal.goal = charging_location - -# Define action to send a goal to the planner to start a mission to the charging station -return_to_charging_station = Actions.send_action_goal( - action_name="test_planner/plan_path", - action_type=PlanPath, - action_request_msg=action_goal - ) - -# Events/Actions -my_events_actions: Dict[event.Event, Action] = { - low_battery: return_to_charging_station -} - -# We can add a config YAML file -path_to_yaml = 'my_config.yaml' - -launcher = Launcher( - components=[planner, controller], - events_actions=my_events_actions, - config_file=path_to_yaml, - activate_all_components_on_start=True, - multi_processing=True, -) - -# Set a topic for all components -odom_topic = Topic(name="robot_odom", msg_type="Odometry") -launcher.inputs(location=odom_topic) - -# If any component fails -> restart it with unlimited retries -launcher.on_component_fail(action_name="restart") - -# Bring up the system -launcher.bringup(ros_log_level="info", introspect=False) -``` diff --git a/docs/design/monitor.md b/docs/design/monitor.md deleted file mode 100644 index 5c33963..0000000 --- a/docs/design/monitor.md +++ /dev/null @@ -1,52 +0,0 @@ -# Monitor - -Monitor is a ROS2 Node (not Lifecycle) responsible of monitoring the status of the stack (rest of the running nodes) and managing requests/responses from the Orchestrator. - - - -## Main Functionalities: -- Creates Subscribers to registered Events. The Monitor is configured to declare an InternalEvent back to the Launcher so the corresponding Action can be executed (see source implementation in launch_actions.py) - - -![Monitoring events](../_static/images/diagrams/events_actions_config.jpg) -![An Event Trigger](../_static/images/diagrams/events_actions_exec.jpg) - - - - -- Creates Subscribers to all registered Components health status topics -- Creates clients for all components main services and main action servers -- Creates service clients to components reconfiguration services to handle actions sent from the Launcher - - -## Usage Example: - -:::{caution} When launching the stack using the Launcher, you do not need to configure the Monitor. The Launcher will configure and launch its own Monitor node internally. The code below shows an example of this internal configuration -::: - -```python -from kompass.monitor import Monitor -from kompass import event - -components = ['planner', 'controller', 'driver'] - -emergency_stop_event = event.OnEqual( - "emergency_stop", - Topic(name="/emergency_stop", msg_type="Bool"), - True, - ("data"), -) - -monitor_node = Monitor(componenets_names=components, - enable_health_status_monitoring=True, - events=[emergency_stop_event], - services_components=None, - action_servers_components=['planner'], - activate_on_start=True, - ) - -``` diff --git a/docs/design/status.md b/docs/design/status.md deleted file mode 100644 index 76ddf46..0000000 --- a/docs/design/status.md +++ /dev/null @@ -1,46 +0,0 @@ -# Health Status - -Component health status is updated by the Component during runtime to declare any detected failure in the component, or in the plugin that the component is using, or in the external system. - -Health Status is configured in the component along with a corresponding publisher by default. - -To use health status in your component: - -- To indicate a malfunction in general without details on the failure level / source, use: - - ```python - self.health_status.set_failure() - ``` - -- It can indicate a mal-function/ failure in the plugin (algorithm) used by the component. In this case it is possible to indicate the failed plugin name in the message. - - ```python - self.health_status.set_fail_plugin(plugin_names=['plugin_1', 'plugin_2']) - ``` - -- It can indicate a mal-function/ failure in the component itself or another component. Component fail by default refers to a failure in the component itself, however it is possible to specify a failure detected in a specific component by passing the name(s) - - ```python - # To indicate failure in the component itself - self.health_status.set_fail_component() - - # To indicate failure in another component - self.health_status.set_fail_component(component_names=['other_component_name']) - - # To indicate failure in multiple components - self.health_status.set_fail_component(component_names=[self.node_name, 'other_component_name']) - ``` - -- It can indicate a mal-function/ failure in the external system. It is possible to add the failure source using component names or topic names (in case a required topic is not available, for example) - - ```python - # For failure related to a specific topic - self.health_status.set_fail_system(topic_names=['some_topic_name']) - ``` - -:::{tip} TIMED components publish the status periodically (if broadcasting is enabled). If the component is not TIMED, then the child component should implement the publishing, using: - -```python - self.health_status_publisher.publish(self.health_status) -``` -::: diff --git a/docs/design/topics.md b/docs/design/topics.md deleted file mode 100644 index ecce268..0000000 --- a/docs/design/topics.md +++ /dev/null @@ -1,28 +0,0 @@ -# Topics - -Kompass provides classes to configure a ROS2 topics as a Component Input/Output. - -## Topic Configuration Class - -- Configured using: - -1. name: [str], ROS2 topic name. - -2. msg_type: [Union[Kompass.data_types.SupportedType, str]], ROS2 message type, passed as a string or as a type. - -3. qos_profile: [QoSConfig](../advanced/advanced_conf/qos.md), See usage in example below. - -- Provides: - -ros_msg_type: [type], Provides the ROS2 message type of the topic. - -:::{note} Topic in Kompass only supports certain ROS2 message types found in [Supported Types](../advanced/types.md) -::: - -## Usage Example - -```python -from kompass.config import Topic - -topic = Topic(name='/local_map', msg_type='OccupancyGrid') -``` diff --git a/docs/navigation/index.md b/docs/navigation/index.md deleted file mode 100644 index 2f5ba43..0000000 --- a/docs/navigation/index.md +++ /dev/null @@ -1,34 +0,0 @@ -# Navigation Components - - -Kompass is divided into several interacting components each responsible for one of the navigation subtasks: - -:::{figure-md} fig-components-tasks - -Kompass Components Tasks - -Kompass Components and Main Tasks -::: - -Each of the previous components runs as a ROS2 lifecycle node and communicates with the other components using ROS2 topics, services or action servers: - -:::{figure-md} fig-components-system - -Kompass Full System - -Kompass Full System for Autonomous Navigation -::: - - -```{toctree} -:maxdepth: 1 -:caption: Navigation Components - -robot -path_planning -control -driver -mapper -motion_server -mapping_localization -```