Pith. sign in

REVIEW 4 major objections 5 minor 17 references

Implementation of Real-Time Lane Detection on Autonomous Mobile Robot

T0 review · 4 major / 5 minor · reviewed 2026-08-12 · deepseek-v4-flash

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

Pith's one-line read Lane detection runs 22 times faster after TensorRT conversion.

desk verdict A thin engineering report with a plausible but underspecified speedup; the 22x claim needs the ONNX baseline and measurement details before it can be trusted. read the letter →

arxiv 2411.14873 v1 pith:5E4MPWQ7 submitted 2024-11-22 cs.RO cs.CV

Midriem Mirdanies , Roni Permana Saputra , Edwar Yazid , Rozeha A. Rashid This is my paper · ORCID
classification cs.ROcs.CV
keywords lanedetectionautonomousmobilerobotUltraFastTensorRTJetsonNanoreal-timeinferenceedgecomputingdomainshift
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 tries to show that a modern deep-learning lane detector can run in real time on a small, low-power robot computer. The authors take the Ultra Fast Lane Detection model, convert it from ONNX format to a TensorRT engine, and run it on a Jetson Nano inside a single-passenger autonomous transporter. Measured processing time drops from about 2.3 seconds to roughly 101 ms on CULane and 105 ms on TuSimple, about 22 times faster, because the converted model finally uses the device's GPU properly. The same conversion is not enough for indoor lanes: the pretrained outdoor model detects outdoor lanes well by the paper's criterion but fails on indoor scenes, leaving domain shift as the remaining problem.

What carries the argument

The engine of the speedup is the ONNX-to-TensorRT conversion: TensorRT generates an optimized inference plan that lets the Jetson Nano's 128-core Maxwell GPU execute the network, whereas the ONNX model runs far slower on the same hardware. The lane-detection network itself is Ultra Fast Lane Detection, which treats lane detection as a row-based selection problem with a lightweight ResNet backbone, so the whole frame does not need expensive per-pixel segmentation. A second mechanism is multicore processing on the quad-core ARM CPU: image capture runs on a separate core from inference, and the camera buffer is set to one frame, which removes the delay where the system would otherwise read a stale frame.

What would settle it

Run the converted TensorRT model on the labeled TuSimple or CULane test sets and compute the standard accuracy or intersection-over-union metric; if the score is near chance, the claim of good outdoor accuracy fails. Independently, time inference on a fresh Jetson Nano under normal operating temperature and camera load; sustained per-frame times well above 105 ms would falsify the real-time speed claim.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central claim is that TensorRT conversion plus CPU multicore processing makes the Ultra Fast Lane Detection algorithm practical on a Jetson Nano, with inference times of approximately 101 ms on CULane and 105 ms on TuSimple, about 22 times faster than the ONNX model. A corollary is that a low-power autonomous robot can process camera frames at roughly 9 to 10 frames per second, enough to avoid buffering when the camera frame rate is matched to the inference time. The paper also claims that the pretrained model is accurate on outdoor highway scenes but not on indoor scenes, and attributes the gap to differences in lane shape and to noise such as reflections.

Load-bearing premise

The accuracy part of the claim rests on a self-defined rule—a frame counts as detected when both left and right lanes are visible and not deviating—with no ground-truth labels or overlap metric, so if that rule is too forgiving, the reported accuracy no longer holds even though the speed numbers could still be right.

Editorial extensions

If this is right

  • A Jetson Nano can serve as the inference computer for a real-time lane-following robot, at roughly 9 to 10 frames per second.
  • Matching the camera frame rate to the inference time and setting the buffer to one frame removes stale-image delays during capture.
  • The same pretrained model cannot be dropped into a different environment; indoor deployment needs transfer learning or fine-tuning.
  • The TensorRT speed advantage is large enough (about 22 times) that deployment, not algorithm design, is the main bottleneck for low-power use.

Reading between the lines

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

  • A natural next experiment is an end-to-end closed-loop test: let the robot steer from the detected lanes and measure lateral error, since the paper only reports per-frame detection, not control performance.
  • The speed comparison uses a single ONNX baseline on the same hardware; timing a well-tuned alternative runtime would make the comparison even fairer, though the magnitude of the speedup suggests the conclusion is robust.
  • The indoor failure mode implies a data-collection recipe: annotate indoor floors with lane-style markings and fine-tune the later layers, which is a cheaper path than redesigning the network.
  • Because the accuracy criterion is non-standard, reporting a standard metric such as intersection-over-union on the public datasets would let other groups compare directly with this deployment.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

