No version for distro humble showing github. Known supported distros are highlighted in the buttons above.

lidar_point_cloud_filter package from airstack repo

airstack_common coordination_bringup coordination_msgs desktop_bringup rqt_py_template waypoint_rviz2_plugin rviz_tasks_panel bag_record_pid logging_bringup airstack_msgs behavior_tree_msgs task_msgs robot_descriptions action_relay gcs_visualizer zed_wrapper autonomy_bringup drone_safety_monitor global_bringup global_plan_navigate_bridge random_walk_planner interface_bringup mavros_interface robot_interface mav_comm mav_msgs mav_planning_msgs mav_state_machine_msgs mav_system_msgs pid_controller pid_controller_msgs trajectory_controller takeoff_landing_planner trajectory_library perception_bringup lidar_point_cloud_filter ms_airsim_ros_bridge sim hello_module

ROS Distro
github

API Docs
Browse Code

Package Summary

Version	0.1.0
License	BSD-3-Clause-Clear
Build type	AMENT_PYTHON
Use	RECOMMENDED

Repository Summary

Description
Checkout URI	https://github.com/castacks/airstack.git
VCS Type	git
VCS Version	develop
Last Updated	2026-09-11
Dev Status	UNKNOWN
Released	UNRELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Package Description

Near-range lidar noise filter: subscribes raw PointCloud2, drops points inside a sensor-frame sphere, publishes xyz float32 cloud.

Maintainers

Andrew Jong

Authors

No additional authors.

robot/ros_ws/src/sensors/lidar_point_cloud_filter/README.md

lidar_point_cloud_filter

Subscribes to a raw sensor_msgs/PointCloud2, removes points whose distance from the origin is less than near_range_m (distance in the cloud frame, same idea as the exploration planner’s lidar pre-process), and publishes a filtered cloud as xyz float32 only.

Topic flow (sim → robot)

In Isaac Sim / Pegasus example launch scripts (e.g. example_one_px4_pegasus_launch_script.py, example_multi_px4_pegasus_launch_script.py with ENABLE_LIDAR), the RTX LiDAR OmniGraph publishes point_cloud_raw under the vehicle namespace (e.g. /robot_N/sensors/ouster/point_cloud_raw). That stream crosses the sim→robot bridge and is what this node subscribes to.

On the robot stack:

Topic	Role
`.../sensors/ouster/point_cloud_raw`	Input — dense cloud from the sim (or hardware driver); may include near-field self-hits / clutter.
`.../sensors/ouster/point_cloud`	Output — same logical topic name consumers expect for “the” LiDAR cloud, but filtered (near-range sphere crop, xyz-only).

Downstream nodes should use point_cloud for planning / visualization unless they explicitly need the raw stream.

Parameters

Parameter	Meaning
`near_range_m`	Points with Euclidean range strictly less than this (meters) are dropped. `<= 0` disables filtering.
`input_topic`	Subscription topic; absolute path recommended (see defaults).
`output_topic`	Publication topic.
`qos_depth`	History depth (keep last).
`qos_reliable`	If true, RELIABLE (matches Isaac Replicator and typical RViz). If false, BEST_EFFORT for drivers that publish that way.

Defaults are in config/lidar_point_cloud_filter.yaml. $(env ROBOT_NAME) is expanded when launch loads the file with allow_substs="true". Python fallbacks use the ROBOT_NAME environment variable the same way.

Launch

ros2 launch lidar_point_cloud_filter lidar_point_cloud_filter.launch.xml

Included from the stack entry files (stacks/*/launch) under the robot and sensors namespaces. Defaults use sensors/ouster/point_cloud_raw → sensors/ouster/point_cloud to match Pegasus / Isaac and vdb_params. For RTX-only topic names, override input_topic and output_topic (for example under sensors/lidar/...).

System tests (`sensors` mark)

Sensor checks (sim + robot topic rates, LiDAR validation) live in repo-root tests/system/test_sensors.py (pytest -m sensors), which runs after tests/system/test_liveliness.py in the default collection order. Numpy-only LiDAR filter rules live in lidar_point_cloud_filter/validation_core.py (this package’s module directory), covered by test/test_validation_core.py (pytest -m unit via proxy in tests/robot/) and imported by scripts/validate_lidar_filter_clouds.py at runtime. For Isaac Sim (--sim isaacsim), that suite:

Proves the filtered topic is alive (ros2 topic echo --once on .../point_cloud — large clouds are not probed with ros2 topic hz).
Runs robot/ros_ws/src/sensors/lidar_point_cloud_filter/scripts/validate_lidar_filter_clouds.py inside each robot container: checks the filtered cloud against near_range_m, optionally compares behavior when point_cloud_raw has near-field returns.

Microsoft AirSim does not guarantee sensors/ouster topics on that profile; those steps are skipped there.

See tests/README.md (Bring-up scope) for how airstack_env applies when you combine liveliness and sensors marks.

CHANGELOG

No CHANGELOG found.

Package Dependencies

Deps	Name
	sensor_msgs_py
	ament_copyright
	ament_flake8
	ament_pep257
	rclpy
	sensor_msgs

System Dependencies

Name
python3-numpy
python3-pytest

Dependant Packages

No known dependants.

Launch files

launch/lidar_point_cloud_filter.launch.xml
- lidar_point_cloud_filter : canonical module launch file (RFC #379 §2/§4). Starts the LiDAR near-range filter. The node reads its topic endpoints from parameters (not remaps), so the declared topic args below are applied as parameter overrides on top of the config YAML; their defaults equal the YAML's canonical values (today's graph). No namespace is pushed here — the caller supplies it (the legacy sensors bringup and the stack entry files both include this file under a `sensors` namespace group), keeping the node path /$ROBOT_NAME/sensors/lidar_point_cloud_filter. Wiring deviations are passed as include args by the stack entry file (stacks//launch/) — the single-locus rule: no remap tags here.
- - lidar_point_cloud_filter_config [default: $(find-pkg-share lidar_point_cloud_filter)/config/lidar_point_cloud_filter.yaml]
  - lidar_point_cloud_filter_input_topic [default: /$(env ROBOT_NAME)/sensors/ouster/point_cloud_raw]
  - lidar_point_cloud_filter_output_topic [default: /$(env ROBOT_NAME)/sensors/ouster/point_cloud]

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged `lidar_point_cloud_filter` at Robotics Stack Exchange

API Docs Browse Code

No version for distro jazzy showing github. Known supported distros are highlighted in the buttons above.

lidar_point_cloud_filter package from airstack repo

airstack_common coordination_bringup coordination_msgs desktop_bringup rqt_py_template waypoint_rviz2_plugin rviz_tasks_panel bag_record_pid logging_bringup airstack_msgs behavior_tree_msgs task_msgs robot_descriptions action_relay gcs_visualizer zed_wrapper autonomy_bringup drone_safety_monitor global_bringup global_plan_navigate_bridge random_walk_planner interface_bringup mavros_interface robot_interface mav_comm mav_msgs mav_planning_msgs mav_state_machine_msgs mav_system_msgs pid_controller pid_controller_msgs trajectory_controller takeoff_landing_planner trajectory_library perception_bringup lidar_point_cloud_filter ms_airsim_ros_bridge sim hello_module

ROS Distro
github

API Docs
Browse Code

Package Summary

Version	0.1.0
License	BSD-3-Clause-Clear
Build type	AMENT_PYTHON
Use	RECOMMENDED

Repository Summary

Description
Checkout URI	https://github.com/castacks/airstack.git
VCS Type	git
VCS Version	develop
Last Updated	2026-09-11
Dev Status	UNKNOWN
Released	UNRELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Package Description

Near-range lidar noise filter: subscribes raw PointCloud2, drops points inside a sensor-frame sphere, publishes xyz float32 cloud.

Maintainers

Andrew Jong

Authors

No additional authors.

robot/ros_ws/src/sensors/lidar_point_cloud_filter/README.md

lidar_point_cloud_filter

Subscribes to a raw sensor_msgs/PointCloud2, removes points whose distance from the origin is less than near_range_m (distance in the cloud frame, same idea as the exploration planner’s lidar pre-process), and publishes a filtered cloud as xyz float32 only.

Topic flow (sim → robot)

In Isaac Sim / Pegasus example launch scripts (e.g. example_one_px4_pegasus_launch_script.py, example_multi_px4_pegasus_launch_script.py with ENABLE_LIDAR), the RTX LiDAR OmniGraph publishes point_cloud_raw under the vehicle namespace (e.g. /robot_N/sensors/ouster/point_cloud_raw). That stream crosses the sim→robot bridge and is what this node subscribes to.

On the robot stack:

Topic	Role
`.../sensors/ouster/point_cloud_raw`	Input — dense cloud from the sim (or hardware driver); may include near-field self-hits / clutter.
`.../sensors/ouster/point_cloud`	Output — same logical topic name consumers expect for “the” LiDAR cloud, but filtered (near-range sphere crop, xyz-only).

Downstream nodes should use point_cloud for planning / visualization unless they explicitly need the raw stream.

Parameters

Parameter	Meaning
`near_range_m`	Points with Euclidean range strictly less than this (meters) are dropped. `<= 0` disables filtering.
`input_topic`	Subscription topic; absolute path recommended (see defaults).
`output_topic`	Publication topic.
`qos_depth`	History depth (keep last).
`qos_reliable`	If true, RELIABLE (matches Isaac Replicator and typical RViz). If false, BEST_EFFORT for drivers that publish that way.

Defaults are in config/lidar_point_cloud_filter.yaml. $(env ROBOT_NAME) is expanded when launch loads the file with allow_substs="true". Python fallbacks use the ROBOT_NAME environment variable the same way.

Launch

ros2 launch lidar_point_cloud_filter lidar_point_cloud_filter.launch.xml

Included from the stack entry files (stacks/*/launch) under the robot and sensors namespaces. Defaults use sensors/ouster/point_cloud_raw → sensors/ouster/point_cloud to match Pegasus / Isaac and vdb_params. For RTX-only topic names, override input_topic and output_topic (for example under sensors/lidar/...).

