In my experience we have got the best results with the FC installed on the centre line of the vehicle and on the turning radius. The accelerations I was referring to were those reported by the GNSS
I understand what you are referring to when you refer to the xtrack ‘stabilising’ at some non zero offset. This is what I have tried to address in my latest changes. I believe that at these relatively small xtrack offsets, the output of the L1 controller is not strong enough.
The ATC_SPEED_FF parameter is not normally used, but in place of this the system uses the CRUISE_THROTTLE and CRUISE_SPEED parameters to determine the same proportion. If you have these set correctly then that is the equivalent. You can calculate these value based on your wheel diameter/rpm for a given throttle command. Because you have velocity controlled motors and have a linear response across the throttle range, it doesn’t matter what throttle value you choose for this setting. The same process can be done for the ATC_STR_RAT_FF setting. This parameter is essentially the amount of steering input to achieve a turning rate of 1 rad/s. Using your same wheel diam and wheel separation you can calculate how much throttle differential you need to achieve this 1 rad/s. It is this throttle value that you use for this parameter (where 1.0 = 100% throttle). Once you have these parameters set, you can dial right back on the ATC_STR_RATE_P and the ATC_SPEED_P values.
I would try to work on reducing the NAVL1_PERIOD. If this is set too low then you will observe the rover oscillating about the path as it over shoots and over corrects.
If you are still having problems with the moving baseline GNSS setup, I have recently implemented heading from dual independent GNSS. We run a local basestation and both GNSS on the vehicle get RTK corrections. Using the position from these two modules and the geometry stored in the GPS_POSXXX params, I calculate the heading. With a seperation of 1.3m I see an accuracy of ~0.5 deg but without the high precision code I would expect the error to double. In this configuration you can also crank up the F9P reporting rate (rtk at up to ~40Hz with code changes)