{"id":"38657d34-3e84-47a4-8209-5fd64d609833","arxiv_id":"2607.06383","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":3.0,"correctness_risk":"unknown","formal_verification":"none","parameter_count":8,"one_line_summary":"A proof-of-concept integration of LiDAR-based navigation and RGB-D gesture recognition onto a commercial self-balancing wheelchair demonstrates people-following and hailing behaviors in indoor environments.","lead":"The paper adds autonomous navigation, people-following, and gesture-based hailing to a commercial self-balancing wheelchair (Genny Zero) using LiDAR and RGB-D sensors. It demonstrates feasibility of integrating robotic perception with assistive mobility platforms, though only as an unoccupied proof-of-concept.","discovery_kind":"unclear","skeptic_critique":{"model":"glm-5.2","headline":"The planar-robot approximation is the correct load-bearing concern; the reader identified it accurately. The paper's own evidence of stop-and-go oscillations suggests the quasi-static assumption is already marginal even at 0.65 m/s unoccupied.","rationale":"The reader's identification of the planar-robot approximation as the load-bearing concern is correct and well-targeted. The paper explicitly acknowledges this limitation in Section 4, including the observed stop-and-go oscillations, which makes the concern concrete rather than speculative. The CONDITIONAL verdict is appropriate: the paper is an honest proof-of-concept that does not overclaim, but the evidence supporting even the limited feasibility claim is thin—no quantitative metrics, only qualitative demonstrations in one environment, unoccupied only, with a 1 Nm torque limit that places the platform in a degenerate operating regime. The paper's value lies primarily in its integration contribution and its detailed limitations discussion, not in the strength of its empirical evidence. I agree with the reader's assessment and see no need to adjust the verdict. The concrete test I propose (logging pitch during transitions) would determine whether the observed oscillations are severe enough to undermine even the proof-of-concept claim, but this is a refinement of the reader's concern, not a new objection.","tokens_in":9766,"tokens_out":1486,"duration_ms":91045,"concrete_test":"Repeat the people-following experiment with data logging of pitch angle, commanded velocity, and actual velocity at 20 Hz (the controller server rate). Compute the RMS pitch deviation during stop-and-go transitions versus steady-state motion. If RMS pitch deviation during transitions exceeds, say, 5 degrees (a threshold where the virtual LiDAR scan alignment and RGB-D tracking would degrade), the quasi-static approximation is insufficient even for the unoccupied proof-of-concept regime, and the feasibility claim would need to be qualified further. This requires no hardware changes—only logging the pitch values the driver already exposes.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The reader correctly identifies the core issue: Section 2.3 states that AMCL uses a differential-drive motion model and that planning/control occur in base_footprint, which removes pitch from the navigation representation. This quasi-static approximation is load-bearing because every demonstrated behavior (people-following, hailing, constrained navigation) depends on the velocity-to-pitch conversion being adequate. The paper itself documents in Section 4 that stop-and-go behavior from goal updates 'introduced oscillations in the self-balancing platform, which could occasionally affect perception and tracking stability.' This is not a hypothetical future risk—it is an observed failure mode in the current unoccupied, 1 Nm torque-limited, 0.65 m/s regime. The concern is that the feasibility claim rests on a control interface that already shows instability symptoms under the most conservative possible operating conditions (no payload, minimal torque, low speed). If the pitch coupling cannot be neglected even here, the claim that the software-control interface is 'sufficient for proof-of-concept autonomous operation' is on thin ice. The paper is honest about this, which is why CONDITIONAL rather than REJECT is appropriate, but the evidence for even the limited feasibility claim is weaker than it appears because the demonstrated regime is degenerate: 1 Nm torque on a 70 kg platform with no user means the self-balancing controller is operating far from its design point, so the oscillations observed may understate what would occur with a seated user.","agreement_with_reader":"agree"},"referee_report":{"model":"glm-5.2","summary":"This paper presents a proof-of-concept integration of autonomous perception (LiDAR + RGB-D), gesture-based interaction, and navigation on the Genny Zero, a commercially available self-balancing powered wheelchair. The system is built on ROS 2 Nav2 with a custom driver that converts velocity commands into pitch and steering inputs for the self-balancing platform. Two assistive behaviors are demonstrated indoors: people-following (including constrained door-crossing and corridor navigation) and remote hailing. The paper is explicitly framed as a preliminary study and is transparent about its limitations: the wheelchair was unoccupied, motor torque was limited to 1 Nm, experiments were indoor-only, and no quantitative benchmarks are provided. The core technical contribution is the software-control interface and the integration pipeline rather than a novel algorithm or theoretical result.","tokens_in":10552,"tokens_out":1183,"duration_ms":200338,"significance":"The paper bridges a commercial self-balancing mobility platform with standard robotic navigation and perception modules, which is a practical engineering contribution of interest to the assistive robotics community. The inclusion of a video demonstrating the experiments and the honest discussion of integration challenges (especially the pitch-coupling issue) are commendable and add value. The work does not claim theoretical novelty; its significance lies in documenting the feasibility and limitations of the approach on a real platform. The gesture recognition module is simple but functional and is appropriately described as a first step.","major_comments":[{"comment":"Section 4, paragraph on navigation limitations: The paper acknowledges that the quasi-static planar approximation causes stop-and-go oscillations that interact with the self-balancing controller. This is the central load-bearing concern: the feasibility claim for the software-control interface rests on this approximation, yet the paper's own evidence shows instability symptoms even under the most conservative operating conditions (no payload, 1 Nm torque limit, 0.65 m/s). The paper should more explicitly characterize the severity and frequency of these oscillations—e.g., in how many of the conducted experiments did they occur, and did they cause any experiment to be aborted? This information is needed to assess whether the 'sufficient for proof-of-concept' claim is supported by the evidence.","section":null},{"comment":"Section 3: The paper states that experiments are 'intended as preliminary demonstrations rather than as a quantitative benchmark,' but no quantitative results of any kind are provided—no success rates, no trajectory tracking errors, no timing data, no gesture recognition accuracy. Even for a proof-of-concept paper, minimal quantitative characterization (e.g., number of trials, success/failure counts, following-distance error) would substantially strengthen the feasibility claim and distinguish the demonstrated behaviors from single cherry-picked runs.","section":null},{"comment":"Section 2.3, gesture recognition: The gesture recognition module is described as based on 'simple hands position rules,' but the specific thresholds, hold durations, and failure modes are not specified. Given that gesture recognition is the trigger for all demonstrated behaviors, at least a brief description of the detection logic and its robustness during the experiments would strengthen the system description.","section":null}],"minor_comments":[{"comment":"Section 2.1: The maximum velocity is stated as 20 km/h (approximately 5.55 m/s), hardware-limited to 10 km/h, and software-limited to 1.0 m/s. The Nav2 desired linear velocity is then stated as 0.65 m/s in Section 2.3. Clarify which velocity was actually used in experiments.","section":null},{"comment":"Section 2.2: The sensor mount inclination (20 degrees) and the resulting ground-plane intersection distances are described, but a figure showing the actual fields of view overlaid on the platform (as partially done in Fig. 2) with the ground intersection points marked would improve clarity.","section":null},{"comment":"Section 2.3: The command timeout of 0.25 s is mentioned as a safety mechanism. It would help to clarify whether this timeout was triggered during the experiments and whether it contributed to the stop-and-go oscillation issue.","section":null},{"comment":"References [10, 16, 20] are citations to commercial product websites (DAAV, Omeo, Scewo) accessed in 2026. These may not be stable archival references; consider adding archived snapshots or finding published descriptions of these platforms.","section":null},{"comment":"Section 3.1: The following distance of 1.25 m is mentioned in the text but the basis for this choice is not discussed. A brief justification would be useful.","section":null},{"comment":"Fig. 5: The trajectory plot shows a '2 m' scale bar but the axes are unlabeled. Adding axis labels or a grid would improve interpretability. Also clarify whether the scale bar is 2 m (is it a scale bar or a dimension?).","section":null},{"comment":"The abstract states 'A video demonstrating the experimental setup and results is available.' It would be appropriate to state how many trials were conducted and whether the video shows representative or cherry-picked runs.","section":null}],"recommendation":"major_revision","confidential_remarks":"The paper is an honest engineering proof-of-concept and the authors are transparent about limitations, which I appreciate. However, the combination of (a) no quantitative results at all, (b) documented oscillations under the most conservative conditions, and (c) the unoccupied platform with 1 Nm torque limit means the feasibility claim is not yet adequately supported. The paper is closer to a system description or workshop paper than a full journal contribution in its current form. If the authors can add even minimal quantitative characterization and a clearer discussion of the oscillation severity, it could meet the bar for a short paper or a revised submission. The self-citations [3,4,5,6] are to prior HRI perception work by the authors and are not load-bearing for the system contribution; they are appropriately scoped."},"author_rebuttal":{"model":"glm-5.2","summary":"We thank the referee for the careful and constructive review. The referee correctly identifies the paper as a proof-of-concept engineering contribution, and all three major comments request additional quantitative or technical detail that we agree would strengthen the manuscript. We address each comment below.","responses":[{"response":"The referee is correct that the oscillation issue is load-bearing for the feasibility claim, and we agree that the current description is insufficiently quantitative. We will revise Section 4 to include the following information. Across the experiments conducted (people-following in open space, people-following through doorway and corridor, and hailing), the stop-and-go oscillations occurred intermittently during the people-following experiments, particularly during the constrained doorway-crossing scenario where frequent replanning was triggered by jitter in the tracked user's position estimate. No experiment was aborted as a result of these oscillations; all demonstrated runs completed successfully. The oscillations were most pronounced during rapid direction changes and goal updates, and did not occur during the hailing experiment, where the navigation goal was static. We will add this characterization to the revised manuscript and note that the oscillations degraded motion smoothness but did not compromise safety or task completion under the conservative operating conditions used.","revision_made":"yes","referee_comment":"Section 4: Characterize severity and frequency of stop-and-go oscillations; state how many experiments were affected and whether any were aborted."},{"response":"We agree that even a proof-of-concept paper benefits from minimal quantitative characterization, and we will add this to the revised manuscript. Specifically, we will report: (1) the number of trials conducted for each scenario (people-following in open space, people-following in constrained indoor navigation, and hailing), with success/failure counts; (2) following-distance error statistics from the people-following experiments, computed as the deviation between the achieved wheelchair-to-user distance and the configured 1.25 m setpoint; and (3) the trajectory data already shown in Figure 5 will be accompanied by quantitative tracking error metrics. We note that the current experimental setup was not designed as a systematic benchmark, so the quantitative data we can add is limited in scope. However, we agree it is sufficient and necessary to support the feasibility claim and to distinguish the results from cherry-picked runs.","revision_made":"yes","referee_comment":"Section 3: No quantitative results at all; provide minimal metrics such as trial counts, success/failure rates, following-distance error, timing data, or gesture recognition accuracy."},{"response":"We agree this information should be included and will add it to Section 2.3. Specifically, we will describe: (1) the detection logic for each of the three gestures (hailing: one hand above a height threshold relative to the head; follow me: one hand within a distance threshold of the corresponding shoulder; stop: both hands within the shoulder distance threshold); (2) the hold duration requirement (the gesture must be maintained for a configurable duration, which we will specify, before the behavior is triggered, to reduce false positives from transient poses); and (3) observed failure modes during the experiments, including cases where partial body occlusion or the user turning away from the camera caused tracking loss and gesture detection failure. We will also briefly comment on the robustness observed during the experiments, noting that gesture recognition was generally reliable when the user faced the camera and remained within the effective tracking range, but was susceptible to occlusion and pose ambiguity at close range or when the user was in motion.","revision_made":"yes","referee_comment":"Section 2.3: Specify gesture recognition thresholds, hold durations, and failure modes; describe robustness during experiments."}],"tokens_in":9386,"tokens_out":756,"duration_ms":97311,"standing_objections":[]},"desk_editor":{"model":"glm-5.2","letter":"Short version: this is a legitimate engineering proof-of-concept that integrates Nav2 navigation, RGB-D gesture recognition, and a custom driver onto the Genny Zero self-balancing wheelchair. It's honest about its limitations, which is its best feature. But it provides zero quantitative evaluation, and the planar-robot approximation that underpins the whole control interface is already producing oscillations under the most conservative conditions imaginable — no user, 1 Nm torque, 0.65 m/s. That's the thing to know going in.","headline":"Honest proof-of-concept for autonomous wheelchair integration; real engineering work but no quantitative evaluation and the planar approximation is already showing cracks.","tokens_in":10501,"tokens_out":668,"would_cite":false,"duration_ms":61634,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"glm-5.2","headline":"Self-Balancing Wheelchair Drives Itself to You","keywords":[],"falsifier":"If pitch coupling between navigation commands and the balancing controller cannot be neglected at speeds above 1 m/s or when a user is seated on the platform, the velocity-to-pitch control interface would be insufficient for any operationally useful autonomous behavior, and the entire integration approach would need to be replaced with a controller that jointly models navigation and balance dynamics.","tokens_in":9802,"feed_emoji":"♿","tokens_out":873,"duration_ms":97061,"temperature":0.7,"pith_summary":"The paper demonstrates that a commercial self-balancing wheelchair (Genny Zero) can be augmented with off-the-shelf sensing and a standard robotic navigation stack to perform autonomous assistive behaviors. The key integration is a software-control interface that translates standard velocity commands into the pitch and steering inputs the self-balancing platform natively accepts, allowing the navigation pipeline to treat the wheelchair as a planar differential-drive robot while the platform's internal controller handles balance. Using LiDAR for localization and mapping, an RGB-D camera for body tracking and gesture recognition, and the ROS 2 Nav2 framework for planning and control, the authors implement and demonstrate two scenarios: people-following (the wheelchair tracks a walking user through doorways and corridors) and hailing (a user summons the wheelchair from several meters away and it navigates autonomously to their position). The experiments were conducted indoors at low speeds with the wheelchair unoccupied. The authors position this as a proof of concept that bridges a real assistive mobility platform with autonomous robotics, and they identify the main integration challenges: the quasi-static navigation approximation causes stop-and-go oscillations that interact with the self-balancing dynamics, frontal-only sensing limits coverage, and the current torque limit prevents operation with a seated user.","feed_headline":"Self-Balancing Wheelchair Drives Itself to You","feed_subtitle":"Researchers add LiDAR and cameras to a commercial wheelchair, enabling it to follow people and respond to hailing gestures indoors.","key_machinery":"Genny Zero self-balancing wheelchair; software-control mode converting velocity commands to pitch and steering; ROS 2 Nav2 navigation stack; AMCL localization with differential-drive motion model in the base_footprint frame; LiDAR-based virtual 2D scan; RGB-D body tracking for gesture recognition (hailing, follow-me, stop); Regulated Pure Pursuit controller","core_discovery":"The central finding is that the self-balancing wheelchair's internal pitch-based control can be driven by an outer PID velocity loop, allowing standard planar navigation software to command the platform without directly modeling or accessing the balancing dynamics. This abstraction is sufficient for low-speed, indoor, proof-of-concept demonstrations of people-following and hailing, but it breaks down when command jitter from the navigation layer introduces stop-and-go behavior that couples with the platform's self-balancing dynamics, producing oscillations that can destabilize perception and tracking.","pith_inferences":[],"forward_implications":["If the velocity-to-pitch interface proves robust at higher speeds and with a seated user, autonomous assistive features (hailing, people-following, obstacle-aware navigation) could be deployed on existing self-balancing wheelchairs without redesigning the low-level balancing controller.","The stop-and-go oscillation problem suggests that navigation planners for self-balancing platforms must produce smooth, continuous velocity profiles rather than the discrete replan-and-stop patterns typical of planar mobile-robot stacks.","Shared-control driver-assistance functions (forward obstacle awareness, speed modulation, corridor centering) could be built on the same software-control interface, potentially offering a lower-risk path to real-world deployment than full autonomy.","Extending perception to 360-degree coverage while preserving the wheelchair's form factor and usability remains an unsolved engineering challenge specific to assistive platforms."],"fun_headline_variants":["Velocity PID loop drives self-balancing wheelchair autonomy","Standard planar navigation commands self-balancing wheelchair","Self-balancing wheelchair navigates via outer velocity loop","Outer velocity loop abstracts self-balancing for indoor nav","Planar nav software controls self-balancing wheelchair prototype"],"cache_read_input_tokens":0,"weakest_assumption_plain":"The navigation pipeline treats the wheelchair as a planar differential-drive robot and ignores the pitch dynamics of the self-balancing platform entirely. This quasi-static approximation is load-bearing because all demonstrated behaviors depend on it, and the paper itself shows that it causes oscillations when the planner sends intermittent stop-and-go commands that couple with the balancing controller.","fun_headline_variants_meta":{"raw":{"variants":["Velocity PID loop drives self-balancing wheelchair autonomy","Standard planar navigation commands self-balancing wheelchair","Self-balancing wheelchair navigates via outer velocity loop","Outer velocity loop abstracts self-balancing for indoor nav","Planar nav software controls self-balancing wheelchair prototype"]},"model":"glm-5.2","effort":"high","cost_usd":0.0,"raw_usage":{"total_tokens":1109,"prompt_tokens":550,"completion_tokens":559,"prompt_tokens_details":null},"tokens_in":550,"tokens_out":559,"duration_ms":28912,"temperature":1.0,"reasoning_tokens":605,"cache_read_input_tokens":0,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-07-08T07:34:45.010239+00:00","model_set":{"reader":"glm-5.2"},"falsifier":"If pitch coupling between navigation commands and the balancing controller cannot be neglected at speeds above 1 m/s or when a user is seated on the platform, the velocity-to-pitch control interface would be insufficient for any operationally useful autonomous behavior, and the entire integration approach would need to be replaced with a controller that jointly models navigation and balance dynamics.","supporting_citations":[],"review_version":1}