V5.1.4 Release

Hello ,Releases · farmerbriantee/AgOpenGPS · GitHub
Download AgopenGPS V5.zip + support.zip
Unzip the files
Launch the AgopenGPS application (in the Agopen_v5 folder)

Any one have settings for v5 with an outback bang bang valve? Cytron controller? Also how well will it work without compass and tilt sensor?

About the ReadExisting, I was testing V5 and the display wasn’t updating, just sitting still. After several minutes while sitting still, the display showed the tractor making the border. I thought this was very weird until I read this thread tonight. I think what happened was I stopped the main task but left the AIO task running (it doesn’t seem to stop when the main task is stopped) and then I restarted the maintask. I think what happened is the AIO kept buffering the GPS data and built up a several minute lag. I am very new to this and it is probably my error, just thought I’d put out what I observed. Using Ardusimple.

It really shouldn’t do that at all, AgIO should just keep sending the GPS data on the internal udp network (loopback) and not care or store anything waiting for AOG.

Nothing i have, or anyone in the dev group has any device this happens on, but it seems to happen on a few systems. I can not figure out why it does that for a few devices.

So if you run them both, this does not occur? But if you turn off AOG and keep AgIO running, it will do this? Will it do it consistently? Any idea as to why?

Can you describe your setup in detail including make/model etc?
single or dual antenna? IMU? Sentences used - like everything in excruciating detail lol.

Surface Pro 7, windows 10. Ardusimple setup from probably a year ago using Long Range radio config as ordered. Have not changed the GPS parameters at all. Looking for a very simple solution, just lightbar, for applying some fertilizer and spraying for weeds. I have no real farming use, just a hobby. Been following forever it seems just because it is interesting. I grew up on farm and then spent 40 years in commercial data processing and now retired, so I just like technology. Loaded up 5.0.4 I think (when I started reading this thread and saw a new version, I deleted the previous folders) and was driving side-by-side in yard with base and rover both active; GPS status = fix. Sitting in yard trying to configure tractor and sprayer so AIO is active and GPS is active but I am just setting there. When I thought I had the config done I saved and started a field. This was my first time through this so I was fumbling a lot, at some point stoped Agopengps and restarted it. I left AIO running so I don’t think it started when I restarted Agopengps. Anyway, started driving a large circle to set boundry and the image on the screen didn’t move, it just set there. I was touching the icon, the red/green line for the implement, the side on/off buttons, everything I could think of to try to get it image to move. Nothing. Completed circle and stopped wondering what was up and in a few minutes, the image started to move and made the boundry I had just finished driving. This really confused me, but I went ahead and tried to set a ab line, but again nothing moved and after crossing the large circle and turning around I stopped and in a few minutes it drew the ab line. At this point I shut everything down and decided to look at the group thread where I saw the entry about a lag in the gps data. Thought I’d just throw this out. I will load current version and make sure all is in sync and try tomorrow. I am very impressed with all the work on this project and know from experience how large of an effort it is to pull this off.

To help Brian and the other developers to diagnose the fault, you must tell the exact date of download.
The version 5.1.4 even got a AGIO update 2 days after first release, so do you use newest from 14 days ago?

Vili uses a surface, has no problems whatsoever. It is a seriously good tablet.

For sure, delete all the previous stuff, download the very latest release and give that a try.

Hi Brain,
I have been experiencing the same lag issue as described above. I am still using version 5.1.3
I use a surface pro 4, pcbv2, cmps14 connected to a nano via usb, and ardusimple LR kit base and single rover. ardusimple is configured for VTG and GGA 10HZ.

First I must say I am not a computer person at all.
When I turn my system on I turn on pcbv2 first then start AOG. When I reach field and create a boundary the tractor on screen doesn’t start moving right away and stays moving for up to a minute after I finish. At first I thought I had the Baud rate on the gps wrong so I changed it. That fixed the problem for that day. The next time I used aog I had the same problem, changed baud to a different setting, problem fixed. Next use lag again, this time all I did was disconnect and reconnect gps in agio and the problem was fixed. Seems to me that the problem might be with the order that I start things?

Anyway not sure if this helps or not, just my observations. Planted corn this year with autosteer thanks to AOG, never would have bought a commercial setup. Thanks so much for this program, I’m having a blast.

Neil

P is the size of the correction the output will make in relation to the error, How much in one step to turn the wheel
I is the time constant to re calculate the error (the reaction of this is heavily dependant on controller algorithm, also can be in inverse units depending on controller) How many steps in a given period to turn the wheel
D is rarely used unless its a system with a big capacity like a large tank filling with water. It will crank the output wide open or closed depending on how far outside the set point you are.

Have finally got around to installing V5 today on my existing setup to start playing / testing…

Some initial issues / problems…

1 - I cant seem to find the min speed setting? Used to be in the module settings… Reason I ask, is it seems / looks like there is currently a 1kph min speed? As until I get over that speed it never seems to steer? Which is a problem for me as we do alot of veg work under 1kph…

2 - I still cant seem to get PP to work well at the moment… I could never get PP to work very well with 4.3 either, but I get the impression PP seems to be the future / best way fowards, and will give much better control on sidehill / high draft sitations, which is really my only problem with 4.3, so would really like to get PP working better… Stanley seems happy enough from some quick testing in the yard, but PP still seems to struggle to get quickly and smoothly on the line, and wonders more than I would like…

3 - It dosnt seem to steer in reverse right now? (I use Dual GPS over ethernet)…4.3 would steer perfectly in reverse which is extremely useful on some jobs that require turning inverted on the ends as it lines you up perfectly for the next pass…Will this be returning at some point in the future (not a big issue just a very nice feature if and when it can be there again!)

Does anyone else with a Hydraforce valve and Dual GPS have V5 up and running / any input on settings to get things working well with PP?

I also had a lot of lag problems. To anyone struggling with this, my first advice check groundings in your setup, and make sure the tablet/pc power supply uses a reliable common ground with the autosteer system. After a lot of investigating I noticed I had a loose connector for my tablet charger, fixed that and never had the problem since.

1 Like

Mine is all connected with UDP, cant see how a tablet ground would effect anything? You shouldnt need any grounds at all with ethernet…?

Probably not your problem then, but might help @jrd and @FarmerNeil. Their issues look a lot like mine.

For sure download the latest 5.1.4 as a start. That is so strange. The fact it will play in real time like a taped version is beyond puzzling. The only thing that can do that is the serial buffer /usb in. But why it wouldn’t just catch up, i have no idea. This is quite frustrating for certainly users and myself because it seems impossible to replicate.

I even used the debugger in AgIO, pausing the program as serial was coming in, resumed it after 10 to 15 seconds. Recorded both the incoming timestamp from gps and the timestamp when AOG got the parsed udp sentence - within milliseconds. It also took less then a second to parse the few hundred sentences that were backlogged.

This problem is 100% driving me bonkers!!! But yes, try 5.1.4

Is someone maybe willing to sent you his tablet with “malfunction”? :face_with_monocle:

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.

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.

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:

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

@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