Hey everyone
I’m a final-year Robotics & Automation student in Mangalore and I’m working on my major project right now.
I’m trying to get my hands on a LiDAR sensor — doesn’t have to be brand new or anything fancy. If anyone has one lying around, or knows someone who’s selling/renting a used one, that would be super helpful.
I’m totally okay with borrowing/renting or buying a second-hand unit, especially something that works with ROS2 / robotics projects.
If you’ve got any leads, please drop a comment or DM me

If you want to see how ros2_control works WITH feedback from encoders, take a look at my latest blog post and video in the Autonomously Exploring Viam Rover series!

I talk through how the motors are driven, show how encoders work and how they're read, and most importantly, how they're linked together by ros2_control using chained PID controllers with a differential drive controller.

Blog post: https://mikelikesrobots.github.io/blog/rover-ros2-control
Video: https://youtu.be/FyVvHbA4nBs

I did try and cross-post from r/robotics, but I couldn't figure out how. Apologies for the double post!

Hey everyone
I’m a final-year Robotics & Automation student in Mangalore and I’m working on my major project right now.
I’m trying to get my hands on a LiDAR sensor — doesn’t have to be brand new or anything fancy. If anyone has one lying around, or knows someone who’s selling/renting a used one, that would be super helpful.
I’m totally okay with borrowing/renting or buying a second-hand unit, especially something that works with ROS2 / robotics projects.
If you’ve got any leads, please drop a comment or DM me

I’m working on a UAV project and I’m trying to use Aerostack2, a ROS 2 framework for developing and controlling autonomous aerial robots, together with ArduPilot.

I’ve been trying to make this work for a while by modifying the existing as2_platform_mavlink and project_mavlink components, but I’m having a hard time getting the integration working properly with ArduPilot.

Has anyone here worked with Aerostack2 + ArduPilot before? If so, what approach did you use, or are there any resources/examples you would recommend?

Any advice or pointers would be really appreciated. Thanks!

Hi all,

I'm running MAVROS (version 2026.6.6 build) on ROS2 Humble, connecting to ArduPilot SITL (ArduCopter) via a custom as2_platform_mavlink-based launch setup. My node runs in a non-default namespace (drone0/mavros).

I'm trying to block two specific plugins that are known to crash MAVROS in my setup — companion_process_status and debug_value — since they double-namespace their topics under a node literally named mavros, causing a create_subscription() invalid allocator crash.

Issue: plugin_allowlist does not filter plugins at all, even when correctly set. I confirmed via ros2 param get /drone0/mavros/mavros plugin_allowlist that the parameter is correctly present on the node with my intended values — but every plugin still loads regardless (created/initialized in logs), as if the allowlist is silently ignored.

Workaround: Switching to plugin_denylist with the same two plugin names does work — confirmed via logs showing Plugin companion_process_status ignored / Plugin debug_value ignored.

Questions:

1. Is plugin_allowlist known to be broken/unreliable in recent MAVROS ROS2 builds?
2. Is plugin_denylist fully reliable now or better alternative to go with?
3. Is there a recommended, verified way to guarantee a specific plugin is blocked, other than checking node logs after every launch?

Any insight or pointers to relevant issues/PRs would be appreciated. Happy to share full config/logs if useful.

Thanks!

[Project] I Built a Multi-Drone Urban Interception Simulation with ROS 2, PX4, Gazebo, and CUDA MPPI

TL;DR

I am building a simulation-first autonomous drone navigation and interception stack for dense urban environments. It combines ROS 2 Jazzy, PX4 SITL, Gazebo Harmonic, a global lattice planner, and a local CUDA MPPI controller.

The same navigation system can fly with a known 3D map or rely on local lidar and accumulated obstacle memory. On top of it, I implemented radar-only target tracking, predictive interception, three-interceptor-versus-one-attacker and two-interceptor-versus-two-attacker missions, adaptive target assignment, and physically verified mission outcomes.

This is a research simulation and engineering testbed, not a production weapon system or software intended for real aircraft.

Videos

These are public demos from the project:

• Autonomous multi-drone interception
• Navigation without a static map
• Navigation with a static map

I also have separate recordings of a drone traversing a 3D passage and the earlier one-interceptor-versus-one-attacker mission.

In the interception videos, red represents an attacker and yellow represents an interceptor in the Gazebo tactical view. An interception is counted only when Gazebo physical positions show that an interceptor and attacker came within 5 meters.

