{"id":"ed984fbe-185c-44a8-975c-1a7bcff09ad2","arxiv_id":"2411.10940","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"Multi-user AR positioning is achieved by aligning each user's SLAM map to a common table plane, with MiDaS monocular depth estimation for occlusion rendering.","lead":"The paper presents an AR system that lets several people, each in a different room, share a virtual workspace on a table. It tracks each user with a phone camera using ORB-SLAM2, aligns everyone's coordinate systems through a common table plane, and adds depth-based occlusion so virtual objects appear hidden behind real objects.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The headline multi-user claim is not actually measured: Section 4.2 quantifies only single-user scale-calibrated pose error vs Vuforia, never the accuracy of across-room avatar alignment from Eqs. 3-5.","rationale":"The reader's verdict is CONDITIONAL, and the reader's weakest_assumption points to the scale-calibration formula (Eqs. 1-2) and its unquantified sensitivity. I agree that the scale calibration is fragile, but I see an even more load-bearing gap: the paper never evaluates the multi-user alignment that constitutes its central claim. The scale-calibration RMSE in Section 4.2 is a single-user, marker-in-view trajectory comparison against Vuforia; it does not establish that Eq. 5 places UserA's avatar correctly in UserB's space. The plane estimation, the arbitrary coincidence of plane coordinate systems, the synthetic rotation in Collaboration Mode, and the one-time scale factor all enter the multi-user pipeline, and none of their combined error is measured. This reinforces the CONDITIONAL verdict rather than changing it, because the manuscript is otherwise coherent and honestly reports limitations, but the headline claim remains under-supported. The concrete test I propose, a two-user cross-room experiment with external ground truth, would directly settle whether the central claim holds.","tokens_in":11677,"tokens_out":5047,"duration_ms":62380,"concrete_test":"Run a two-user experiment in two separate rooms, each with a table, and track both AR glasses with an external motion-capture system (e.g., OptiTrack/Vicon) to obtain ground-truth device poses in each room. Define the intended shared table alignment (e.g., both tables treated as the same virtual plane with matched origins and orientations). Have each user move through a 1-2 minute trajectory; at synchronized timestamps, compute the error between UserA's avatar position rendered in UserB's view (via Eqs. 3-5) and UserA's ground-truth position transformed through the true relative table pose. Report translational and rotational RMSE for the avatar placement, with per-axis breakdown and multiple trials. If this error is not reported or exceeds, say, 10 cm, the central multi-user alignment claim is unsupported by the current evidence.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim is a multi-user positioning system that aligns users in different physical spaces using each user's table plane as a shared reference. However, the only quantitative evaluation, Section 4.2, measures single-user camera pose error after scale calibration against Vuforia, with the calibration marker present in the scene. It does not measure the multi-user alignment that the title and abstract promise. The multi-user pipeline in Section 3.4.1 concatenates per-user monocular SLAM poses, per-user plane poses estimated by RANSAC/SVD, and a one-time scale factor from exactly two ORB correspondences (Eqs. 1-2). Every one of these component errors propagates into Eq. 5, where UserA's avatar is placed in UserB's SLAM coordinate system by composing UserA's camera-to-plane pose with UserB's plane pose. The paper does not report an error metric for this cross-space avatar placement, offers no trial counts or confidence intervals for the reported RMSE, and provides only qualitative screenshots (Figs. 5-6) as evidence that the multi-user alignment works. Moreover, the plane coordinate system's x-axis is defined by projecting each user's camera position onto the plane (Section 3.3), so the 'coincided' plane frames are not objectively aligned unless users stand in corresponding positions; the Collaboration Mode applies an arbitrary rotation (Eq. 6) rather than a measured physical alignment. Because the central claim is about multi-user positioning, the missing multi-user accuracy evaluation is the most load-bearing gap: the reported 0.0065 m / 0.6302° RMSE supports only the scale-calibration component, not the full system claim.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a multi-user AR positioning system built on monocular ORB-SLAM2. Each user runs ORB-SLAM2 on RGB images from an AR glass or smartphone; a one-time marker-based calibration resolves monocular scale uncertainty (Section 3.2, Eqs. 1-2); RANSAC/SVD plane estimation recovers a table plane with finite boundaries (Section 3.3); a TCP coordination server exchanges camera-to-plane relative poses so that each user can render other users' avatars in their own SLAM coordinate frame (Section 3.4, Eqs. 3-5); and a MiDaS-based depth server supplies per-frame depth for occlusion rendering (Section 3.5). Quantitative results are reported for scale-calibrated single-user pose accuracy against Vuforia (Tables 1-2, RMSE 0.0065 m and 0.6302 degrees) and for runtime (Table 4), with qualitative demonstrations of plane intersection and occlusion (Figs. 10-11).","tokens_in":11947,"tokens_out":3222,"duration_ms":37735,"significance":"If the multi-user alignment were properly validated, the paper would offer a practical, lightweight alternative to map-merging approaches for remote AR collaboration, and the use of a detected table plane as a common reference frame is a sensible design choice. The system integrates open-source monocular SLAM with a commercial AR headset, clearly decomposes the software architecture into localization, plane estimation, coordination, and depth modules, and reports per-module runtimes, which is useful for practitioners. The contribution is diminished, however, by the fact that the headline multi-user positioning claim is not measured: the only pose-error evaluation is single-user scale calibration against Vuforia, and the multi-user alignment from Eqs. (3)-(5) is supported only by screenshots. The significance of the paper therefore hinges on additional experiments that have not yet been reported.","major_comments":[{"comment":"The quantitative evaluation measures single-user camera pose error after scale calibration, but the title, abstract, and introduction claim a multi-user positioning system. The multi-user avatar alignment produced by Eqs. (3)-(5) is never evaluated with any error metric, trial count, confidence interval, or comparison against a reference. Please add an experiment in which two or more users in separate physical spaces are tracked, the rendered avatar position/orientation in one user's SLAM frame is compared with a measured ground-truth relative pose, and the results are reported over multiple trials and trajectories.","section":"Section 4.2, Tables 1-2"},{"comment":"The scale factor is computed from exactly two ORB correspondences under the assumption that the marker is viewed fronto-parallel, so that pixel distances scale linearly to physical distances. No sensitivity analysis is provided for perspective distortion, matching errors, non-coplanar correspondences, or invalid 3D map points. Because this single scalar multiplies every subsequent plane boundary, object placement, and avatar position, the paper should quantify how calibration repeatability and viewpoint variation affect the reported 0.0065 m RMSE, or justify why a two-point fronto-parallel model is sufficient.","section":"Section 3.2, Eqs. (1)-(2)"},{"comment":"The plane coordinate system's x-axis is defined by projecting the camera's position onto the estimated plane. This makes the plane frame viewpoint-dependent: two users standing at different positions around their tables will define different x-axes, so 'coinciding all the plane's coordinate systems' is not a physically meaningful alignment unless users stand in corresponding locations. The paper should either define plane axes from table geometry independent of camera position, or explicitly analyze how the viewpoint-dependent x-axis affects the avatar placement in Eq. (5).","section":"Section 3.3 and Section 3.4.1"},{"comment":"Collaboration Mode assigns user positions by an arbitrary rotation theta = 360 deg / N times i rather than by any measured physical arrangement. Consequently, the opposite-side placement shown in Fig. 6 is imposed by the system, not validated as an accurate cross-space alignment. Please clarify that Eq. (6) is a deliberate user-interface choice, and exclude this mode from any claim of measured physical alignment unless a separate metric is reported.","section":"Section 3.4.2, Eq. (6)"}],"minor_comments":[{"comment":"Please correct typos such as 'Wphysic' and 'Hphysic' (should be 'physical'), and clean up author/affiliation formatting artifacts such as 'T aiwan' and 'Y a-Hui T ang'.","section":"Throughout"},{"comment":"The text says p1 and p2 are 'correspondences in the marker,' but the formula uses pixel distance in the marker image; clarify whether p1 and p2 are 2D marker coordinates or scene-image keypoints, and define all symbols explicitly.","section":"Eq. (1)"},{"comment":"The notation SA P T, P SA T, SA CA T, and P CA T is visually confusing; consider using a consistent convention such as T_{a,b} for a transform from frame b to frame a, with all frames defined in a table.","section":"Section 3.4.1, Eqs. (3)-(5)"},{"comment":"Report the number of trials, trajectory length, number of frames, and confidence intervals for the RMSE values; also use a consistent numerical format and degree symbol in the table headers.","section":"Tables 1-2"},{"comment":"The occlusion evaluation is qualitative; please state whether any quantitative depth error metrics (e.g., RMSE or absolute relative error against known ground truth) were considered, and clarify how 'satisfactory' is defined in the model-selection discussion.","section":"Section 4.4, Fig. 11"},{"comment":"The total depth-thread time is listed as 0.0803 s, but the tabulated components are 0.053 s and 0.027 s, which sum to 0.080 s; check this value and the four-decimal '0.07211' in the coordination thread for consistency.","section":"Section 4.5, Table 4"}],"recommendation":"major_revision","confidential_remarks":"The paper has a coherent architecture and the single-user components are plausibly demonstrated, but the central multi-user alignment claim is currently supported only by qualitative figures. I recommend major revision rather than rejection because the missing evaluation is an experimental gap that is within scope to fill: the authors could add a two-user cross-space accuracy experiment with a measured ground truth, plus a calibration repeatability study. I would also encourage the editor to consider whether the contribution is better framed as a system paper with explicit scope limits, since the technical novelty over standard SLAM plus plane estimation is modest."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Worth a look if you care about multi-user AR systems, but not as a validated result. The paper is a clear, honest integration of ORB-SLAM2, RANSAC/SVD plane fitting, a TCP coordination server, and MiDaS depth for occlusion. The new piece is using each user's detected table plane as a shared reference frame, plus convex-hull intersection for a common interaction area. That's a legitimate extension of existing collaborative-SLAM ideas, and the components are standard but sensibly combined.\n\nThe soft spot is the gap between the title's promise and the evaluation. Section 4.2 measures single-user camera pose error after scale calibration against Vuforia, with the marker present. That's a fine calibration check, but it doesn't measure the multi-user avatar alignment that Eqs. 3-5 are supposed to deliver. Figures 5 and 6 are screenshots. No error metric for cross-space placement, no trial counts, no confidence intervals. Also, the plane coordinate system defines its x-axis by projecting the camera position onto the plane, so two users' plane frames coincide only if they stand in corresponding positions. Collaboration Mode applies a nominal rotation rather than a measured alignment. That's a conceptual soft spot, not just a missing experiment. The scale calibration itself assumes a fronto-parallel marker and uses exactly two ORB correspondences; sensitivity to viewing angle and matching errors is unquantified. Minor issues: Vuforia as ground truth is uncharacterized, and runtime is per-module.\n\nThe paper deserves a serious referee because the idea is plausible and the gaps are fixable. I'd ask for a multi-user alignment metric (for example, avatar pose error in one user's frame compared to a measured ground truth) and a discussion of the plane-frame alignment assumption. As it stands, it's not citable as a validated multi-user system, but it's a solid starting point for an engineering venue.","headline":"A clearly-built AR integration whose headline multi-user alignment is never actually measured; the single-user scale calibration works, but the across-user avatar placement is only shown in screenshots.","tokens_in":12541,"tokens_out":2725,"would_cite":false,"duration_ms":31871,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A detected tabletop in each user's room can replace shared maps as the alignment anchor for multi-user AR.","keywords":["augmented reality","multi-user positioning","ORB-SLAM2","plane estimation","scale calibration","monocular depth estimation","occlusion rendering","virtual avatars"],"falsifier":"Repeat the calibration with the marker held at oblique angles (for example, 30 and 45 degrees) or with part of it obscured, then walk a measured path and compare the reconstructed trajectory against a tape-measured ground truth; if the translational RMSE grows substantially beyond the reported 0.0065 m, the scale calibration's viewpoint sensitivity is confirmed.","tokens_in":11461,"feed_emoji":"🕶️","tokens_out":9274,"duration_ms":95296,"temperature":0.7,"pith_summary":"This paper claims that users in different physical rooms can share one augmented-reality space without sharing SLAM maps, by making each user's detected table plane the common reference frame. Each device runs monocular ORB-SLAM2, performs a one-time scale calibration with a printed marker, and computes the plane of its own table from the resulting sparse map. Users exchange only camera-to-plane poses and table-boundary points through a central server, and every device reconstructs the other users' avatars by applying those relative poses to its own plane. A server-side monocular depth model supplies occlusion, so real objects can correctly hide virtual avatars. After calibration, the reported trajectory error against a commercial visual-tracking baseline is 0.0065 m translational RMSE and 0.6302 degrees rotational RMSE.","feed_headline":"A table plane aligns remote AR users to 6.5 mm","feed_subtitle":"Instead of sharing maps, users share only their table-plane pose; avatars and virtual objects stay aligned across rooms.","key_machinery":"The load-bearing mechanism is the plane-as-reference transform chain. Each user's table plane gives a local coordinate frame whose origin is the centroid of RANSAC inlier map points and whose y-axis is the plane normal; the plane boundary is the convex hull of those inliers (computed by the Graham algorithm). The scale conversion $\\mathrm{Scale}=D_\\mathrm{physic}/\\|P_1-P_2\\|$ turns one marker observation into global metric units, and the two transformations above convert any camera pose from one user's SLAM frame into another user's frame through the plane frames. The same plane frames also define the common placement area, since the system intersects the convex polygons of all users' table boundaries to find the region where a virtual object stays on every table. Occlusion works by a separate depth channel: the server-side monocular depth model produces a per-frame depth map, and Unity's fragment shader compares it with rendered object depth, drawing background pixels wherever the real scene is closer.","core_discovery":"On the author's account, the central discovery is that a planar surface, a tabletop, can act as a shared anchor for coordinate alignment, even though every user's SLAM map is local. Plane estimation uses RANSAC to remove outlier map points and SVD-based least-squares fitting to obtain the table plane; the plane's x-axis is oriented toward the user, so virtual objects face them. A scale factor, $\\mathrm{Scale}=D_\\mathrm{physic}/\\|P_1-P_2\\|$, is computed once from two matched ORB points on a known-size marker and converts the unitless monocular map into metric units. The relative pose of a user's camera with respect to their plane, \\({}^P T_{C_A} = {}^P T_{S_A}\\, {}^{S_A}T_{C_A}\\), is broadcast, and the receiving user places the avatar via \\({}^ {S_B} T_{C_A} = {}^{S_B}T_P\\, {}^P T_{C_A}\\). Shared virtual objects are confined to the intersection of the convex hulls of all users' table boundaries, and the MiDaS monocular depth estimator is run on a server to drive occlusion in the fragment shader.","pith_inferences":["The same plane-as-anchor trick should transfer to any detectable planar surface, wall, whiteboard, floor, or poster, so the table is likely a convenience rather than a requirement, as long as all users can detect the same class of surface.","Because the scale factor is computed from only two ORB correspondences and one assumed fronto-parallel view of the marker, a natural robustness test is to replace it with a multi-correspondence least-squares or homography-based scale estimate; the paper does not quantify how oblique views degrade the 6.5 mm result.","Since the shared placement area is an intersection of convex hulls, adding users with smaller tables shrinks the common region, which may explain the paper's own scalability warning; larger or similar-sized tables would keep the shared area usable.","The depth server costs about 80 ms per frame on the depth thread, so occlusion and pose refresh around 12 fps; an on-device or distilled depth model would be the obvious next step for smoother AR experiences."],"forward_implications":["After a single scale calibration, the localization output tracks a commercial visual-tracking baseline with 0.0065 m translational RMSE and 0.6302 degrees rotational RMSE.","No SLAM map, keyframe, or point cloud ever has to be sent between users; only camera-to-plane poses and plane-boundary points cross the network.","A common virtual object stays within every user's table because its allowed placement region is the intersection of all detected table-plane convex hulls.","The collaboration mode rotates a user's plane frame by the user's ID-dependent angle, so participants can be arranged around the table as if they were at 180 degrees (two users) or other angular spacings.","The paper itself expects the system to scale poorly as the number of users grows, since the coordination server aggregates all pose and boundary data centrally."],"supporting_citations":[{"why":"Supplies the open-source monocular SLAM backbone used for camera pose estimation and the sparse 3D map.","marker":"[16]"},{"why":"Supplies the printed marker for scale calibration and the pose baseline used as ground truth in the accuracy comparison.","marker":"[3]"},{"why":"Supplies the RANSAC outlier-removal step that guards the plane fitting from map points not on the table.","marker":"[9]"},{"why":"Provides the convex-hull construction that turns the plane's inlier points into a finite table boundary.","marker":"[4]"},{"why":"Provides the convex-polygon intersection properties used to compute the common usable area across users' tables.","marker":"[5]"},{"why":"Provides the monocular depth-estimation model whose depth maps drive the occlusion rendering.","marker":"[20]"},{"why":"Supplies the dense-prediction transformer backbones whose runtime and accuracy trade-off is evaluated for choosing the depth model.","marker":"[19]"}],"fun_headline_variants":["A table plane aligns multi-user AR to 6.5 mm","Table plane syncs AR users to 6.5 mm without map sharing","Plane pose sharing gets AR users to 6.5 mm","No map sharing: table plane for 6.5 mm AR sync","Monocular SLAM and a table plane yield 6.5 mm AR"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The whole system's position accuracy rests on a one-time calibration that assumes the printed marker is viewed fronto-parallel and that the two most similar ORB matches it chooses are correct; if either fails, every table boundary, virtual object, and avatar is shifted by the same scale error.","fun_headline_variants_meta":{"raw":{"variants":["A table plane aligns multi-user AR to 6.5 mm","Table plane syncs AR users to 6.5 mm without map sharing","Plane pose sharing gets AR users to 6.5 mm","No map sharing: table plane for 6.5 mm AR sync","Monocular SLAM and a table plane yield 6.5 mm AR"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001213,"raw_usage":{"total_tokens":5025,"prompt_tokens":1010,"completion_tokens":4015,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":626,"completion_tokens_details":{"reasoning_tokens":3919}},"tokens_in":626,"tokens_out":4015,"duration_ms":30140,"temperature":1.0,"reasoning_tokens":3919,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T19:08:03.235286+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Repeat the calibration with the marker held at oblique angles (for example, 30 and 45 degrees) or with part of it obscured, then walk a measured path and compare the reconstructed trajectory against a tape-measured ground truth; if the translational RMSE grows substantially beyond the reported 0.0065 m, the scale calibration's viewpoint sensitivity is confirmed.","supporting_citations":[{"cited_title":"Mur-Artal and J","cited_arxiv_id":null,"evidence_quote":"Supplies the open-source monocular SLAM backbone used for camera pose estimation and the sparse 3D map."},{"cited_title":"https://developer.vuforia.com/","cited_arxiv_id":null,"evidence_quote":"Supplies the printed marker for scale calibration and the pose baseline used as ground truth in the accuracy comparison."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the RANSAC outlier-removal step that guards the plane fitting from map points not on the table."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the convex-hull construction that turns the plane's inlier points into a finite table boundary."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the convex-polygon intersection properties used to compute the common usable area across users' tables."},{"cited_title":"Ranftl, K","cited_arxiv_id":null,"evidence_quote":"Provides the monocular depth-estimation model whose depth maps drive the occlusion rendering."},{"cited_title":"Ranftl, A","cited_arxiv_id":null,"evidence_quote":"Supplies the dense-prediction transformer backbones whose runtime and accuracy trade-off is evaluated for choosing the depth model."}],"review_version":1}