Add timer-based propagation functionality to AMCL #492

fbattocchia · 2025-08-05T16:28:03Z

Proposed changes

Add 'increase_propagation' parameter (0-100 Hz) for timer-based propagation
Implement propagation_timer_callback() for forced propagation updates
Add update_propagation() method to Amcl class for motion-only updates
Add comprehensive tests for propagation timer functionality
Use MutuallyExclusive callback group for thread safety
Timer disabled by default (frequency = 0.0)

This feature allows for increased propagation rates independent of sensor updates.
This improvement allows the implementation of the speed-based motion model

Type of change

🐛 Bugfix (change which fixes an issue)
🚀 Feature (change which adds functionality)
📚 Documentation (change which fixes or extends documentation)

Checklist

Lint and unit tests (if any) pass locally with my changes
I have added tests that prove my fix is effective or that my feature works
I have added necessary documentation (if appropriate)
All commits have been signed for DCO

Signed-off-by: fbattocchia <[email protected]>

glpuga

Great work @fbattocchia ! left a few comments.

glpuga · 2025-08-13T19:50:50Z

beluga_amcl/src/amcl_node.cpp

+  // Force a propagation-only update (without sensor data)
+  particle_filter_->update_propagation(base_pose_in_odom.value());
+
+  RCLCPP_INFO(get_logger(), "Forced propagation update executed");


Maybe this log will be too noisy, logging this message at high rate?

+1. Consider demoting it to DEBUG.

glpuga · 2025-08-13T19:51:59Z

beluga_amcl/src/amcl_node.cpp

-    // tf thread. The message filter we are using avoids the need for it.
    tf2::convert(
        tf_buffer_
            ->lookupTransform(
-                get_parameter("odom_frame_id").as_string(), get_parameter("base_frame_id").as_string(),
-                tf2_ros::fromMsg(laser_scan->header.stamp))
+                get_parameter("odom_frame_id").as_string(), get_parameter("base_frame_id").as_string(), time)
            .transform,
        base_pose_in_odom);
+    return base_pose_in_odom;
  } catch (const tf2::TransformException& error) {
-    RCLCPP_ERROR(get_logger(), "Could not transform from odom to base: %s", error.what());


Good call wrapping this in a function.

glpuga · 2025-08-13T20:05:08Z

beluga_amcl/src/amcl_node.cpp

+  }
+
+  // Get base pose in odom frame at laser scan timestamp
+  auto base_pose_in_odom = get_base_pose_in_odom(tf2_ros::fromMsg(laser_scan->header.stamp));


I wonder if it can happen that we get a lidar message with a timestamp that is previous to a get_base_pose_in_odom() update.

Say, we execute get_base_pose_in_odom() at 10, 20, 30, 40, 50 and then we get a lidar message with timestamp 45. We might be adding a little bit more noise then.

Maybe when we update the motion model from a separate thread then we should either

Only update if the time stamp is later (no noise added then). If we don't, particle state might be up to one timer event behind sensor data.