System tests (`sensors` mark)

Sensor checks (sim + robot topic rates, LiDAR validation) live in repo-root tests/system/test_sensors.py (pytest -m sensors), which runs after tests/system/test_liveliness.py in the default collection order. Numpy-only LiDAR filter rules live in lidar_point_cloud_filter/validation_core.py (this package’s module directory), covered by test/test_validation_core.py (pytest -m unit via proxy in tests/robot/) and imported by scripts/validate_lidar_filter_clouds.py at runtime. For Isaac Sim (--sim isaacsim), that suite:

Proves the filtered topic is alive (ros2 topic echo --once on .../point_cloud — large clouds are not probed with ros2 topic hz).
Runs robot/ros_ws/src/sensors/lidar_point_cloud_filter/scripts/validate_lidar_filter_clouds.py inside each robot container: checks the filtered cloud against near_range_m, optionally compares behavior when point_cloud_raw has near-field returns.

Microsoft AirSim does not guarantee sensors/ouster topics on that profile; those steps are skipped there.

See tests/README.md (Bring-up scope) for how airstack_env applies when you combine liveliness and sensors marks.

CHANGELOG

No CHANGELOG found.

Package Dependencies

Deps	Name
	sensor_msgs_py
	ament_copyright
	ament_flake8
	ament_pep257
	rclpy
	sensor_msgs

System Dependencies

Name
python3-numpy
python3-pytest

Dependant Packages

No known dependants.

Launch files

