Pith. sign in

REVIEW 3 major objections 5 minor 37 references

LiGuard: A Streamlined Open-Source Framework for Rapid & Interactive Lidar Research

T0 review · 3 major / 5 minor · reviewed 2026-08-05 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read LiGuard lets lidar researchers reorder pipelines live, no rewiring.

desk verdict A genuinely useful open-source lidar pipeline tool, but the paper's interactive reordering claim is under-validated and the shared-data-dictionary dependency issue is the real soft spot. read the letter →

arxiv 2509.02902 v1 pith:L7R74WDT submitted 2025-09-03 cs.CV

Muhammad Shahbaz , Shaurya Agarwal This is my paper · ORCID
classification cs.CV
keywords lidarpointcloudinteractivepipelineopen-sourcesoftwaredatadictionaryobjectdetectionintelligenttransportationsystemsvisualization
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper presents LiGuard, an open-source, GUI-based framework for research on lidar point clouds and accompanying image data. The central claim is that by making every functional step of an experiment independent and communicating only through a shared data dictionary, researchers can rapidly assemble, tweak, and reuse multi-stage lidar pipelines without rewriting or recompiling code. The authors argue this addresses the common frustration of duplicated effort and tightly coupled code in lidar research. The value would be concrete: experiments that once required editing interdependent scripts can instead be built, ablated, and shared as structured, reorderable components. The paper demonstrates the claim with two case studies, one using a pre-trained PointPillars detector on the KITTI dataset and one using a custom roadside lidar dataset.

What carries the argument

The shared data dictionary is the central mechanism: every function reads from and writes to this common structure, so no function invokes another directly. A companion configuration dictionary stores pipeline settings, and GUI panels expose these settings live, allowing on-the-fly reordering, enabling, disabling, and parameter adjustment without code changes.

What would settle it

Run Pipeline 2 through the GUI and disable the background-filtering step while leaving downstream clustering and bounding-box regression enabled; if the pipeline silently produces garbage clusters or crashes without a clear error, the claimed modular independence is violated. Alternatively, reorder the background-filter and clustering steps via the GUI and observe whether the pipeline still executes or whether it raises an unexplained data-availability error.

Watch

Extended reading notes

Core claim

The paper's core claim is that a software framework with a modular, data-dictionary-centric architecture can make lidar research substantially faster and more reproducible. In LiGuard, every functional step—data reading, preprocessing, point cloud operations, image operations, labeling, and post-processing—is implemented as an independent function that reads input from and writes output to a shared data dictionary. Because no function is hardcoded to call another, users can enable, disable, reorder, and tune steps live through a GUI, and can create new custom steps from standardized templates. The authors argue that this design decouples the experiment logic from application plumbing, and th

Load-bearing premise

The load-bearing premise is that every functional step in a pipeline is truly independent and relies only on the shared data dictionary, so enabling, disabling, reordering, or replacing steps will not break the pipeline in hidden ways.

Editorial extensions

If this is right

  • Researchers can perform ablation studies by simply disabling a step in the GUI, without editing or rerunning code, making systematic evaluation of pipeline components easier.
  • Individual functions built for one experiment can be reused in another by copying the structured component files, reducing duplicated implementation effort across studies.
  • Entire experiment pipelines can be shared as structured directories, improving reproducibility and making it easier for others to inspect and modify the exact sequence of operations.
  • The framework's support for multiple data sources (stored files, live sensors, and the CARLA simulator) means the same pipeline logic can be transferred across data modalities with minimal changes.
  • Because custom functions follow a standard template and integrate into the GUI, the framework can grow a library of reusable components contributed by the research community.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The modular data-dictionary design could be extended beyond point clouds and images to other time-series or multi-modal sensor research, since the core independence principle is not lidar-specific.
  • A natural testable extension would be a user study measuring time-to-pipeline-completion or number of code edits for a standard task on LiGuard versus a conventional script-based approach; the paper does not provide such a quantitative comparison.
  • The claim that pipelines are automatically reproducible partly depends on the stability of the pipeline directory format and the compatibility of referenced external tools (e.g., Open3D, OpenCV, PointPillars), so version pinning would be a prudent extension.
  • The interactivity benefit is most valuable for iterative tuning loops with slow-to-edit parameters; the paper's case studies demonstrate this qualitatively but do not benchmark how much faster a full tuning cycle becomes.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper presents LiGuard, an open-source GUI-based framework for point cloud and image research, targeting ITS applications. It claims to enable rapid, interactive, reusable, and reproducible lidar experimentation by providing built-in readers, pre/post-processing functions, algorithms, visualizers, and an interactive pipeline editor built around a shared data dictionary. The architecture is described in Section III, and two case studies (KITTI PointPillars inference and a self-supervised label generation pipeline) are presented in Section IV as qualitative demonstrations. The central claim is that functional steps are independent (no hardcoded calls) so users can enable/disable/reorder steps and live-edit parameters.

