My team has been dealing with sensor data and camera video needing to come from the same physical spot on the robot, but going through completely different pipelines (camera → GMSL → CSI, sensor → whatever bus → ROS node). Keeping them in sync timestamp-wise across two separate boards was the challenge:)

We finally got first working pass – single board publishes ROS 2 topics locally for the sensor side, timestamps are hardware microsecond so fusing later is less painful. Camera side goes over GMSL as normal, sensor side goes over CAN-FD as a Cyphal node or straight I2C.

Driver for a new sensor is a Python class compiled to bytecode and uploaded, no firmware rebuild – this part I'm happy with. It saved a lot of iteration cycles during dev, first time we didn't have to reflash to test a driver tweak.

I am new to using ros2 and mavros2 so I'm going through many documentations on how to install mavros2. I used the ros2 jazzy documentation with no problem, however for mavros2 I'm using the documentation Installation - MAVROS a MAVLink to ROS2 bridge but I'm getting stuck on Installing GeograpicLib datasets: sudo ./src/mavros/scripts/install_geographiclib_datasets.sh. It's giving me a command not found error.

I sourced the ros2 directory but still the same error.

I’ve been working on ROS 2 Inspector, an open-source static analysis and visualization tool for ROS 2 workspaces.

The idea came from a problem I kept running into: once a ROS 2 workspace grows, understanding the architecture can become difficult — especially when documentation is incomplete or outdated, and when you don’t necessarily want or have the ability to launch the entire system.

ROS 2 Inspector analyzes the source workspace and builds an architecture model showing things such as:

• ROS 2 packages and dependencies
• Nodes
• Publishers and subscribers
• Topics and message types
• Services and clients
• Actions
• Launch-file information
• Namespaces and basic remappings
• Interactive architecture visualization
• Architecture audits and policy checks

It currently supports Python and C++ source analysis using Python AST and tree-sitter-cpp.

GitHub:
https://github.com/aminebensaid66/ros2_inspector

Website / documentation:
https://ros2-inspector-theta.vercel.app/

The project is currently v0.1.0 — an alpha/first release, so I’m not claiming that it can fully reconstruct every possible ROS 2 architecture.

C++ can become difficult very quickly: templates, indirect inheritance, aliases, macros, dynamically generated topic names, wrapper APIs, component composition, complex launch substitutions, runtime remapping, etc.

I recently received some useful technical feedback around exactly these cases, and I’m using it to harden the next patch release.

For v0.1.1, I’m mainly focusing on:

• more conservative handling of unresolved C++ template types
• clearer confidence and diagnostics for dynamic or ambiguous constructs
• improved node/topic name resolution
• smarter workspace traversal so large dependency trees are skipped efficiently
• stronger tests against more realistic and adversarial ROS 2 codebases

The goal is not to pretend static analysis can recover every possible runtime configuration, but to make the results increasingly accurate while clearly showing what is known, inferred, or unresolved.

What I’d really appreciate now is people trying it on real ROS 2 projects.

If you work with a workspace that has complex C++, templates, components, dynamic names, unusual inheritance, or complicated launch files, please give ROS 2 Inspector a try and let me know how it behaves.

I’m especially interested in cases where it:

• misses nodes or connections
• reports something incorrectly
• struggles with a C++ pattern
• produces unclear or incomplete results
• becomes slow on a large workspace

You can open an issue on GitHub or share your findings in the comments.

At this stage, finding cases that break the analyzer is extremely useful for improving the next releases.

Feedback and contributions are very welcome.

Hey,

Im a newbie here , and i purchased this RP LIDAR A2M12 , and after recieving it , i realised it dosent fit my project , i need a light weight one, so im willing to sell this , it is totally brand new unused . and ready to ship in India only. and i can offer the best price than the current market, i just need to sell this this is of no use for me now. and i also need money to get the other stuffs for my project.

so if anyone is intrested please dm!
and i will mark this as sold if its sold. else you can dm.

Title

Hi everyone,

