- Generated by
1.17.0
|
EasyFleet
A simple-by-default framework for multi-robot, multi-capability fleets built on ROS 2
|
Publishes a RoutesMap on /global_routes, and keeps it live-editable. More...
#include <routes_publisher.hpp>
Public Member Functions | |
| void | publish (rclcpp::Node &node) |
| Read "routes.package"/"routes.map_path_file" from node, load the routes they name, publish them once on /global_routes (QoS: depth 1, transient_local, reliable, per the user's own spec for this topic), and set up the visualization + interactive-marker publishers so the routes can be edited live from RViz. | |
Publishes a RoutesMap on /global_routes, and keeps it live-editable.
Loaded the same way easynav_routes_maps_manager's own RoutesMapsManager loads its local map_path_file, via easynav::load_routes_from_yaml() – every robot's own "routes" maps_manager_node need only remap its "incoming_routes" topic to /global_routes to receive this centrally instead of loading its own copy (see easyfleet_navigation_manager's README). Unlike maps, only one route representation exists, so this is a single concrete class rather than a MapPublisherBase-style extensibility point.
Reproduces RoutesMapsManager's own interactive-marker editing mechanism exactly (same marker layout, same per-segment edit-mode toggle, same move/rotate/add/remove controls – see RoutesMapsManager::publish_interactive_markers()/handle_interactive_feedback() in easynav_routes_maps_manager), with one difference in what a route edit (as opposed to just toggling edit mode) does afterwards: here it also republishes the updated RoutesMap on /global_routes – so every robot picks up the edit immediately – and re-saves it to the same YAML file it was loaded from (via easynav::save_routes_to_yaml()), so edits made live in RViz survive a restart. RoutesMapsManager itself only does the equivalent of the second part on demand, via its own save_routes service.
The visualization MarkerArray on /global_routes_markers is a deliberate exception to the "publish once, rely on transient_local" approach used everywhere else in this class: a late-joining subscriber reliably getting the retained visualization_msgs/MarkerArray sample via durability-service replay turned out NOT to be guaranteed in practice here (verified independently of this class, with a minimal throwaway publisher/subscriber pair outside this codebase – a plain std_msgs/String with the exact same QoS delivered its retained sample to a late joiner every time, MarkerArray did not). A topic is one or the other, not both: something that needs periodic republishing to reach late joiners isn't really transient_local, so /global_routes_markers is volatile and kept alive by a low-rate timer (routes.markers_republish_rate_hz) instead – matching the rate nav2's own costmap/marker publishers already default to for the same class of topic. interactive_markers::InteractiveMarkerServer sidesteps the whole question for its own topics: it doesn't rely on durability-service replay at all, it actively resends the full marker set whenever a new subscriber connects. /global_routes itself (a plain custom message, no embedded image/mesh types, and genuinely only republished in response to an edit – never periodically) was confirmed to not have this problem, so it's left as transient_local, publish-on-change only, with no timer.
| void publish | ( | rclcpp::Node & | node | ) |
Read "routes.package"/"routes.map_path_file" from node, load the routes they name, publish them once on /global_routes (QoS: depth 1, transient_local, reliable, per the user's own spec for this topic), and set up the visualization + interactive-marker publishers so the routes can be edited live from RViz.
Also starts a low-rate timer that keeps re-publishing the visualization MarkerArray (see the class doc comment for why).
| node | Node to declare parameters on and to create the publishers/interactive marker server from. Must outlive this RoutesPublisher. |
| std::runtime_error | if the parameters are unset or the named package doesn't exist. |
1.17.0