Summary. The paper reports an implementation study of the Ultra Fast Lane Detection (UFLD) algorithm on a Jetson Nano for the SEATER autonomous mobile robot. The authors convert two pre-trained ONNX models (TuSimple and CULane variants) to TensorRT, deploy them on the Jetson Nano with CPU/GPU multicore separation, and report processing speeds of about 101 ms (CULane) and 105 ms (TuSimple) versus roughly 2,280-2,295 ms for the ONNX baseline, a factor of about 22. They also evaluate accuracy on an outdoor highway video dataset and an internally collected indoor dataset using a binary 'detected/undetected' criterion, concluding that outdoor performance is good while indoor performance is poor, motivating future fine-tuning.

Significance. If the reported speed figures are reliable, the paper demonstrates that a modern lane-detection network can run at approximately 9-10 frames per second on a low-power Jetson Nano, a practically useful rate for a slowly moving indoor/outdoor mobile robot. The honest reporting of poor indoor accuracy and the explicit suggestion of transfer learning are useful. The paper also provides implementation artifacts (ONNX-to-TensorRT conversion, multicore processing) that can help practitioners reproduce the deployment. However, the central quantitative claims currently rest on sparse experimental evidence: single latency measurements without variance, an unspecified ONNX execution context, and a subjective binary accuracy criterion with no ground-truth comparison. The significance would be much stronger if the speed and accuracy evaluations met standard benchmarking practice.

major comments (4)
  1. [Section III, Table I] The speed comparison is not reproducible because the manuscript does not report the experimental protocol: number of repeated trials, mean/standard deviation, warmup policy, TensorRT precision (FP32/FP16/INT8), input resolution, or the execution provider used for the ONNX baseline. On a Jetson Nano, onnxruntime may default to CPU unless a CUDA/TensorRT execution provider is selected, so the 22x figure could be a CPU-versus-GPU comparison rather than a measure of TensorRT optimization. Please provide repeated measurements with error bars, state the exact ONNX runtime configuration, and report the TensorRT precision and input dimensions.
  2. [Section III, Table II] The accuracy evaluation uses a self-defined binary criterion ('if both the left and right lanes are detected, even if imperfectly, but their direction is not deviating') with no annotated ground truth, no intersection-over-union or per-frame accuracy metric, and no comparison against a baseline. The table format is also difficult to parse because the column headers are repeated and the count of rows per condition is unclear. To support the claim that the model 'performs well' on outdoor data, the authors should report a quantitative detection rate (e.g., percentage of frames meeting the criterion) and, ideally, precision/recall against manual annotations on a held-out subset.
  3. [Section II and Section III, multicore processing] The claimed contribution of multicore CPU processing to avoid buffering/delay is described only at a high level (splitting image reading from inference onto different cores). No thread implementation details, core-affinity choices, or quantitative evidence of buffering reduction (e.g., frame timestamps, drop rate, or latency distribution) are provided. Since this is presented as part of the speed optimization, please include a concrete description of the threading architecture and measurements that demonstrate the claimed benefit.
  4. [Section III, first paragraph] The source and exact configuration of the ONNX model used as the baseline are not specified. The manuscript references an ONNX inference example [17], but does not state the UFLD backbone variant (ResNet-18 or ResNet-34), the input resolution expected by the model, or the preprocessing pipeline. These details are load-bearing for reproducing both the 2,295/2,280 ms baseline times and the 105/101 ms TensorRT times.
minor comments (5)
  1. [Table II heading] The heading 'PRETRAINING MODEL ACCURATION' contains a typo; it should be 'ACCURACY'.
  2. [Section III, Table II layout] The table layout is confusing because the same column headers ('TuSimple CULane') are repeated for the two datasets, and the row entries are ambiguous. Consider splitting into separate tables for outdoor and indoor, or adding explicit column labels for each dataset and model.
  3. [Section II.B, datasets] The outdoor dataset is described only as highway videos from Pixabay [15]; please specify the number of videos, frame sampling rate, resolution, and the total number of frames used in the experiment. Similarly, describe the indoor dataset acquisition conditions (camera height, resolution, lighting, and number of distinct scenes).
  4. [Conclusion] The conclusion states that TensorRT's 'ability to leverage the Jetson Nano's GPU resources' explains the speedup; this is plausible but should be explicitly tied to the baseline execution configuration (i.e., whether the ONNX model ran on CPU or GPU).
  5. [Throughout] Several figures (Fig. 3, Fig. 4, Fig. 5, Fig. 6) are referenced in the text but not included in the provided manuscript; ensure all figures are present and legible in the final submission, and that each figure is cited in the text.