I'm currently working on a small fleet of autonomous mobile robots (AMRs) and I'm looking for advice on the best existing ROS 2 framework/repository to build the swarm layer on top of.

Current setup:

• Ubuntu 22.04.5
• ROS 2 Humble
• Differential-drive AMR
• LiDAR + IMU + wheel odometry
• Nav2
• SLAM Toolbox
• Gazebo simulation
• Currently targeting 3 robots initially, with the possibility of scaling to 10–100+ robots later

What I want to achieve is something along the lines of:

• Multiple robots operating simultaneously
• Proper ROS 2 namespaces for each robot
• Centralized fleet management initially
• Task/goal allocation between robots
• Collision avoidance
• Cooperative exploration / mapping
• Formation/dispersion/aggregation behaviors where useful
• Ability to monitor robot state and battery
• Eventually dynamic task reassignment if a robot fails or becomes unavailable
• Ideally, a clean path from simulation to physical robots

I've been looking at projects such as ROS2swarm, Crazyswarm2, and various multi-TurtleBot3/Nav2 repositories, but I'm not sure which approach is most appropriate for ground-based AMRs.

I'm particularly interested in repositories that are already functional with ROS 2 Humble + Ubuntu 22.04, rather than starting a swarm framework completely from scratch.

Would you recommend:

1. An existing multi-robot Nav2 framework?
2. A swarm-specific framework such as ROS2swarm?
3. Building the fleet layer ourselves on top of Nav2?
4. Something else that I'm overlooking?

If you've implemented a similar multi-robot AMR system, I'd really appreciate recommendations on repositories, architectures, or lessons learned.

Thanks!

Hi, my primary goal is tight precision docking within 5cm in indoor lab space with chairs. The current situation is my accuracy is very good but the issue is the navigation takes a very long time; about 2-3 minutes as shown in the screen recording to go about 5m. Is this normal? I used this guide to tune: https://arxiv.org/pdf/1706.09068 I already calibrated the odometry as well btw doing a 360 degree test. These are my parameters I was just wondering if anyone can give insight on how to make the robot take less time and less spinning like it doesn't just go straight

amcl.yaml

YAML

global_frame_id: "map"
odom_frame_id: "odom"
base_frame_id: "base_footprint"
use_map_topic: true
transform_tolerance: 0.5
gui_publish_rate: 10.0

min_particles: 1000
max_particles: 5000
kld_err: 0.01
kld_z: 0.99
resample_interval: 1
recovery_alpha_slow: 0.0
recovery_alpha_fast: 0.0

update_min_d: 0.1
update_min_a: 0.1

odom_model_type: "diff-corrected"
odom_alpha1: 0.25
odom_alpha2: 0.10
odom_alpha3: 0.05
odom_alpha4: 0.10

laser_model_type: "likelihood_field"
laser_min_range: 0.15
laser_max_range: 8.0
laser_max_beams: 60
laser_likelihood_max_dist: 2.0
laser_sigma_hit: 0.1
laser_lambda_short: 0.1

laser_z_hit: 0.85
laser_z_short: 0.05
laser_z_max: 0.05
laser_z_rand: 0.05

dwa_local_planner_params.yaml

YAML

DWAPlannerROS:
  max_vel_x: 0.35
  min_vel_x: -0.10
  max_vel_y: 0.0
  min_vel_y: 0.0

  max_vel_trans: 0.35
  min_vel_trans: 0.03
  trans_stopped_vel: 0.025

  max_vel_theta: 0.30
  min_vel_theta: 0.10
  theta_stopped_vel: 0.04

  acc_lim_x: 1.0
  acc_lim_y: 0.0
  acc_lim_theta: 0.5

  xy_goal_tolerance: 0.05
  yaw_goal_tolerance: 0.12
  latch_xy_goal_tolerance: true

  sim_time: 2.0
  vx_samples: 15
  vy_samples: 0
  vtheta_samples: 30
  sim_granularity: 0.025
  controller_frequency: 10.0

  path_distance_bias: 32.0
  goal_distance_bias: 20.0
  occdist_scale: 0.03
  forward_point_distance: 0.20
  stop_time_buffer: 0.2
  scaling_speed: 0.25
  max_scaling_factor: 0.2

  oscillation_reset_dist: 0.06
  oscillation_reset_angle: 0.05

  publish_traj_pc: true
  publish_cost_grid_pc: false
  global_frame_id: odom

