V5.1.4 Release

News / Updates
261

I too have what sounds like the same problem as @FarmerNeil, but haven’t wanted to complain. I’ve sprayed 1500 acres with it so far and it isn’t a big deal for me–I just wait. Version 5 is too awesome in every other regard to go back.

Here’s my setup currently:

  • v5.1.3 running on a Surface Book Core i5 with 8GB of ram (I just upgraded to the latest v5.1.4 during the rain here and I’ll test it when I get going again)
  • PCBv2 with a CMPS14 connected right to the steer Nano. That placement works great for me!
  • SwiftNav Piksi Multi with DGPS sending out just GGA and VTG at 10Hz over UDP
  • all communication with the tablet is over UDP via WiFi with a Ubiquiti Cube router
  • work switch which controls manual to enable and disable the spray
  • all mounted in a old Ford pickup with fixed booms on the back. Total width is just over 63 feet.

Here’s my analysis:

  • It only happens when I’m running on a boundary curve. If I get to a (rounded off) 90 degree corner on the second round (labeled as curve 1), I typically shut the autosteer off just before it wants to turn the corner on its own and continue straight ahead, shut the spray off, backup and square off the corner. It starts slowing down and “grinding gears” the moment it jumps the guidance from curve 1 to curve 0 (the outside round) once I’m closer to 0 than curve 1. I assume AgOpenGPS is crunching away at the intercept calculations when it slows down.
  • Once it starts grinding away at the intercept for curve 0, it seems to play in slow motion. It still captures my path, even while I physically backup, but it takes sometimes two or three minutes to show it.
  • It captures the work switch and the manual activation/deactivation sound happens, but it is just as delayed as the path and sometimes doesn’t shut off the spray off on the computer while I back up.
  • It never happens on an AB Line, even when crossing AB lines at 90 degree angles and jumping from one to the other.
  • I have noticed that switching to guidance on say an AB Line from the AB Curve just before I come up to the corner prevents this whole debacle.
  • Once it starts grinding, pushing other buttons does not work until it catches up. In my mind I feel that hitting another button seems to make it speed through the crunching faster, but often Windows just says that the program isn’t responding during that time and it goes “foggy”. I’m not sure if its really faster though–too many variables.
  • I’ve tried to replicate it in the simulator without success.

Like I said, for me this isn’t a big deal. It only adds ten minutes to the whole field. I run AB Line with auto U-Turn after the two outside rounds.

Once seeding is over and everything settles down with this virus, I can bring my whole setup to you–it’s about time I got involved with the development anyway and I’ve been meaning to buy you lunch. In the meantime, I can get screenshots or start debugging if that helps. Thanks for all your hard work.

262

this probably doesn’t help, but i don’t have any hardware other than the surface pro connected via usb-C to as shipped ardusimple rover talking to ardusimple base. i was trying to establish a boundary at the time.

263

I need to check my versions. I downloaded the latest version this morning, worried I had an older one in the tractor, although actually I don’t think it is. Running the new version (with the corresponding .ino file) I found the WAS all over the place. Also, roll and heading were very very slow to respond. No resetting or anything seemed to make any difference, so I gave up and reverted to the version I was running previously, leaving the new .ino file on the arduino. The previous version was fine. Roll, heading and WAS back as they should be and it worked fine all day, maize drilling. Odd. :man_shrugging:

264

I finally have a fully working AOG system and I’m more than a little impressed with its performance. Blows my JD system out of the water.

Just to put a red herring into the lag discussion but I had two issues with AOG running slowly.

1:) I was messing about with the F9p and set it up to deliver all NMEA sentences. I use an esp32 connected via UART to f9p which collects the sentences then spits them out over UDP. ( I’ll post that code up when I write up my project on here.) all that data going to AOG made everything slow. I wrote a filter into esp32 to collect everything but only send GGA & VTG messages out on UDP - AOG worked fine (or so I thought).

2:) after a week of frustration trying to get it to steer properly I noticed that AOG seemed to be a second our so behind where we were physically. I reconfigured the F9p to only send out GGA & VTG @ 10HZ and it instantly resolved the problem.

I’m running AOG on the slowest of slow 5 year + atom tablet.

Is probably not related but it looks like AOG doesn’t like being bombarded with data. I’ll check out the boundary contours when I have a chance and check performance again.

There ought to be a beer kitty setup for Brian and the team, id put in a barrel… The software is brilliant.

2 Likes
265

