Why do my drones slow to a crawl whenever they get close to an obstacle?

The uniform slowdown across the whole group is actually the biggest clue, and it points away from a force-tuning problem. If the repulsion and attraction terms were fighting each other, you'd see exactly what you said: drones near the pillars crawling while the outer ones barely notice. When everyone slows by the same amount, something is syncing their speeds, and in a neighbor-based controller the usual suspect is velocity consensus. If each drone's desired velocity includes a term that pulls it toward the average velocity of its neighbors, then whichever drone is closest to a pillar slows down first, and that slowdown ripples through the whole formation in a few control steps. Everyone ends up moving at roughly the pace of the most constrained drone. That's why it looks choreographed, because it literally is, just not on purpose. I ran into basically the same thing with a ground robot swarm a while back. One robot clipping a corner would drag the entire group down to a shuffle until it cleared the obstacle. Took me way too long to figure out because I kept staring at the avoidance gains instead of the velocity alignment term.

Easy way to confirm it: log each drone's commanded velocity separately for one run. If the outer drones' commands dip at the same time as the inner ones, even though their own obstacle distances are huge, it's the consensus term. If the outer commands stay high but the actual motion still slows, then look at your formation position targets, because if slots are defined relative to neighbors, a lagging drone pulls everyone's target positions back too, which has a similar effect.

Fixes depend on what you want. You can weight the velocity alignment less when obstacle proximity is high, so the constrained drone slows without dragging the rest. Or decouple the speed profile from the formation entirely: compute a per-drone safe speed from its own obstacle distance and let the formation terms handle direction only. Some people also gate the alignment term by whether the neighbor is actually visible or in front, which stops rear drones from inheriting slowdowns they can't even see.

One more thing worth checking, since it bit me once: if you're clamping the output velocity anywhere shared, like a group-level limit based on the minimum clearance across the swarm, that'll produce this exact uniform throttle too.

One diagnostic that helped me with something similar: check wheather the slowdown kicks in before and after the pillars symmetrically. If they only crawl on the exit side, I'd look at how fast your repulsion term decays with distance. Mine had a tail that was way too wide, so drones were still getting pushed well clear of anything, and the net command ended up tiny everywhere. Shrank the influence radius and most of the mystery slowdown vanished. Also curious what your control loop rate is versus the physics step, since a slow loop can smear commands like this too.

Something like this bit me once and the culprit was my clearance margin, not the gains. I had padded the obstacle geometry for safety and then forgot about it, so a gap that looked plenty wide on screen was borderline from the controller's point of view, and every drone in the group was technically near enugh to some pillar to trigger the slow mode. Worth measuring the actual distance your code thinks it has before trusting your eyes on the sim view. Also, when you say the formation snaps back after clearing, do the slots get reassigned at that moment, or are they fixed the whole time? If they reassign, part of that dramatic speed-up might just be a fresh target jump rather than the same controller suddenly agreeing with itself.

No clue on the tech side but this reminded me of watching my kids' toy drones do the same thing in the yard. Turned out one of them had a low battery and the others kind of matched its pace somehow, or maybe I imagined that part. Anyway, does each drone know how fast the others are actually going, or just where they are? beacuse if it only sees positions, a slow one in the middle would make the gaps shrink and everyone else might ease off without any speed info being shared at all. Just guessing here, probly wrong.

Update: the clearance margin thing was it, partly. I had padded my pillar geometry way bigger than the actual meshes, so every drone thought the gaps were tight. Shrank the padding and the slowdown got much better. Still crawling a bit on the exit side though, which makes me wonder about that repulsion decay tail idea. How wide did you end up cutting yours down?