launch/lidar_point_cloud_filter.launch.xml
- lidar_point_cloud_filter : canonical module launch file (RFC #379 §2/§4). Starts the LiDAR near-range filter. The node reads its topic endpoints from parameters (not remaps), so the declared topic args below are applied as parameter overrides on top of the config YAML; their defaults equal the YAML's canonical values (today's graph). No namespace is pushed here — the caller supplies it (the legacy sensors bringup and the stack entry files both include this file under a `sensors` namespace group), keeping the node path /$ROBOT_NAME/sensors/lidar_point_cloud_filter. Wiring deviations are passed as include args by the stack entry file (stacks//launch/) — the single-locus rule: no remap tags here.
- - lidar_point_cloud_filter_config [default: $(find-pkg-share lidar_point_cloud_filter)/config/lidar_point_cloud_filter.yaml]
  - lidar_point_cloud_filter_input_topic [default: /$(env ROBOT_NAME)/sensors/ouster/point_cloud_raw]
  - lidar_point_cloud_filter_output_topic [default: /$(env ROBOT_NAME)/sensors/ouster/point_cloud]

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged `lidar_point_cloud_filter` at Robotics Stack Exchange

API Docs Browse Code

No version for distro kilted showing github. Known supported distros are highlighted in the buttons above.

lidar_point_cloud_filter package from airstack repo

airstack_common coordination_bringup coordination_msgs desktop_bringup rqt_py_template waypoint_rviz2_plugin rviz_tasks_panel bag_record_pid logging_bringup airstack_msgs behavior_tree_msgs task_msgs robot_descriptions action_relay gcs_visualizer zed_wrapper autonomy_bringup drone_safety_monitor global_bringup global_plan_navigate_bridge random_walk_planner interface_bringup mavros_interface robot_interface mav_comm mav_msgs mav_planning_msgs mav_state_machine_msgs mav_system_msgs pid_controller pid_controller_msgs trajectory_controller takeoff_landing_planner trajectory_library perception_bringup lidar_point_cloud_filter ms_airsim_ros_bridge sim hello_module

ROS Distro
github

API Docs
Browse Code

Package Summary

Version	0.1.0
License	BSD-3-Clause-Clear
Build type	AMENT_PYTHON
Use	RECOMMENDED

Repository Summary

Description
Checkout URI	https://github.com/castacks/airstack.git
VCS Type	git
VCS Version	develop
Last Updated	2026-09-11
Dev Status	UNKNOWN
Released	UNRELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Package Description

Near-range lidar noise filter: subscribes raw PointCloud2, drops points inside a sensor-frame sphere, publishes xyz float32 cloud.

Maintainers

Andrew Jong

Authors

No additional authors.

robot/ros_ws/src/sensors/lidar_point_cloud_filter/README.md

lidar_point_cloud_filter

Subscribes to a raw sensor_msgs/PointCloud2, removes points whose distance from the origin is less than near_range_m (distance in the cloud frame, same idea as the exploration planner’s lidar pre-process), and publishes a filtered cloud as xyz float32 only.

Topic flow (sim → robot)

In Isaac Sim / Pegasus example launch scripts (e.g. example_one_px4_pegasus_launch_script.py, example_multi_px4_pegasus_launch_script.py with ENABLE_LIDAR), the RTX LiDAR OmniGraph publishes point_cloud_raw under the vehicle namespace (e.g. /robot_N/sensors/ouster/point_cloud_raw). That stream crosses the sim→robot bridge and is what this node subscribes to.

On the robot stack:

Topic	Role
`.../sensors/ouster/point_cloud_raw`	Input — dense cloud from the sim (or hardware driver); may include near-field self-hits / clutter.
`.../sensors/ouster/point_cloud`	Output — same logical topic name consumers expect for “the” LiDAR cloud, but filtered (near-range sphere crop, xyz-only).

Downstream nodes should use point_cloud for planning / visualization unless they explicitly need the raw stream.

Parameters

Parameter	Meaning
`near_range_m`	Points with Euclidean range strictly less than this (meters) are dropped. `<= 0` disables filtering.
`input_topic`	Subscription topic; absolute path recommended (see defaults).
`output_topic`	Publication topic.
`qos_depth`	History depth (keep last).
`qos_reliable`	If true, RELIABLE (matches Isaac Replicator and typical RViz). If false, BEST_EFFORT for drivers that publish that way.

Defaults are in config/lidar_point_cloud_filter.yaml. $(env ROBOT_NAME) is expanded when launch loads the file with allow_substs="true". Python fallbacks use the ROBOT_NAME environment variable the same way.

Launch

ros2 launch lidar_point_cloud_filter lidar_point_cloud_filter.launch.xml

Included from the stack entry files (stacks/*/launch) under the robot and sensors namespaces. Defaults use sensors/ouster/point_cloud_raw → sensors/ouster/point_cloud to match Pegasus / Isaac and vdb_params. For RTX-only topic names, override input_topic and output_topic (for example under sensors/lidar/...).

System tests (`sensors` mark)

Sensor checks (sim + robot topic rates, LiDAR validation) live in repo-root tests/system/test_sensors.py (pytest -m sensors), which runs after tests/system/test_liveliness.py in the default collection order. Numpy-only LiDAR filter rules live in lidar_point_cloud_filter/validation_core.py (this package’s module directory), covered by test/test_validation_core.py (pytest -m unit via proxy in tests/robot/) and imported by scripts/validate_lidar_filter_clouds.py at runtime. For Isaac Sim (--sim isaacsim), that suite:

Proves the filtered topic is alive (ros2 topic echo --once on .../point_cloud — large clouds are not probed with ros2 topic hz).
Runs robot/ros_ws/src/sensors/lidar_point_cloud_filter/scripts/validate_lidar_filter_clouds.py inside each robot container: checks the filtered cloud against near_range_m, optionally compares behavior when point_cloud_raw has near-field returns.

Microsoft AirSim does not guarantee sensors/ouster topics on that profile; those steps are skipped there.

See tests/README.md (Bring-up scope) for how airstack_env applies when you combine liveliness and sensors marks.

CHANGELOG

No CHANGELOG found.

Package Dependencies

Deps	Name
	sensor_msgs_py
	ament_copyright
	ament_flake8
	ament_pep257
	rclpy
	sensor_msgs

System Dependencies

Name
python3-numpy
python3-pytest

Dependant Packages

No known dependants.

Launch files

launch/lidar_point_cloud_filter.launch.xml
- lidar_point_cloud_filter : canonical module launch file (RFC #379 §2/§4). Starts the LiDAR near-range filter. The node reads its topic endpoints from parameters (not remaps), so the declared topic args below are applied as parameter overrides on top of the config YAML; their defaults equal the YAML's canonical values (today's graph). No namespace is pushed here — the caller supplies it (the legacy sensors bringup and the stack entry files both include this file under a `sensors` namespace group), keeping the node path /$ROBOT_NAME/sensors/lidar_point_cloud_filter. Wiring deviations are passed as include args by the stack entry file (stacks//launch/) — the single-locus rule: no remap tags here.
- - lidar_point_cloud_filter_config [default: $(find-pkg-share lidar_point_cloud_filter)/config/lidar_point_cloud_filter.yaml]
  - lidar_point_cloud_filter_input_topic [default: /$(env ROBOT_NAME)/sensors/ouster/point_cloud_raw]
  - lidar_point_cloud_filter_output_topic [default: /$(env ROBOT_NAME)/sensors/ouster/point_cloud]

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged `lidar_point_cloud_filter` at Robotics Stack Exchange

API Docs Browse Code

No version for distro lyrical showing github. Known supported distros are highlighted in the buttons above.

lidar_point_cloud_filter package from airstack repo

airstack_common coordination_bringup coordination_msgs desktop_bringup rqt_py_template waypoint_rviz2_plugin rviz_tasks_panel bag_record_pid logging_bringup airstack_msgs behavior_tree_msgs task_msgs robot_descriptions action_relay gcs_visualizer zed_wrapper autonomy_bringup drone_safety_monitor global_bringup global_plan_navigate_bridge random_walk_planner interface_bringup mavros_interface robot_interface mav_comm mav_msgs mav_planning_msgs mav_state_machine_msgs mav_system_msgs pid_controller pid_controller_msgs trajectory_controller takeoff_landing_planner trajectory_library perception_bringup lidar_point_cloud_filter ms_airsim_ros_bridge sim hello_module

ROS Distro
github

API Docs
Browse Code

Package Summary

Version	0.1.0
License	BSD-3-Clause-Clear
Build type	AMENT_PYTHON
Use	RECOMMENDED

Repository Summary

Description
Checkout URI	https://github.com/castacks/airstack.git
VCS Type	git
VCS Version	develop
Last Updated	2026-09-11
Dev Status	UNKNOWN
Released	UNRELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Package Description

Near-range lidar noise filter: subscribes raw PointCloud2, drops points inside a sensor-frame sphere, publishes xyz float32 cloud.

Maintainers

Andrew Jong

Authors

No additional authors.

robot/ros_ws/src/sensors/lidar_point_cloud_filter/README.md

lidar_point_cloud_filter

Subscribes to a raw sensor_msgs/PointCloud2, removes points whose distance from the origin is less than near_range_m (distance in the cloud frame, same idea as the exploration planner’s lidar pre-process), and publishes a filtered cloud as xyz float32 only.

Topic flow (sim → robot)

In Isaac Sim / Pegasus example launch scripts (e.g. example_one_px4_pegasus_launch_script.py, example_multi_px4_pegasus_launch_script.py with ENABLE_LIDAR), the RTX LiDAR OmniGraph publishes point_cloud_raw under the vehicle namespace (e.g. /robot_N/sensors/ouster/point_cloud_raw). That stream crosses the sim→robot bridge and is what this node subscribes to.

On the robot stack:

Topic	Role
`.../sensors/ouster/point_cloud_raw`	Input — dense cloud from the sim (or hardware driver); may include near-field self-hits / clutter.
`.../sensors/ouster/point_cloud`	Output — same logical topic name consumers expect for “the” LiDAR cloud, but filtered (near-range sphere crop, xyz-only).

Downstream nodes should use point_cloud for planning / visualization unless they explicitly need the raw stream.

Parameters

Parameter	Meaning
`near_range_m`	Points with Euclidean range strictly less than this (meters) are dropped. `<= 0` disables filtering.
`input_topic`	Subscription topic; absolute path recommended (see defaults).
`output_topic`	Publication topic.
`qos_depth`	History depth (keep last).
`qos_reliable`	If true, RELIABLE (matches Isaac Replicator and typical RViz). If false, BEST_EFFORT for drivers that publish that way.

Defaults are in config/lidar_point_cloud_filter.yaml. $(env ROBOT_NAME) is expanded when launch loads the file with allow_substs="true". Python fallbacks use the ROBOT_NAME environment variable the same way.

Launch

ros2 launch lidar_point_cloud_filter lidar_point_cloud_filter.launch.xml

Included from the stack entry files (stacks/*/launch) under the robot and sensors namespaces. Defaults use sensors/ouster/point_cloud_raw → sensors/ouster/point_cloud to match Pegasus / Isaac and vdb_params. For RTX-only topic names, override input_topic and output_topic (for example under sensors/lidar/...).

System tests (`sensors` mark)

Sensor checks (sim + robot topic rates, LiDAR validation) live in repo-root tests/system/test_sensors.py (pytest -m sensors), which runs after tests/system/test_liveliness.py in the default collection order. Numpy-only LiDAR filter rules live in lidar_point_cloud_filter/validation_core.py (this package’s module directory), covered by test/test_validation_core.py (pytest -m unit via proxy in tests/robot/) and imported by scripts/validate_lidar_filter_clouds.py at runtime. For Isaac Sim (--sim isaacsim), that suite:

Proves the filtered topic is alive (ros2 topic echo --once on .../point_cloud — large clouds are not probed with ros2 topic hz).
Runs robot/ros_ws/src/sensors/lidar_point_cloud_filter/scripts/validate_lidar_filter_clouds.py inside each robot container: checks the filtered cloud against near_range_m, optionally compares behavior when point_cloud_raw has near-field returns.

Microsoft AirSim does not guarantee sensors/ouster topics on that profile; those steps are skipped there.

See tests/README.md (Bring-up scope) for how airstack_env applies when you combine liveliness and sensors marks.

CHANGELOG

No CHANGELOG found.

Package Dependencies

Deps	Name
	sensor_msgs_py
	ament_copyright
	ament_flake8
	ament_pep257
	rclpy
	sensor_msgs

System Dependencies

Name
python3-numpy
python3-pytest

Dependant Packages

No known dependants.

Launch files

launch/lidar_point_cloud_filter.launch.xml
- lidar_point_cloud_filter : canonical module launch file (RFC #379 §2/§4). Starts the LiDAR near-range filter. The node reads its topic endpoints from parameters (not remaps), so the declared topic args below are applied as parameter overrides on top of the config YAML; their defaults equal the YAML's canonical values (today's graph). No namespace is pushed here — the caller supplies it (the legacy sensors bringup and the stack entry files both include this file under a `sensors` namespace group), keeping the node path /$ROBOT_NAME/sensors/lidar_point_cloud_filter. Wiring deviations are passed as include args by the stack entry file (stacks//launch/) — the single-locus rule: no remap tags here.
- - lidar_point_cloud_filter_config [default: $(find-pkg-share lidar_point_cloud_filter)/config/lidar_point_cloud_filter.yaml]
  - lidar_point_cloud_filter_input_topic [default: /$(env ROBOT_NAME)/sensors/ouster/point_cloud_raw]
  - lidar_point_cloud_filter_output_topic [default: /$(env ROBOT_NAME)/sensors/ouster/point_cloud]

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged `lidar_point_cloud_filter` at Robotics Stack Exchange

API Docs Browse Code

No version for distro rolling showing github. Known supported distros are highlighted in the buttons above.

lidar_point_cloud_filter package from airstack repo

airstack_common coordination_bringup coordination_msgs desktop_bringup rqt_py_template waypoint_rviz2_plugin rviz_tasks_panel bag_record_pid logging_bringup airstack_msgs behavior_tree_msgs task_msgs robot_descriptions action_relay gcs_visualizer zed_wrapper autonomy_bringup drone_safety_monitor global_bringup global_plan_navigate_bridge random_walk_planner interface_bringup mavros_interface robot_interface mav_comm mav_msgs mav_planning_msgs mav_state_machine_msgs mav_system_msgs pid_controller pid_controller_msgs trajectory_controller takeoff_landing_planner trajectory_library perception_bringup lidar_point_cloud_filter ms_airsim_ros_bridge sim hello_module

ROS Distro
github

API Docs
Browse Code

Package Summary

Version	0.1.0
License	BSD-3-Clause-Clear
Build type	AMENT_PYTHON
Use	RECOMMENDED

Repository Summary

Description
Checkout URI	https://github.com/castacks/airstack.git
VCS Type	git
VCS Version	develop
Last Updated	2026-09-11
Dev Status	UNKNOWN
Released	UNRELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Package Description

Near-range lidar noise filter: subscribes raw PointCloud2, drops points inside a sensor-frame sphere, publishes xyz float32 cloud.

Maintainers

Andrew Jong

Authors

No additional authors.

robot/ros_ws/src/sensors/lidar_point_cloud_filter/README.md

lidar_point_cloud_filter

Subscribes to a raw sensor_msgs/PointCloud2, removes points whose distance from the origin is less than near_range_m (distance in the cloud frame, same idea as the exploration planner’s lidar pre-process), and publishes a filtered cloud as xyz float32 only.

Topic flow (sim → robot)

In Isaac Sim / Pegasus example launch scripts (e.g. example_one_px4_pegasus_launch_script.py, example_multi_px4_pegasus_launch_script.py with ENABLE_LIDAR), the RTX LiDAR OmniGraph publishes point_cloud_raw under the vehicle namespace (e.g. /robot_N/sensors/ouster/point_cloud_raw). That stream crosses the sim→robot bridge and is what this node subscribes to.

On the robot stack:

Topic	Role
`.../sensors/ouster/point_cloud_raw`	Input — dense cloud from the sim (or hardware driver); may include near-field self-hits / clutter.
`.../sensors/ouster/point_cloud`	Output — same logical topic name consumers expect for “the” LiDAR cloud, but filtered (near-range sphere crop, xyz-only).

Downstream nodes should use point_cloud for planning / visualization unless they explicitly need the raw stream.

Parameters

Parameter	Meaning
`near_range_m`	Points with Euclidean range strictly less than this (meters) are dropped. `<= 0` disables filtering.
`input_topic`	Subscription topic; absolute path recommended (see defaults).
`output_topic`	Publication topic.
`qos_depth`	History depth (keep last).
`qos_reliable`	If true, RELIABLE (matches Isaac Replicator and typical RViz). If false, BEST_EFFORT for drivers that publish that way.

Defaults are in config/lidar_point_cloud_filter.yaml. $(env ROBOT_NAME) is expanded when launch loads the file with allow_substs="true". Python fallbacks use the ROBOT_NAME environment variable the same way.

Launch

ros2 launch lidar_point_cloud_filter lidar_point_cloud_filter.launch.xml

Included from the stack entry files (stacks/*/launch) under the robot and sensors namespaces. Defaults use sensors/ouster/point_cloud_raw → sensors/ouster/point_cloud to match Pegasus / Isaac and vdb_params. For RTX-only topic names, override input_topic and output_topic (for example under sensors/lidar/...).

System tests (`sensors` mark)

Sensor checks (sim + robot topic rates, LiDAR validation) live in repo-root tests/system/test_sensors.py (pytest -m sensors), which runs after tests/system/test_liveliness.py in the default collection order. Numpy-only LiDAR filter rules live in lidar_point_cloud_filter/validation_core.py (this package’s module directory), covered by test/test_validation_core.py (pytest -m unit via proxy in tests/robot/) and imported by scripts/validate_lidar_filter_clouds.py at runtime. For Isaac Sim (--sim isaacsim), that suite:

Proves the filtered topic is alive (ros2 topic echo --once on .../point_cloud — large clouds are not probed with ros2 topic hz).
Runs robot/ros_ws/src/sensors/lidar_point_cloud_filter/scripts/validate_lidar_filter_clouds.py inside each robot container: checks the filtered cloud against near_range_m, optionally compares behavior when point_cloud_raw has near-field returns.

Microsoft AirSim does not guarantee sensors/ouster topics on that profile; those steps are skipped there.

See tests/README.md (Bring-up scope) for how airstack_env applies when you combine liveliness and sensors marks.

CHANGELOG

No CHANGELOG found.

Package Dependencies

Deps	Name
	sensor_msgs_py
	ament_copyright
	ament_flake8
	ament_pep257
	rclpy
	sensor_msgs

System Dependencies

Name
python3-numpy
python3-pytest

Dependant Packages

No known dependants.

Launch files

launch/lidar_point_cloud_filter.launch.xml
- lidar_point_cloud_filter : canonical module launch file (RFC #379 §2/§4). Starts the LiDAR near-range filter. The node reads its topic endpoints from parameters (not remaps), so the declared topic args below are applied as parameter overrides on top of the config YAML; their defaults equal the YAML's canonical values (today's graph). No namespace is pushed here — the caller supplies it (the legacy sensors bringup and the stack entry files both include this file under a `sensors` namespace group), keeping the node path /$ROBOT_NAME/sensors/lidar_point_cloud_filter. Wiring deviations are passed as include args by the stack entry file (stacks//launch/) — the single-locus rule: no remap tags here.
- - lidar_point_cloud_filter_config [default: $(find-pkg-share lidar_point_cloud_filter)/config/lidar_point_cloud_filter.yaml]
  - lidar_point_cloud_filter_input_topic [default: /$(env ROBOT_NAME)/sensors/ouster/point_cloud_raw]
  - lidar_point_cloud_filter_output_topic [default: /$(env ROBOT_NAME)/sensors/ouster/point_cloud]

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged `lidar_point_cloud_filter` at Robotics Stack Exchange

API Docs Browse Code

lidar_point_cloud_filter package from airstack repo

airstack_common coordination_bringup coordination_msgs desktop_bringup rqt_py_template waypoint_rviz2_plugin rviz_tasks_panel bag_record_pid logging_bringup airstack_msgs behavior_tree_msgs task_msgs robot_descriptions action_relay gcs_visualizer zed_wrapper autonomy_bringup drone_safety_monitor global_bringup global_plan_navigate_bridge random_walk_planner interface_bringup mavros_interface robot_interface mav_comm mav_msgs mav_planning_msgs mav_state_machine_msgs mav_system_msgs pid_controller pid_controller_msgs trajectory_controller takeoff_landing_planner trajectory_library perception_bringup lidar_point_cloud_filter ms_airsim_ros_bridge sim hello_module

ROS Distro
github

API Docs
Browse Code

Package Summary

Version	0.1.0
License	BSD-3-Clause-Clear
Build type	AMENT_PYTHON
Use	RECOMMENDED

Repository Summary

Description
Checkout URI	https://github.com/castacks/airstack.git
VCS Type	git
VCS Version	develop
Last Updated	2026-09-11
Dev Status	UNKNOWN
Released	UNRELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Package Description

Near-range lidar noise filter: subscribes raw PointCloud2, drops points inside a sensor-frame sphere, publishes xyz float32 cloud.

Maintainers

Andrew Jong

Authors

No additional authors.

robot/ros_ws/src/sensors/lidar_point_cloud_filter/README.md

lidar_point_cloud_filter

Subscribes to a raw sensor_msgs/PointCloud2, removes points whose distance from the origin is less than near_range_m (distance in the cloud frame, same idea as the exploration planner’s lidar pre-process), and publishes a filtered cloud as xyz float32 only.

Topic flow (sim → robot)

In Isaac Sim / Pegasus example launch scripts (e.g. example_one_px4_pegasus_launch_script.py, example_multi_px4_pegasus_launch_script.py with ENABLE_LIDAR), the RTX LiDAR OmniGraph publishes point_cloud_raw under the vehicle namespace (e.g. /robot_N/sensors/ouster/point_cloud_raw). That stream crosses the sim→robot bridge and is what this node subscribes to.

On the robot stack:

Topic	Role
`.../sensors/ouster/point_cloud_raw`	Input — dense cloud from the sim (or hardware driver); may include near-field self-hits / clutter.
`.../sensors/ouster/point_cloud`	Output — same logical topic name consumers expect for “the” LiDAR cloud, but filtered (near-range sphere crop, xyz-only).

Downstream nodes should use point_cloud for planning / visualization unless they explicitly need the raw stream.

Parameters

Parameter	Meaning
`near_range_m`	Points with Euclidean range strictly less than this (meters) are dropped. `<= 0` disables filtering.
`input_topic`	Subscription topic; absolute path recommended (see defaults).
`output_topic`	Publication topic.
`qos_depth`	History depth (keep last).
`qos_reliable`	If true, RELIABLE (matches Isaac Replicator and typical RViz). If false, BEST_EFFORT for drivers that publish that way.

Defaults are in config/lidar_point_cloud_filter.yaml. $(env ROBOT_NAME) is expanded when launch loads the file with allow_substs="true". Python fallbacks use the ROBOT_NAME environment variable the same way.

Launch

ros2 launch lidar_point_cloud_filter lidar_point_cloud_filter.launch.xml

Included from the stack entry files (stacks/*/launch) under the robot and sensors namespaces. Defaults use sensors/ouster/point_cloud_raw → sensors/ouster/point_cloud to match Pegasus / Isaac and vdb_params. For RTX-only topic names, override input_topic and output_topic (for example under sensors/lidar/...).

System tests (`sensors` mark)

Sensor checks (sim + robot topic rates, LiDAR validation) live in repo-root tests/system/test_sensors.py (pytest -m sensors), which runs after tests/system/test_liveliness.py in the default collection order. Numpy-only LiDAR filter rules live in lidar_point_cloud_filter/validation_core.py (this package’s module directory), covered by test/test_validation_core.py (pytest -m unit via proxy in tests/robot/) and imported by scripts/validate_lidar_filter_clouds.py at runtime. For Isaac Sim (--sim isaacsim), that suite:

Proves the filtered topic is alive (ros2 topic echo --once on .../point_cloud — large clouds are not probed with ros2 topic hz).
Runs robot/ros_ws/src/sensors/lidar_point_cloud_filter/scripts/validate_lidar_filter_clouds.py inside each robot container: checks the filtered cloud against near_range_m, optionally compares behavior when point_cloud_raw has near-field returns.

Microsoft AirSim does not guarantee sensors/ouster topics on that profile; those steps are skipped there.

See tests/README.md (Bring-up scope) for how airstack_env applies when you combine liveliness and sensors marks.

CHANGELOG

No CHANGELOG found.

Package Dependencies

Deps	Name
	sensor_msgs_py
	ament_copyright
	ament_flake8
	ament_pep257
	rclpy
	sensor_msgs

System Dependencies

Name
python3-numpy
python3-pytest

Dependant Packages

No known dependants.

Launch files

launch/lidar_point_cloud_filter.launch.xml
- lidar_point_cloud_filter : canonical module launch file (RFC #379 §2/§4). Starts the LiDAR near-range filter. The node reads its topic endpoints from parameters (not remaps), so the declared topic args below are applied as parameter overrides on top of the config YAML; their defaults equal the YAML's canonical values (today's graph). No namespace is pushed here — the caller supplies it (the legacy sensors bringup and the stack entry files both include this file under a `sensors` namespace group), keeping the node path /$ROBOT_NAME/sensors/lidar_point_cloud_filter. Wiring deviations are passed as include args by the stack entry file (stacks//launch/) — the single-locus rule: no remap tags here.
- - lidar_point_cloud_filter_config [default: $(find-pkg-share lidar_point_cloud_filter)/config/lidar_point_cloud_filter.yaml]
  - lidar_point_cloud_filter_input_topic [default: /$(env ROBOT_NAME)/sensors/ouster/point_cloud_raw]
  - lidar_point_cloud_filter_output_topic [default: /$(env ROBOT_NAME)/sensors/ouster/point_cloud]

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged `lidar_point_cloud_filter` at Robotics Stack Exchange

API Docs Browse Code

No version for distro galactic showing github. Known supported distros are highlighted in the buttons above.

lidar_point_cloud_filter package from airstack repo

airstack_common coordination_bringup coordination_msgs desktop_bringup rqt_py_template waypoint_rviz2_plugin rviz_tasks_panel bag_record_pid logging_bringup airstack_msgs behavior_tree_msgs task_msgs robot_descriptions action_relay gcs_visualizer zed_wrapper autonomy_bringup drone_safety_monitor global_bringup global_plan_navigate_bridge random_walk_planner interface_bringup mavros_interface robot_interface mav_comm mav_msgs mav_planning_msgs mav_state_machine_msgs mav_system_msgs pid_controller pid_controller_msgs trajectory_controller takeoff_landing_planner trajectory_library perception_bringup lidar_point_cloud_filter ms_airsim_ros_bridge sim hello_module

ROS Distro
github

API Docs
Browse Code

Package Summary

Version	0.1.0
License	BSD-3-Clause-Clear
Build type	AMENT_PYTHON
Use	RECOMMENDED

Repository Summary

Description
Checkout URI	https://github.com/castacks/airstack.git
VCS Type	git
VCS Version	develop
Last Updated	2026-09-11
Dev Status	UNKNOWN
Released	UNRELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Package Description

Near-range lidar noise filter: subscribes raw PointCloud2, drops points inside a sensor-frame sphere, publishes xyz float32 cloud.

Maintainers

Andrew Jong

Authors

No additional authors.

robot/ros_ws/src/sensors/lidar_point_cloud_filter/README.md

lidar_point_cloud_filter

Subscribes to a raw sensor_msgs/PointCloud2, removes points whose distance from the origin is less than near_range_m (distance in the cloud frame, same idea as the exploration planner’s lidar pre-process), and publishes a filtered cloud as xyz float32 only.

Topic flow (sim → robot)

In Isaac Sim / Pegasus example launch scripts (e.g. example_one_px4_pegasus_launch_script.py, example_multi_px4_pegasus_launch_script.py with ENABLE_LIDAR), the RTX LiDAR OmniGraph publishes point_cloud_raw under the vehicle namespace (e.g. /robot_N/sensors/ouster/point_cloud_raw). That stream crosses the sim→robot bridge and is what this node subscribes to.

On the robot stack:

Topic	Role
`.../sensors/ouster/point_cloud_raw`	Input — dense cloud from the sim (or hardware driver); may include near-field self-hits / clutter.
`.../sensors/ouster/point_cloud`	Output — same logical topic name consumers expect for “the” LiDAR cloud, but filtered (near-range sphere crop, xyz-only).

Downstream nodes should use point_cloud for planning / visualization unless they explicitly need the raw stream.

Parameters

Parameter	Meaning
`near_range_m`	Points with Euclidean range strictly less than this (meters) are dropped. `<= 0` disables filtering.
`input_topic`	Subscription topic; absolute path recommended (see defaults).
`output_topic`	Publication topic.
`qos_depth`	History depth (keep last).
`qos_reliable`	If true, RELIABLE (matches Isaac Replicator and typical RViz). If false, BEST_EFFORT for drivers that publish that way.

Defaults are in config/lidar_point_cloud_filter.yaml. $(env ROBOT_NAME) is expanded when launch loads the file with allow_substs="true". Python fallbacks use the ROBOT_NAME environment variable the same way.

Launch

ros2 launch lidar_point_cloud_filter lidar_point_cloud_filter.launch.xml

Included from the stack entry files (stacks/*/launch) under the robot and sensors namespaces. Defaults use sensors/ouster/point_cloud_raw → sensors/ouster/point_cloud to match Pegasus / Isaac and vdb_params. For RTX-only topic names, override input_topic and output_topic (for example under sensors/lidar/...).

System tests (`sensors` mark)

Sensor checks (sim + robot topic rates, LiDAR validation) live in repo-root tests/system/test_sensors.py (pytest -m sensors), which runs after tests/system/test_liveliness.py in the default collection order. Numpy-only LiDAR filter rules live in lidar_point_cloud_filter/validation_core.py (this package’s module directory), covered by test/test_validation_core.py (pytest -m unit via proxy in tests/robot/) and imported by scripts/validate_lidar_filter_clouds.py at runtime. For Isaac Sim (--sim isaacsim), that suite:

Proves the filtered topic is alive (ros2 topic echo --once on .../point_cloud — large clouds are not probed with ros2 topic hz).
Runs robot/ros_ws/src/sensors/lidar_point_cloud_filter/scripts/validate_lidar_filter_clouds.py inside each robot container: checks the filtered cloud against near_range_m, optionally compares behavior when point_cloud_raw has near-field returns.

Microsoft AirSim does not guarantee sensors/ouster topics on that profile; those steps are skipped there.

See tests/README.md (Bring-up scope) for how airstack_env applies when you combine liveliness and sensors marks.

CHANGELOG

No CHANGELOG found.

Package Dependencies

Deps	Name
	sensor_msgs_py
	ament_copyright
	ament_flake8
	ament_pep257
	rclpy
	sensor_msgs

System Dependencies

Name
python3-numpy
python3-pytest

Dependant Packages

No known dependants.

Launch files

launch/lidar_point_cloud_filter.launch.xml
- lidar_point_cloud_filter : canonical module launch file (RFC #379 §2/§4). Starts the LiDAR near-range filter. The node reads its topic endpoints from parameters (not remaps), so the declared topic args below are applied as parameter overrides on top of the config YAML; their defaults equal the YAML's canonical values (today's graph). No namespace is pushed here — the caller supplies it (the legacy sensors bringup and the stack entry files both include this file under a `sensors` namespace group), keeping the node path /$ROBOT_NAME/sensors/lidar_point_cloud_filter. Wiring deviations are passed as include args by the stack entry file (stacks//launch/) — the single-locus rule: no remap tags here.
- - lidar_point_cloud_filter_config [default: $(find-pkg-share lidar_point_cloud_filter)/config/lidar_point_cloud_filter.yaml]
  - lidar_point_cloud_filter_input_topic [default: /$(env ROBOT_NAME)/sensors/ouster/point_cloud_raw]
  - lidar_point_cloud_filter_output_topic [default: /$(env ROBOT_NAME)/sensors/ouster/point_cloud]

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged `lidar_point_cloud_filter` at Robotics Stack Exchange

API Docs Browse Code

No version for distro iron showing github. Known supported distros are highlighted in the buttons above.

lidar_point_cloud_filter package from airstack repo

airstack_common coordination_bringup coordination_msgs desktop_bringup rqt_py_template waypoint_rviz2_plugin rviz_tasks_panel bag_record_pid logging_bringup airstack_msgs behavior_tree_msgs task_msgs robot_descriptions action_relay gcs_visualizer zed_wrapper autonomy_bringup drone_safety_monitor global_bringup global_plan_navigate_bridge random_walk_planner interface_bringup mavros_interface robot_interface mav_comm mav_msgs mav_planning_msgs mav_state_machine_msgs mav_system_msgs pid_controller pid_controller_msgs trajectory_controller takeoff_landing_planner trajectory_library perception_bringup lidar_point_cloud_filter ms_airsim_ros_bridge sim hello_module

ROS Distro
github

API Docs
Browse Code

Package Summary

Version	0.1.0
License	BSD-3-Clause-Clear
Build type	AMENT_PYTHON
Use	RECOMMENDED

Repository Summary

Description
Checkout URI	https://github.com/castacks/airstack.git
VCS Type	git
VCS Version	develop
Last Updated	2026-09-11
Dev Status	UNKNOWN
Released	UNRELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Package Description

Near-range lidar noise filter: subscribes raw PointCloud2, drops points inside a sensor-frame sphere, publishes xyz float32 cloud.

Maintainers

Andrew Jong

Authors

No additional authors.

robot/ros_ws/src/sensors/lidar_point_cloud_filter/README.md

lidar_point_cloud_filter

Subscribes to a raw sensor_msgs/PointCloud2, removes points whose distance from the origin is less than near_range_m (distance in the cloud frame, same idea as the exploration planner’s lidar pre-process), and publishes a filtered cloud as xyz float32 only.

Topic flow (sim → robot)

In Isaac Sim / Pegasus example launch scripts (e.g. example_one_px4_pegasus_launch_script.py, example_multi_px4_pegasus_launch_script.py with ENABLE_LIDAR), the RTX LiDAR OmniGraph publishes point_cloud_raw under the vehicle namespace (e.g. /robot_N/sensors/ouster/point_cloud_raw). That stream crosses the sim→robot bridge and is what this node subscribes to.

On the robot stack:

Topic	Role
`.../sensors/ouster/point_cloud_raw`	Input — dense cloud from the sim (or hardware driver); may include near-field self-hits / clutter.
`.../sensors/ouster/point_cloud`	Output — same logical topic name consumers expect for “the” LiDAR cloud, but filtered (near-range sphere crop, xyz-only).

Downstream nodes should use point_cloud for planning / visualization unless they explicitly need the raw stream.

Parameters

Parameter	Meaning
`near_range_m`	Points with Euclidean range strictly less than this (meters) are dropped. `<= 0` disables filtering.
`input_topic`	Subscription topic; absolute path recommended (see defaults).
`output_topic`	Publication topic.
`qos_depth`	History depth (keep last).
`qos_reliable`	If true, RELIABLE (matches Isaac Replicator and typical RViz). If false, BEST_EFFORT for drivers that publish that way.

Defaults are in config/lidar_point_cloud_filter.yaml. $(env ROBOT_NAME) is expanded when launch loads the file with allow_substs="true". Python fallbacks use the ROBOT_NAME environment variable the same way.

Launch

ros2 launch lidar_point_cloud_filter lidar_point_cloud_filter.launch.xml

Included from the stack entry files (stacks/*/launch) under the robot and sensors namespaces. Defaults use sensors/ouster/point_cloud_raw → sensors/ouster/point_cloud to match Pegasus / Isaac and vdb_params. For RTX-only topic names, override input_topic and output_topic (for example under sensors/lidar/...).

System tests (`sensors` mark)

Sensor checks (sim + robot topic rates, LiDAR validation) live in repo-root tests/system/test_sensors.py (pytest -m sensors), which runs after tests/system/test_liveliness.py in the default collection order. Numpy-only LiDAR filter rules live in lidar_point_cloud_filter/validation_core.py (this package’s module directory), covered by test/test_validation_core.py (pytest -m unit via proxy in tests/robot/) and imported by scripts/validate_lidar_filter_clouds.py at runtime. For Isaac Sim (--sim isaacsim), that suite:

Proves the filtered topic is alive (ros2 topic echo --once on .../point_cloud — large clouds are not probed with ros2 topic hz).
Runs robot/ros_ws/src/sensors/lidar_point_cloud_filter/scripts/validate_lidar_filter_clouds.py inside each robot container: checks the filtered cloud against near_range_m, optionally compares behavior when point_cloud_raw has near-field returns.

Microsoft AirSim does not guarantee sensors/ouster topics on that profile; those steps are skipped there.

See tests/README.md (Bring-up scope) for how airstack_env applies when you combine liveliness and sensors marks.

CHANGELOG

No CHANGELOG found.

Package Dependencies

Deps	Name
	sensor_msgs_py
	ament_copyright
	ament_flake8
	ament_pep257
	rclpy
	sensor_msgs

System Dependencies

Name
python3-numpy
python3-pytest

Dependant Packages

No known dependants.

Launch files

launch/lidar_point_cloud_filter.launch.xml
- lidar_point_cloud_filter : canonical module launch file (RFC #379 §2/§4). Starts the LiDAR near-range filter. The node reads its topic endpoints from parameters (not remaps), so the declared topic args below are applied as parameter overrides on top of the config YAML; their defaults equal the YAML's canonical values (today's graph). No namespace is pushed here — the caller supplies it (the legacy sensors bringup and the stack entry files both include this file under a `sensors` namespace group), keeping the node path /$ROBOT_NAME/sensors/lidar_point_cloud_filter. Wiring deviations are passed as include args by the stack entry file (stacks//launch/) — the single-locus rule: no remap tags here.
- - lidar_point_cloud_filter_config [default: $(find-pkg-share lidar_point_cloud_filter)/config/lidar_point_cloud_filter.yaml]
  - lidar_point_cloud_filter_input_topic [default: /$(env ROBOT_NAME)/sensors/ouster/point_cloud_raw]
  - lidar_point_cloud_filter_output_topic [default: /$(env ROBOT_NAME)/sensors/ouster/point_cloud]

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged `lidar_point_cloud_filter` at Robotics Stack Exchange

API Docs Browse Code

No version for distro melodic showing github. Known supported distros are highlighted in the buttons above.

lidar_point_cloud_filter package from airstack repo

airstack_common coordination_bringup coordination_msgs desktop_bringup rqt_py_template waypoint_rviz2_plugin rviz_tasks_panel bag_record_pid logging_bringup airstack_msgs behavior_tree_msgs task_msgs robot_descriptions action_relay gcs_visualizer zed_wrapper autonomy_bringup drone_safety_monitor global_bringup global_plan_navigate_bridge random_walk_planner interface_bringup mavros_interface robot_interface mav_comm mav_msgs mav_planning_msgs mav_state_machine_msgs mav_system_msgs pid_controller pid_controller_msgs trajectory_controller takeoff_landing_planner trajectory_library perception_bringup lidar_point_cloud_filter ms_airsim_ros_bridge sim hello_module

ROS Distro
github

API Docs
Browse Code
Wiki

Package Summary

Version	0.1.0
License	BSD-3-Clause-Clear
Build type	AMENT_PYTHON
Use	RECOMMENDED

Repository Summary

Description
Checkout URI	https://github.com/castacks/airstack.git
VCS Type	git
VCS Version	develop
Last Updated	2026-09-11
Dev Status	UNKNOWN
Released	UNRELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Package Description

Near-range lidar noise filter: subscribes raw PointCloud2, drops points inside a sensor-frame sphere, publishes xyz float32 cloud.

Maintainers

Andrew Jong

Authors

No additional authors.

robot/ros_ws/src/sensors/lidar_point_cloud_filter/README.md

lidar_point_cloud_filter

Subscribes to a raw sensor_msgs/PointCloud2, removes points whose distance from the origin is less than near_range_m (distance in the cloud frame, same idea as the exploration planner’s lidar pre-process), and publishes a filtered cloud as xyz float32 only.

Topic flow (sim → robot)

In Isaac Sim / Pegasus example launch scripts (e.g. example_one_px4_pegasus_launch_script.py, example_multi_px4_pegasus_launch_script.py with ENABLE_LIDAR), the RTX LiDAR OmniGraph publishes point_cloud_raw under the vehicle namespace (e.g. /robot_N/sensors/ouster/point_cloud_raw). That stream crosses the sim→robot bridge and is what this node subscribes to.

On the robot stack:

Topic	Role
`.../sensors/ouster/point_cloud_raw`	Input — dense cloud from the sim (or hardware driver); may include near-field self-hits / clutter.
`.../sensors/ouster/point_cloud`	Output — same logical topic name consumers expect for “the” LiDAR cloud, but filtered (near-range sphere crop, xyz-only).

Downstream nodes should use point_cloud for planning / visualization unless they explicitly need the raw stream.

Parameters

Parameter	Meaning
`near_range_m`	Points with Euclidean range strictly less than this (meters) are dropped. `<= 0` disables filtering.
`input_topic`	Subscription topic; absolute path recommended (see defaults).
`output_topic`	Publication topic.
`qos_depth`	History depth (keep last).
`qos_reliable`	If true, RELIABLE (matches Isaac Replicator and typical RViz). If false, BEST_EFFORT for drivers that publish that way.

Defaults are in config/lidar_point_cloud_filter.yaml. $(env ROBOT_NAME) is expanded when launch loads the file with allow_substs="true". Python fallbacks use the ROBOT_NAME environment variable the same way.

Launch

ros2 launch lidar_point_cloud_filter lidar_point_cloud_filter.launch.xml

Included from the stack entry files (stacks/*/launch) under the robot and sensors namespaces. Defaults use sensors/ouster/point_cloud_raw → sensors/ouster/point_cloud to match Pegasus / Isaac and vdb_params. For RTX-only topic names, override input_topic and output_topic (for example under sensors/lidar/...).

System tests (`sensors` mark)

Sensor checks (sim + robot topic rates, LiDAR validation) live in repo-root tests/system/test_sensors.py (pytest -m sensors), which runs after tests/system/test_liveliness.py in the default collection order. Numpy-only LiDAR filter rules live in lidar_point_cloud_filter/validation_core.py (this package’s module directory), covered by test/test_validation_core.py (pytest -m unit via proxy in tests/robot/) and imported by scripts/validate_lidar_filter_clouds.py at runtime. For Isaac Sim (--sim isaacsim), that suite:

Proves the filtered topic is alive (ros2 topic echo --once on .../point_cloud — large clouds are not probed with ros2 topic hz).
Runs robot/ros_ws/src/sensors/lidar_point_cloud_filter/scripts/validate_lidar_filter_clouds.py inside each robot container: checks the filtered cloud against near_range_m, optionally compares behavior when point_cloud_raw has near-field returns.

Microsoft AirSim does not guarantee sensors/ouster topics on that profile; those steps are skipped there.

See tests/README.md (Bring-up scope) for how airstack_env applies when you combine liveliness and sensors marks.

CHANGELOG

No CHANGELOG found.

Package Dependencies

Deps	Name
	sensor_msgs_py
	ament_copyright
	ament_flake8
	ament_pep257
	rclpy
	sensor_msgs

System Dependencies

Name
python3-numpy
python3-pytest

Dependant Packages

No known dependants.

Launch files

launch/lidar_point_cloud_filter.launch.xml
- lidar_point_cloud_filter : canonical module launch file (RFC #379 §2/§4). Starts the LiDAR near-range filter. The node reads its topic endpoints from parameters (not remaps), so the declared topic args below are applied as parameter overrides on top of the config YAML; their defaults equal the YAML's canonical values (today's graph). No namespace is pushed here — the caller supplies it (the legacy sensors bringup and the stack entry files both include this file under a `sensors` namespace group), keeping the node path /$ROBOT_NAME/sensors/lidar_point_cloud_filter. Wiring deviations are passed as include args by the stack entry file (stacks//launch/) — the single-locus rule: no remap tags here.
- - lidar_point_cloud_filter_config [default: $(find-pkg-share lidar_point_cloud_filter)/config/lidar_point_cloud_filter.yaml]
  - lidar_point_cloud_filter_input_topic [default: /$(env ROBOT_NAME)/sensors/ouster/point_cloud_raw]
  - lidar_point_cloud_filter_output_topic [default: /$(env ROBOT_NAME)/sensors/ouster/point_cloud]

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged `lidar_point_cloud_filter` at Robotics Stack Exchange

API Docs Browse Code Wiki

No version for distro noetic showing github. Known supported distros are highlighted in the buttons above.

lidar_point_cloud_filter package from airstack repo

airstack_common coordination_bringup coordination_msgs desktop_bringup rqt_py_template waypoint_rviz2_plugin rviz_tasks_panel bag_record_pid logging_bringup airstack_msgs behavior_tree_msgs task_msgs robot_descriptions action_relay gcs_visualizer zed_wrapper autonomy_bringup drone_safety_monitor global_bringup global_plan_navigate_bridge random_walk_planner interface_bringup mavros_interface robot_interface mav_comm mav_msgs mav_planning_msgs mav_state_machine_msgs mav_system_msgs pid_controller pid_controller_msgs trajectory_controller takeoff_landing_planner trajectory_library perception_bringup lidar_point_cloud_filter ms_airsim_ros_bridge sim hello_module

ROS Distro
github

API Docs
Browse Code
Wiki

Package Summary

Version	0.1.0
License	BSD-3-Clause-Clear
Build type	AMENT_PYTHON
Use	RECOMMENDED

Repository Summary

Description
Checkout URI	https://github.com/castacks/airstack.git
VCS Type	git
VCS Version	develop
Last Updated	2026-09-11
Dev Status	UNKNOWN
Released	UNRELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Package Description

Near-range lidar noise filter: subscribes raw PointCloud2, drops points inside a sensor-frame sphere, publishes xyz float32 cloud.

Maintainers

Andrew Jong

Authors

No additional authors.

robot/ros_ws/src/sensors/lidar_point_cloud_filter/README.md

lidar_point_cloud_filter

Subscribes to a raw sensor_msgs/PointCloud2, removes points whose distance from the origin is less than near_range_m (distance in the cloud frame, same idea as the exploration planner’s lidar pre-process), and publishes a filtered cloud as xyz float32 only.

Topic flow (sim → robot)

In Isaac Sim / Pegasus example launch scripts (e.g. example_one_px4_pegasus_launch_script.py, example_multi_px4_pegasus_launch_script.py with ENABLE_LIDAR), the RTX LiDAR OmniGraph publishes point_cloud_raw under the vehicle namespace (e.g. /robot_N/sensors/ouster/point_cloud_raw). That stream crosses the sim→robot bridge and is what this node subscribes to.

On the robot stack:

Topic	Role
`.../sensors/ouster/point_cloud_raw`	Input — dense cloud from the sim (or hardware driver); may include near-field self-hits / clutter.
`.../sensors/ouster/point_cloud`	Output — same logical topic name consumers expect for “the” LiDAR cloud, but filtered (near-range sphere crop, xyz-only).

Downstream nodes should use point_cloud for planning / visualization unless they explicitly need the raw stream.

Parameters

Parameter	Meaning
`near_range_m`	Points with Euclidean range strictly less than this (meters) are dropped. `<= 0` disables filtering.
`input_topic`	Subscription topic; absolute path recommended (see defaults).
`output_topic`	Publication topic.
`qos_depth`	History depth (keep last).
`qos_reliable`	If true, RELIABLE (matches Isaac Replicator and typical RViz). If false, BEST_EFFORT for drivers that publish that way.

Defaults are in config/lidar_point_cloud_filter.yaml. $(env ROBOT_NAME) is expanded when launch loads the file with allow_substs="true". Python fallbacks use the ROBOT_NAME environment variable the same way.

Launch

ros2 launch lidar_point_cloud_filter lidar_point_cloud_filter.launch.xml

Included from the stack entry files (stacks/*/launch) under the robot and sensors namespaces. Defaults use sensors/ouster/point_cloud_raw → sensors/ouster/point_cloud to match Pegasus / Isaac and vdb_params. For RTX-only topic names, override input_topic and output_topic (for example under sensors/lidar/...).

System tests (`sensors` mark)

Sensor checks (sim + robot topic rates, LiDAR validation) live in repo-root tests/system/test_sensors.py (pytest -m sensors), which runs after tests/system/test_liveliness.py in the default collection order. Numpy-only LiDAR filter rules live in lidar_point_cloud_filter/validation_core.py (this package’s module directory), covered by test/test_validation_core.py (pytest -m unit via proxy in tests/robot/) and imported by scripts/validate_lidar_filter_clouds.py at runtime. For Isaac Sim (--sim isaacsim), that suite:

Proves the filtered topic is alive (ros2 topic echo --once on .../point_cloud — large clouds are not probed with ros2 topic hz).
Runs robot/ros_ws/src/sensors/lidar_point_cloud_filter/scripts/validate_lidar_filter_clouds.py inside each robot container: checks the filtered cloud against near_range_m, optionally compares behavior when point_cloud_raw has near-field returns.

Microsoft AirSim does not guarantee sensors/ouster topics on that profile; those steps are skipped there.

See tests/README.md (Bring-up scope) for how airstack_env applies when you combine liveliness and sensors marks.

CHANGELOG

No CHANGELOG found.

Package Dependencies

Deps	Name
	sensor_msgs_py
	ament_copyright
	ament_flake8
	ament_pep257
	rclpy
	sensor_msgs

System Dependencies

Name
python3-numpy
python3-pytest

Dependant Packages

No known dependants.

Launch files

launch/lidar_point_cloud_filter.launch.xml
- lidar_point_cloud_filter : canonical module launch file (RFC #379 §2/§4). Starts the LiDAR near-range filter. The node reads its topic endpoints from parameters (not remaps), so the declared topic args below are applied as parameter overrides on top of the config YAML; their defaults equal the YAML's canonical values (today's graph). No namespace is pushed here — the caller supplies it (the legacy sensors bringup and the stack entry files both include this file under a `sensors` namespace group), keeping the node path /$ROBOT_NAME/sensors/lidar_point_cloud_filter. Wiring deviations are passed as include args by the stack entry file (stacks//launch/) — the single-locus rule: no remap tags here.
- - lidar_point_cloud_filter_config [default: $(find-pkg-share lidar_point_cloud_filter)/config/lidar_point_cloud_filter.yaml]
  - lidar_point_cloud_filter_input_topic [default: /$(env ROBOT_NAME)/sensors/ouster/point_cloud_raw]
  - lidar_point_cloud_filter_output_topic [default: /$(env ROBOT_NAME)/sensors/ouster/point_cloud]

Messages

No message files found.

Services

No service files found

Plugins

No plugins found.

Recent questions tagged `lidar_point_cloud_filter` at Robotics Stack Exchange

API Docs Browse Code Wiki

lidar_point_cloud_filter package from airstack repo

ROS Distrogithub

Package Summary

Repository Summary

Package Description

Maintainers

Authors

lidar_point_cloud_filter

Topic flow (sim → robot)

Parameters

Launch

System tests (sensors mark)

Package Dependencies

System Dependencies

Dependant Packages

Launch files

Messages

Services

Plugins

Recent questions tagged lidar_point_cloud_filter at Robotics Stack Exchange

lidar_point_cloud_filter package from airstack repo

ROS Distrogithub

Package Summary

Repository Summary

Package Description

Maintainers

Authors

lidar_point_cloud_filter

Topic flow (sim → robot)

Parameters

Launch

System tests (sensors mark)

Package Dependencies

System Dependencies

Dependant Packages

Launch files

Messages

Services

Plugins

Recent questions tagged lidar_point_cloud_filter at Robotics Stack Exchange

lidar_point_cloud_filter package from airstack repo

ROS Distrogithub

Package Summary

Repository Summary

Package Description

Maintainers

Authors

lidar_point_cloud_filter

Topic flow (sim → robot)

Parameters

Launch

System tests (sensors mark)

Package Dependencies

System Dependencies

Dependant Packages

Launch files

Messages

Services

Plugins

Recent questions tagged lidar_point_cloud_filter at Robotics Stack Exchange

lidar_point_cloud_filter package from airstack repo

ROS Distrogithub

Package Summary

Repository Summary

Package Description

Maintainers

Authors

lidar_point_cloud_filter

Topic flow (sim → robot)

Parameters

Launch

System tests (sensors mark)

Package Dependencies

System Dependencies

Dependant Packages

Launch files

Messages

Services

Plugins

Recent questions tagged lidar_point_cloud_filter at Robotics Stack Exchange

ROS Distro
github

System tests (`sensors` mark)

Recent questions tagged `lidar_point_cloud_filter` at Robotics Stack Exchange

ROS Distro
github

System tests (`sensors` mark)

Recent questions tagged `lidar_point_cloud_filter` at Robotics Stack Exchange

ROS Distro
github

System tests (`sensors` mark)

Recent questions tagged `lidar_point_cloud_filter` at Robotics Stack Exchange

ROS Distro
github

System tests (`sensors` mark)

Recent questions tagged `lidar_point_cloud_filter` at Robotics Stack Exchange

ROS Distro
github

System tests (`sensors` mark)

Recent questions tagged `lidar_point_cloud_filter` at Robotics Stack Exchange

ROS Distro
github

System tests (`sensors` mark)

Recent questions tagged `lidar_point_cloud_filter` at Robotics Stack Exchange

ROS Distro
github

System tests (`sensors` mark)

Recent questions tagged `lidar_point_cloud_filter` at Robotics Stack Exchange

ROS Distro
github