@BrianTee_Admin
Here is the tram kml writer to add to the FileSaveFieldKML() ,if you’d like. I put mine after the recorded path. By default it is off.

Edit: Field and boundary is separate.

            //Tram TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
            kml.WriteStartElement("Folder");
            kml.WriteElementString("name", "Tram");
            kml.WriteElementString("visibility", "0");

            //Tram Boundarys

            kml.WriteStartElement("Folder");
            kml.WriteElementString("name", "Tram Boundary");
            kml.WriteElementString("visibility", "0");

            linePts = "";

            //outer

            kml.WriteStartElement("Placemark");
            kml.WriteElementString("visibility", "0");

            kml.WriteElementString("name", "Tram Outer");

            kml.WriteStartElement("Style");

            kml.WriteStartElement("LineStyle");
            kml.WriteElementString("color", "5514F050");
            kml.WriteElementString("width", "2");
            kml.WriteEndElement(); // <LineStyle>
            kml.WriteEndElement(); //Style

            kml.WriteStartElement("LineString");
            kml.WriteElementString("tessellate", "1");
            kml.WriteStartElement("coordinates");

            for (int h = 0; h < tram.tramBndOuterArr.Count; h++)
                linePts += pn.GetLocalToWSG84_KML(tram.tramBndOuterArr[h].easting, tram.tramBndOuterArr[h].northing, 0);

            kml.WriteRaw(linePts);

            kml.WriteEndElement(); // <coordinates>
            kml.WriteEndElement(); // <LineString>

            kml.WriteEndElement(); // <Placemark>

            linePts = "";

            //inner

            kml.WriteStartElement("Placemark");
            kml.WriteElementString("visibility", "0");

            kml.WriteElementString("name", "Tram Inner");

            kml.WriteStartElement("Style");

            kml.WriteStartElement("LineStyle");
            kml.WriteElementString("color", "5514F050");
            kml.WriteElementString("width", "2");
            kml.WriteEndElement(); // <LineStyle>
            kml.WriteEndElement(); //Style

            kml.WriteStartElement("LineString");
            kml.WriteElementString("tessellate", "1");
            kml.WriteStartElement("coordinates");

            for (int h = 0; h < tram.tramBndInnerArr.Count; h++)
                linePts += pn.GetLocalToWSG84_KML(tram.tramBndInnerArr[h].easting, tram.tramBndInnerArr[h].northing, 0);

            kml.WriteRaw(linePts);

            kml.WriteEndElement(); // <coordinates>
            kml.WriteEndElement(); // <LineString>

            kml.WriteEndElement(); // <Placemark>



            kml.WriteEndElement(); // <Folder>

            //Tram Field

            kml.WriteStartElement("Folder");
            kml.WriteElementString("name", "Tram Field");
            kml.WriteElementString("visibility", "0");

            linePts = "";
            string side = "a";
            int cnt = 1;
            for (int i = 0; i < tram.tramList.Count; i++)
            {
                linePts = "";

                kml.WriteStartElement("Placemark");
                kml.WriteElementString("visibility", "0");

                kml.WriteElementString("name", "Tram " + cnt+side);
                if (side == "a") { side = "b"; } else { side = "a"; cnt++; };
                kml.WriteStartElement("Style");

                kml.WriteStartElement("LineStyle");
                kml.WriteElementString("color", "5514F050");
                kml.WriteElementString("width", "2");
                kml.WriteEndElement(); // <LineStyle>
                kml.WriteEndElement(); //Style

                kml.WriteStartElement("LineString");
                kml.WriteElementString("tessellate", "1");
                kml.WriteStartElement("coordinates");

                for (int h = 0; h < tram.tramList[i].Count; h++)
                    linePts += pn.GetLocalToWSG84_KML(tram.tramList[i][h].easting, tram.tramList[i][h].northing, 0);

                kml.WriteRaw(linePts);

                kml.WriteEndElement(); // <coordinates>
                kml.WriteEndElement(); // <LineString>

                kml.WriteEndElement(); // <Placemark>
            }

            kml.WriteEndElement(); // <Folder> 
            kml.WriteEndElement(); // <Folder>   

            // End of Tram.TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT

image

3 Likes
266

Had basically the exact same problem I chased for awhile…Kaupoi posted a ublox configuration file that solved it all for me anyways… runs in real time no lag or “playback” https://discourse.agopengps.com/t/v-5-beta/4678/283V 5 Beta - #283 by Kaupoi

267