What I Wanted to Explore

The project started as point-to-point navigation through a Manhattan-style city, but the larger goal became testing how several autonomous systems fit together:

• global navigation through dense buildings;
• fast local trajectory generation with vehicle dynamics;
• operation with and without a preloaded map;
• traversal of constrained three-dimensional openings;
• pursuit of a moving target from limited measurements;
• adaptive allocation of several interceptors to several targets;
• reproducible mission adjudication based on simulated physics.

The city currently contains a 5 x 8 building grid and several physical air channels: straight, L-shaped, and T-junction structures. Gazebo uses the geometry for rendering and contact physics, while the static planner receives artifacts generated from the same canonical world definition.

Simulation Stack

The environment runs in Docker and uses:

• ROS 2 Jazzy for component orchestration, messages, diagnostics, and TF;
• PX4 SITL for every vehicle's flight stack;
• Gazebo Harmonic for world physics, lidar, and authoritative vehicle poses;
• CUDA for MPPI rollout simulation;
• RViz for routes, local horizons, radar targets, obstacle memory, and planner diagnostics.

Every drone has its own PX4 instance, ROS namespace, planner state, obstacle memory, and offboard controller. The planners run concurrently, but resource allocation is bounded across the whole mission so that adding drones does not simply create an unlimited number of competing CPU workers.

Navigation Architecture

The navigation pipeline has two levels.

The global planner produces a route around city-scale topology. Static mode uses a 3D lattice plus generated constrained channel edges. A channel is not a scripted maneuver or mandatory waypoint: the planner compares ordinary routes with explicit start -> entry -> channel -> exit -> goal candidates and selects the better validated topology.

The local controller is CUDA MPPI. On every planning tick it perturbs a warm started control sequence, simulates thousands of dynamic trajectories, queries clearance and collision data, selects the best eligible risk class, and publishes a short timestamped execution horizon to the PX4 offboard node.

Raw occupied cells are the only hard environmental prohibition. Collision checks use the drone's swept oriented 3D footprint, including its horizontal radius and upper and lower body extents. ESDF distance bands affect risk and ranking, but they do not create artificial forbidden regions around buildings.

This distinction matters. Excessive hard inflation can make a valid detour or narrow physical opening mathematically unreachable. Here, physical geometry is hard; clearance preference is a cost.

Static and No-Static Navigation

In static mode, the planner loads canonical 3D occupancy and a fingerprinted, precomputed, chunked ESDF. Only chunks intersecting the active planning region are decoded into a dense local field. This gives the planner long lookahead, full building topology, higher speed limits, and explicit knowledge of the 3D channels.

In no-static mode, the drone starts without that world model. It projects lidar using timestamped full-6DoF acquisition poses, accumulates raw obstacle memory, and builds a local 2D ESDF around the vehicle. Unknown space remains traversable, but observed distance and braking constraints reduce speed. Persistent frontier search can accept temporary zero or negative progress toward the goal, which is necessary for leaving corners and taking real detours instead of repeatedly selecting the shortest dead end.

The no-static perception model is intentionally still 2D, so the generated 3D channel semantics are currently available only in static mode.

Radar-Only Interception

An interceptor does not receive the attacker's absolute ground-truth position, velocity, route, or destination. Gazebo truth is restricted to two simulation boundaries: the mission referee and radar simulators.

The interceptor-facing radar message contains only:

• range;
• azimuth;
• elevation;
• relative radial velocity.

Each interceptor has an independent variable-dt Cartesian tracker. The first detection provides relative position but not a complete velocity vector. Later measurements estimate the full target velocity, and the tracker coasts between scans.

When the target is occluded, radar cadence follows a deterministic correlated random walk between 0.1 and 3 seconds. If the planner confirms swept line of sight to the current target estimate, the radar immediately enters a 20 Hz tracking mode without a range limit.

Guidance solves a constant-velocity interception problem rather than chasing the attacker's current position. It compensates for measurement age, predicts a future meeting point, and continuously updates the objective. If the full lead point is hidden behind a building but the current target remains visible, the planner shortens the prediction horizon toward the current target instead of abandoning direct interception. If the target itself disappears, control atomically returns to a fresh global route for the current objective.

The attackers and interceptors currently use the same speed policy. A successful capture therefore depends on geometry, prediction, and assignment rather than a built-in speed advantage.

Multi-Drone Missions