Circularity Check

1 steps flagged · score 2.0 of 10

Speed benchmark is independent; the accuracy criterion is mildly self-definitional, but no load-bearing circularity.

  1. self definitional [Section III, paragraph following Table II]
    "The criteria for categorizing the lane detection results as either "detected" or "undetected" in this paper are as follows: if both the left and right lanes are detected, even if imperfectly, but their direction is not deviating, they are considered detected. If this condition is not met, the result is considered undetected. Based on Table 2, it can be found that the method performs well on the outdoor dataset, demonstrating high accuracy in lane detection."

    The accuracy claim is not derived from independent ground-truth annotations, intersection-over-union, or any externally defined lane labels. Instead, 'detected' is defined by the very condition being tested: both left and right lanes are detected. The conclusion that the method 'performs well' therefore largely restates the criterion used to label frames, making the accuracy result a self-defined pass criterion rather than an externally measured prediction. This is a mild evaluation circularity; it does not affect the speed benchmark, which is measured independently.

full rationale

The central speed claim (ONNX 2,280/2,295 ms versus TensorRT 101/105 ms) is an empirical runtime comparison on fixed Jetson Nano hardware using public pretrained models, and no fitted parameter or self-citation is needed to produce it. References [1] and [2] are prior SEATER and navigation work by the co-authors, but they are not load-bearing for the lane-detection speed or accuracy conclusions. The only circular flavor is the Section III accuracy criterion, which defines 'detected' as both lanes being detected and then reports high accuracy from the same criterion. That weakens the accuracy result as a validity claim, but it does not make the speed benchmark circular; the ONNX baseline execution details are a benchmarking-correctness concern, not a circularity one. Overall, this is a minor self-definitional issue in the accuracy evaluation, not a derivation equivalent to its input.

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

The central speed claim needs no fitted constants. The only hand-tuned value is the camera buffer size. The accuracy claim rests on the assumption that the pretrained models transfer to the test videos and that the self-defined visual criterion is meaningful; both assumptions are untested.

free parameters (1)
  • camera buffer size = 1
    Set to 1 based on experiments ('the most optimal value is 1') to avoid camera read buffering delays; this is a hand-tuned implementation parameter, not a model parameter.
assumptions (3)
  • domain assumption The ONNX checkpoints for TuSimple and CULane are faithful to the original Ultra Fast Lane Detection models and preserve accuracy through TensorRT conversion.
    Section II-B relies on public pretrained models [17] and assumes conversion does not change outputs; no verification of conversion fidelity is provided.
  • domain assumption The outdoor Pixabay highway clips and the indoor BRIN Workshop videos are representative test sets for the intended use.
    Section II-B states the outdoor data is used to validate accuracy because the pretraining was on outdoor images, but no ground-truth labels are used for either dataset.
  • domain assumption Single latency measurements in Table I are stable and representative of the Jetson Nano's performance under the described conditions.
    Section III reports one number per condition with no repeated trials, error bars, or mention of thermal or power state.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Implementation of Real-Time Lane Detection on Autonomous Mobile Robot." pith.science (2026). https://pith.science/paper/5E4MPWQ7

@misc{pith2026241114873,
  author       = {Pith},
  title        = {Pith review of: Implementation of Real-Time Lane Detection on Autonomous Mobile Robot},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/5E4MPWQ7}},
  note         = {Machine review of arXiv:2411.14873}
}
read the original abstract

This paper describes the implementation of a learning-based lane detection algorithm on an Autonomous Mobile Robot. It aims to implement the Ultra Fast Lane Detection algorithm for real-time application on the SEATER P2MC-BRIN prototype using a camera and optimize its performance on the Jetson Nano platform. Preliminary experiments were conducted to evaluate the algorithm's performance in terms of data processing speed and accuracy using two types of datasets: outdoor using a public dataset and indoor using an internal dataset from the indoor area of the BRIN Workshop Building in Bandung. The experiments revealed that the algorithm runs more optimally on the Jetson Nano platform after conversion to TensorRT compared to the ONNX model, achieving processing speeds of approximately 101 ms using CULane and 105 ms using TuSimple, which is about 22 times faster than the previous model. While the algorithm demonstrates good accuracy on the outdoor public dataset, its performance falls short on the indoor dataset. Future work should focus on transfer learning and fine-tuning to enhance indoor lane detection accuracy.