Significance. If the claims are substantiated, LiGuard would provide a practical tool to reduce duplicated code and experimental rework in lidar-related research, especially for ITS applications. The open-source release, structured pipeline directories, custom function templates, and support for CARLA and multiple datasets are concrete contributions. The paper's value is in the system design and its potential community impact, but the current manuscript offers only qualitative case studies and no quantitative validation of the key interactivity and reusability claims.

major comments (3)
  1. [Section III (Data Flow & Operation)] The paper's central interactive/reorder claim rests on the modularity assertion that any function can be enabled/disabled/reordered because it only relies on the shared data dictionary. However, this assertion is not validated. The shared dictionary has no schema or dependency metadata, and the text itself qualifies the claim: 'As long as the required data is available in the data stream' (Section III). The GUI permits toggling functions without checking whether required keys exist. Neither case study exercises a non-trivial reorder or disable; Pipeline 2 is presented in a fixed order. This is a load-bearing gap: if hidden data dependencies break, the claimed 'interactive' advantage over conventional code editing is substantially weakened. Please either add dependency validation/schema or empirically demonstrate a non-trivial reorder/disable on both pipelines.
  2. [Section IV-A, Figure 5] The reusability case study using the custom dataset ends with the caption: 'The model is clearly hallucinating as the data is completely different.' This is not a successful demonstration of reusability; it shows the pipeline executes but produces meaningless detections. As a result, this example undermines the paper's effectiveness claim rather than supporting it. The authors should either replace this example with a case where the same pipeline produces useful results after appropriate retraining/fine-tuning, or explicitly frame this as a known limitation and discuss the additional steps required (e.g., domain adaptation). Presenting a failure as evidence of reusability is confusing and disproportionate to the claim.
  3. [Section IV (Technology Demonstration)] The paper does not provide any quantitative evidence for the 'rapid' or 'effective' claims. The two case studies are qualitative screenshots with no metrics such as time-to-pipeline, code-line reduction, number of GUI interactions, throughput, or usability measures. No comparison is made with a conventional code-based workflow (e.g., using Open3D/PCL directly). For a systems paper, some quantitative demonstration of the claimed productivity gains is needed, even if modest. Without it, the central contribution is only that the tool runs, which is not sufficient to distinguish it from existing SDKs.
minor comments (5)
  1. [Table II] Descriptions contain typos: 'Inifity' should be 'Infinity'; 'Trvelotocam' likely 'Tr_velo_to_cam'. The 'manualcalibration' row appears to combine three separate descriptions without separators.
  2. [Abstract / Introduction] Typo: 'Forth, for reproducibility' should be 'Fourth'.
  3. [Table I] The comparison table uses checkmarks without defining the criteria (e.g., what counts as 'Interactive GUI' or 'Data Agnostic Support'). This makes the comparison hard to interpret and potentially misleading.
  4. [References] Reference [36] is dated 2000; the associated GitHub repository for PointPillars is recent. Please verify and update the year. Reference [34] (PCL.py) should also list a proper URL.
  5. [Section III-C] The priority mechanism is defined within process categories, but it is unclear how ordering is handled across categories or whether cross-category reordering is supported in the GUI. A short clarification would help.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: LiGuard is a software framework whose claims are demonstrated by usage examples, not derived from fitted parameters or self-citation chains.

full rationale