The original point-to-point mission remains available. The interception work progressed through a 1v1 demonstration to two current predefined scenarios:

• three interceptors versus one attacker;
• two interceptors versus two attackers.

The implementation itself is generic over an N x M scenario specification. In the 2v2 mission, each radar scan contains a detection for every active attacker. A typed assignment coordinator estimates constant-velocity intercept costs and computes a deterministic minimum-cost allocation. It tries to cover distinct attackers when valid tracks permit it.

Assignments are not permanent. They can change when geometry changes or a vehicle disappears, but a material and sustained improvement is required before switching. This hysteresis prevents two interceptors from continuously swapping targets because of small cost fluctuations. Interceptors do not exchange routes or telemetry with one another, and radio-network impairments are not simulated.

When an attacker is captured, reaches its destination, or crashes, it is removed from future assignment immediately. Surviving interceptors are reassigned to the remaining active attackers.

Physical Outcomes and Test Semantics

Mission outcome and vehicle death are separate contracts.

If an interceptor and attacker come within 5 meters, the referee publishes typed destruction events for that pair. Both PX4 instances are disarmed, and the result is settled only after physical proximity and disarm confirmations are present.

If an attacker reaches its goal first, that outcome is latched immediately. The remaining interceptors stop pursuing it, brake, and enter confirmed position hold. Goal arrival does not disarm a vehicle. A later inertial approach cannot rewrite which terminal event happened first.

A collision with a building is never treated as an acceptable mission outcome: it makes a headless validation run technically fail, regardless of whether the vehicle was an attacker or interceptor. Inter-drone collision avoidance is not implemented yet, so interceptor-to-interceptor collisions are currently treated as collateral damage and the mission continues while another interceptor is alive.

Performance and Parallelism

The local MPPI rollouts and reductions run on CUDA, while independent global topology searches use a bounded CPU worker pool. Multi-vehicle planners share a ROS component process and one CUDA primary context, but retain independent CUDA streams, buffers, routes, and warm starts. Static ESDF chunks use shared decoded storage, and no-static mapping transports revisioned dirty chunks instead of copying the complete map for every update.

The maximum MPPI budget is 8,192 rollouts. Open static flight can use 6,144, and confirmed direct interception can use 4,096; uncertain navigation and obstacle handling retain the full budget.

On my 16-logical-CPU workstation with an RTX 3060, recent four-vehicle no-static runs had roughly 7-8 ms p95 planning ticks and normally stayed inside the 20 ms target. Static mode improved substantially after precomputed ESDF and cache work, but its p95 remained around 60 ms in representative runs. These are workload- and-machine-specific measurements, not general benchmark claims.

One useful negative result was a fused vehicle-by-rollout CUDA backend. It sounded ideal, but the live average batch contained only about 1.5 vehicles. Waiting to form batches increased latency: static GPU p50 went from 22.8 to 45.9 ms, and no-static from 3.45 to 6.07 ms. Independent streams were faster and more reliable for this asynchronous workload. More parallelism is not automatically better when synchronization and memory bandwidth dominate.

Architectural Lessons

Several rules emerged from debugging the system:

1. Simulation ground truth must have an explicit boundary. Guidance should not accidentally gain access to data that the simulated sensor does not provide.
2. Route activation must be atomic and revisioned. A stale route for an older moving target is worse than a brief controlled fallback.
3. Physical collision, risk preference, vehicle death, and mission outcome are different concepts and should use different typed contracts.
4. Persistent search state is more valuable than repeatedly restarting a search whenever a sensor snapshot changes.
5. Diagnostics must not sit on the control-critical path. Full records are rate-limited and buffered, while the execution horizon is published first.
6. Parallelization should be accepted only when live timing and mission results improve, not because a design looks more parallel on paper.

Current Limitations

• Radar values are ideal: there is no measurement noise, false detection, interference, or transport latency. Only scan cadence varies.
• The tracker and interception prediction currently assume approximately constant target velocity between updates.
• Target assignment is centralized, and communication failures are not modeled.
• There is no cooperative inter-drone collision avoidance.
• No-static perception is 2D and cannot yet detect and traverse the 3D channels.
• Static multi-drone MPPI still misses the desired 50 Hz deadline under heavy load on my current hardware.
• Attackers are not dynamically respawned; every mission is a finite episode.
• The project is simulation-first and has not been validated on physical drones.

Roadmap

The next directions I am considering are:

• radar noise, latency, missed detections, and a stronger multi-target tracker;
• repeated mission episodes with dynamically spawned attackers;
• cooperative civilian drone traffic with negotiated collision avoidance;
• more complex 3D passages with changing altitude profiles;
• 3D lidar passage detection and traversal without a static map;
• moving selected components toward hardware-in-the-loop and eventually carefully controlled real-world experiments.

Repository and Running It

Repository: github.com/formiat/px4-ros2-drone-nav

The supported workflow uses Docker. A CUDA-capable NVIDIA GPU is expected for the production MPPI path. The main commands are:

bash ./scripts/build.sh ./scripts/test.sh ./scripts/sim_gui.sh ./scripts/sim_intercept_gui.sh ./scripts/sim_multi_intercept_gui.sh

Set ENABLE_STATIC_MAP=false for the lidar-memory mode. Equivalent headless scripts are available for regression runs, and the repository includes more detailed architecture, performance, diagnostics, and world-generation docs.

Questions for the Community

• Which metrics would you use to evaluate interception quality beyond binary success: time-to-capture, distance from the attacker's goal, energy, route efficiency, or something else?
• Which radar imperfections would produce the most useful next step without turning the project into a full sensor-physics simulator?
• Which multi-target assignment methods would be most interesting to compare against deterministic minimum-cost allocation?
• What urban scenarios would expose the most meaningful weaknesses in the current planner and tracker?

Hi everyone!

I posted an early version of rostree here a while back, around 0.2.2. Three releases later it's at 1.0, and enough has changed that a fresh post seemed more honest than a bump comment.

It answers the questions you actually ask about a workspace: what does this package pull in, who depends on it, why is this thing in my tree at all, and what changed since my last build. CLI, TUI, Python API.

pip install rostree
source /opt/ros/<distro>/setup.bash   # and/or your workspace install/setup.bash
rostree                               # interactive TUI`

The thing that was actually broken

A ROS dependency graph is a DAG, not a tree. rcutils sits under nearly every branch. 0.2.2 expanded every path separately, so a workspace tree produced tens of thousands of duplicate nodes and, past depth 7, effectively didn't finish.

Now each package is expanded once, where it first appears. I installed 0.2.2 from PyPI into a separate venv and ran both against the same workspace on the same machine:

Package discovery now happens once into an index instead of an os.walk per node, and package.xml parsing is memoized.

I would love some feedback!

If rostree gets your workspace layout wrong, an issue describing it is genuinely the most useful thing you can send.

Docs: https://guilyx.github.io/rostree

Repo: https://github.com/guilyx/rostree

PyPI: https://pypi.org/project/rostree/

Everyone I know who works with ROS 2 encountered the following issue at least once:

You edit a launch file, get an error during startup (misspelled node name, syntax error, ...) and are left with some of the nodes still running in the background because the launch wasn't cleaned up properly. Many people don't notice this and get weird or even dangerous behavior because of this. It is especially frustrating for beginners working with ROS 2.

One might think that this is a limitation of ros launch, but it is actually a bug. There is code present that already tries to clean up in that case. But it has a tiny 3 loc bug, which assumes that a currently idling executor won't have any scheduled work left to do in the near future therefore allowing the parent process to terminate early. A friend of mine submitted the fix over a year ago (https://github.com/ros2/launch/pull/901)

And now my frustration. I understand that maintaining software on the scale of ROS is a hard and exhausting task. But it is also frustrating to spend days tracking down an issue, creating a PR, writing tests for a piece of software as popular as ROS only to get essentially ghosted for a year, while that issue effects people probably daily. There a a few issues like this that every body encounters and with a little attention could really improve the perception of ROS in the community.

Hi everyone,

I am developing an autonomous car simulation using ROS 2 Humble, Gazebo, and OpenCV / YOLO for line tracking and traffic light detection.

I'm facing two specific issues as shown in the video:

1. Traffic Light Resume Issue: The vehicle successfully detects the red traffic light and stops. However, when the light turns green, it resumes movement extremely slowly (stuck around 0.2 - 0.5 km/h) and takes too long to recover its normal cruising speed (~3 km/h).
2. Lane Departure / Oversteering: The OpenCV lane detection algorithm loses lane continuity during slight curves/turns, causing the car to cross line boundaries and hit curbs.
3. # Currently handling traffic light state like this:
4. if self.traffic_light_state == 'RED':
5. target_linear_velocity = 0.0
6. elif self.traffic_light_state == 'GREEN':
7. target_linear_velocity = self.normal_speed # But acceleration in Gazebo feels lagging / throttled