Figures

Figures reproduced from arXiv: 2411.14873 by the authors.

Figure 3
Figure 3. Fig.3. Overall architecture of Ultra Fast Lane Detection [10] [PITH_FULL_IMAGE:figures/full_fig_p002_3.png] view at source ↗
Figure 2
Figure 2. illustrates the SEATER prototype, which consists of two driving wheels connected to drive motors, two supporting omnidirectional wheels, a circuit, a data processing unit, a data communication media, and several sensors including a camera, which serves as the primary sensor for the autonomous navigation system. The primary objective of this paper is to conduct preliminary experiments evaluating the performance of th… view at source ↗
Figure 7
Figure 7. Example of the interface of the lane detection [PITH_FULL_IMAGE:figures/full_fig_p003_7.png] view at source ↗
Figures from the paper (1 more)
Figure 6
Figure 6. Figure 6: Optimizing resource on Jetson Nano III. RESULTS AND DISCUSSION A Python-based implementation code has been developed based on the methodologies presented in the references [16] [17]. The implementation includes three primary programs: the lane detection application, a …

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

17 extracted references · 15 canonical work pages

  1. [16]

    GitHub - MaybeShewill-CV/lanenet-lane-detection: Unofficial implemention of lanenet model for real time lane detection

    “GitHub - MaybeShewill-CV/lanenet-lane-detection: Unofficial implemention of lanenet model for real time lane detection.” https://github.com/MaybeShewill-CV/lanenet-lane- detection?tab=readme-ov-file (accessed Jun. 21, 2024)

    work page 2024

  2. [15]

    6.000+ Video, Klip HD & 4K Jalan Raya & Jalan Gratis - Pixabay

    “6.000+ Video, Klip HD & 4K Jalan Raya & Jalan Gratis - Pixabay.” https://pixabay.com/id/videos/search/jalan raya/ (accessed Jun. 21, 2024)

    work page 2024

  3. [17]

    GitHub - ibaiGorordo/onnx-Ultra-Fast-Lane-Detection-Inference: Example scripts for the detection of lanes using the ultra fast lane detection model in ONNX

    “GitHub - ibaiGorordo/onnx-Ultra-Fast-Lane-Detection-Inference: Example scripts for the detection of lanes using the ultra fast lane detection model in ONNX.” https://github.com/ibaiGorordo/onnx- Ultra-Fast-Lane-Detection-Inference (accessed Jun. 21, 2024)

    work page 2024

  4. [1]

    Autonomous Docking Method via Non-linear Model Predictive Control,

    R. P. Saputra, M. Mirdanies, E. J. Pristianto, and D. Kurniawan, “Autonomous Docking Method via Non-linear Model Predictive Control,” Proceeding - 2023 Int. Conf. Radar, Antenna, Microwave, Electron. Telecommun. Empower. Glob. Prog. Innov. Electron. Telecommun. Solut. a Sustain. Futur. ICRAMET 2023 , pp. 331–336, 2023, doi: 10.1109/ICRAMET60171.2023.10366563

    arXiv 2023

  5. [2]

    ROS-based multi-sensor integrated localization system for cost- effective and accurate indoor navigation system,

    A. S. Irwansyah, B. Heryadi, D. K. Dewi, R. P. Saputra, and Z. Abidin, “ROS-based multi-sensor integrated localization system for cost- effective and accurate indoor navigation system,” Int. J. Intell. Robot. Appl., pp. 1–19, Jun. 2024, doi: 10.1007/S41315-024-00350- 1/TABLES/2

    work page doi:10.1007/s41315-024-00350- 2024

  6. [3]

    Map- Matching-Based Localization Using Camera and Low-Cost GPS For Lane-Level Accuracy,

    R. Sadli, M. Afkir, A. Hadid, A. Rivenq, and A. Taleb-Ahmed, “Map- Matching-Based Localization Using Camera and Low-Cost GPS For Lane-Level Accuracy,” Procedia Comput. Sci., vol. 198, pp. 255–262, Jan. 2022, doi: 10.1016/J.PROCS.2021.12.237

    work page doi:10.1016/j.procs.2021.12.237 2022

  7. [4]

    An efficient approach for highway lane detection based on the Hough transform and Kalman filter,

    S. Kumar, M. Jailia, and S. Varshney, “An efficient approach for highway lane detection based on the Hough transform and Kalman filter,” Innov. Infrastruct. Solut. 2022 75 , vol. 7, no. 5, pp. 1–24, Jul. 2022, doi: 10.1007/S41062-022-00887-9

    work page doi:10.1007/s41062-022-00887-9 2022

  8. [5]

    Practical limitations of lane detection algorithm based on Hough transform in challenging scenarios,

    Q. Huang and J. Liu, “Practical limitations of lane detection algorithm based on Hough transform in challenging scenarios,” Int. J. Adv. Robot. Syst., vol. 18, no. 2, Apr. 2021, doi: 10.1177/17298814211008752/ASSET/IMAGES/LARGE/10.1177_17 298814211008752-FIG11.JPEG

    work page doi:10.1177/17298814211008752/asset/images/large/10.1177_17 2021