Interesting, Although dont think that is the cause of my problem as am using MTZ ESP dual gps, and F9P configs, which already have all the un-nessercery stuff turned off as far as im aware…

268

:+1: :+1:

269

An update to some problems / bit more info on the delay issue…

So good news, and bad news…

The good news, is that I can confirm the problem with there being a 1-3 second delay between hitting the steer button, and the wheels moving, is almost certainly related to the issue with it steering really badly / really struggling to find the line…

I set out today to make some videos, and logNMEA of the problems I was having…however having entered the field and tested the steering, I knew instantly something had changed, as today, there is absulutely no delay at all when hitting steer, Its just as it was with 4.3, the wheels are moving the second you touch the steer button! And sure enough, with no fine tuning even, it steers 1000x better! And finds the line much better, maybe not quite perfect as still overshoots a tad, but in comparison to yesterday, its 10,000x better, absulutly useable now!

The bad news is, I have changed absulutly nothing between yesterday and today…So now have no idea what could be going on, and if it will return another day?

This is with PP to…and I had never got PP to work on even 4.3… So big change here!

Have attached a cople videos and NMEA log anyway…

First video is just showing the steering reaction in drive mode stood still. (Sorry for the complete fail with screen record, thought I had it recording the entire screen, but somehow was not, so still cant see it all even now!):

And video of it in the field:

If anyone wants the NMEA log PM me / message me on telegram and ill send it over.

270

Is there a written procedure or video to adjust all parameters of the autosteer. Gain, pwm min, p max, and parameter of pure pand stanley

271

I have attempted to fix the delay issue some are experiencing. There is a new version to try. I’ll make a new topic.

https://github.com/farmerbriantee/AgOpenGPS/releases

272

Seeding caught up to me way to fast this year, there is a manual that describes the functions at the top menu, Manual or Help. I will make one showing tips and tricks as seeding winds down.

2 Likes
273

OK thanks Brian

274

The steering test window allows you to change the steering angle by 1 degree. In my experience, a resolution of 0.1 degrees is needed to correctly set the hydraulic valves. Most of the corrections during automatic driving are between 0 and 1 degree. For setting, instead of arrows, I use the slider to set the sensor 0 where I can set values ​​less than 1 degree and only then you can see if the control is working well or badly and you can tell when the vehicle is stationary. The most difficult and KEY when adjusting the hydraulic valves is to find the optimal minimum PWM value, it is not possible when you increase the error by 1 degree. You click 1 degree left or right and you see how the plumbing is beautifully pulling the green line, you think it’s ok. But you change the sensor 0 every 0.1 degree and you see that, for example, up to 0.8 degree error nothing happens and only at 0, 9 pulls to the correct level. With such testing, every 0.1, you can only see what needs to be improved, you can test different frequencies for better detachment of the slider, etc.
So our beloved programmers, maybe when introducing some changes, it would be worth adding the possibility of test control every 0.1 degree, it will certainly facilitate the calibration of settings, especially of hydraulic valves.

3 Likes
275

WAS sensor, bad contact?

276

Instead of using the 1 degree steps to find min PWM, use the min PWM slider. So set P to 0, set 1 degree error then adjust min PWM until the valve or motor barely activate. Check both directions.

3 Likes
277

I have also had a heck of a time with a steer issue as well. One moment it steers like a dream and the next it snakes back and forth trying to find the line. I am assuming its the delay issue I have read about. I will update and report back with my findings. Also I find it flips around and wants to drive in reverse quite a bit.

278

I do what you say but this way you can get a preset and it will usually be too low. If you want precise steering without swinging the wheels, you need to check how the system reacts to a 0.1 degree error. If you can set a 0.1 degree error then of course you can use the minimum PWM slider and find the value that will correct this error, if you are able to set the valve to correct every 0.1 degree then you have what you need.
This is the only way to diagnose the correct operation of the valves, it is not always possible to set the exact response to 0.1 degree error and then you have to look for the causes in the hydraulic system, but you can only see all this if you look at the response to a 0.1-0.2 degree error not 1 degree.

I made the PWM settings in this tractor at a standstill, observing the reaction to a 0.1 degree error. Until recently, like everyone else, I observed the reaction to deegre 1 and did not have good results, it was only when driving that I had to look for good settings.

3 Likes
279

Be sure to download version 5.1.5 !!

280

I had this behavior too. I think it is related with cmps14 and roll but maybe I am wrong. What setup are you using ?