Update curvature_factor interpolation - #192
Open
Praeuner wants to merge 2 commits into
Open
Conversation
Add "high_gain_boundary" interpolation based on speed. Modify curvature_factor interpolation range from .0005 to the new high_gain_boundary.
Collaborator
|
I'm not rejecting this.... but I'll need to see that it makes a very significant improvement. Changing the interpolation range means everyone on bp-7.0 has to retune. That's a tough pill for them to swallow. |
Contributor
Author
|
Of my two current pull requests (apologies for my closed PR that wasn't as fully tested), this one is by far the more impactful for me. Drastically improves confidence in both high and low speed curves. It should be very easy to see a difference in a route. Similar to my comment on the predicted_curve PR, I'll upload a new route and then downgrade before capturing a new route with only this removed to give a good apples to apples comparison. But ya, the tuning changes could be a bit rough. I suggested modifying the per-platform gain defaults, but I realize a +.20 across the board would need a bit of a coordinated effort for testing. |
dsaderholm
added a commit
to dsaderholm/bluepilot
that referenced
this pull request
Aug 28, 2026
…s and does not fix HIS SKEPTICISM WAS CORRECT: "Just because there's a PR, doesn't mean it's actually the fix. I want to make sure you have it all right. I think the goal is for desired curvature to match actual curvature, right?" Yes -- and my first A/B measured internal gain swing instead, which is not that. THE PR IS A GENUINE MATCH TO THE SYMPTOM. BluePilotDev#192 (bp-gain-interpolation), author's own words: "Reduce oscillations through curves, particularly around 1000m-1600m radius... Initial fast swing made car lurch on entering a curve, and if curve continued near previous interp range, oscillations would continue." His worst measured episodes sit exactly there -- radius 894, 1282 and 1327 m. Applied unmodified. Also NAMED the blend breakpoints (_GAIN_BLEND_V_BP), because a test had pinned 26.82 as "the top of the blend" and silently became wrong when the PR widened it to 31.29 -- it was asserting an endpoint that is now mid-interpolation. The test now reads the constant. REPLAYED AGAINST HIS OWN 847k FRAMES, and the honest result is mixed: whole drive gain swing -74% COMMAND swing -2% in the band gain swing -91% COMMAND swing -11% (route de: -13%) A 74% improvement in an internal number that moves the actual command 2% is not a cure, and saying so matters more than the PR looking right. AND IT DOES NOT ADDRESS THE OTHER HALF AT ALL. There are two problems: 1. command smoothness (the lurch) -- BluePilotDev#192 helps ~11% where it acts 2. command magnitude vs delivery -- the car returns ~87% of commanded curvature, 65% at 50-60 mph. BluePilotDev#192 changes magnitude barely at all. THE HARD LIMIT, stated because he asked me to be sure: offline replay can show what the COMMAND does and can NEVER show what the car does back. "Actual curvature" is the PSCM physically responding, and no model of it exists here. Whether desired comes to match actual is a drive question, not a log question. AND CURVATURE MODE IS OFF THE TABLE. His friend switched to it out of frustration; he does not want it: "I am not switching back to curvature! Curvature is terrible!" The fix has to live in the angle path. 904 pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
dsaderholm
added a commit
to dsaderholm/bluepilot
that referenced
this pull request
Aug 30, 2026
… thresholds He asked for the whole BluePilot repo checked and approved taking what it found: "Yes, take it. I trust bp-dev." One commit touching the angle path was missing from our history -- ba20937 "Predicted_Curvature Weight Blending" (Praeuner, 2026-08-25). We took PR BluePilotDev#192 off bp-dev-191 and missed the commit underneath it. _desired_falling abs(des) < abs(last) - 0.010 -> abs(last) > 0.001 and abs(des) < abs(last) * 0.8 _kappa_entering kappa_at_t_base > abs(des) -> abs(des) > 0.001 and kappa_at_t_base > abs(des) * 1.25 b_blend snapped b <-> b*0.25 -> ramps 0.1/call toward b*0.25 exit / b*0.35 straight / b The _desired_falling change independently confirms the bug measured here two days earlier: the 0.010 absolute threshold is 5.4x the p99 fall across 239,038 intervals and fired on 0.054% of them, so the exit-biased blend never ran on an ordinary curve exit. A relative threshold is scale-free and cannot rot against a cadence change the way the absolute one did. Reconciled with our blend-horizon change, which touches the same block; b_blend is persistent state on the CarController, seeded in __init__ (called explicitly at carcontroller.py:89) and reset at all three early-return sites so a re-engage cannot inherit the last drive's weight. AND IT IS INERT ON HIS GENTLE CURVES. Both new guards carry an abs(...) > 0.001 floor -- a 1000 m radius. His reported episodes include 1271 m, 1327 m and 2514 m, all below it, so neither guard can fire there and the ramp never leaves b. Real improvement tighter than ~1000 m, nothing on the sweepers where he first described the symptom. Pinned by a test so it is not rediscovered, and NOT to be reported to him as a whole-complaint fix. One of my own tests was vacuous until mutation testing said so: test_blend_weight_ramp.py mirrors the arithmetic rather than executing it and stayed green with b_step=1.0. TestTheBlendWeightRampRunsForReal drives the real update_angle_strategy and dies on that mutation. The scenario is what made it real -- a hard exit cannot fire _desired_falling on call one, so the target equalled the seed and the weight had nowhere to move. 959 green, ruff clean, carcontroller smoke 36/36. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bring down high curve gain boundary for both high and low speed to better match real world max curves. Previous boundaries were theoretically possible, but would need an unrealistically gentle curve increase for the wheel to keep up with required angle.
Contributor
Author
|
Apologies @dsaderholm, I made my commits to both PR 191 and 192 with some tweaks before seeing you had also made commits on your end. Reasoning is stated in my newest commit messages. 192 changes to hit maximum gain on tightest practical curves when taking into account limitations on how fast the wheel can actually be turned instead of theoretical tightest turns in a vacuum. |
alan-polk
added a commit
that referenced
this pull request
Sep 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
Reduce oscillations through curves, particularly around 1000m-1600m radius.
Changes
Modified speed interpolation ranges from 30-60 to 25-70.
Extend interpolation from .0007-.001 (1600m-1000m) to .0005-"high_gain_boundary" (2000m-variable). This makes the interpolation happen over a much larger interval, preventing the fast swings from low to high gain. Initial fast swing made car lurch on entering a curve, and if curve continued near previous interp range, oscillations would continue.
Add high_gain_boundary that interpolates the high gain curve radius using speed. "High curvature" is very dependent on speed--using .02 (50m rad) at 25 mph (.255 g, considered fairly low) and .0045 (222m rad) at 70 mph (.45 g, considered moderately aggressive).
Notes