Repeat the value of the latest get_base_pose_in_odom() odom value we updated (so that no extra noise is ever added. We will always be up to one timer event behind sensor timestamp.

Always update. If we get "late" lidar messages, we might "roll back" motion from the particle state in between timer activations and in the end, end up adding more noise.

I tend to like more 1 or 2. 3 might add a lot more noise if the late arrivers are recurrent.
Say we update motion at 40hz, get lidar messages at 10hz, and lidar messages always end up arriving after the timer for a later timestamp already updated the filter. 1 in four message will add false motion and increase noise.

Thoughts @fbattocchia @hidmic ?

Say, we execute get_base_pose_in_odom() at 10, 20, 30, 40, 50 and then we get a lidar message with timestamp 45. We might be adding a little bit more noise then.

I mean, we would be "rolling back" motion from 50 to 45, then forwarding again from 45 to 60 in the next timer event, thus adding extra "motion" and thus noise (proportional to motion).

I wonder if it can happen that we get a lidar message with a timestamp that is previous to a get_base_pose_in_odom() update.

That's a very good point, and yes, this can absolutely happen. It's an out of sequence measurement (OOSM) case. A principled, general solution is probably out of scope for your purposes though (e.g. https://ieeexplore.ieee.org/document/8455401, but there is quite a bit of research on the topic).

I tend to like more 1 or 2. 3 might add a lot more noise if the late arrivers are recurrent.

🤔 What if we don't touch the filter itself? If we let it evolve at lidar rates, we can still propagate the latest distribution up to current time on timer callback. Our control deltas wouldn't be any larger than they are at lidar rates. You could even do that deterministically on the latest estimate by applying an unscented transform with the motion nonlinear function (which we don't have, we just have a sampler, but it could be added) and spare the cost of sampled propagation.

What if we don't touch the filter itself? If we let it evolve at lidar rates...

I'm not sure I follow. Can you provide an example of what it would look like?

Another option is to do the the updates lazily:

We don't update the filter in the timer callback, we just take note of the latest odometry motion at that time and queue it for later. When the lidar message arrives, we process the queue all the way up to the last timestamp that is before the lidar timestamp and leave any remaining one in the queue for later.

We transfer the work of updating the filter to the lidar callback and force an ordered update sequence.

Ahh, I see now. I thought you wanted estimates at a rate higher than the lidar rate, but this is about processing odometry at a higher rate than lidar rate. If it were the former, what I meant is that you can always predict forward from the latest estimate (which is almost the same as relying on odometry given a fixed map to odom transform but for the explicit uncertainty modelling). But I sense it's the latter, so +100 to lazy updates. Maybe we can collect all odometry updates in a bigger control window.

I think it's a good idea to implement lazily updates.

glpuga · 2025-08-13T20:09:01Z

beluga_ros/src/amcl.cpp

+  std::visit(
+      [&, this](auto& policy, auto& motion_model) {
+        particles_ |= beluga::actions::propagate(policy, motion_model(control_action_window_ << base_pose_in_odom)) |
+                      beluga::actions::normalize(policy);


We don't need to normalize, since we only affected distribution density, but we left the weights unchanged.

glpuga · 2025-08-13T20:10:59Z

beluga_ros/test/test_amcl.cpp

+TEST(TestAmcl, UpdatePropagationWithNoParticles) {
+  auto amcl = make_amcl();
+  amcl.update_propagation(Sophus::SE2d{});
+  ASSERT_EQ(amcl.particles().size(), 0);
+}
+


I get that this manages to make the coverage checker think that the function was tested, but it does not look like its functionally testing anything. Let's do a propagation step with a few particles in the set.

Yes, I did the test to achieve coverage, I agree with it doesn't make much sense. What I need to test is that it doesn't do anything because there are no particles. I changed the function's logic so I wouldn't have to do that check. (Another option would be to return a bool and verify the return in the test.)

hidmic · 2025-08-13T20:15:53Z

beluga_amcl/src/amcl_node.cpp

+    descriptor.floating_point_range[0].from_value = 0.0;
+    descriptor.floating_point_range[0].to_value = 100.0;
+    descriptor.floating_point_range[0].step = 0.0;
+    declare_parameter("increase_propagation", rclcpp::ParameterValue(0.0), descriptor);


@fbattocchia nit:

Suggested change

declare_parameter("increase_propagation", rclcpp::ParameterValue(0.0), descriptor);

declare_parameter("propagation_rate", rclcpp::ParameterValue(0.0), descriptor);

perhaps?

hidmic · 2025-08-13T20:17:07Z

beluga_amcl/src/amcl_node.cpp

+  // Force a propagation-only update (without sensor data)
+  particle_filter_->update_propagation(base_pose_in_odom.value());
+
+  RCLCPP_INFO(get_logger(), "Forced propagation update executed");


+1. Consider demoting it to DEBUG.

hidmic · 2025-08-13T20:17:20Z

beluga_amcl/src/amcl_node.cpp

+  }
+
+  // Get current base pose in odom frame (latest available)
+  auto base_pose_in_odom = get_base_pose_in_odom(tf2::TimePointZero);


@fbattocchia nit: can be const

hidmic · 2025-08-13T20:19:06Z

beluga_ros/include/beluga_ros/amcl.hpp

+   *
+   * \param base_pose_in_odom Base pose in the odometry frame.
+   */
+  void update_propagation(Sophus::SE2d base_pose_in_odom);


@fbattocchia consider making this just another update overload.

Suggested change

void update_propagation(Sophus::SE2d base_pose_in_odom);

void update(const Sophus::SE2d& base_pose_in_odom);

It is updating after all, it just uses less data.

hidmic · 2025-08-13T20:19:16Z

beluga_ros/src/amcl.cpp

+  std::visit(
+      [&, this](auto& policy, auto& motion_model) {
+        particles_ |= beluga::actions::propagate(policy, motion_model(control_action_window_ << base_pose_in_odom)) |
+                      beluga::actions::normalize(policy);


hidmic · 2025-08-13T20:35:20Z

beluga_amcl/src/amcl_node.cpp

+  }
+
+  // Get base pose in odom frame at laser scan timestamp
+  auto base_pose_in_odom = get_base_pose_in_odom(tf2_ros::fromMsg(laser_scan->header.stamp));


I wonder if it can happen that we get a lidar message with a timestamp that is previous to a get_base_pose_in_odom() update.

That's a very good point, and yes, this can absolutely happen. It's an out of sequence measurement (OOSM) case. A principled, general solution is probably out of scope for your purposes though (e.g. https://ieeexplore.ieee.org/document/8455401, but there is quite a bit of research on the topic).

I tend to like more 1 or 2. 3 might add a lot more noise if the late arrivers are recurrent.

🤔 What if we don't touch the filter itself? If we let it evolve at lidar rates, we can still propagate the latest distribution up to current time on timer callback. Our control deltas wouldn't be any larger than they are at lidar rates. You could even do that deterministically on the latest estimate by applying an unscented transform with the motion nonlinear function (which we don't have, we just have a sampler, but it could be added) and spare the cost of sampled propagation.

Signed-off-by: fbattocchia <[email protected]>

hidmic · 2025-08-19T12:34:03Z

beluga_amcl/src/amcl_node.cpp

+    while (!odometry_motion_buffer_.empty()) {
+      const auto& [odom_time, odom_pose] = odometry_motion_buffer_.front();
+      if (odom_time >= laser_scan_stamp) {
+        break;
+      }
+      particle_filter_->update(odom_pose);
+      odometry_motion_buffer_.pop_front();
+    }


@fbattocchia meta: it's a bit of a bummer that the feature exists outside core Beluga but this is simple enough. How would you go about adding (some) support for this at the motion model level if we had to?

yes, I could define an interface in the Beluga motion model to accept a sequence of movements (for example, apply_odometry_sequence or update_odometry_buffer_until) and process them all together

hidmic · 2025-08-19T12:35:37Z

beluga_amcl/src/amcl_node.cpp

+    return;
+  }
+
+  const auto now = this->now();


@fbattocchia now() will likely be different than the latest transform time. Consider using the latter.

On a more general note, it's starting to look like time is a relevant quantity we don't often propagate and we probably should.

Signed-off-by: fbattocchia <[email protected]>

glpuga

Great work! a few comments.

glpuga · 2025-08-26T12:45:09Z

beluga_amcl/src/amcl_node.cpp

+
+  {
+    auto descriptor = rcl_interfaces::msg::ParameterDescriptor();
+    descriptor.description = "Set true to enable increased propagation, and set false to disable it.";


Suggested change

descriptor.description = "Set true to enable increased propagation, and set false to disable it.";

descriptor.description = "Set true to enable odometry-driven filter propagation.";

glpuga · 2025-08-26T12:51:07Z

beluga_amcl/src/amcl_node.cpp

+  {
+    auto descriptor = rcl_interfaces::msg::ParameterDescriptor();
+    descriptor.description = "Set true to enable increased propagation, and set false to disable it.";
+    declare_parameter("propagation_rate", rclcpp::ParameterValue(false), descriptor);


We need to change the name of the parameter.

maybe use_odometry_propagation?

Better odometry_driven_propagation

glpuga · 2025-08-26T12:52:52Z

beluga_amcl/test/test_amcl_node.cpp

+  EXPECT_EQ(amcl_node_->has_odom_sub(), true);
+}
+
+TEST_F(TestNode, PropagationRate) {


Related t changing the parameter name.

glpuga · 2025-08-26T12:56:11Z

beluga_amcl/test/test_amcl_node.cpp

+  // Check that odometry_motion_buffer_ was consumed up to the lidar timestamp
+  EXPECT_EQ(amcl_node_->odometry_motion_buffer().size(), 0);


Add two more odometry messages: one with a timestamp equal than the one in the lidar, and one later, and test that we consume all but the one with the later timestamp.

Receiving lidar and odometry messages with the same timestamp is a frequent thing in simulators.

glpuga · 2025-08-26T12:58:43Z

beluga_ros/include/beluga_ros/amcl.hpp

 };

+/// Type Buffer for queued odometry motions (timestamp, pose)
+using OdometryMotion = std::pair<tf2::TimePoint, Sophus::SE2d>;


nit: while pairs and tuples are great for function-local anonymous data types, it might be better to just use a struct for this.

Nevermind, if we move this into a private type in beluga_amcl, then a tuple is ok.

glpuga · 2025-08-26T13:01:10Z

beluga_ros/src/amcl.cpp

+void Amcl::process_buffered_odometry_until(std::deque<OdometryMotion>& buffer, const tf2::TimePoint& until) {
+  while (!buffer.empty()) {
+    const auto& [odom_time, odom_pose] = buffer.front();
+    if (odom_time >= until)
+      break;
+    update(odom_pose);
+    buffer.pop_front();
+  }
+}


it sounds to me like this belongs in beluga_amcl.cpp, justl ike the OdometryMotion datatype, since implementing the odometry message queue is that file's concern.

My only comment here, and it is as meta as #492 (comment) was, is that processing a longer window of odometry measurements is something that could be pushed to the core motion model. This is like conditioning the proposal distribution on a control sequence that is longer than two elements.

Really, it is a non-issue here. Keep it simple. It can be explored in follow-up work.

glpuga · 2025-08-26T13:01:33Z

beluga_ros/src/amcl.cpp

+void Amcl::process_buffered_odometry_until(std::deque<OdometryMotion>& buffer, const tf2::TimePoint& until) {
+  while (!buffer.empty()) {
+    const auto& [odom_time, odom_pose] = buffer.front();
+    if (odom_time >= until)


I would still process it if it's ==

glpuga · 2025-08-26T13:03:35Z

beluga_amcl/src/amcl_node.cpp

  particle_filter_.reset();
  likelihood_field_pub_.reset();  // attaching likelihood_field_pub_ lifespan to particle_filter_ lifespan
  enable_tf_broadcast_ = false;
+  odometry_motion_buffer_.clear();


We should also clear this whenever the particle filter is initialized/created.

I'm clearing the buffer in do_activate() where the odometry subscription is performed

Yes, but that only happens when the node starts. The filter might be reinitialized multiple times afterwards, whenever the map is updated or when the user sends a pose intialization message. Look for calls to initialize_from_estimate() in amcl_node.cpp

Signed-off-by: fbattocchia <[email protected]>

hidmic

Great work @fbattocchia! Left a few minor comments here and there.

I defer the approval to @glpuga.

hidmic · 2025-09-03T12:15:20Z

beluga_amcl/README.md

 |------------------|-------------------------------------------|-----------------------------------------------------------------------------|
 | `map`            | `nav_msgs/OccupancyGrid`                  | Input topic for map updates.                                                |
 | `scan`           | `sensor_msgs/LaserScan`                   | Input topic for laser scan updates.                                         |
+| `odom`           | `nav_msgs/Odometry`                       | Input topic for odometry updates (when use_odometry_propagation is enabled).       |


hidmic · 2025-09-03T12:16:28Z

beluga_amcl/include/beluga_amcl/amcl_node.hpp


 #include <beluga/beluga.hpp>
 #include <beluga_ros/amcl.hpp>
+#include <deque>


@fbattocchia nit: this one goes up with the other C++ standard headers. Wonder why the linter didn't complain 🤔

hidmic · 2025-09-03T12:17:08Z

beluga_amcl/src/amcl_node.cpp

+
+  {
+    auto descriptor = rcl_interfaces::msg::ParameterDescriptor();
+    descriptor.description = "Set true to enable odometry-driven filter propagation.";


@fbattocchia nit:

Suggested change

descriptor.description = "Set true to enable odometry-driven filter propagation.";

descriptor.description = "Enable odometry-driven filter propagation.";

hidmic · 2025-09-03T12:18:28Z

beluga_amcl/src/amcl_node.cpp

+  odometry_motion_buffer_.emplace_back(time, base_pose_in_odom);
+}
+
+void AmclNode::process_buffered_odometry_until(std::deque<OdometryMotion>& buffer, const tf2::TimePoint& until) {


@fbattocchia nit^2: do we need to pass the buffer explicitly? The call site would read better if we didn't.

@hidmic The parameter remained from when I implemented this function in amcl_ros and I forgot to remove it. Thank you for pointing that out.

hidmic · 2025-09-03T12:19:31Z

beluga_amcl/test/test_amcl_node.cpp

 }

+TEST_F(TestNode, OdomSubNotCreatedWhenPropagationDisabled) {
+  amcl_node_->set_parameter(rclcpp::Parameter{"use_odometry_propagation", false});


@fbattocchia nit: shall we check that the default value (when unset) is false too?

@hidmic No, I don't verify that it's the default value, but if I delete this line, I can verify two things: that the default value is false and that the odometry subscription is not created if it is false.

hidmic · 2025-09-03T12:20:41Z

beluga_amcl/test/test_amcl_node.cpp

+  EXPECT_EQ(amcl_node_->odometry_motion_buffer().size(), 0);
+}
+
+TEST_F(TestNode, OdometryBufferConsumedWhenOdomTimestampsMajorThanLidar) {


@fbattocchia nit:

Suggested change

TEST_F(TestNode, OdometryBufferConsumedWhenOdomTimestampsMajorThanLidar) {

TEST_F(TestNode, OdometryBufferConsumedWhenOdomTimestampsGreaterThanLidar) {

glpuga

Great job! Final comments.

glpuga · 2025-09-03T15:13:12Z

beluga_amcl/include/beluga_amcl/amcl_node.hpp

+  /// Odometry updates subscription.
+  rclcpp::Subscription<nav_msgs::msg::Odometry>::SharedPtr odom_sub_;
+


nit, but for you to know:

In this node it does not really matter because this is a lifecycle node and thus subscribers get destroyed before the wrapping class does, but its a good habit to put anything that has a callback int the very last position in the class members declarations.

The reason is so that whenever the class gets destroyed, those are the first to be destroyed, and that includes rendering them unable to execute their callbacks.

If they are not last, some datastructure their callbacks depend on might be destroyed first concurrently with something triggering the callback, and that will usually cause a crash.

This is a frequent cause of flaky tests and nodes that randomly seem to crash when being stopped.

it's good to know

glpuga · 2025-09-03T15:50:49Z

beluga_amcl/src/amcl_node.cpp

+          get_parameter("odom_topic").as_string(), rclcpp::SensorDataQoS(),
+          std::bind(&AmclNode::odometry_callback, this, std::placeholders::_1), common_subscription_options_);
+
+      RCLCPP_INFO(get_logger(), "Subscribed to odom_topic: %s", odom_sub_->get_topic_name());


Suggested change

RCLCPP_INFO(get_logger(), "Subscribed to odom_topic: %s", odom_sub_->get_topic_name());

RCLCPP_INFO(get_logger(), "Subscribed to odometry topic: %s", odom_sub_->get_topic_name());

glpuga · 2025-09-03T15:52:23Z

beluga_amcl/src/amcl_node.cpp

+  if (get_parameter("use_odometry_propagation").as_bool()) {
+    const auto laser_scan_stamp = tf2_ros::fromMsg(laser_scan->header.stamp);
+    process_buffered_odometry_until(odometry_motion_buffer_, laser_scan_stamp);
+  }


nit, but if odometry driven prop is off, the queue will be empty anyway.

@glpuga Removing the if statement would make the code more compact, but in my opinion, less explicit. Keeping it helps clarify that this action is only performed when use_odometry_propagation is enabled, which can be beneficial for someone reading or maintaining the code. But replacing the if with a comment can serve the same purpose, so I'll do that.

Ok, I'm ok with it staying.

Signed-off-by: fbattocchia <[email protected]>

glpuga

Great job @fbattocchia, LGTM. However, don't merge yet!

@hidmic I'd like to have a devel or experimental branch in the repository to buffer changes. I'd rather no longer hit main with changes we have not measured to ensure they have an objective reason to exist and to ensure they don't represent a regression by some other measure.

We should only graduate stuff from devel to main after evaluation.

hidmic · 2025-09-03T21:07:42Z

@hidmic I'd like to have a devel or experimental branch in the repository to buffer changes. I'd rather no longer hit main with changes we have not measured to ensure they have an objective reason to exist and to ensure they don't represent a regression by some other measure.

🤔 I'm on the fence. We don't provide stability guarantees on main. We have release branches and tags for that. How would the transition work? How is it different from ad-hoc feature branches with large patches? I really like the idea of the data driven process for vetting contributions but I want to weigh it against the cost of contribution. It's already difficult to land anything on main, and if we add another gate without a clear process to land a patch (which I know we don't really have, so far it's crafting dedicated experiments and rigs to prove ourselves it's worthy) no one other than us will even dare to try.

feat: Add timer-based propagation functionality to AMCL

8479fd0

Signed-off-by: fbattocchia <[email protected]>

fbattocchia force-pushed the fbattocchia/increase-propagation-rate branch from 025df5c to 8479fd0 Compare August 5, 2025 18:15

add unit test to improve coverage

8086f76

Signed-off-by: fbattocchia <[email protected]>

fbattocchia requested review from glpuga and hidmic August 5, 2025 21:41

glpuga requested changes Aug 13, 2025

View reviewed changes

hidmic reviewed Aug 13, 2025

View reviewed changes

fbattocchia requested review from glpuga and hidmic August 17, 2025 23:44

fbattocchia force-pushed the fbattocchia/increase-propagation-rate branch 3 times, most recently from f4e4640 to 1571ebe Compare August 18, 2025 15:39

fbattocchia added 2 commits August 18, 2025 12:40

added updates lazily of propagation model

1571ebe

Signed-off-by: fbattocchia <[email protected]>

fixed pr

9994687

Signed-off-by: fbattocchia <[email protected]>

hidmic reviewed Aug 19, 2025

View reviewed changes

fbattocchia force-pushed the fbattocchia/increase-propagation-rate branch 2 times, most recently from c066d6a to 4f7b10c Compare August 25, 2025 21:49

add odometry subscriber

4f7b10c

Signed-off-by: fbattocchia <[email protected]>

fbattocchia requested a review from hidmic August 26, 2025 12:03

glpuga requested changes Aug 26, 2025

View reviewed changes

fbattocchia force-pushed the fbattocchia/increase-propagation-rate branch from af0a591 to ce8b3f4 Compare August 28, 2025 16:46

fbattocchia requested a review from glpuga August 28, 2025 16:47

fbattocchia added 2 commits August 28, 2025 13:47

fixed pr

ce8b3f4

Signed-off-by: fbattocchia <[email protected]>

fixed pr

3ff9266

Signed-off-by: fbattocchia <[email protected]>

hidmic mentioned this pull request Sep 3, 2025

Add support for point clouds in beluga_amcl #491

Merged

9 tasks

hidmic reviewed Sep 3, 2025

View reviewed changes

glpuga reviewed Sep 3, 2025

View reviewed changes

fbattocchia requested review from glpuga and hidmic September 3, 2025 19:05

fixed pr

d13e2fc

Signed-off-by: fbattocchia <[email protected]>

glpuga approved these changes Sep 3, 2025

View reviewed changes

	declare_parameter("increase_propagation", rclcpp::ParameterValue(0.0), descriptor);
	declare_parameter("propagation_rate", rclcpp::ParameterValue(0.0), descriptor);

	void update_propagation(Sophus::SE2d base_pose_in_odom);
	void update(const Sophus::SE2d& base_pose_in_odom);

	descriptor.description = "Set true to enable increased propagation, and set false to disable it.";
	descriptor.description = "Set true to enable odometry-driven filter propagation.";

		// Check that odometry_motion_buffer_ was consumed up to the lidar timestamp
		EXPECT_EQ(amcl_node_->odometry_motion_buffer().size(), 0);

	\| `odom` \| `nav_msgs/Odometry` \| Input topic for odometry updates (when use_odometry_propagation is enabled). \|
	\| `odom` \| `nav_msgs/Odometry` \| Input topic for odometry updates (when use_odometry_propagation is enabled). \|

	descriptor.description = "Set true to enable odometry-driven filter propagation.";
	descriptor.description = "Enable odometry-driven filter propagation.";

	TEST_F(TestNode, OdometryBufferConsumedWhenOdomTimestampsMajorThanLidar) {
	TEST_F(TestNode, OdometryBufferConsumedWhenOdomTimestampsGreaterThanLidar) {

		/// Odometry updates subscription.
		rclcpp::Subscription<nav_msgs::msg::Odometry>::SharedPtr odom_sub_;

	RCLCPP_INFO(get_logger(), "Subscribed to odom_topic: %s", odom_sub_->get_topic_name());
	RCLCPP_INFO(get_logger(), "Subscribed to odometry topic: %s", odom_sub_->get_topic_name());

Add timer-based propagation functionality to AMCL #492

Are you sure you want to change the base?

Add timer-based propagation functionality to AMCL #492

Uh oh!

Conversation

fbattocchia commented Aug 5, 2025

Proposed changes

Type of change

Checklist

Uh oh!

glpuga left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hidmic Aug 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

glpuga Aug 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hidmic Aug 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fbattocchia Aug 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hidmic Aug 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

glpuga left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hidmic Aug 13, 2025 •

edited

Loading

glpuga Aug 13, 2025 •

edited

Loading

hidmic Aug 13, 2025 •

edited

Loading

fbattocchia Aug 17, 2025 •

edited

Loading

hidmic Aug 13, 2025 •

edited

Loading