easynav_core

Core base classes for all Easy Navigation method plugins (controllers, planners, localizers, map managers).
This package provides a common lifecycle, timing utilities and shared behaviors for EasyNav plugins.

Base Classes Overview

Each plugin README in easynav_plugins can refer to these sections instead of duplicating the shared behavior.

easynav::MethodBase

Header: easynav_core/MethodBase.hpp
Role: Common lifecycle and timing utilities for all method plugins.

MethodBase Responsibilities

• Store a pointer to the parent rclcpp_lifecycle::LifecycleNode.
• Keep the plugin name and TF prefix.
• Provide initialize() + virtual on_initialize() hook for derived classes.
• Provide update-rate helpers for real-time and non-real-time loops.

Parameters

MethodBase declares, under each plugin’s namespace:

Both must be finite and > 0 (initialize() throws otherwise), and at most system_node.rt_freq / system_node.freq (EasyNav fails to configure otherwise). The system cycles only check whether it is time for each component to run: the component’s frequency is what it runs at. The schedule does not drift (a 30 Hz component checked at 50 Hz runs 30 times per second); more than a period behind, it restarts from now.

MethodBase Public API

NavState / Topics

MethodBase writes only its rate diagnostics, diagnostics.<plugin>.rt_rate and diagnostics.<plugin>.rate (diagnostic_msgs/DiagnosticStatus, in the diagnostics group): written when first checked and then on changes; WARN after a window (1 s or 10 periods) with fewer than 90 % of the expected runs (after 3 in a row, the message says for how long). Never ERROR: it is only reported, not mitigated. Time without checks counts as slow (a component blocking its cycle is reported); the nodes call reset_rate_monitors() on activation, so the time inactive does not. It does not create publishers or subscriptions. All such interfaces are defined in derived base classes (see below) and their plugins.

Robot geometry

The robot’s shape is configured once, in system_node, and shared with every component (costmap inflation, planners, recovery…). Plugins read it with MethodBase::get_robot_geometry(); other code, with easynav::get_robot_geometry() (easynav_common/RobotGeometry.hpp).

A component’s former geometry parameter (e.g. an inflation filter’s inscribed_radius) still applies, with a deprecation warning, where robot_geometry does not configure that field; robot_geometry takes precedence when both are set.

easynav::ControllerMethodBase

Header: easynav_core/ControllerMethodBase.hpp
Role: Base class for controllers that generate velocity commands.

Typical derived plugins: easynav_simple_controller, easynav_mppi_controller, easynav_serest_controller, easynav_vff_controller.

Controller Responsibilities

• Extend MethodBase with a real-time control loop (update_rt).
• Take the robot’s velocity and acceleration limits from controller_node.robot_limits (get_robot_limits()).

Braking before an obstacle is not the controller’s job: it belongs to the recovery system (recovery_node), which checks every RT cycle, right before publishing, whatever command is about to be sent. The former colision_checker.* parameters are gone.

Controller Public API

File truncated at 100 lines see the full file

Changelog for package easynav_core

0.5.0 (2026-10-08)

• Lifecycle states and runtime reconfiguration of the plugins (PluginSwitcher)
• Robot limits and velocity smoother; velocity multiplexer between the controller and the recovery system
• Recovery framework (RecoveryManagerBase)
• Safety mode support: configuration checks, safety channel status, data age
• Each component runs at its own frequency without drift, and whether it keeps it is reported as a WARN diagnostic (<plugin>.rt_rate / <plugin>.rate)
• The collision checker is no longer part of the controllers
• Builds on Humble, Jazzy, Kilted, Lyrical and Rolling
• Conda packages with pixi (pixi-build-ros)
• Contributors: Francisco Martín Rico

0.4.2 (2026-07-26)

• get_by_type and get_to_vector in NavState
• Refactor PerceptionHandler PerceptionHandler now represents a single sensor input, not a sensor group
• Fix test bug in plugin class loader
• Increase coverage
• Perception types and ops to easynav_sensors
• GPLv3 -> Apache 2.0
• Adjust process time to input times
• Sync time for markers with its the collision percetion time
• Set robot_frame as default for collision checker
• Add a base_footprint frame in TFInfo
• Hotfix: Remove remaining C++20/23 features
• Remove std::expected from MethodBase::initialize interface
• Added operation to get latest perception, with valid TF or not
• TFInfo in RTTFBuffer
• Create header for TFInfo
• Tests and refactoring
• TF Refactor
• Add README.md with base classes description
• Remove unused include and random
• Set collision checker disabled by default
• Comment unused variables
• Cleanup unused headers
• Add warning when exceeding the target cycle time
• Merge new changes into rolling
• Minor linting fix
• Finished collision checker
• Tracing for eficiency
• First proposal for collision checker
• Second simple approach
• First functional version
• Reset method execution time when triggered
• Contributors: Francisco Martín Rico, Francisco Miguel Moreno

0.1.4 (2025-10-16)

• Merge kilted version bump into rolling
• Merge kilted into rolling. Update version to 0.1.3
• Contributors: Francisco Miguel Moreno

0.1.3 (2025-10-12)

0.1.2 (2025-09-26)

• Trigger planner if new goals appear
• Multi-robot support by namespacing TFs
• Use tf_prefix instead of tf_namespace
• [WIP] Blackboard for NavSate
• Redesing with NavState
• Yaets traces
• Fix CMake targets. Update package dependencies
• Install bins in correct place
• Updated Doxygen description headers
• [WIP] System Execution
• RTTFBuffer. Dictionary maps.
• [WIP] Changes to load plugins
• Changes to load plugins
• NavState refs in update
• Base interfaces for module algorithms
• Works on Map Manager Types
• Add tests for easynav_core base classes
• Group common method functionality
• Add dummy plugins for core modules
• Install runtime binary targets under lib
• Add base abstract classes for the algorithm plugins
• Refactoring to nodes
• Minor typo in license
• Add Result Class
• Reading params to core
• Separation ROS and non-ROS and skeletons
• Initial skeleton
• Contributors: Francisco Martín Rico, Francisco Miguel Moreno Olivo, Juan Carlos Manzanares Serrano