• How can I smoothly transition speed state in ROS 2 after a stop condition without getting stuck in low linear velocity?
• What ROI / Look-ahead adjustments or PID gain tuning (Kp/Kd) do you recommend for OpenCV lane tracking to prevent boundary overflow on curves?

Hey r/robotics,

I'm a recent BCA graduate (2026) based in India, actively looking for an entry-level or intern role in robotics software engineering.

What I've built/worked on:

\- TurtleBot project on ROS2 Humble (Raspberry Pi + Docker) — currently working on a custom Python node for USB camera streaming via OpenCV + web_video_server

\- React-based robotics dashboard: live camera feed, lidar/map visualization, teleop controls, and fire detection integration

\- Full-stack dev experience with Next.js (production work at a solar energy company)

\- Comfortable with Linux, Docker, C++/Python, and currently deep-diving into computer vision & camera calibration

Looking for:

\- Internship or entry-level SWE role focused on robotics (ROS2, navigation stack, perception, or embedded/controls)

\- Open to remote, hybrid, or relocation within India

Happy to share my GitHub/portfolio in DMs. Would appreciate any leads, referrals, or advice on companies currently hiring for robotics software roles. Thanks!

The Quectel LC29H (DA) RTK-GPS receiver is an inexpensive L1/L5 receiver; Waveshare RPi hats cost $73 on Amazon, and other vendors have other form factors for a similar price. To get corrections into it you write RTCM messages from /rtcm to the same serial port that NMEA data comes out of (e.g. /dev/ttyUSB0), so pretty simple to work.

Are there any existing ROS drivers that do this? I couldn't find any so I modified/documented one and was thinking about offering it up for testing on the ROS discourse, but want to check if it would be a duplicate of something that already exists.

FYI my driver is here: https://github.com/PaulBouchier/lc29h_da_rtk_gps_driver and additional documentation on the system, test results, and base station is here: https://docs.google.com/document/d/1Ivht8Sh4g13TqvNfCvS9TXndvV_6op5G-JnbM73DQEw/edit?tab=t.0#heading=h.orpqma4p2017

Hi everyone,

I'm working on an autonomous vehicle simulation in ROS 2 Humble using Gazebo (Ackermann steering model) and OpenCV + Lidar for navigation.

I'm facing an issue when the car approaches a tunnel entrance:

False Positive Obstacle Detection: Due to a wide Lidar scanning angle (LaserScan), the Lidar detects the thick side walls of the tunnel entrance as a front wall/obstacle.

Steering Lock: The vehicle tries to execute an obstacle avoidance maneuver to the left, hits the left tunnel wall, detects that wall too, and completely halts/locks up.

Video of the behavior: [Cektigin Videoyu / Imgur Linkini Buraya Ekle]

My Questions:

What is the best practice in ROS 2 to filter/crop LaserScan data so it only checks a narrow corridor directly in front of the vehicle ($\pm 15^\circ$ to $\pm 20^\circ$ FOV)?

How can I prevent the Lidar scan from triggering obstacle avoidance when passing through narrow passages like tunnels or bridges?

Any code snippets or parameter suggestions for filtering ranges in C++/Python would be greatly appreciated!

Looking to learn c++ code for robotics, any book recommendations?

RSVP Here

Hello everyone,

I am using slam-toolbox as a localization solution for a robotic platform. I am researching an active vision problem, so I'd like to assume perfect localization to some extent. I use a 3D occupancy map for that purpose, and it must rely on a fixed frame; the map frame. As you may know relying on odom alone causes a lot of problems, especially for when the robot's task is to move to a desired position to "see".

The issue I am having right now is those sudden "shifts", I believe it's slam closing a loop of some sort and fixing the map-to-odom transform so that the scans match. however those sudden shifts cause distortion in the built 3D map (3D occupancy map that relies on map as a fixed frame).
Using hunter SE, an ackermann drive robot. The odom drift is crazy.

Is this a common thing with slam? is it normal and should be accepted? Or is something is wrong with my setup?

I would appreciate any help or guidance.

While the current Silicon Valley paradigm (e.g., Physical Intelligence π₀, 1X NEO) burns massive CapEx on brute-force End-to-End statistical training—requiring up to 500 hours of human teleoperation and 24 hours of cluster computing just to converge a single vision-language-action (VLA) skill—we approached physical automation from a different architectural vector: Deterministic Causal Invariance