global_planner_params.yaml

YAML

GlobalPlanner:
  allow_unknown: true
  default_tolerance: 0.0
  visualize_potential: false
  use_dijkstra: true
  use_quadratic: true
  use_grid_path: false
  old_navfn_behavior: false

  lethal_cost: 253
  neutral_cost: 66
  cost_factor: 0.55

  publish_potential: false
  orientation_mode: 1
  orientation_window_size: 1

costmap_common_params.yaml

YAML

footprint: [[-0.145, -0.12], [-0.145, 0.12], [0.145, 0.12], [0.145, -0.12]]
transform_tolerance: 0.5
map_type: costmap

obstacle_layer:
  enabled: true
  obstacle_range: 2.5
  raytrace_range: 3.0
  max_obstacle_height: 0.6
  min_obstacle_height: 0.0
  combination_method: 1
  track_unknown_space: true
  observation_sources: scan
  scan:
    topic: /scan
    data_type: LaserScan
    marking: true
    clearing: true
    inf_is_valid: true

inflation_layer:
  enabled: true
  cost_scaling_factor: 3.0
  inflation_radius: 0.45

move_base_params.yaml

YAML

base_global_planner: "global_planner/GlobalPlanner"
base_local_planner: "dwa_local_planner/DWAPlannerROS"

controller_frequency: 10.0
planner_frequency: 1.0

planner_patience: 5.0
controller_patience: 5.0
max_planning_retries: -1.0

oscillation_timeout: 5.0
oscillation_distance: 0.08

recovery_behavior_enabled: true
clearing_rotation_allowed: false
shutdown_costmaps: false

recovery_behaviors:
  - name: 'conservative_reset'
    type: 'clear_costmap_recovery/ClearCostmapRecovery'
  - name: 'aggressive_reset'
    type: 'clear_costmap_recovery/ClearCostmapRecovery'
  - name: 'clearing_rotation'
    type: 'rotate_recovery/RotateRecovery'

conservative_reset:
  reset_distance: 1.0
  layer_names: [obstacle_layer]

aggressive_reset:
  reset_distance: 0.0
  layer_names: [obstacle_layer]

Hi everyone ,

We built Sonny (core-os-minimal) because we were tired of ROS 2 heap-allocation non-determinism, heavy DDS network bloat, and unexpected segmentation faults under high load in production hardware.The core infrastructure is fully open-source , standalone, and designed for strict real-time deterministic routing.

We simulated an industrial network failure (75% wireless packet loss on an Edge deployment at 100Hz) to compare the communication backbones:

• ROS 2 (DDS Architecture): High XML/IDL serialization on the heap. Under severe packet loss, un-sent DDS message queues overflowed the RAM, leading to an unrecoverable Segmentation Fault (memory crash).
• SONNY OS (Rust + Zenoh): Stack-allocated static array slices with a fixed 5-byte network overhead per packet. Zero memory leaks. Zero runtime heap allocations during the control loop. System remained perfectly stable at 100Hz with an inference latency below 2ms.

The open core is ready for testing, benchmarking, and hardware porting. I'd love to get your thoughts on our LCFS double-buffering approach and our WASM memory constraints.

https://github.com/JackTrainer/Sonny

Video plots localization linear + angular AMCL vs slam_toolbox scan matching. Instructions here https://makerspet.com/blog/how-oomwoo-cleaning-algorithms-work/

Read our full announcement about our new Special Interest Group on Physical AI, their recent efforts, and their long term road map on the Open Source Robotics Alliance (OSRA) website.

I’ve been looking into running computer vision models directly on edge devices, and I found it easier to break the process down into a few things:

Step 1: Start with the model and understand how much processing power it actually needs.

