The PID is only P as there is no I term 
so the problem will exist.
Intriguing idea to use the dual as an “imu”. That has got me thinking a bit…
OK. I would definitely recommend an integral term to take out bias on slopes even without dual antenna. So if I understand correctly are you just replacing the Kalman heading output with the dual antenna heading output and keeping the gyro/IMU/magnetometer. Without trawling through the code I am not sure exactly what is going on, what is the basic calculation interval? is it just the GPS update rate?
Maybe there is a control system overview that I can look at?
There is no kalman on the heading, just a fix to fix calculation x meters back (settable), or the heading from vtg, of heading from dual antenna. Fix to fix and gps heading can also be fused with imu heading for stability.
The pwm loop runs at 25 hz, AOG sends new data at which point the Arduino immediately sends back its data. I would also recommend an Integral term - just haven’t got it working any better then none at all.
At a speed of 10km/hr or 2.77m/sec with a rtk gps update rate of 10hz for position that gives a new position every 27cm. If this is the case i can not see how the control algorithm can be so accurate. I think that you do some data fusion with the IMU in your code. If so is the output rate of the gps upgraded by the IMU data fusion?
I would think that a update fused position of 100hz would be required to allow the control algorithm to get you down to 2-3cm of error
Please let me know if this view is correct or not
Regards
I will over the next week or so try to get your dual code working on my system. You have done a lot of coding well done
I see from the code that you can select the orientation of the dual antenna to be inline with the tractor or transverse to it (for roll)
I prefer in the line of the tractor so i can have a longer moving base. If done this way i assume the dogs2 can still do the roll.
If using dual antenna then the brick2 is of no use unless you use it to fuse the gps data for a higher output rate
Regards
https://photos.google.com/photo/AF1QipNSOxr4PSciINyHM5kxGFapz-nPzBhdBjeO3uK0
https://photos.google.com/photo/AF1QipMjidxMTpsKvAiAXKZTYDoJsq4HIhSrBpyBV4E5
I started the project with 2 antennas and it is not going well …
I combined as seen in the pictures.
I uploaded INO to the ESP32 board (I can connect via wifi and open the web interface)
I loaded the configuration with github MTZ8302 on every F9P.
I have set the USB data transfer in the code
Poor effects, no GPS data in the AG.
After enabling debugging on the serial port monitor I only have this:
nǔ…
WLAN-Client-Connection failed
Accesspoint started - Name : GPS_unit_F9P_Net
IP address: 192.168.1.1
NTRIP UDP Listening to port: 2233
UDP writing to IP: 192.168.1.255
UDP writing to port: 9999
UDP writing from port: 5544
What else is missing?
Is it enough to load the configuration on F9P or should I additionally manually enter the settings according to MTZ 8302 recommendations?
Edit
After enabling debugging I have this:
UBX RelPosNED found
UBXRelPosNED flag heading: NOT valid, checksum OK; sentence NOT used
UBX RelPosNED found
UBXRelPosNED flag heading: NOT valid, checksum OK; sentence NOT used
UBX RelPosNED found
UBXRelPosNED flag heading: NOT valid, checksum OK; sentence NOT used
UBX RelPosNED found
UBXRelPosNED flag heading: NOT valid, checksum OK; sentence NOT used
UBX RelPosNED found
UBXRelPosNED flag heading: NOT valid, checksum OK; sentence NOT used
UBX RelPosNED found
UBXRelPosNED flag heading: NOT valid, checksum OK; sentence NOT used
UBX RelPosNED found
UBXRelPosNED flag heading: NOT valid, checksum OK; sentence NOT used
I’ve made a lot of progress.
I have GPS data but the angle is missing and the course behaves strangely In which direction not to turn the arrow on the screen is oriented all the time, i.e. when I go sideways the tractor goes sideways.
New config files on GitHub, the 1.13 PVT had to less messages.
Hope this will solve the RelPosNED flag prob
Believe it or not, the accuracy is due to the fact that a vehicle moves much slower then the gps fixes. As you get close to the line, the fixes will bounce back and forth across the line and the steering will try to go left and right but it all averages out to being really close to dead on. Trying to keep up with all the fixes, steering too fast etc will only cause problems and oscillations.
This was a bit of an interesting discovery especially with a true pid controller when all that was needed to get 99% of the way was a slightly underdamped P value that allows the steering to go slightly back and forth on the line. anything else caused too much noise and was only worse. A slow accumulating integral fixed the sidehill draft, but even that needs to be set so it moves the machine slowly over a few seconds meaning it counts 40 or 50 fixes.