Show all 17 references
  1. [6]

    Towards End-to-End Lane Detection: An Instance Segmentation Approach,

    D. Neven, B. De Brabandere, S. Georgoulis, M. Proesmans, and L. Van Gool, “Towards End-to-End Lane Detection: An Instance Segmentation Approach,” IEEE Intell. Veh. Symp. Proc. , vol. 2018- June, pp. 286–291, Oct. 2018, doi: 10.1109/IVS.2018.8500547

    2018

  2. [7]

    Spatial as Deep: Spatial CNN for Traffic Scene Understanding,

    X. Pan, J. Shi, P. Luo, X. Wang, and X. Tang, “Spatial as Deep: Spatial CNN for Traffic Scene Understanding,” doi: 10.5555/3504035.3504926

  3. [8]

    RESA: Recurrent Feature-Shift Aggregator for Lane Detection,

    T. Zheng et al., “RESA: Recurrent Feature-Shift Aggregator for Lane Detection,” Proc. AAAI Conf. Artif. Intell. , vol. 35, no. 4, pp. 3547– 3554, May 2021, doi: 10.1609/AAAI.V35I4.16469

    2021 doi

  4. [9]

    CurveLane- NAS: Unifying Lane-Sensitive Architecture Search and Adaptive Point Blending,

    H. Xu, S. Wang, X. Cai, W. Zhang, X. Liang, and Z. Li, “CurveLane- NAS: Unifying Lane-Sensitive Architecture Search and Adaptive Point Blending,” Lect. Notes Comput. Sci. (including Subser. Lect. Notes Artif. Intell. Lect. Notes Bioinformatics) , vol. 12360 LNCS, pp. 689– 704,...

    2020 doi

  5. [10]

    Ultra Fast Structure-Aware Deep Lane Detection,

    Z. Qin, H. Wang, and X. Li, “Ultra Fast Structure-Aware Deep Lane Detection,” Lect. Notes Comput. Sci. (including Subser. Lect. Notes Artif. Intell. Lect. Notes Bioinformatics) , vol. 12369 LNCS, pp. 276– 291, 2020, doi: 10.1007/978-3-030-58586-0_17

    2020 doi

  6. [11]

    GitHub - TuSimple/tusimple-benchmark: Download Datasets and Ground Truths: https://github.com/TuSimple/tusimple- benchmark/issues/3

    “GitHub - TuSimple/tusimple-benchmark: Download Datasets and Ground Truths: https://github.com/TuSimple/tusimple- benchmark/issues/3.” https://github.com/TuSimple/tusimple- benchmark (accessed Aug. 19, 2024)

    2024

  7. [12]

    CULane Dataset

    “CULane Dataset.” https://xingangpan.github.io/projects/CULane.html (accessed Aug. 19, 2024)

    2024

  8. [13]

    TensorRT Implementations of Model Quantization on Edge SoC,

    Y. Zhou, Z. Guo, Z. Dong, and K. Yang, “TensorRT Implementations of Model Quantization on Edge SoC,” Proc. - 2023 16th IEEE Int. Symp. Embed. Multicore/Many-Core Syst. MCSoC 2023, pp. 486–493, 2023, doi: 10.1109/MCSOC60832.2023.00078

    2023

  9. [14]

    TensorRT SDK | NVIDIA Developer

    “TensorRT SDK | NVIDIA Developer.” https://developer.nvidia.com/tensorrt (accessed Jun. 21, 2024)

    2024

Pith tools

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