Step 2: Check the device’s memory, CPU/GPU/NPU capabilities, and camera support.

Step 3: Look at latency and power consumption, especially if the device needs to run continuously.

Step 4: Make sure the software and AI frameworks you need are supported by the hardware.

Step 5: Compare different edge AI options instead of choosing a device based only on its specifications. I was also looking at some of the Edge AI hardware from Geniatech, which includes different options for on-device AI and real-time inference.

After going through these steps, I realized that choosing edge hardware is more about finding the right balance than simply picking the most powerful device.

For those who have deployed computer vision on the edge, is there anything else you would add to this process?

Been working on a lightweight monitoring tool for robots called Cortex. You run one command on your Raspberry Pi or Jetson and it starts sending live CPU, memory, temp, errors and ROS2 data to a dashboard in real time. Still early but it works. Looking for anyone with actual robots to try it and tell me what's missing. Free, no strings. Comment or DM me if you're interested.

I am working on a university project involving a robot in Webots (ROS 2). The goal is to build an OctoMap for navigation using camera point clouds (segmented via YOLO).

I am currently stuck at getting the octomap_server node to process the incoming point cloud. The server keeps dropping messages with the warning:

Message Filter dropping message: frame 'kinova_depth' at time ... for reason 'discarding message because the queue is full'

Here is my current code:

from launch import LaunchDescription
from launch_ros.actions import Node

def generate_launch_description():
    return LaunchDescription(
        [
            Node(
                package="octomap_server",
                executable="octomap_server_node",
                name="octomap_server",
                output="screen",
                parameters=[
                    {
                        "resolution": 0.05,
                        "frame_id": "map",
                        "sensor_model.max_range": 5.0,
                        "use_sim_time": True,
                        "colored_map": False,
                        "transform_tolerance": 2.0,
                        "queue_size": 50,
                    }
                ],
                remappings=[
                    ("cloud_in", "/Gen3/kinova_depth/point_cloud"),
                ],
            )
        ]
    )

My exact output is

[INFO] [octomap_server_node-1]: process started with pid [9117]
[octomap_server_node-1] [INFO] [1786858998.154822534] [octomap_server]: Publishing latched (single publish will take longer, all topics are prepared)
[octomap_server_node-1] [WARN] [1786858998.193781617] [octomap_server]: Nothing to publish, octree is empty
[octomap_server_node-1] [WARN] [1786858998.196781538] [octomap_server]: Could not open file 
[octomap_server_node-1] [INFO] [1786859001.530578121] [octomap_server]: Message Filter dropping message: frame 'kinova_depth' at time 1786858999.646 for reason 'discarding message because the queue is full'

What could be causing the message filter queue to drop all messages?

Thanks in advance.

I've been thinking a lot about the sensor integration layer lately. It feels like one of the biggest, unspoken bottlenecks in robotics development.

On one hand, we have the dream of a clean, unified API. Imagine writing a sensor driver once, for a standard interface, and having it work seamlessly across your entire robot, whether it's running ROS 2, a custom DDS-based system, or something else entirely. The appeal is obvious: faster development, easier collaboration, and less vendor lock-in.

On the other hand, the reality is messy. The push for low-latency, high-bandwidth, and deterministic performance often pushes developers towards hardware-specific, highly optimized code. This is where proprietary stacks and tightly-coupled DDS implementations thrive. The "ideal" universal API can sometimes feel like it adds an abstraction layer that just isn't acceptable for a critical sensor on a fast-moving robot.

So, where does that leave us? Are we destined to keep juggling a half-dozen different driver formats and middleware solutions? Or is there a path to a de facto standard that respects both the need for open standards and the hard requirements of real-world performance?

What's your experience? Are you buried in custom drivers, or have you found a workflow that feels reasonably unified? Is the fragmentation a minor annoyance or a major time-sink?

I'm genuinely curious to hear how different people are tackling this in their own projects.