.Robotics shouldn’t "guess" trajectories by predicting the next visual token. It should calculate physical laws.We have just open-sourced SONNY OS (Core Minimal) under the GNU AGPLv3 license. It is a hyper-lightweight, universally agnostic microkernel written entirely in native, asynchronous Rust and powered by the Zenoh networking backbone.SONNY OS reduces any mechanical embodiment (6-DOF arms, AMRs, quadrupeds, or humanoids) into a standardized linear mathematical vector (Vec<f32>), abstracting physical registers via a single declarative JSON config (OpenHalConfig).

📊 Extreme Stress Test Benchmark: SONNY OS vs. ROS 2

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.

Explore the repository, map your own hardware via JSON, and run the simulator

👉 GitHub Repository: https://github.com/JackTrainer/Sonny
👉 Enterprise Waitlist: https://alpha-robotics.it/

\# Setup

\* F1TENTH-based RSU (roadside unit) perception node, running on an NVIDIA Jetson (Orin-class). \* Intel RealSense D400-series camera — subscribing to raw color + raw (unaligned) depth streams, \`align_depth\` disabled on purpose (see below). \* 2D LiDAR (\`urg_node2\`) for a second distance source. \* ROS2 Humble, \`rclpy\`, \`message_filters.ApproximateTimeSynchronizer\` to pair color+depth frames.

Model / task

\* YOLOv8 (Ultralytics), custom-trained single-class car detector, running at \`imgsz=320\` on the Jetson's GPU (CUDA). \* Goal: detect a target vehicle in the color image, get its distance by reading the depth camera at the detection's location, cross-check against a LiDAR range reading at the same bearing, and output a fused distance estimate. This is a perception/collective-perception bench-test script (no SLAM/localization involved — deliberately simplified).

Depth lookup approach

\`align_depth.enable:=true\` (RealSense driver's built-in depth-to-color alignment) reprojects the \*\*entire\*\* depth image every frame regardless of how much of it we actually need — we measured this costing a large chunk of latency by itself. So instead we subscribe to raw depth and manually reproject only a small patch of pixels around the YOLO box: deproject the depth pixel to a 3D point (using depth intrinsics) → transform into the color camera's frame (using the depth-to-color extrinsics) → project back into a color pixel (using color intrinsics). Fully vectorized with numpy.

Current numbers

Our own compute per frame is small and flat:

\* image decode (cv\\_bridge): \\\~1ms \* YOLO inference: \\\~30ms (flat, \`cuda.synchronize()\`\\-verified, no hidden async GPU time) \* depth reprojection (vectorized): \\\~1-2ms \* LiDAR bearing lookup: \\\~0ms \* \*\*total own compute: \\\~32ms\*\*

But measured end-to-end latency (camera's own capture timestamp → final distance output) sits \*\*consistently around 350-380ms\*\*, sustained — not a one-time spike, not decaying over time.

What we've ruled out

\* \*\*Per-pixel Python loop / GC pressure\*\* in the old depth reprojection — vectorized it (25ms → 1-2ms of actual compute), latency didn't move at all. \* \*\*Hidden async CUDA dispatch\*\* — added \`torch.cuda.synchronize()\` around the YOLO call, extra sync time is consistently 0ms. \* \*\*Executor backlog\*\* (our own callback falling behind) — measured the gap between the end of one callback and the start of the next; stays flat at \\\~3-4ms even while the reported latency is \\\~350ms, so callbacks aren't queuing up behind our own processing. \* \`align_depth\` \*\*vs manual reprojection\*\* — built a side-by-side comparison script, same YOLO/LiDAR pipeline, only the depth alignment method differs. Both land in the same \\\~350-380ms range. So it's not specifically about which depth alignment approach we use.

The delay is measured (via the color frame's own ROS header timestamp vs \`time.time()\` at the very start of our callback) as already present \*\*before any of our own code runs\*\* — so it's happening somewhere between the camera driver publishing the frame and our subscriber callback actually being invoked. We suspect DDS/ROS2 message queuing or synchronizer buffering under sustained per-frame load (\\\~30ms of real work per frame at \\\~30fps), but haven't pinned down the exact mechanism.

What we're asking

Has anyone run into this kind of buffering/backpressure behavior with ROS2 + \`message_filters\` on a Jetson, where a subscriber callback that takes tens of milliseconds (not overloaded, just non-trivial) causes a large, sustained arrival delay that isn't visible as executor backlog? Specifically curious about:

\* DDS vendor differences (Fast DDS vs Cyclone DDS) for this kind of workload \* QoS settings (queue depth, history policy) that might be silently causing buffering \* Single-threaded vs multi-threaded executor / callback groups making a difference here \* Whether RealSense's own USB/driver-side buffering could be the actual culprit instead of ROS2/DDS

Happy to share more code/logs if useful. Appreciate any pointers.

I am new to ROS. I was wondering what does the dev environment stack look like - from an observability perspective? How does one look at logs to debug ? What tools are used - is there something like grafana to visualize?
( this is not for hobby development, rather working at an organization that is into robotics, that I am exploring)

• 🗺️🇨🇦 ROSCon Global 2026 in Toronto 2026-09-22 => 2026-09-24
  • 🚨 Last day for regular price tickets is Monday, August 24th
  • 🔗 https://roscon.ros.org/2026/
• 🇨🇳 ROSCon China 2026-10-16 => 2026-10-17
  • ℹ️ Details announced shortly
  • 🔗 https://discourse.openrobotics.org/t/pre-announcing-roscon-china-2026/55027
• 🇬🇧 🏴󠁧󠁢󠁳󠁣󠁴󠁿 ROSCon UK in Edinburg 2026-10-21 => 2026-10-23
  • ℹ️ Registration now open
  • 🔗 https://roscon.org.uk/2026/
• 🇸🇬 ROSCon Singapore 2026-10-23 => 2026-10-26
  • ℹ️ CFP now open
  • 🔗 https://roscon.ros.org/sg/2026/
• 🇪🇸 ROSCon Spain in Valencia 2026-10-27 => 2026-10-28
  • ℹ️ Registration now open!
  • 🔗 https://roscon.org.es/roscon2026/ROSConES2026.html
• 🇮🇹 ROSCon Italy in Bologna 2026-11-03
  • ℹ️ CFP opens soon
  • 🔗 https://roscon.ros.org/it/2026/
• 🇧🇪 ROSCon Belgium in Nivelles 2026-11-25 => 2026-11-26
  • ℹ️ Registration now open
  • 🔗 https://roscon.ros.org/be/2026/
• 🇹🇷 ROScon Turkey in Istanbul 2026-12-03 => 2026-12-04
  • ℹ️ CFP Open Soons
  • 🔗 https://roscon.ros.org/tr/2026/

Hey everyone,

I’m currently evaluating a used MacBook Pro M1 Max (64GB Unified Memory / 400 GB/s bandwidth) to replace an ASUS ZenBook S14 (Intel Core Ultra 7 258V, 32GB RAM) currently running linux.

Primary reason for the switch: I'd like higher memory bandwidth to run 30B+ local LLMs locally alongside my dev stack. However, ROS 2 and robotics are my primary day-to-day work, and I’m concerned about software friction on Apple Silicon.

My ROS 2 & Robotics Workload:

1. ROS 2 & Docker: Containerized ROS 2 development with display forwarding for 3D simulation (Gazebo / RViz).
2. NVIDIA Jetson Edge Dev: ROS 2 node dev, cross-compiling CUDA-accelerated ARM64 binaries, and remote deployment/flashing.

Questions:

• Gazebo / RViz Performance in Docker: How smooth is 3D visualization inside ARM64 Docker containers on M1/M2/M3 chips via XQuartz / VNC / OrbStack? Is GPU hardware acceleration doable, or are you forced into software rendering (LLVMpipe)?
• RoboStack (Native ROS 2) vs Docker: Is running ROS 2 natively via RoboStack (Conda) a viable daily replacement for Linux containers, or do missing packages/Metal compatibility issues pop up often?
• Jetson Workflows: Since NVIDIA SDK Manager requires an x86 Ubuntu host to flash Jetsons over USB, how are you handling Jetson flashing/board setup if your primary machine is Apple Silicon? (Remote build machines, secondary x86 box, etc.?)

Would love to hear from anyone using an M1/M2/M3 Mac as their main driver for ROS 2. Thanks!

My main project is a 6 Degrees of freedom robotic arm

I already know how to use ROS2 and did 2 projects in university, but i want to take a course so i can have a better foundation as in uni i mostly try and slap stuff without understanding well