{"id":"8398a8f7-e173-40c4-bc70-61444d8733fe","arxiv_id":"2510.12346","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":8,"one_line_summary":"A humanoid robot climbs unknown stairs by building a real-time polygonal map from fused LiDAR/RGB-D/IMU data and planning footholds on it.","lead":"This paper describes PolygMap, a system that lets a full-size humanoid robot see staircases with LiDAR and depth cameras, plan safe footholds, and climb stairs indoors and outdoors in real time. It is a useful demonstration that online perception, footstep planning, and whole-body locomotion are converging on practical legged stair climbing.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Eq. 31 forces planned foot z to zero: p_f,z = z_t + (−z_t), so the described footstep planner cannot place feet on stair treads at height >0; the paper never couples z_0 to the Sec. III-B foothold height.","rationale":"The reader's weakest-assumption analysis focused on depth-perception reliability, which is plausible and supported by the paper's own admissions about L515 limitations and outdoor failures. However, I find a more fundamental and more easily checkable internal concern in the footstep planner itself. Eq. 31, as written, makes the planned foot's world height identically zero, independent of the target stair height. This is not merely an unstated threshold or an outdoor robustness issue; it is an apparent inconsistency in the core planning formulation. If the actual implementation overwrites p_f,z or uses Eq. 32's z_0 to carry the stair height, then the paper needs to state that explicitly; otherwise, the method description cannot reproduce the claimed stair climbing. This does not disprove the experimental results—they may well be genuine—but it makes the central capability claim conditional on a missing or mis-specified coupling. I therefore keep the verdict CONDITIONAL, with the added condition that the authors clarify or correct the footstep height formulation. I do not fully agree with the reader's choice of weakest assumption, since the perception concern, while real, is secondary to this internal planning inconsistency.","tokens_in":9695,"tokens_out":5927,"duration_ms":52870,"concrete_test":"Evaluate Eq. 31 for the indoor trial: set torso z_t = 0.9 m (typical for a 1.66 m humanoid) and a target stair height of 0.13 m. The formula gives p_f,z = 0, not 0.13. Then trace Eq. 32 and determine whether z_0 is explicitly assigned the foothold height p*_z from Eq. 26. If z_0 is unspecified or independent, the planner as written cannot lift feet to stair height. If the authors clarify that z_0 = p*_z and that Eq. 31's z-component is overridden, the concern is resolved; otherwise, recomputing the foot trajectory for Trial 1 in Table II with p_f,z forced to 0 should show a direct mismatch with the reported climbing sequence.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The central claim requires an internally consistent footstep planner that can place feet on stair treads at increasing heights. The planner as written cannot do this. In Sec. III-C, Eq. 31 sets the foot position as p_f = p_t + R_z(φ_t) b_f, with p_t = [x_t, y_t, z_t, φ_t] and b_f = [0, ±y_b, −z_t]. Since R_z only rotates the x/y components, the world z-component is p_f,z = z_t − z_t = 0. That is, every footstep target has the same world height as the ground plane, regardless of which stair is being targeted. The subsequent sinusoidal Z-trajectory in Eq. 32 has a 'reference landing height' z_0, but the text never defines z_0 as the foothold height from Sec. III-B, and Eq. 31 still reports p_f as the foot pose. For the reported indoor 13 cm steps, a foot placed on the second stair would need z≈0.13 + ground height, not 0. This is not a tuning issue; it is a missing coupling between the foothold height output by Sec. III-B and the footstep planner. Unless Eq. 31 is a typo and the actual implementation overwrites p_f,z with the selected foothold height, the method description is not sufficient to reproduce the claimed stair-climbing results.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents PolygMap, a perception and locomotion framework for humanoid stair climbing. It fuses Point-LIO LiDAR-inertial odometry with joint kinematics through a linear Kalman filter and complementary filtering, builds a polygonal stair map from a downward-facing RGB-D camera via anisotropic diffusion, Sobel normals, Canny/RANSAC plane fitting, converts polygons into dense point clouds with erosion-based foothold candidates, and generates sinusoidal foot trajectories. Validation is performed in Gazebo and on a KUA VO humanoid, with indoor/outdoor stair climbs using double-step and single-step gaits. The paper reports planning rates of 20–30 Hz, footstep errors of 11.4–33.4 mm in real trials, and one documented outdoor toe-collision failure.","tokens_in":10048,"tokens_out":6439,"duration_ms":57787,"significance":"If the described methods work as claimed, the paper makes a useful systems contribution: full-size humanoid robots can climb unknown multi-step staircases online using onboard perception, without pre-mapped models, at planning rates high enough for real-time control. The inclusion of quantitative footstep errors, simulation trials, and a candid description of a failure mode is a strength. However, the support is limited: only five real trials are reported, no failure-rate or variance statistics are given, and the planning formulation in Sec. III-C appears to have a missing coupling between the detected foothold height and the generated foot trajectory. The central idea is plausible, but the manuscript as written does not yet provide a reproducible description.","major_comments":[{"comment":"The footstep planner as written cannot place feet on stair treads. With p_t = [x_t, y_t, z_t, φ_t]^T and b_f = [0, ±y_b, −z_t]^T, Eq. (31) gives p_{f,z} = z_t − z_t = 0 for every footstep. The Z-trajectory in Eq. (32) introduces a 'reference landing height' z_0, but z_0 is never defined as the height of the selected foothold from Sec. III-B, and no equation connects the output p* of Eq. (26) to x_end, y_end, or z_0 in Eqs. (32)–(33). Thus the described pipeline is not sufficient to reproduce the reported climbing of 13 cm steps; either Eq. (31) is a typo or the foothold height from Sec. III-B is never used. This coupling must be specified explicitly.","section":"III-C, Eqs. (31)–(32)"},{"comment":"The foothold generation stage outputs p* (Eq. 26), but the footstep planning stage takes only the torso pose B_t as input (Eq. 29). Neither x_end/y_end in Eq. (33) nor z_0 in Eq. (32) is defined in terms of p* or the polygon map. Consequently, even if Eq. (31)'s z-component were corrected, the text would still not specify how the detected stair geometry determines the target foot placement. The authors should give the explicit mapping from the selected foothold polygon to the footstep target used in Eqs. (31)–(33).","section":"III-B to III-C"},{"comment":"The real-world validation consists of five runs (two indoor DS, three SS, one of which failed). No error bars, confidence intervals, or failure-rate statistics are reported, although the text acknowledges a 'failure rate' for outdoor SS. Given the robot's foot length (26 cm) and the stair tread (28 cm), a 33.4 mm maximum error can be comparable to or greater than the available 20 mm longitudinal margin; the connection between the reported errors and the observed toe collision should be analyzed quantitatively. As it stands, the claim of robustness is stronger than the data support.","section":"IV-C, Table II and Fig. 8"}],"minor_comments":[{"comment":"'footstep planar' should be 'footstep planner'.","section":"Abstract"},{"comment":"The figure contains the typo 'Kallman' for 'Kalman'.","section":"Fig. 3"},{"comment":"'Ontology-Based' appears to be a typo for 'Odometry-Based'.","section":"Fig. 4 caption"},{"comment":"Setting the height of each polygon vertex to zero before computing the 2D convex hull is deliberate, but it may confuse readers; clarify that the original heights are restored in Eq. (18).","section":"III-B, Eq. (14)"},{"comment":"The text says the optimal foothold points provide 'both spatial position and orientation,' but Eq. (26) returns only a position. Specify how the foot yaw is determined.","section":"III-B, last paragraph"},{"comment":"Reference [15] contains a URL with a space ('polygon mapping') and should be formatted correctly.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"The central issue in Eq. (31) may be a manuscript typo rather than an implementation flaw; if the authors can show the coupling between Sec. III-B footholds and the footstep planner, the paper could be acceptable after revision. The lack of statistical validation is a separate concern that can be addressed with more trials or a clearly scoped claim."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"What you should know: the group actually put a full-size humanoid on real staircases with a fused LiDAR, RGB-D, IMU pipeline, polygonal plane extraction, and foothold planning, and it climbed 4 to 6 steps repeatedly, with footstep errors from 11 to 33 mm. They also report a failure mode: outdoor single-step on a protruding edge caused a toe collision. That is more than many perceptive-locomotion papers show, and it should be taken seriously. But the written method has a load-bearing hole: Eq. 31 defines the foot position as p_f = p_t + R_z(phi_t) * [0, +/- y_b, -z_t], so the world z-component is z_t - z_t = 0 every time. As written, the planner cannot place a foot on a 13 cm tread. The paper never ties the foothold height from Sec. III-B to the z_0 in Eq. 32, so this is not a tuning issue; it is a missing coupling. Given that the robot demonstrably climbs stairs, I strongly suspect Eq. 31 is a typo and the implementation overwrites the foot height from the foothold candidate. But the paper as text is not reproducible, and that is a serious flaw.\n\nWhat is genuinely new is the integration. Each module has prior art, but the full stack on a 55 kg humanoid at 20-30 Hz, with real stair results, is not a rehash. The quantitative footstep errors and the honest reporting of the outdoor failure are real evidence. The paper also seems fair in citing related work; I do not see a citation-pattern problem.\n\nSoft spots beyond the Eq. 31 issue: five real trials, no error bars, no failure-rate statistic, no baseline comparison to other stair-climbing methods. The claimed 20-30 Hz whole-body motion planning frequency is supported in the experiments only by plane detection frequency (20-23 Hz), which is not the same thing. Many perception thresholds (g_res, g_z, h_layer, N_erosion, delta_foot, diffusion parameters) are unstated, and the code is promised upon acceptance rather than released now. None of these are fatal by themselves, but combined with the equation bug, the paper is not yet ready to be judged as a trustworthy systems contribution.\n\nWho is this for? People working on perceptive legged locomotion, especially humanoid stair climbing and foothold selection. If the authors fix the math, release the code and data, and run a few more trials with failure statistics, it could become a solid systems paper. As it stands, it needs a serious referee and heavy revision.\n\nMy recommendation: send it to peer review, but the reviewers must press hard on the Eq. 31 issue, the missing parameters, and the gap between the claimed planning frequency and what is actually measured.","headline":"A real stair-climbing demo but Eq. 31, taken literally, zeroes foot height; worth refereeing for the hardware results, but the planning equations and the quantitative claims need hard fixes.","tokens_in":872,"tokens_out":2007,"would_cite":false,"duration_ms":35763,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A humanoid robot can climb unknown staircases online by planning each footstep on a real-time polygonal map built from fused LiDAR, RGB-D, and IMU data.","keywords":["humanoid locomotion","stair climbing","perceptive locomotion","polygon mapping","footstep planning","multi-sensor fusion","LiDAR-inertial odometry","RGB-D perception"],"falsifier":"Run the same pipeline on a staircase with matte black or otherwise absorptive treads in outdoor sunlight: if the polygonal map misses treads or produces false planes, foothold candidates disappear and the robot either stops or clips a stair edge, which would falsify the claim of robust unknown-stair climbing. A less extreme check: measure planned-versus-executed footstep error on a long single-step outdoor climb and see whether it exceeds the tread-width minus foot-length safety margin (about 2 cm on the reported 28 cm tread and 26 cm foot).","tokens_in":9521,"feed_emoji":"🦿","tokens_out":5154,"duration_ms":42214,"temperature":0.7,"pith_summary":"The paper proposes PolygMap, a perception–planning framework that lets a full-size humanoid robot climb multi-step staircases it has never seen before. The key move is to turn raw depth and LiDAR measurements into a compact polygon map of stair tread planes in real time, then erode those polygons to obtain safe foothold candidates and plan whole-body stepping motions at 20–30 Hz on an onboard computer. The authors validate the framework in Gazebo simulation and in real indoor and outdoor stair-climbing experiments, reporting footstep errors of 11–33 mm and successful climbs of 4–6 consecutive steps. They also report that the faster single-step gait has a nonzero failure rate outdoors, attributed to state-estimation inaccuracy, lighting, and actuator issues under that gait. If correct, the work demonstrates that online foothold planning from a compact polygonal representation can support sustained stair climbing without pre-mapped geometry.","feed_headline":"One polygon map lets a humanoid climb unknown stairs","feed_subtitle":"Fusing LiDAR, RGB-D, and IMU, the system plans 20–30 Hz footholds on real staircases without a pre-built map.","key_machinery":"The load-bearing object is the eroded polygonal foothold map: a set of convex-hull polygons fitted to detected stair planes, rasterized into a dense point cloud, filtered to the robot's reachable range and foot-height threshold, and eroded per height layer to suppress edge noise. This representation converts sparse, noisy depth measurements into stable candidate foothold positions near the robot, and it is what couples perception to footstep planning. The supporting machinery is the state estimator: a linear Kalman filter plus complementary filtering that fuses LiDAR-inertial odometry with forward kinematics so that depth polygons are anchored to a low-drift body pose.","core_discovery":"The central claim is that a polygonal staircase plane semantic map, rebuilt at 20–30 Hz from depth images and fused LiDAR-inertial/proprioceptive odometry, can serve as the sole geometric basis for humanoid stair-climbing footstep planning. The pipeline extracts plane polygons from the depth stream using anisotropic diffusion, Sobel-based normals, Canny contours, and RANSAC fitting, anchors them to the world with a low-drift fused pose, rasterizes each polygon into a dense point cloud, erodes the points by height layer to remove edge noise, and selects the closest reachable foothold that satisfies the step-height threshold. The authors report that this closed loop climbs 4–6 consecutive real","pith_inferences":["The admitted outdoor failures point to the depth sensor's known weakness on dark, absorptive tread surfaces as the likeliest single-point failure; a depth modality robust to matte black surfaces would directly extend the method to more real stairwells.","The same polygon-erosion pipeline could generalize beyond stairs to gap crossing or stepping stones, since it already reduces arbitrary planar regions to ranked foothold candidates with a height threshold.","A testable extension would be to add predictive foothold selection during the swing phase of the single-step gait, using the fused state estimate to plan the next step before the body has fully settled, which could shrink the 33.4 mm error.","The paper leaves implicit that the 20–30 Hz polygon map rate is measured on an NVIDIA Orin; porting to lighter embedded hardware would clarify the minimum compute budget for perceptive stair climbing."],"forward_implications":["A full-size humanoid can climb multi-step, previously unseen staircases without a pre-built map, provided the onboard depth stream yields reliable tread polygons while walking.","The 20–30 Hz planning rate means foothold decisions can be recomputed within a single step cycle, allowing gait adjustment to the next detected tread.","The reported 11–33 mm planned-versus-executed footstep errors are small relative to the 28-cm tread width, implying a comfortable safety margin for the double-step gait.","The faster single-step gait trades accuracy for speed, with larger errors approaching the safety margin, so its use on long outdoor stairs requires better state estimation or gait timing."],"fun_headline_variants":["Polygon map lets humanoid climb stairs on the fly","Humanoid climbs unknown stairs via polygon map","Real-time polygon map for biped stair climbing","Sensor fusion builds 20–30 Hz stair map for robot","PolygMap: stair-climbing without pre-built map"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The whole loop depends on the downward-facing depth camera producing accurate polygons of stair treads while the robot is walking; the paper itself notes the sensor degrades on highly absorptive surfaces and blames some outdoor failures on lighting and state-estimation inaccuracy.","fun_headline_variants_meta":{"raw":{"variants":["Polygon map lets humanoid climb stairs on the fly","Humanoid climbs unknown stairs via polygon map","Real-time polygon map for biped stair climbing","Sensor fusion builds 20–30 Hz stair map for robot","PolygMap: stair-climbing without pre-built map"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000207,"raw_usage":{"total_tokens":1208,"prompt_tokens":684,"completion_tokens":524,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":428,"completion_tokens_details":{"reasoning_tokens":447}},"tokens_in":428,"tokens_out":524,"duration_ms":4507,"temperature":1.0,"reasoning_tokens":447,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-04T09:56:18.739239+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the same pipeline on a staircase with matte black or otherwise absorptive treads in outdoor sunlight: if the polygonal map misses treads or produces false planes, foothold candidates disappear and the robot either stops or clips a stair edge, which would falsify the claim of robust unknown-stair climbing. A less extreme check: measure planned-versus-executed footstep error on a long single-step outdoor climb and see whether it exceeds the tread-width minus foot-length safety margin (about 2 cm on the reported 28 cm tread and 26 cm foot).","supporting_citations":[],"review_version":1}