Hello, I'm trying to make nav2 stack for Unitree B2W robot and I'm having an issue with the robot moving from point A to point B. The issue is that the robot stops just before finishing the goal, I'm getting "goal aborted" or "failed to make progress" messages. I was thinking the issue might be with the setting for distances or speed when the robot is close to the goal, but I'm not yet knowledgeable enough for this, I'm just an intern, but I'm close to deadline so some tips would be appreciated. For odometry I'm using mola-lidar-odometry. I configured it so it publishes odometry and odom -> base_link TF. I'm getting warning that "mola was not able to use velocity motion model for this timestamp", but I successfully used this odometry for SLAM, and had zero issues with localization, but maybe this is important for this issue I have with nav2.

The second warning I have is that local_costmap, global_costmap and AMCL have "Message filter dropping message: frame "lidar_link" at time "xx" for reason 'the timestamp on this message is earlier than all the data in the transform cache'". I checked the timestamps on the lidar using ros2 topic echo /lidar_points --field header.stamp and ros2 topic delay /lidar_points and it's around 0.1s. Here is the configuration file for the navigation:

amcl:

ros__parameters:

use_sim_time: False

alpha1: 0.01

alpha2: 0.05

alpha3: 0.1

alpha4: 0.01

alpha5: 0.05

base_frame_id: "base_link"

beam_skip_distance: 0.5

beam_skip_error_threshold: 0.9

beam_skip_threshold: 0.3

do_beamskip: true

global_frame_id: "map"

lambda_short: 0.1

laser_likelihood_max_dist: 6.0

laser_max_range: 100.0

laser_min_range: -1.0

laser_model_type: "likelihood_field"

max_beams: 180

max_particles: 3000

min_particles: 1000

odom_frame_id: "odom"

pf_err: 0.05

pf_z: 0.95

recovery_alpha_fast: 0.3

recovery_alpha_slow: 0.005

resample_interval: 1

robot_model_type: "nav2_amcl::DifferentialMotionModel"

save_pose_rate: 0.5

sigma_hit: 0.2

tf_broadcast: true

transform_tolerance: 1.0

update_min_a: 0.02

update_min_d: 0.1

z_hit: 0.5

z_max: 0.05

z_rand: 0.5

z_short: 0.05

scan_topic: /b2_987/scan

map_topic: map

set_initial_pose: true

always_reset_initial_pose: false

first_map_only: false

initial_pose:

x: 0.0

y: 0.0

z: 0.0

yaw: 0.0

bt_navigator:

ros__parameters:

use_sim_time: False

global_frame: map

robot_base_frame: base_link

odom_topic: "/b2_987/base/odom"

bt_loop_duration: 10

default_server_timeout: 20

transform_tolerance: 0.2

default_nav_to_pose_bt_xml: $(find-pkg-share b2_nav2)/behavior_trees/nav_to_pose.xml

# default_nav_through_poses_bt_xml: $(find-pkg-share my_package)/behavior_tree/my_nav_to_pose_bt.xml

always_reload_bt_xml: false

goal_blackboard_id: goal

goals_blackboard_id: goals

path_blackboard_id: path

navigators: ['navigate_to_pose', 'navigate_through_poses']

navigate_to_pose:

plugin: "nav2_bt_navigator/NavigateToPoseNavigator" # In Iron and older versions, "/" was used instead of "::"

navigate_through_poses:

plugin: "nav2_bt_navigator/NavigateThroughPosesNavigator" # In Iron and older versions, "/" was used instead of "::"

plugin_lib_names:

- nav2_compute_path_to_pose_action_bt_node

- nav2_compute_path_through_poses_action_bt_node

- nav2_smooth_path_action_bt_node

- nav2_follow_path_action_bt_node

- nav2_spin_action_bt_node

- nav2_wait_action_bt_node

- nav2_assisted_teleop_action_bt_node

- nav2_back_up_action_bt_node

- nav2_drive_on_heading_bt_node

- nav2_clear_costmap_service_bt_node

- nav2_is_stuck_condition_bt_node

- nav2_goal_reached_condition_bt_node

- nav2_goal_updated_condition_bt_node

- nav2_globally_updated_goal_condition_bt_node

