feat: implement autoware system designer by technolojin · Pull Request #403 · tier4/nebula

technolojin · 2026-02-12T04:24:37Z

PR Type

New Feature

Description

describing node information using autoware_system_design_format

Review Procedure

To try autoware_system_designer, please follow instruction here

Remarks

Pre-Review Checklist for the PR Author

PR Author should check the checkboxes below when creating the PR.

Assign PR to reviewer

Checklist for the PR Reviewer

Reviewers should check the checkboxes below before approval.

Commits are properly organized and messages are according to the guideline
(Optional) Unit tests have been written for new behavior
PR title describes the changes

Post-Review Checklist for the PR Author

PR Author should check the checkboxes below before merging.

All open points are addressed and tracked via issues or tickets

CI Checks

Build and test for PR: Required to pass before the merge.

codecov · 2026-02-12T04:39:52Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 36.75%. Comparing base (bf52dda) to head (67edbe0).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #403   +/-   ##
=======================================
  Coverage   36.75%   36.75%           
=======================================
  Files         138      138           
  Lines       11207    11207           
  Branches     5961     5961           
=======================================
  Hits         4119     4119           
  Misses       6301     6301           
  Partials      787      787

Flag	Coverage Δ
nebula_continental	`34.81% <ø> (?)`
nebula_hesai	`34.81% <ø> (?)`
nebula_velodyne	`34.81% <ø> (?)`

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

mojomex

Thank you for the PR!
I am very keen on integrating with Autoware System Designer!