The paper makes no quantitative predictions and contains no equations or fitted parameters. Its central claims are that the LiGuard GUI framework enables rapid, interactive, reusable, and reproducible lidar research by modularizing pipeline steps and sharing data through a configuration dictionary and a data dictionary (Section III). The effectiveness claim is supported by two case-study pipelines (Section IV) assembled from LiGuard's built-in functions and custom templates. There is no derivation chain whose output is equivalent to its input by construction, and no fitted quantity is renamed as a prediction. The paper also does not rely on any self-citation for load-bearing support; its citations are to external libraries, datasets, and algorithms such as Open3D, OpenCV, KITTI, PointPillars, and CARLA. The closest thing to a limitation is the paper's own qualification in Section III that functions can execute 'as long as the required data is available in the data stream,' which shifts responsibility for data-availability consistency to the user rather than the framework. This is a design-assumption gap and a potential correctness risk, but it is not a circularity: the claim that LiGuard permits interactive enabling/disabling/reordering is not established by assuming that claim. The case studies are authored by the developers, which is a mild form of self-demonstration, but the claim is falsifiable by using the open-source framework on independent pipelines, and nothing in the paper reduces the claimed functionality to a restatement of its inputs. Therefore no circular step can be quoted or exhibited, and the appropriate score is 0.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The central claim is a software engineering capability claim; it rests on the reliability of underlying libraries, the validity of the modular architecture, and the representativeness of the case studies.

assumptions (3)
  • domain assumption Open3D and OpenCV provide correct and sufficient underlying implementations for point cloud and image operations.
    LiGuard builds on these libraries; if they have bugs or limitations, LiGuard's functionality is compromised.
  • ad hoc to paper Each pipeline function is independent, relying only on the shared data dictionary, so any ordering or combination is valid.
    Section III claims modularity without proof; this is a design invariant that the framework's interactivity depends on.
  • domain assumption The two case studies are representative of common lidar research workflows.
    Effectiveness is claimed via two self-selected examples; no external validation is provided.

how reviews work

0 comments
Cite this review

Pith. "Pith review of LiGuard: A Streamlined Open-Source Framework for Rapid & Interactive Lidar Research." pith.science (2026). https://pith.science/paper/L7R74WDT

@misc{pith2026250902902,
  author       = {Pith},
  title        = {Pith review of: LiGuard: A Streamlined Open-Source Framework for Rapid & Interactive Lidar Research},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/L7R74WDT}},
  note         = {Machine review of arXiv:2509.02902}
}
read the original abstract

There is a growing interest in the development of lidar-based autonomous mobility and Intelligent Transportation Systems (ITS). To operate and research on lidar data, researchers often develop code specific to application niche. This approach leads to duplication of efforts across studies that, in many cases, share multiple methodological steps such as data input/output (I/O), pre/post processing, and common algorithms in multi-stage solutions. Moreover, slight changes in data, algorithms, and/or research focus may force major revisions in the code. To address these challenges, we present LiGuard, an open-source software framework that allows researchers to: 1) rapidly develop code for their lidar-based projects by providing built-in support for data I/O, pre/post processing, and commonly used algorithms, 2) interactively add/remove/reorder custom algorithms and adjust their parameters, and 3) visualize results for classification, detection, segmentation, and tracking tasks. Moreover, because it creates all the code files in structured directories, it allows easy sharing of entire projects or even the individual components to be reused by other researchers. The effectiveness of LiGuard is demonstrated via case studies.

Figures

Figures reproduced from arXiv: 2509.02902 by the authors.