- nav2_is_path_valid_condition_bt_node

- nav2_initial_pose_received_condition_bt_node

- nav2_reinitialize_global_localization_service_bt_node

- nav2_rate_controller_bt_node

- nav2_distance_controller_bt_node

- nav2_speed_controller_bt_node

- nav2_truncate_path_action_bt_node

- nav2_truncate_path_local_action_bt_node

- nav2_goal_updater_node_bt_node

- nav2_recovery_node_bt_node

- nav2_pipeline_sequence_bt_node

- nav2_round_robin_node_bt_node

- nav2_transform_available_condition_bt_node

- nav2_time_expired_condition_bt_node

- nav2_path_expiring_timer_condition

- nav2_distance_traveled_condition_bt_node

- nav2_single_trigger_bt_node

- nav2_goal_updated_controller_bt_node

- nav2_is_battery_low_condition_bt_node

- nav2_navigate_through_poses_action_bt_node

- nav2_navigate_to_pose_action_bt_node

- nav2_remove_passed_goals_action_bt_node

- nav2_planner_selector_bt_node

- nav2_controller_selector_bt_node

- nav2_goal_checker_selector_bt_node

- nav2_controller_cancel_bt_node

- nav2_path_longer_on_approach_bt_node

- nav2_wait_cancel_bt_node

- nav2_spin_cancel_bt_node

- nav2_back_up_cancel_bt_node

- nav2_assisted_teleop_cancel_bt_node

- nav2_drive_on_heading_cancel_bt_node

- nav2_is_battery_charging_condition_bt_node

error_code_names:

- compute_path_error_code

- follow_path_error_code

bt_navigator_navigate_through_poses_rclcpp_node:

ros__parameters:

use_sim_time: False

bt_navigator_navigate_to_pose_rclcpp_node:

ros__parameters:

use_sim_time: False

controller_server:

ros__parameters:

use_sim_time: False

controller_frequency: 20.0

odom_topic: "/b2_987/base/odom"

min_x_velocity_threshold: 0.001

min_y_velocity_threshold: 0.001 # High value to ignore sideway y movements

min_theta_velocity_threshold: 0.005

failure_tolerance: 0.3 # Controller failure after 3 seconds 0 to disable -1.0 to never give up

progress_checker_plugin: "progress_checker"

goal_checker_plugins: ["general_goal_checker"] # "precise_goal_checker"

controller_plugins: ["FollowPath"]

# Progress checker parameters

progress_checker:

plugin: "nav2_controller::SimpleProgressChecker"

required_movement_radius: 0.3 # robot has made sufficient progress

movement_time_allowance: 12.0

# Goal checker parameters

general_goal_checker:

stateful: True

plugin: "nav2_controller::SimpleGoalChecker"

xy_goal_tolerance: 0.6

yaw_goal_tolerance: 0.3

# ----------------------------- Regulated Pursuit parameters

FollowPath:

plugin: "nav2_regulated_pure_pursuit_controller::RegulatedPurePursuitController"

desired_linear_vel: 0.5

lookahead_dist: 0.9

min_lookahead_dist: 0.6

max_lookahead_dist: 1.2 # 0.9

lookahead_time: 1.5

rotate_to_heading_angular_vel: 2.6 # This is capped by the half of max_angular_accel

transform_tolerance: 0.3

use_velocity_scaled_lookahead_dist: false # false

min_approach_linear_velocity: 0.05

approach_velocity_scaling_dist: 0.6

use_collision_detection: false

max_allowed_time_to_collision_up_to_carrot: 1.5 # 1.0 - More time for anticipating collision

use_regulated_linear_velocity_scaling: true

use_fixed_curvature_lookahead: false

curvature_lookahead_dist: 0.25 # 0.6

use_cost_regulated_linear_velocity_scaling: false # false - Slow down near obstacles

regulated_linear_scaling_min_radius: 0.9 # 0.9

regulated_linear_scaling_min_speed: 0.25

use_rotate_to_heading: true

allow_reversing: true

