{"id":"999e18e3-d6f1-4a43-9f3b-2bb947a00d10","arxiv_id":"2411.14873","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":2.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"Converting the Ultra Fast Lane Detection model to TensorRT on a Jetson Nano cuts inference time roughly 22x, but indoor lane detection remains inaccurate.","lead":"This paper puts a known lane-detection AI onto a small robot computer and speeds it up by converting the model to NVIDIA's optimized format. It processes images in about 100 milliseconds instead of 2.3 seconds, but it works outdoors and misses indoor lanes.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The ~22x TensorRT speedup rests on an unspecified ONNX baseline; if that baseline used CPU-only onnxruntime, the comparison is CPU-vs-GPU rather than evidence of TensorRT optimization, and the 101/105 ms figures lack the repeated-measurement detail needed to support a real-time claim.","rationale":"The reader identifies the subjective accuracy criterion as the weakest assumption, and that concern is valid: Table II reports checkmarks without counts, ground truth, or IoU/F1, so the 'good accuracy' sentence is unsupported. However, the strongest claim as stated is the speed claim, and the most load-bearing threat to that claim is the uncontrolled ONNX baseline. A 22x speedup is far larger than typical TensorRT-vs-ONNX gains when both use the GPU; the likely explanation is that the ONNX baseline ran on CPU. That would not disprove the final system's ~9-10 fps capability, but it would invalidate the headline comparison. Because the manuscript also omits measurement protocol details, the absolute latency cannot be independently checked. The right outcome remains CONDITIONAL as the reader concluded: the paper is a preliminary engineering report whose speed and accuracy conclusions both need reproducible, objective validation. Since my concern does not move the verdict, I mark it UNCHANGED, while noting that the conditions should include the ONNX execution-provider comparison and repeated timing measurements, not only the accuracy re-evaluation.","tokens_in":6409,"tokens_out":5801,"duration_ms":62292,"concrete_test":"Re-run the benchmark on the same Jetson Nano with the same pretrained UFLD weights and same input images, measuring per-frame time over e.g. 50 warmup frames plus 500 timed frames, and report mean, median, and standard deviation for: (1) ONNX Runtime with CPU execution provider, (2) ONNX Runtime with CUDA execution provider, (3) TensorRT FP32, and (4) TensorRT FP16. Also state whether the reported milliseconds include camera read, resizing, or post-processing. If conditions (2) and (3) are within about two-fold of each other, the 22x speedup is an artifact of the baseline; if TensorRT remains more than 10x faster than the CUDA ONNX baseline with non-overlapping confidence intervals, the speed claim is sustained.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central quantitative claim is the 22x speedup (2,280 ms to 101 ms for CULane, 2,295 ms to 105 ms for TuSimple in Table I). The manuscript never states how the ONNX baseline was executed. On a Jetson Nano, onnxruntime defaults to CPU unless a CUDA or TensorRT execution provider is selected, and the paper's own resource plan (Fig. 6) assigns GPU work only to the TensorRT path. A CPU-only ONNX baseline would make the 22x factor a CPU-versus-GPU comparison, not a measure of TensorRT's optimization value. The absolute latency may still be near 100 ms, but no number of trials, warmup policy, TensorRT precision (FP32/FP16/INT8), input resolution, or variance is reported. A single 101 ms figure, without error bars, is weak evidence for a stable real-time rate on a platform subject to thermal throttling and frequency scaling.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":6601,"tokens_out":3114,"duration_ms":32385,"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":[{"comment":"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.","section":"Section III, Table I"},{"comment":"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.","section":"Section III, Table II"},{"comment":"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.","section":"Section II and Section III, multicore processing"},{"comment":"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.","section":"Section III, first paragraph"}],"minor_comments":[{"comment":"The heading 'PRETRAINING MODEL ACCURATION' contains a typo; it should be 'ACCURACY'.","section":"Table II heading"},{"comment":"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.","section":"Section III, Table II layout"},{"comment":"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).","section":"Section II.B, datasets"},{"comment":"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).","section":"Conclusion"},{"comment":"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.","section":"Throughout"}],"recommendation":"major_revision","confidential_remarks":"The paper is an engineering report rather than a research contribution with a new algorithmic idea. The central deployment result is plausible but under-validated. The authors should also double-check the relevance of reference [16], which is a LaneNet implementation, while the paper is about Ultra Fast Lane Detection; if used for the image conversion tool, that should be stated explicitly. If the speed baseline is indeed CPU-only, the '22x speedup' claim loses most of its interest, so the revision must clarify the execution context."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: this is a thin engineering report with one useful datapoint—TensorRT conversion gets Ultra Fast Lane Detection to roughly 100 ms per frame on a Jetson Nano—but the measurement reporting is too thin to take the 22x number at face value, and the accuracy evaluation is observational. The paper is honest about its indoor failure and doesn't oversell, so it reads as a preliminary deployment note, not a research result.\n\nWhat's actually here: a straightforward speed comparison between an ONNX runtime and a TensorRT-converted model of UFLD, run on a Jetson Nano using public pretrained TuSimple and CULane models. The reported 101/105 ms figures are in the right ballpark for this class of network and hardware, and the paper's candid admission that indoor detection fails on the currently pretrained model is useful for anyone planning to deploy UFLD indoors. The multicore/buffer adjustment is a minor practical detail, not a contribution.\n\nThe soft spots are real. The ONNX baseline is never specified. If it was onnxruntime with the default CPU execution provider, then the 22x is a CPU-vs-GPU comparison, not a measure of TensorRT's optimization. The paper's own resource figure assigns GPU only to the TensorRT path, which suggests that's exactly what happened. There are no repeated trials, error bars, warmup policy, TensorRT precision, or input resolution reported. A single latency number on a thermally throttling device is weak evidence. The accuracy evaluation in Table II is a binary visual criterion—'both lanes detected and direction not deviating'—with no ground truth or IOU. That's fine for a smoke test, but it doesn't support the phrase 'good accuracy.' Also, no code or data is released, which makes the numbers even harder to check.\n\nOne smaller issue: reference [16] points to a LaneNet implementation, not UFLD, and [15] is a Pixabay video search rather than a formal dataset. Sloppy, but not a substantive problem.\n\nMy take: the core speed result is plausible but under-supported as reported. The paper deserves a serious referee because the datapoint is of real practical interest to people deploying lane detection on low-power robots, and the missing details are fixable. I'd send it to review, but the referee report should be explicit that the ONNX baseline, trial counts, and precision settings are mandatory before the 22x claim can be taken seriously. If the authors can't produce those, this should be rejected.","headline":"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.","tokens_in":7129,"tokens_out":2710,"would_cite":false,"duration_ms":39732,"reading_group":"no","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Lane detection runs 22 times faster after TensorRT conversion.","keywords":["lane detection","autonomous mobile robot","Ultra Fast Lane Detection","TensorRT","Jetson Nano","real-time inference","edge computing","domain shift"],"falsifier":"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.","tokens_in":6229,"feed_emoji":"🚗","tokens_out":4211,"duration_ms":38622,"temperature":0.7,"pith_summary":"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.","feed_headline":"Lane detection runs 22 times faster after TensorRT conversion","feed_subtitle":"A converted model processes road images in about 101–105 ms on a low-power robot computer, hitting near real-time.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the Ultra Fast Lane Detection architecture and row-based formulation that is converted and deployed.","marker":"[10]"},{"why":"Provides the TuSimple highway dataset used to pretrain and test the model.","marker":"[11]"},{"why":"Provides the CULane road dataset used to pretrain and test the model.","marker":"[12]"},{"why":"Motivates TensorRT as a route to faster inference on embedded devices.","marker":"[13]"},{"why":"Is the SDK that performs the ONNX-to-TensorRT conversion.","marker":"[14]"},{"why":"Is the source of outdoor highway videos converted into test frames.","marker":"[15]"},{"why":"Supplies the ONNX inference scripts on which the lane-detection application is based.","marker":"[17]"}],"fun_headline_variants":["Robot lane detection now 22x faster with TensorRT","TensorRT makes lane detection 22x faster on Jetson Nano","Real-time lane detection on robot via TensorRT speedup","From 2.2s to 101ms: lane detection speedup on robot","Jetson Nano lane detection: 22x speedup for real-time"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Robot lane detection now 22x faster with TensorRT","TensorRT makes lane detection 22x faster on Jetson Nano","Real-time lane detection on robot via TensorRT speedup","From 2.2s to 101ms: lane detection speedup on robot","Jetson Nano lane detection: 22x speedup for real-time"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000411,"raw_usage":{"total_tokens":2085,"prompt_tokens":858,"completion_tokens":1227,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":474,"completion_tokens_details":{"reasoning_tokens":1134}},"tokens_in":474,"tokens_out":1227,"duration_ms":10808,"temperature":1.0,"reasoning_tokens":1134,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T14:46:13.601642+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Ultra Fast Structure-Aware Deep Lane Detection,","cited_arxiv_id":null,"evidence_quote":"Supplies the Ultra Fast Lane Detection architecture and row-based formulation that is converted and deployed."},{"cited_title":"GitHub - TuSimple/tusimple-benchmark: Download Datasets and Ground Truths: https://github.com/TuSimple/tusimple- benchmark/issues/3","cited_arxiv_id":null,"evidence_quote":"Provides the TuSimple highway dataset used to pretrain and test the model."},{"cited_title":"CULane Dataset","cited_arxiv_id":null,"evidence_quote":"Provides the CULane road dataset used to pretrain and test the model."},{"cited_title":"TensorRT SDK | NVIDIA Developer","cited_arxiv_id":null,"evidence_quote":"Is the SDK that performs the ONNX-to-TensorRT conversion."},{"cited_title":"6.000+ Video, Klip HD & 4K Jalan Raya & Jalan Gratis - Pixabay","cited_arxiv_id":null,"evidence_quote":"Is the source of outdoor highway videos converted into test frames."},{"cited_title":"GitHub - ibaiGorordo/onnx-Ultra-Fast-Lane-Detection-Inference: Example scripts for the detection of lanes using the ultra fast lane detection model in ONNX","cited_arxiv_id":null,"evidence_quote":"Supplies the ONNX inference scripts on which the lane-detection application is based."}],"review_version":1}