Figure 1
Figure 1. LiGuard’s Interface. Left: The Configuration window allows users to interactively control experiment pipeline; users can leverage built-in data loading capabilities, create, enable/disable/reorder functional steps, dynamically change exposed parameters, and customize visualizations. Middle Top: The Image Feed window visualizes image data. Middle Bottom: The PointCloud Feed window visualizes the lidar data. Both visu… view at source ↗
Figure 2
Figure 2. LiGuard’s Architecture graphical-user-interface) and OpenCV [2] (for operating on image data), to offer flexibility in expansion. Its architecture, as presented in the [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Pipeline 1: PointPillars [13] Inference on KITTI [8] Dataset. In the Center the flow of the experiment pipeline is shown that is color coded according to Right Bottom Software Stack diagram. On Left & Right Top, in pink bordered boxes, the corresponding GUI components are shown to visualize the pipeline relation to LiGuard’s Configuration window. of execution depends upon priority, a live-editable number (lower is h… view at source ↗
Figures from the paper (5 more)
Figure 5
Figure 5. Figure 5: A point cloud frame from a custom dataset passed [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]
Figure 4
Figure 4. Figure 4: A point cloud frame from KITTI [8] dataset passed through Pipeline 1. The sub-figures are crops from the Image Feed and PointCloud Feed windows of LiGuard’s interface shown in [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 6
Figure 6. Figure 6: Pipeline 2: Self-Supervised Labeling for Custom Dataset. In the Center the flow of the experiment pipeline is shown that is color coded according to Right Center Software Stack diagram. On Left and Right (Top and Bottom), in pink bordered boxes, the corresponding GUI c…
Figure 7
Figure 7. Figure 7: Pipeline 2 Stages. The sub-figures, from left to right, display original point cloud followed by the processed output from BGFilterSTDF, O3D_DBSCAN, and Cluster2Object functions, respectively. For this pipeline, each functional step (background filtering, clustering, b…
Figure 8
Figure 8. Figure 8: Pipeline 2-Modified. To modify pipeline 2 to use CARLA [7] as data source instead of a stored dataset, the only required change is disabling everything under data and enabling lidar under sensors in the Configuration window. The rest of pipeline stays exactly the same,…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

37 extracted references · 31 canonical work pages

  1. [1]

    Cython: The best of both worlds,

    S. Behnel, R. Bradshaw, C. Citro, L. Dalcin, D. S. Seljebotn, and K. Smith, “Cython: The best of both worlds,” Computing in Science & Engineering , vol. 13, no. 2, pp. 31–39, 2011

    work page 2011

  2. [2]

    The OpenCV Library,

    G. Bradski, “The OpenCV Library,” Dr . Dobb’s Journal of Software Tools, 2000

    work page 2000

  3. [3]

    Caron, “Pclpy,” https://github.com/davidcaron/pclpy, 2018

    D. Caron, “Pclpy,” https://github.com/davidcaron/pclpy, 2018

    work page 2018

  4. [4]

    Cloudcompare,

    CloudCompare, “Cloudcompare,” https://github.com/CloudCompare/ CloudCompare, 2012

    work page 2012

  5. [5]

    Pdal point data abstraction library,

    P. Contributors, “Pdal point data abstraction library,” Aug. 2022. [Online]. Available: https://doi.org/10.5281/zenodo.2616780

    doi:10.5281/zenodo.2616780 2022

  6. [6]

    daavoo/pyntcloud: v0.2.0,

    D. de la Iglesia Castro, K. Mader, Hanchen, B. Sullivan, pandu rao, J. Cole, M. Wallbaum, N. Mitchell, Sebastian, M. Movva, P. McCartney, S. Jadhav, Y . B. de Miguel, A. Milan, B. Mitzkus, D. Bazazian, G. Gandenberger, J. Buchanan, M. D. Trevisani, M. Quach, N-McA, R. P. Joshi, R. Tweedie, brett koonce, fatih, iindovina, J. Hadfield, and joskaaaa, “daavoo...

    work page doi:10.5281/zenodo.6462793 2022

  7. [7]

    CARLA: An open urban driving simulator,

    A. Dosovitskiy, G. Ros, F. Codevilla, A. Lopez, and V . Koltun, “CARLA: An open urban driving simulator,” in Proceedings of the 1st Annual Conference on Robot Learning , 2017, pp. 1–16

    2017

  8. [8]

    Vision meets robotics: The kitti dataset,

    A. Geiger, P. Lenz, C. Stiller, and R. Urtasun, “Vision meets robotics: The kitti dataset,” The International Journal of Robotics Research , vol. 32, no. 11, pp. 1231–1237, 2013

    2013

Show all 37 references
  1. [9]

    ‘pointcloudset‘: Efficient analysis of large datasets of point clouds recorded over time,

    T. Goelles, B. Schlager, S. Muckenhuber, S. Haas, and T. Hammer, “‘pointcloudset‘: Efficient analysis of large datasets of point clouds recorded over time,” Journal of Open Source Software , vol. 6, no. 65, p. 3471, 2021. [Online]. Available: https://doi.org/10.21105/joss.03471

    2021 doi

  2. [10]

    Os1-64 lidar sensor,

    O. Inc., “Os1-64 lidar sensor,” https://ouster.com/products/hardware/ os1-lidar-sensor, n.d., accessed: 2024-12-10

    2024

  3. [11]

    pybind11 – seamless operability between c++11 and python,

    W. Jakob, J. Rhinelander, and D. Moldovan, “pybind11 – seamless operability between c++11 and python,” 2017, https://github.com/pybind/pybind11

    2017

  4. [12]

    Paraview,

    Kitware, “Paraview,” https://github.com/Kitware/ParaView, 2000

    2000

  5. [13]

    Pointpillars: Fast encoders for object detection from point clouds,

    A. H. Lang, S. V ora, H. Caesar, L. Zhou, J. Yang, and O. Beijbom, “Pointpillars: Fast encoders for object detection from point clouds,” in Proceedings of the IEEE/CVF conference on computer vision and pattern recognition, 2019, pp. 12 697–12 705

    2019

  6. [14]

    A progress review on solid-state lidar and nanophotonics-based lidar sensors,

    N. Li, C. P. Ho, J. Xue, L. W. Lim, G. Chen, Y . H. Fu, and L. Y . T. Lee, “A progress review on solid-state lidar and nanophotonics-based lidar sensors,” Laser & Photonics Review , 2022

    2022

  7. [15]

    entwine,

    C. Manning, “entwine,” https://github.com/connormanning/entwine, 2015

    2015

  8. [16]

    Maturana, “Pypcd,” https://github.com/dimatura/pypcd, 2013

    D. Maturana, “Pypcd,” https://github.com/dimatura/pypcd, 2013

    2013

  9. [17]

    3dtk–the 3d toolkit,

    A. N ¨uchter and K. Lingemann, “3dtk–the 3d toolkit,” Retrieved Jan , vol. 20, p. 2021, 2011

    2021

  10. [18]

    Meshlab,

    Paolo Cignoni, Alessandro Muntoni, Guido Ranzuglia, Marco Callieri, “Meshlab,” 2012

    2012

  11. [19]

    lidr: An r package for analysis of airborne laser scanning (als) data,

    J.-R. Roussel, D. Auty, N. C. Coops, P. Tompalski, T. R. Goodbody, A. S. Meador, J.-F. Bourdon, F. De Boissieu, and A. Achim, “lidr: An r package for analysis of airborne laser scanning (als) data,” Remote Sensing of Environment , vol. 251, p. 112061, 2020

    2020

  12. [20]

    3D is here: Point Cloud Library (PCL),

    R. B. Rusu and S. Cousins, “3D is here: Point Cloud Library (PCL),” in IEEE International Conference on Robotics and Automation (ICRA) . Shanghai, China: IEEE, 5 2011

    2011

  13. [21]

    Python-pcl,

    S. A. Straw, “Python-pcl,” https://github.com/strawlab/python-pcl, 2012

    2012

  14. [22]

    PyVista: 3D plotting and mesh analysis through a streamlined interface for the Visualization Toolkit (VTK),

    B. Sullivan and A. Kaszynski, “PyVista: 3D plotting and mesh analysis through a streamlined interface for the Visualization Toolkit (VTK),” Journal of Open Source Software , vol. 4, no. 37, p. 1450, 5 2019. [Online]. Available: https://doi.org/10.21105/joss.01450

    2019 doi

  15. [23]

    Object detection based on roadside lidar for cooperative driving automation: A review,

    P. Sun, C. Sun, R. Wang, and X. Zhao, “Object detection based on roadside lidar for cooperative driving automation: A review,” Sensors, vol. 22, no. 23, p. 9316, 2022

    2022

  16. [24]

    3-d data processing to extract vehicle trajectories from roadside lidar data,

    Y . Sun, H. Xu, J. Wu, J. Zheng, and K. M. Dietrich, “3-d data processing to extract vehicle trajectories from roadside lidar data,” Transportation research record, vol. 2672, no. 45, pp. 14–22, 2018

    2018

  17. [25]

    Openpcdet: An open-source toolbox for 3d object detection from point clouds,

    O. D. Team, “Openpcdet: An open-source toolbox for 3d object detection from point clouds,” https://github.com/open-mmlab/OpenPCDet, 2020

    2020

  18. [26]

    tmontaigu, “Laspy,” https://github.com/laspy, 2012

    2012

  19. [27]

    Efficient lidar point cloud data managing and processing in a hadoop-based distributed framework,

    C. Wang, F. Hu, D. Sha, and X. Han, “Efficient lidar point cloud data managing and processing in a hadoop-based distributed framework,” ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information Sciences , vol. IV-4/W2, pp. 121–124, 2017

    2017

  20. [28]

    Ips300+: a challenging multi-modal data sets for intersection perception system,

    H. Wang, X. Zhang, Z. Li, J. Li, K. Wang, Z. Lei, and R. Haibing, “Ips300+: a challenging multi-modal data sets for intersection perception system,” in 2022 International Conference on Robotics and Automation (ICRA). IEEE, 2022, pp. 2539–2545

    2022

  21. [29]

    Theoretically-efficient and practical parallel dbscan,

    Y . Wang, Y . Gu, and J. Shun, “Theoretically-efficient and practical parallel dbscan,” in Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data , ser. SIGMOD ’20. New York, NY , USA: Association for Computing Machinery, 2020, p. 2555–2571. [Online]...

    2020 doi

  22. [30]

    An automatic procedure for vehicle tracking with a roadside lidar sensor,

    J. Wu, “An automatic procedure for vehicle tracking with a roadside lidar sensor,” Institute of Transportation Engineers. ITE Journal , vol. 88, no. 11, pp. 32–37, 2018

    2018

  23. [31]

    cilantro: A lean, versatile, and efficient library for point cloud data processing,

    K. Zampogiannis, C. Fermuller, and Y . Aloimonos, “cilantro: A lean, versatile, and efficient library for point cloud data processing,” in Proceedings of the 26th ACM International Conference on Multimedia , ser. MM ’18. New York, NY , USA: ACM, 2018, pp. 1364–1367

    2018

  24. [32]

    Detection and tracking of pedestrians and vehicles using roadside lidar sensors,

    J. Zhao, H. Xu, H. Liu, J. Wu, Y . Zheng, and D. Wu, “Detection and tracking of pedestrians and vehicles using roadside lidar sensors,” Transportation research part C: emerging technologies , vol. 100, pp. 68–87, 2019

    2019

  25. [33]

    All-solid-state beam steering via integrated optical phased array technology,

    S. Zhao, J. Chen, and Y . Shi, “All-solid-state beam steering via integrated optical phased array technology,” Micromachines, 2022

    2022

  26. [34]

    Zhong, “Pcl.py,” https://github.com/cmpute/pcl.py, 2018

    J. Zhong, “Pcl.py,” https://github.com/cmpute/pcl.py, 2018

    2018

  27. [35]

    Open3D: A modern library for 3D data processing,

    Q.-Y . Zhou, J. Park, and V . Koltun, “Open3D: A modern library for 3D data processing,” arXiv:1801.09847, 2018

    2018 arXiv

  28. [36]

    Pointpillars: Fast encoders for object detection from point clouds,

    ZhuLifa, “Pointpillars: Fast encoders for object detection from point clouds,” https://github.com/zhulf0804/PointPillars, 2000

    2000

  29. [37]

    Infradet3d: Multi-modal 3d object detection based on roadside infrastructure camera and lidar sensors,

    W. Zimmer, J. Birkner, M. Brucker, H. T. Nguyen, S. Petrovski, B. Wang, and A. C. Knoll, “Infradet3d: Multi-modal 3d object detection based on roadside infrastructure camera and lidar sensors,” in 2023 IEEE Intelligent V ehicles Symposium (IV) . IEEE, 2023, pp. 1–8. JOURNAL OF...

    2023

Pith tools

Reviewed August 5, 2026 · model on record in the stance chip above.