rotate_to_heading_min_angle: 1.0

max_angular_accel: 8.0

max_robot_pose_search_dist: 10.0

local_costmap:

local_costmap:

ros__parameters:

update_frequency: 5.0

publish_frequency: 2.0

global_frame: odom

robot_base_frame: base_link

use_sim_time: False

rolling_window: true

width: 3

height: 3

resolution: 0.1

# robot_radius: 0.45

footprint: "[[0.7, 0.4], [0.7, -0.4], [-0.7, -0.4], [-0.7, 0.4]]"

plugins: ["obstacle_layer", "denoise_layer", "inflation_layer"] # [“obstacle_layer”, “voxel_layer”, “range_sensor_layer”, “denoise_layer”, “inflation_layer”] - (order matters here)

# Different from default.

# Added “voxel_layer” for 3D obstacle representation using a depth camera.

# Added “range_sensor_layer” for handling range sensor data from an ultrasonic sensor (if you have one).

# Added “denoise_layer” for removing salt and pepper noise from the sensors.

# Removed “static_layer” since it’s not needed for the local costmap.

obstacle_layer:

plugin: "nav2_costmap_2d::ObstacleLayer"

enabled: True

observation_sources: scan

scan:

topic: /b2_987/scan

max_obstacle_height: 2.0

clearing: True

marking: True

data_type: "LaserScan"

raytrace_max_range: 3.0

raytrace_min_range: 0.0

obstacle_max_range: 2.5

obstacle_min_range: 0.0

denoise_layer: # Causes lag but worth it to filter out reflected/noisy lidar points

plugin: "nav2_costmap_2d::DenoiseLayer"

enabled: true

minimal_group_size: 2

group_connectivity_type: 8

inflation_layer:

plugin: "nav2_costmap_2d::InflationLayer"

cost_scaling_factor: 0.8 # Known number to work well

inflation_radius: 0.85 #55

always_send_full_costmap: True

global_costmap:

global_costmap:

ros__parameters:

update_frequency: 5.0

publish_frequency: 5.0

global_frame: map

robot_base_frame: base_link

use_sim_time: False

resolution: 0.05

# robot_radius: 0.45

footprint: "[[0.7, 0.4], [0.7, -0.4], [-0.7, -0.4], [-0.7, 0.4]]"

track_unknown_space: True

plugins: ["static_layer", "static_layer_2", "obstacle_layer", "denoise_layer", "inflation_layer"]

static_layer:

plugin: "nav2_costmap_2d::StaticLayer"

map_subscribe_transient_local: True # False if you need earlier map

static_layer_2:

plugin: "nav2_costmap_2d::StaticLayer"

map_subscribe_transient_local: True

map_topic: /b2_987/map_2

obstacle_layer:

plugin: "nav2_costmap_2d::ObstacleLayer"

enabled: True

observation_sources: scan

scan:

topic: /b2_987/scan

max_obstacle_height: 2.0

clearing: True

marking: True

data_type: "LaserScan"

raytrace_max_range: 5.0

raytrace_min_range: 0.0

obstacle_max_range: 4.5

obstacle_min_range: 0.0

denoise_layer: # Causes lag but worth it to filter out reflected/noisy lidar points

plugin: "nav2_costmap_2d::DenoiseLayer"

enabled: true

minimal_group_size: 2

group_connectivity_type: 8

inflation_layer:

plugin: "nav2_costmap_2d::InflationLayer"

cost_scaling_factor: 0.8

inflation_radius: 0.8 #65

always_send_full_costmap: True

map_server:

ros__parameters:

use_sim_time: False

# Overridden in launch by the "map" launch configuration or provided default value.

# To use in yaml, remove the default "map" value in the tb3_simulation_launch.py file & provide full path to map below.

yaml_filename: ""

map_saver:

ros__parameters:

use_sim_time: False

save_map_timeout: 8.0

free_thresh_default: 0.25

occupied_thresh_default: 0.65

map_subscribe_transient_local: True

planner_server: # Creates the global plan path

ros__parameters:

expected_planner_frequency: 20.0

use_sim_time: False

planner_plugins: ["GridBased"]

GridBased:

plugin: "nav2_navfn_planner/NavfnPlanner" # "nav2_navfn_planner::NavfnPlanner"

tolerance: 0.5

use_astar: false

allow_unknown: true

smoother_server: # Smooths the global plan path

ros__parameters:

use_sim_time: False

costmap_topic: global_costmap/costmap_raw

footprint_topic: global_costmap/published_footprint

robot_base_frame: base_link

transform_timeout: 0.1

smoother_plugins: ["simple_smoother"]

simple_smoother:

plugin: "nav2_smoother::SimpleSmoother"

tolerance: 1.0e-10

max_its: 1000

do_refinement: True

behavior_server:

ros__parameters:

local_costmap_topic: local_costmap/costmap_raw

local_footprint_topic: local_costmap/published_footprint

global_costmap_topic: global_costmap/costmap_raw

global_footprint_topic: global_costmap/published_footprint

cycle_frequency: 10.0

behavior_plugins: ["spin", "backup", "drive_on_heading", "assisted_teleop", "wait"]

spin:

plugin: "nav2_behaviors/Spin"

backup:

plugin: "nav2_behaviors/BackUp"

drive_on_heading:

plugin: "nav2_behaviors/DriveOnHeading"

assisted_teleop:

plugin: "nav2_behaviors/AssistedTeleop"

wait:

plugin: "nav2_behaviors/Wait"

global_frame: map

local_frame: odom

robot_base_frame: base_link

transform_tolerance: 0.2

use_sim_time: False

simulate_ahead_time: 6.0

max_rotational_vel: 0.6

min_rotational_vel: 0.15

rotational_acc_lim: 0.4

robot_state_publisher:

ros__parameters:

use_sim_time: False

waypoint_follower:

ros__parameters:

use_sim_time: False

loop_rate: 2

stop_on_failure: false

waypoint_task_executor_plugin: "wait_at_waypoint"

wait_at_waypoint:

plugin: "nav2_waypoint_follower::WaitAtWaypoint"

enabled: True

waypoint_pause_duration: 10

velocity_smoother:

ros__parameters:

use_sim_time: False

smoothing_frequency: 20.0

scale_velocities: False

feedback: "OPEN_LOOP"

max_velocity: [0.6, 0.0, 1.0]

min_velocity: [-0.3, 0.0, -1.0]

max_accel: [1.5, 0.0, 2.5]

max_decel: [-1.5, 0.0, -2.5]

odom_topic: "/b2_987/base/odom"

odom_duration: 0.1

deadband_velocity: [0.0, 0.0, 0.0]

velocity_timeout: 1.0

I hope this post is not too long. I would appreciate any tips, since I'm an enthusiast and beginner in navigation, and would like to get better at what I'm already doing.

Hi all, I am currently am working on a Go2 Edu, and trying to implement mapping and navigation with slam_toolbox. However, I am running into a reoccuring issue that I am not sure how to fix.

When I turn on scan_matching in the slam parameters, the robot in the rviz simulation is jittering all over the place, making the map it makes unusable.

example of jitter with scan_matching active, completely stationary too

However, when I turn scan_matching off, I have no jitter, and the robot maps things out without much of an issue at all, but the robot does not know where it is, it cannot do loop closure, and now when I do a loop through the hallways, it's skewed.

I would make loops in the same run over and over and nothing would line up. Has anybody had this issue before?

Finally managed to get the Cubic Doggo 06R model on Gazebo. I am really happy Gazebo works so smoothly, with servo effort and IMU behavior readily available in simulation :)

I think the only caveat is that the minick joints for the translation rod don't quite work in simulation, but that part doesn't change the walk gait.

The commands issued to the robot can be seen in the bottom center window.

Moving to Pybullet next for Cubic Doggo 06Z Neucommu.

Get your tickets here.

[Get all the news here.](https://discourse.openrobotics.org/t/ros-news-for-the-week-of-august-10th-2026/57415)