{"id":"e87b865a-85cc-4a96-a39a-6d1b03b45f7d","arxiv_id":"2505.09434","paper_version":2,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":10,"one_line_summary":"A decentralized NMPC flocking controller is extended with point-cloud-based obstacle avoidance that filters and downsamples sensor data, and is shown to run in real time on Raspberry Pi 4 in simulation and HIL.","lead":"This paper adds a point-cloud based obstacle avoidance layer to an existing decentralized NMPC flocking controller, using directional filtering and down-sampling to reduce computation. It shows three Husky robots navigating an unknown obstructed environment in simulation and on Raspberry Pi 4 hardware-in-the-loop.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Directional filtering (Eq. 14) can discard obstacle points behind the current intent plane even though the unicycle model can turn into them within the horizon, so constraint set (19) may omit active collisions and the safety claim is not yet established.","rationale":"The reader identified static obstacles as the weakest assumption and mentioned directional filtering as a related issue. I agree with the spirit but believe the directional filter is the more precise, load-bearing gap: it is internal to the proposed method, applies even in static environments, and can be settled by a targeted offline check or simulation. The paper's HIL timing and single successful trajectory are credible engineering evidence, but they do not establish that the filter never removes an active safety constraint. The scalability note in the conclusion and the lack of released code are secondary concerns. My recommendation therefore retains the reader's conditional verdict: the central feasibility claim is plausible, but the safety claim needs either a design change to retain reachable backward points or an explicit demonstration that filtered points cannot intersect the predicted reachable set.","tokens_in":14389,"tokens_out":7003,"duration_ms":80362,"concrete_test":"Use the recorded LiDAR scans from the HIL/Gazebo runs: at each time t, compute the filtered set O_t_i from the raw point cloud using Eqs. (14)-(17), then test whether any discarded raw point (q not in O_t_i) lies within r_s of the robot's executed trajectory over the subsequent 1 s (T*dt). If any such point exists, the planner traversed a region that was filtered out, so safety was not guaranteed by the constraints. A sharper targeted test: place a single obstacle 0.3 m behind a follower, keep the desired direction (weighted neighbor average) forward, and run the NMPC with a sharp turn; record whether the predicted path collides with the discarded obstacle before replanning can include it.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central safety claim depends on every obstacle that can intersect the predicted trajectory being represented in the constraint set O_t_i. Directional filtering (Eq. 14) admits only points q with <p_t|t_b,i, p_t_b,q|i> >= 0, where the normal p_t|t_b,i = M(...)(p_t|t_i - p_t_i) points from the agent's current position toward the weighted-average neighbor position. This is a forward half-plane in the body frame. But the unicycle model (Eq. 23) has input limits v in [-0.1,1.0] m/s and angular velocity in [-8,8] rad/s (Section 4.1). With horizon T=10 and dt=0.1 s, the reachable set over the prediction horizon is not confined to the forward half-plane: the vehicle can reverse its heading in roughly 0.4 s and reach points that were behind the reference plane at time t. Consequently, an obstacle point with negative inner product in Eq. (14) can lie on the optimal predicted trajectory while remaining absent from Eq. (19); the NMPC problem then reports a constraint-satisfying solution that is in collision. The Gazebo and HIL demonstrations show one scenario with no collision, but they do not test or bound this blind-spot case. The static-obstacle assumption is secondary: even with perfectly static obstacles, the filter can remove an active constraint. This is load-bearing because the headline claim is safe navigation, not merely successful single-run navigation.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"This paper extends the authors' prior distributed NMPC flock-navigation framework by adding a local obstacle-avoidance strategy based on raw LiDAR point clouds. The main technical additions are a directional filtering step, a down-sampling step, and an obstacle-avoidance inequality constraint integrated into the NMPC problem. The authors evaluate the approach in Gazebo with one leader and two followers, compare it against a VFH-based reactive controller, and report a hardware-in-the-loop experiment in which the follower NMPC solvers run on Raspberry Pi 4 boards. The paper claims safe navigation through an unknown obstructed environment with real-time performance.","tokens_in":14777,"tokens_out":4167,"duration_ms":46071,"significance":"If the claims hold, the paper is a useful engineering contribution: it demonstrates that a distributed NMPC flocking controller with point-cloud-based obstacle constraints can run on low-cost embedded hardware and that directional filtering plus down-sampling keeps the solver within a 100 ms sampling period. The HIL experiment with average solve times below 25 ms is a concrete, reproducible result. However, the safety claim is not supported by the presented analysis: the directional filter can discard obstacle points that the unicycle robot could reach within the prediction horizon, and the evaluation is a single run with one environment and no statistical basis. The paper also provides no formal guarantees of collision avoidance or connectivity, so the headline claims should be revised to match the evidence.","major_comments":[{"comment":"The directional filter retains only points q satisfying <p_t|t_b,i, p_t_b,q|i> >= 0, i.e., points in the forward half-plane of the reference plane. For the unicycle model (23) with v in [-0.1, 1.0] m/s and omega in [-8, 8] rad/s, the reachable set over the horizon T=10, dt=0.1 includes points behind that plane: the robot can reverse its heading in about 0.4 s. An obstacle point behind the plane at time t can therefore lie on the optimal predicted trajectory while being absent from the constraint set O_t_i in (19). This undermines the claim that the NMPC enforces obstacle avoidance. Please either revise the filter to retain all points in the horizon-reachable set, or provide a closed-loop counterexample test with an obstacle placed just behind the filtering plane and update the safety claims accordingly.","section":"§3.1.1, Eq. (14) and §3.2, Eq. (19)"},{"comment":"The evaluation consists of a single run in a single environment with three robots. The conclusion that the fleet can navigate safely through an unknown obstructed environment is therefore supported only by one demonstration. Please add multiple trials with varied obstacle layouts and initial conditions, and report success rates, minimum distances to obstacles, and error bars or other statistics. The VFH comparison in Fig. 9 is also based on one trajectory, so the comparative claim needs repeated runs before it can be considered established.","section":"§4.2–4.3, Figs. 7–13"},{"comment":"The obstacle constraint uses the point cloud sensed at time t for all k = 0,...,T-1, which assumes obstacles are static over the prediction horizon. For moving obstacles, the constraint is invalid. This limitation should be stated explicitly. In addition, the HIL experiment accepts suboptimal solutions returned at the 95 ms cutoff; the assertion that these were 'sufficiently effective' should be quantified, for example by reporting the frequency of cutoff events, constraint violations at the returned solution, or a comparison with converged solutions on the same problem instances.","section":"§3.2, Eq. (19) and §4.3"}],"minor_comments":[{"comment":"The down-sampling notation is unclear: the segments [is:is+fs] with is in {0, fs, 2fs, ..., ns fs} may not partition the full index set, and the formula for ns should be checked. Please specify how the final partial segment is handled.","section":"§3.1.2, Eq. (15)"},{"comment":"The sentence 'In the demo, each follower recognized up to two neighbors if they are in the sensor's range, regardless of the point cloud processing, which only simplifies the obstacle avoidance constraint' is confusing. Please rephrase to clarify the role of neighbor exclusion and the effect of point cloud processing on the constraint set.","section":"§4.2"},{"comment":"Figure 13 reports average and peak solve times, but no solver convergence statistics are given. Reporting the number of times the cutoff was hit and the final cost or constraint residuals would strengthen the HIL feasibility claim.","section":"§4.3"},{"comment":"The reference-trajectory optimization in Eq. (24) is not described in enough detail for reproducibility. Please provide the waypoint set, the values of qp, qu, qT, and the exact trajectory used in the simulations.","section":"§4.2, Eq. (24)"}],"recommendation":"major_revision","confidential_remarks":"The directional-filtering issue is the most serious technical concern. It is not merely a missing proof: the constraint set can omit active obstacles for the given dynamics and horizon. If the authors cannot fix the filter or add a meaningful safeguard, the safety claim should be removed, and the paper should be reframed as an empirical demonstration. The evaluation also needs more than one run to support the comparative and general claims. On the positive side, the HIL implementation is a solid engineering result and the paper is clearly written. I would not accept in the current form, but the issues are addressable in a revised manuscript."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"What to know: this is an incremental but real engineering contribution. The authors take their prior NMPC flocking formulation and add a practical point-cloud obstacle-avoidance pipeline: directional filtering (Eq. 14) plus down-sampling, then hard constraints in the NMPC. The strongest empirical part is the hardware-in-the-loop study showing average solve times of 17.19 ms and 24.6 ms on Raspberry Pi 4s. That is a genuine data point for embedded optimization in multi-robot systems, and it is likely to be useful to people thinking about deploying NMPC on low-cost hardware.\n\nThe directional filtering idea itself is straightforward — keep points in front of the current intent plane — and the voxel/angular down-sampling is a known recipe, but the combination inside a distributed NMPC with real LiDAR data is new enough to count as a modest contribution. The Gazebo and HIL runs show one successful three-robot navigation in a cluttered environment, and the VFH comparison, while limited to one trajectory, at least gives a plausible connectivity improvement.\n\nNow the soft spots, in proportion. The safety claim is not established. Equation 19 enforces obstacle avoidance only for points that survive Eq. 14. But Eq. 14 discards every point behind the current intent direction. With the unicycle model (Eq. 23) and its angular velocity bound of ±8 rad/s, the robot can turn to face a discarded point within about 0.4 s, long before the 1-second horizon ends. Even with v capped at 1.0 m/s, the reachable set over the horizon is not confined to the forward half-plane. So the filter can remove an obstacle that lies on the optimal predicted trajectory, and the NMPC will return a collision-free-in-constraint solution that is actually in collision. This is not a nitpick about formal safety guarantees: the paper's title says 'real-time obstacle avoidance,' and a reader would reasonably expect the constraint set to cover the horizon. The static-obstacle assumption is real, but secondary: this blind spot occurs even with perfectly static obstacles.\n\nEvaluation is also thin: a single run, three robots, no error bars, no code release. The paper says in Section 4.2 that the algorithm is scalable, then notes in the conclusion that increasing agent count raises solve time until the optimizer may not converge. That is a mild inconsistency in tone, not a fatal one, but it should be reconciled.\n\nNone of this kills the paper. The engineering pipeline works in demonstrated scenarios, and the HIL timing is reproducible evidence. The paper deserves serious peer review because the claims are testable and the flaw I described is fixable — e.g., by re-including points within a reachability cone or by re-checking the full point cloud along the first few horizon steps. I would send this to referees, with a request for more runs and a caveat on the safety language.","headline":"Solid engineering extension with real HIL timing data, but the obstacle-avoidance safety claim has a blind spot: directional filtering can discard points the robot can reach within the horizon.","tokens_in":15260,"tokens_out":2817,"would_cite":false,"duration_ms":31426,"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 distributed nonlinear model predictive controller can steer a leader-follower robot flock through an unknown, obstacle-strewn environment using only locally sensed point clouds, and the optimizer runs in real time on a Raspberry Pi 4.","keywords":["nonlinear model predictive control","flocking","obstacle avoidance","point cloud","distributed control","hardware-in-the-loop","multi-robot systems"],"falsifier":"In the Gazebo environment, put a moving obstacle (or an extra robot) that enters a follower's sensing range only after its point cloud has been processed, and have it cross the predicted path; a collision or a violation of the safety distance $r_s$ would show that the static-obstacle assumption breaks the guarantee. Alternatively, force a U-turn into the region that directional filtering discarded; a collision there would show that discarding points behind the reference plane can remove safety-critical obstacles.","tokens_in":14174,"feed_emoji":"🤖","tokens_out":9576,"duration_ms":88283,"temperature":0.7,"pith_summary":"Flocking robots usually need a clean analytic description of obstacles, but real robots only have point clouds from LiDAR or depth cameras. This paper claims that the gap can be closed: a distributed nonlinear model predictive controller can take each follower's local point cloud, filter and downsample it, and turn the surviving points into obstacle-avoidance constraints over the prediction horizon. The scheme is validated in a Gazebo simulation of a leader and two Husky followers in an obstructed playpen, and in hardware-in-the-loop runs where the followers solve their NMPC on Raspberry Pi 4 boards with average solver times of 17.19 ms and 24.6 ms. If the claim holds, it shows that NMPC flock navigation is practical on low-cost embedded hardware in unknown environments.","feed_headline":"Robot flock dodges unknown obstacles in real time","feed_subtitle":"Each follower folds LIDAR point clouds into its solver, which runs in under 25 ms on a Raspberry Pi 4.","key_machinery":"The central object is the processed point-cloud index set $O^t_i$ in Eq. (17), which converts raw perception into a handful of constraints compatible with NMPC. The pipeline has three stages: directional filtering (Eq. 14) keeps points whose dot product with the intended-travel vector $p^{t|t}_{b,i}$ is nonnegative; downsampling picks the closest point in each angular sector (2D) or voxel (3D); neighbor exclusion removes points that correspond to teammates. These constraints, $h(\\cdot)\\le 0$, are imposed at every horizon step, so the solver plans a trajectory that avoids all retained points rather than reacting to the nearest one. The PANOC/OpEn solver is the numerical machinery that makes this constraint set solvable within a 95 ms cut-off.","core_discovery":"The paper's central claim is that local sensor data alone is enough to keep an NMPC flock safe and connected in an unknown obstructed environment. Each follower builds the processed point-cloud set $O^t_i$ by keeping only points ahead of a reference plane normal to its intended travel direction, downsampling to the nearest point per sector (2D LiDAR) or voxel (3D depth data), and deleting points that belong to neighboring agents. Every retained obstacle point $m\\in O^t_i$ then enters the optimal control problem as an inequality constraint $h(p^{t+k+1|t}_i, p^t_{m|i}) \\le 0$ for each prediction step $k$, i.e., the predicted trajectory must stay outside the safety circle of each point. The authors report that the resulting optimization, solved with the PANOC method via the OpEn code generator, runs at 17.19 ms and 24.6 ms average solve times on Raspberry Pi 4 in HIL, and that the fleet maintains connectivity better than a vector-field-histogram baseline while navigating barriers, hydrants, dumpsters, and cones in Gazebo.","pith_inferences":["A corollary the paper does not spell out is that the safety constraint is only as fresh as the last point cloud: an obstacle that enters after directional filtering is invisible to the current solve, so deployment in human-inhabited spaces would likely need a fast re-planning trigger based on newly appearing points.","The directional filtering step assumes the current heading is a good proxy for where the trajectory will go; in tight turns the plane could be widened or replaced by a cone to keep more points, a change that would trade solve speed for safety margin.","Grouping processed points into object-level constraints, which the authors mention as future work, would reduce constraint count from roughly one per LIDAR point to a handful per object; if the average solve time scales with constraint count, this could enable larger fleets on the same Raspberry Pi hardware.","The HIL experiment uses only one leader and two followers, so the reported solve times do not yet show how the scheme behaves with dense neighborhoods; before promising scalability, one would want a measurement of solve time versus the number of detected neighbor agents."],"forward_implications":["The obstacle-avoidance layer no longer requires a precomputed analytic map; each agent's LiDAR or depth sensor supplies everything the NMPC needs.","Because the same pipeline handles 2D sectors and 3D voxels, the method transfers from 2D LiDAR on ground robots to depth-camera or 3D-LiDAR setups.","Average solve times of 17.19 ms and 24.6 ms on Raspberry Pi 4 show that the whole flocking-plus-avoidance computation fits inside a 100 ms control loop on low-cost embedded hardware.","Solving time grows with the number of detected agents and constraints, so the authors note that smaller sampling times or larger fleets can hit the 95 ms cut-off and return suboptimal solutions."],"supporting_citations":[{"why":"Supplies the distributed NMPC flocking formulation with modified flocking rules that this paper extends to local point-cloud obstacle avoidance.","marker":"Nag and Yamamoto (2024)"},{"why":"Introduces the NMPC flock navigation with graph-distance hierarchy and cohesion/alignment trade-off used as the baseline controller.","marker":"Nag et al. (2022)"},{"why":"Provides the PANOC algorithm that solves the nonlinear optimal control problem fast enough for real-time operation.","marker":"Stella et al. (2017)"},{"why":"Supplies the OpEn code generator used to produce the embedded solver running on the Raspberry Pi.","marker":"Sopasakis et al. (2020)"},{"why":"Provides the obstacle-avoidance inequality formulation and the PANOC-based solution approach that the point-cloud constraints adapt.","marker":"Sathya et al. (2018)"},{"why":"Supplies the Gazebo simulator in which the 3D close-to-real validation is performed.","marker":"Koenig and Howard (2004)"},{"why":"Provides the Husky UGV model used as the simulated agents.","marker":"Clearpath Robotics (2015)"},{"why":"Provides the obstructed playpen environment used in the navigation experiments.","marker":"Mukherjee (2015)"},{"why":"Provides the vector-field-histogram baseline against which the proposed method's connectivity preservation is compared.","marker":"Liang et al. (2023)"}],"fun_headline_variants":["Decentralized NMPC keeps fleets safe in unknown mazes","Real-time flock obstacle avoidance on a Raspberry Pi","Local-sensor flock navigation dodges unknown obstacles","Point-cloud NMPC runs under 25 ms for flock avoidance"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the obstacles detected in the point cloud at time $t$ stay fixed for the entire prediction horizon, because the same sensed points are used to constrain every future predicted position.","fun_headline_variants_meta":{"raw":{"variants":["Decentralized NMPC keeps fleets safe in unknown mazes","Real-time flock obstacle avoidance on a Raspberry Pi","Local-sensor flock navigation dodges unknown obstacles","Point-cloud NMPC runs under 25 ms for flock avoidance"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000364,"raw_usage":{"total_tokens":1952,"prompt_tokens":926,"completion_tokens":1026,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":542,"completion_tokens_details":{"reasoning_tokens":958}},"tokens_in":542,"tokens_out":1026,"duration_ms":8735,"temperature":1.0,"reasoning_tokens":958,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T21:30:51.561174+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"In the Gazebo environment, put a moving obstacle (or an extra robot) that enters a follower's sensing range only after its point cloud has been processed, and have it cross the predicted path; a collision or a violation of the safety distance $r_s$ would show that the static-obstacle assumption breaks the guarantee. Alternatively, force a U-turn into the region that directional filtering discarded; a collision there would show that discarding points behind the reference plane can remove safety-critical obstacles.","supporting_citations":[{"cited_title":"and Yamamoto, K","cited_arxiv_id":null,"evidence_quote":"Supplies the distributed NMPC flocking formulation with modified flocking rules that this paper extends to local point-cloud obstacle avoidance."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Introduces the NMPC flock navigation with graph-distance hierarchy and cohesion/alignment trade-off used as the baseline controller."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the PANOC algorithm that solves the nonlinear optimal control problem fast enough for real-time operation."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the OpEn code generator used to produce the embedded solver running on the Raspberry Pi."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the obstacle-avoidance inequality formulation and the PANOC-based solution approach that the point-cloud constraints adapt."},{"cited_title":"and Howard, A","cited_arxiv_id":null,"evidence_quote":"Supplies the Gazebo simulator in which the 3D close-to-real validation is performed."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the vector-field-histogram baseline against which the proposed method's connectivity preservation is compared."}],"review_version":1}