I am however concerned by the sheer number of lines this will introduce (only 4 out of our supported 16 are in this PR, and it's 900 lines already).

Nebula is quite unique since we have a big matrix of sensors with similar-but-not-same parameters, causing huge duplication already in our JSON schemas.

I am not sure what is planned on the tooling front, but treating these files as "lock files" (see Cargo, uv, Yarn, Pixi, etc.) seems the most sensible to me:
We launch each configuration in CI, get available topics, params, etc. and generate the Autoware System Designer files from that.

This way, they are guaranteed to stay up-to-date, and people don't have to manually change

the Node
the JSON schema
the YAML configs
AND the Autoware System Designer
everytime they make a change to params.

Please let me know your thoughts!

technolojin · 2026-02-13T06:58:06Z

Nebula is quite unique since we have a big matrix of sensors with similar-but-not-same parameters, causing huge duplication already in our JSON schemas.

I agree the maintenance cost concern.

the launcher can be generated from these node defitions
similar configuration can be covered by 'base-variant' pair
If user does not manipulate the sensor parameters, we can keep those in config files. the reason it has so many parameters is to follow current aip_launcher implementation.

I am not sure what is planned on the tooling front, but treating these files as "lock files" (see Cargo, uv, Yarn, Pixi, etc.) seems the most sensible to me: We launch each configuration in CI, get available topics, params, etc. and generate the Autoware System Designer files from that.

This way, they are guaranteed to stay up-to-date, and people don't have to manually change

the Node

the JSON schema

the YAML configs

AND the Autoware System Designer
everytime they make a change to params.

Please let me know your thoughts!

I am open to your idea. Please raise those topic to https://github.com/autowarefoundation/autoware_system_designer or https://github.com/autowarefoundation/autoware_system_designer
By the way, my idea is that the ros node implementation shall be automatically generated from the node configuration (and schema defines parameters). It is opposite of getting node configurations from current implementation (Maxime tried to extract node config from existing code, but it didn't went well).

technolojin · 2026-02-23T23:57:06Z

@mojomex
let me suggest action items

@mojomex list up parameters shall be in config files, not in the 'param_values'
@technolojin update the node files. may param_values reduced.
@mojomex review PR

mojomex

I've finally taken the time to take a look 🙇

There are some features/mechanisms that, if added, would make your tool a much better fit with Nebula. I've left some comments about those.

For the param question, we can reasonably expect the user to want to change all of them. I'm not quite sure what the effect of removing param_values has when param_files are also given, but if they can be removed here and still be set by pipelines/architectures, then I'd like to remove all of them as they're already in the config files. The config files are CI-checked agains the parameter schemas, and thus unlikely to fall out of sync with the actual node behavior.

Please let me know your thoughs.

mojomex · 2026-03-02T10:04:17Z

src/nebula_continental/nebula_continental/design/NebulaArs548_decode.node.yaml

+
+name: NebulaArs548_decode.node
+
+base: NebulaArs548.node


For Nebula, and for plugin-based systems like the planning modules, I think a composable or mixin-based config would be best, i.e. not having a singular base but a list of mixins.

For Nebula, this would enable us to have small, verifiable configs e.g. for:

ip connection

packet publisher

lidar decoder

ars548 decoder

hesai ptp settings
etc.

This would reduce the base config sizes and make pieces of them reusable in a composable way.

Also, I haven't come across an inheritance-style pattern that removes some of it's parent's properties, so I'm not sure this is in line of SWE best practices (it might well be, I've just not seen anything like it). What are your thoughts?

In my opinion, hardware interface and decoder shall be separated.
The first thing we need to do is not to make node complex.

The current base-variant is already complex, but I implemented this for this kind of requirement.
mixin will make even more complex.

I first implemented inheritance-style (not allow remove) but faced limitation in Autoware use cases. the nebula driver is one of them.

The concept is to lower the complexity. I would like to do it as current concept for the initial introduction.
If you have better idea and implementation, let's discuss for next version.

In my opinion, hardware interface and decoder shall be separated.

They were, originally. However, that caused all sorts of nasty issues, such as:

timing being at the mercy of DDS

scan cutting logic being duplicated between HW interface and decoder

duplicated shared parameters, e.g. FoV settings

increased buffer copies

Basically, similar to the planning modules, we realized that an over-reliance on ROS 2 for modularizing our software introduced problems.

I would like to do it as current concept for the initial introduction.
If you have better idea and implementation, let's discuss for next version.

Works for me 👍

One (imho nicer) option that gets rid of the remove keyword is to split into 3 configs:

NebulaArs584_base (has only /pandar_points pub, decoder process)

NebulaArs584_online (has HW interface process, /pandar_packets pub)

NebulaArs584_offline (has /pandar_packets sub)

mojomex · 2026-03-02T10:04:35Z

src/nebula_hesai/nebula_hesai/design/NebulaHesaiPandar128E4X.node.yaml

+processes:
+  - name: hw_interface
+    trigger_conditions:
+      - periodic: 100 # Hz


While incoming packets are (depending on sensor settings!) 900-3600 Hz, the output pandar_packets are accumulated and published together with pandar_points at 10Hz (or 5, or 20, depending on sensor settings) (so they could be thought of as one process). Please confirm what the best way to express this with your tool is.

Generally, architecture params that are dependent on node parameters are currently hard to express (e.g. processes.decoder.trigger_conditions.preiodic = param_values.rotation_speed // 60). I think you've talked about the ability to substitute e.g. topic names with parameter values (e.g. for pointcloud concat), so expanding this to a jinja2-style template system that can more accurately describe param dependencies would be nice.

It is not implemented but I can make the process arguments can be resolved by parameter.
see 5d0e9a9

mojomex · 2026-03-02T12:13:01Z

src/nebula_velodyne/nebula_velodyne/design/NebulaVelodyneVLP16.node.yaml

+  - name: blockage_range
+    type: string
+    default: "[0.0, 0.0]"
+  - name: horizontal_ring_id
+    type: int
+    default: 40
+  - name: is_channel_order_top2down
+    type: bool
+    default: true
+  - name: point_filters.downsample_mask.path
+    type: string
+    default: ""
+  - name: min_azimuth_deg
+    type: double
+    default: 135.0
+  - name: max_azimuth_deg
+    type: double
+    default: 225.0
+  - name: polar_voxel_visibility_estimation_mode
+    type: string
+    default: disable
+  - name: vertical_bins
+    type: int
+    default: 128
+  - name: horizontal_resolution
+    type: double
+    default: 0.4
+  - name: enable_blockage_diag
+    type: bool
+    default: true
+  - name: blockage_diagnostics_param_file
+    type: string
+    default: config/blockage_diagnostics_param_file.yaml
+  - name: use_dual_return_filter
+    type: bool
+    default: false


A lot of these are not Nebula args but pointcloud preprocessor args. Please double-check with Nebula's parameter schemas. Similarly for the other LiDAR configs.

parameters that are not used in nebula are removed bdccc21

mojomex

The cleaned up version already looks much better! The line number became about half of that before 🎉

There are some smaller comments but I think it's close already!

mojomex · 2026-03-09T08:42:03Z

src/nebula_hesai/nebula_hesai/design/NebulaHesaiPandar128E4X.node.yaml

+  - name: point_filters.downsample_mask.path
+    type: string
+    default: ""


Is there a reason this specific param was included here?

this parameter was not included in param file. check your files.

mojomex · 2026-03-09T08:47:34Z

src/nebula_hesai/nebula_hesai/design/NebulaHesaiPandar128E4X.node.yaml

+processes:
+  - name: hw_interface
+    trigger_conditions:
+      - periodic: 600.0 # future: ${parameter rotation_speed}


To be precise, it would be something like (2 ** ${param hires_mode}) * (${param return_mode} not in ["First", "Last", "Strongest"]).
Additionally, the actual triggering largely depends on scheduling settings (multiple packets can be processed per trigger).

At this point, I would simplify that to ${param rotation_speed} // 60, which is the output frequency of the packets.

this process description is mainly for system design and analysis.
it will not effect to operation.

which number do you need when you design sensing system?
I suggest to set a representative number here.

In that case, it's ${param rotation_speed} // 60 or 10 Hz.

mojomex · 2026-03-09T08:47:58Z

src/nebula_hesai/nebula_hesai/design/NebulaHesaiPandar128E4X.node.yaml

+  - name: rotation_speed
+    type: float
+    default: 600.0


I suppose this was only included for future use in processes below?

yes. if you don't use, it can be removed.

mojomex · 2026-03-09T08:52:17Z

src/nebula_continental/nebula_continental/design/NebulaArs548_decode.node.yaml

+
+name: NebulaArs548_decode.node
+
+base: NebulaArs548.node


One (imho nicer) option that gets rid of the remove keyword is to split into 3 configs:

NebulaArs584_base (has only /pandar_points pub, decoder process)

NebulaArs584_online (has HW interface process, /pandar_packets pub)

NebulaArs584_offline (has /pandar_packets sub)

src/nebula_velodyne/nebula_velodyne/design/NebulaVelodyneVLP16.node.yaml

mojomex · 2026-03-09T08:57:00Z

src/nebula_hesai/nebula_hesai/design/NebulaHesaiPandar128E4X.node.yaml

+  use_container: true
+  container_name: pointcloud_container


These are product-specific and not necessarily how one would use Nebula elsewhere, especially after the introduction of Agnocast.

I think this should be a property of a specific pipeline that uses Nebula, not of Nebula itself.

I agree.
I set those configuration as PoC.

Future: the container configuration will be set by module.

launch configuration can be set from module

https://github.com/autowarefoundation/autoware_system_designer/blob/b0651d346458dc260f939c12a5dec3766961a363/autoware_system_designer/autoware_system_designer/builder/instances/instance_tree.py#L165-L189

I implemented this already, but not used. let me try it.

PR autowarefoundation/autoware_system_designer#30

this PR implements container settings are set from modules and system layer, instead of node.

…rmat - Introduced a new workflow to lint system design format files on pull requests and pushes to the main branch. - Updated pre-commit configuration to include a new hook for linting with autoware_system_designer. Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

- Introduced NebulaArs548_decode.node.yaml and NebulaHesaiPandar128E4X_decode.node.yaml for decoding processes. - Updated NebulaArs548.node.yaml and NebulaHesaiPandar128E4X.node.yaml with new input/output configurations and parameters. - Removed obsolete inputs and outputs in the decode configurations to streamline processing. Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

…e configurations - Changed launch package for NebulaHesaiPandar128E4X from nebula_ros to nebula_hesai. - Updated parameter file path for NebulaHesaiPandar128E4X. - Introduced new configurations for NebulaVelodyneVLS128, including inputs, outputs, and parameters for the Velodyne sensor. - Added a decoding process for NebulaVelodyneVLS128 with appropriate trigger conditions and outcomes. Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

- Introduced NebulaVelodyneVLP16.node.yaml with detailed input/output configurations and parameters for the Velodyne sensor. - Added a new NebulaVelodyneVLP16_decode.node.yaml for decoding processes, specifying inputs, outputs, and parameters. - Streamlined the configuration by removing obsolete outputs and processes in the decoder setup. Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

- Changed launch package from nebula_ros to nebula_continental in NebulaArs548.node.yaml to reflect the correct package structure. Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

…ode configuration - Changed the message type from pandar_msgs/msg/PandarScan to velodyne_msgs/msg/VelodyneScan in NebulaVelodyneVLS128_decode.node.yaml to ensure compatibility with the Velodyne sensor data. Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

- Changed the default value of the calibration_file parameter in NebulaVelodyneVLS128.node.yaml to point to the correct calibration file location: $(find-pkg-share nebula_velodyne_decoders)/calibration/VLS128.yaml. Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

- Changed 'inheritance' to 'base' in NebulaArs548_decode.node.yaml, NebulaHesaiPandar128E4X_decode.node.yaml, NebulaVelodyneVLP16_decode.node.yaml, and NebulaVelodyneVLS128_decode.node.yaml to align with the updated configuration structure. Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

…de configuration - Changed the message type from pandar_msgs/msg/PandarScan to velodyne_msgs/msg/VelodyneScan in NebulaVelodyneVLP16_decode.node.yaml to ensure compatibility with the Velodyne sensor data. Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

…dar128E4X - Bumped autoware_system_design_format from v0.1.0 to v0.2.0 in both NebulaArs548.node.yaml and NebulaHesaiPandar128E4X.node.yaml. - Added package information including name and provider for both nodes to enhance clarity and structure. - Adjusted launch package references to align with the updated package structure. Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

- Updated autoware_system_design_format from v0.x.x to 0.x.x in multiple node configuration files for consistency across the project. Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

…parameter naming - Bumped autoware_system_design_format to 0.3.0 in multiple node configuration files for consistency. - Renamed 'parameters' to 'param_values' and 'parameter_files' to 'param_files' for uniformity across the project. Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

Signed-off-by: Takagi, Isamu <isamu.takagi@tier4.jp> Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

…ebulaHesaiPandar128E4X configuration - Introduced a new parameter 'rotation_speed' with a default value of 600.0. - Updated the trigger condition for 'hw_interface' to use the new 'rotation_speed' parameter. - Modified the 'decoder' process to trigger on 'hw_interface' for improved workflow. Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

…28E4X configuration Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

…bulaVelodyneVLS128 configurations - Deleted the 'blockage_mask' publisher entry from both node configuration files to streamline the design. Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

technolojin · 2026-03-10T00:05:42Z

One (imho nicer) option that gets rid of the remove keyword is to split into 3 configs:
NebulaArs584_base (has only /pandar_points pub, decoder process)
NebulaArs584_online (has HW interface process, /pandar_packets pub)
NebulaArs584_offline (has /pandar_packets sub)

Does it mean NebulaArs584_base is a not-working node?

mojomex · 2026-03-12T13:27:08Z

@technolojin

Does it mean NebulaArs584_base is a not-working node?

Basically, yes. Conceptually it would be the same as an abstract class in object oriented programming.

technolojin mentioned this pull request Feb 12, 2026

Autoware System Designer - initial implementation autowarefoundation/autoware#6793

Open

3 tasks

technolojin self-assigned this Feb 12, 2026

technolojin changed the title ~~feat: support autoware system designer~~ feat: implement autoware system designer Feb 12, 2026

technolojin assigned mojomex Feb 12, 2026

technolojin marked this pull request as ready for review February 12, 2026 09:18

mojomex reviewed Feb 13, 2026

View reviewed changes

mojomex mentioned this pull request Feb 13, 2026

Treat autoware_system_designer files as lock files autowarefoundation/autoware_system_designer#6

Open

mojomex requested changes Mar 2, 2026

View reviewed changes

technolojin force-pushed the autoware-system-designer branch from d039bae to bdccc21 Compare March 9, 2026 07:15

technolojin requested a review from mojomex March 9, 2026 07:53

mojomex reviewed Mar 9, 2026

View reviewed changes

technolojin mentioned this pull request Mar 9, 2026

ci: add GitHub Actions workflow for linting Autoware system design format #416

Open

5 tasks

technolojin and others added 14 commits March 10, 2026 08:39

fix: update launch package for NebulaArs548 node configuration

e9f4b45

- Changed launch package from nebula_ros to nebula_continental in NebulaArs548.node.yaml to reflect the correct package structure. Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

ci(pre-commit): autofix

38c3c98

Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

chore: standardize autoware_system_design_format versioning

99c87f7

- Updated autoware_system_design_format from v0.x.x to 0.x.x in multiple node configuration files for consistency across the project. Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

chore: fix yaml formats

bd86f9a

Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

replace input field

1000f89

Signed-off-by: Takagi, Isamu <isamu.takagi@tier4.jp> Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

isamu-takagi and others added 4 commits March 10, 2026 08:39

replace output filed

ab38762

Signed-off-by: Takagi, Isamu <isamu.takagi@tier4.jp> Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

refactor: remove param_values included in config files

80d81fb

Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

fix: correct indentation in trigger conditions for NebulaHesaiPandar1…

7d2930c

…28E4X configuration Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

technolojin force-pushed the autoware-system-designer branch from 7d61a04 to 7d2930c Compare March 9, 2026 23:40

chore: remove blockage_mask publisher from NebulaVelodyneVLP16 and Ne…

67edbe0

…bulaVelodyneVLS128 configurations - Deleted the 'blockage_mask' publisher entry from both node configuration files to streamline the design. Signed-off-by: Taekjin LEE <taekjin.lee@tier4.jp>

Conversation

technolojin commented Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Type

Related Links

Description

Review Procedure

Remarks

Pre-Review Checklist for the PR Author

Checklist for the PR Reviewer

Post-Review Checklist for the PR Author

CI Checks

Uh oh!

codecov bot commented Feb 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

mojomex left a comment

Choose a reason for hiding this comment

Uh oh!

technolojin commented Feb 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

technolojin commented Feb 23, 2026

Uh oh!

mojomex left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mojomex left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

technolojin commented Mar 10, 2026

Uh oh!

mojomex commented Mar 12, 2026

Uh oh!

Reviewers

Assignees

technolojin commented Feb 12, 2026 •

edited

Loading

codecov bot commented Feb 12, 2026 •

edited

Loading

technolojin commented Feb 13, 2026 •

edited

Loading