mmmh … there must be some bug with the step distance, sometimes another problem happens. if I register the boundaries of the field with the tractor the field will be much larger than the real one and the trees do not have the right distances.
This one allows the user to turn off or on the filter and allows the user to select the minimum speed.
The default for this program is fix to fix 1.0. Minimum speed is 0.6 per the original AgOpenGps. But the filter is on. Under display the filter can be turned off. Fix to Fix is under settings-data sources-heading. I do not know why the boundaries are larger. May try this one with the fix to fix set to 1 and then to 0.1. Same with speed.
Edit: I have removed the link for the reverse edition. I never removed the modification that allowed it to run in the simulator. I changed the if(!issimtimer) to if(issimtimer) I don’t think it will work at all outside of the simulator. It is still on github but there is no filter for the GPS.
I’m missed something. What does the smaller fix to fix do? Also what does the filter do? I won/t be able to try it out for real for quite a while here. (-10 F this AM)
The smaller fix to fix:
When using the heading fix to fix, the position will not move until the tractor has moved the fix to fix distance. Trying to get exactly on a point, it may stop short or long but not on the point. The smaller fix to fix should only be used if your GPS is very accurate. Otherwise it will drift horribly.
The filter:
The filter was used to get rid of the spikes in the heading variants and to eliminate the flicker when heading goes from 359 to 0. It does not work with the reverse system. I had to make the simulator work under the “fix” system to test the reverse. Turns out, I don’t believe that I removed that edit before I posted it. Therefore it probably will not work at all outside the simulator. I will fix it and re-post.
so there is no kalmann filter in the latest version?
I quickly tried the latest version, it seems there are no more bugs.
but why does the distance Y (L / R from the tree) increase when you move to the next tree?
If the button is green in the display settings, you are running the filter. But it is only in the fix to fix heading setting. It is not in the GPS or Dual, but never has been.
It is always looking for the closest tree. Not the next tree. I guess if there was a trigger that said we are finished with this tree?, or if y < 0 don’t use this tree. It would eliminate the option to back up when you over shoot it.
Here is the link for the reverse. I eliminated the need for a separate simulator heading calculator. It also works fix to fix. Someone give this a go and see if the reverse works in the fix to fix calculations.
So I asked AOG to build a boundary around each tree and then drive it. What do you know, It worked. @BrianTee_Admin you are a genius!!!. I’ve got some tweaking to do but wow!
No, they are built in AOG. When loading a tree from the file, build a boundary around it. Here I simply used a four point diamond to see if would work. Now it builds a “circle” to a given radius. Still just lines, just 20 of them.
public void AddBoundaryAroundTree(vec3 TreeCenter, double radius)
{
int bntct = bnd.bndArr.Count;
bnd.bndArr.Add(new CBoundaryLines());
turn.turnArr.Add(new CTurnLines());
gf.geoFenceArr.Add(new CGeoFenceLines());
bnd.bndArr[bntct].isDriveThru = false;
bnd.bndArr[bntct].isDriveAround = true;
vec3 vecPt = new vec3();
double theta = 6.28 / 20;
double c = Math.Cos(theta);//precalculate the sine and cosine
double s = Math.Sin(theta);
double x = 0;
double y = 0;
x += radius;
vecPt.easting=x+ TreeCenter.easting;
vecPt.northing = y + TreeCenter.northing;
vecPt.heading = 0;
bnd.bndArr[bntct].bndLine.Add(vecPt);
for (int ii = 0; ii < 21; ii++)
{
//apply the rotation matrix
double t = x;
x = ((c * x) - (s * y));
y = (s * t) + (c * y);
vecPt.easting = x+TreeCenter.easting;
vecPt.northing = y+TreeCenter.northing;
vecPt.heading = 0;
bnd.bndArr[bntct].bndLine.Add(vecPt);
}
//fix the points if there are gaps bigger then
bnd.bndArr[bntct].isTree = true;
bnd.bndArr[bntct].CalculateBoundaryHeadings();
bnd.bndArr[bntct].PreCalcBoundaryLines();
bnd.bndArr[bntct].FixBoundaryLine(bntct, tool.toolWidth);
//boundary area, pre calcs etc
bnd.bndArr[bntct].CalculateBoundaryArea();
bnd.bndArr[bntct].isSet = true;
}
And this is the portion of the Tree.txt reader that was modified. I had to move the Tree.txt reader to after the boundary reader because the main boundary has to be established first. I also turned the maze grid on so I could see what I was doing.
while (!reader.EndOfStream)
{
//read how many vertices in the file
int verts = int.Parse(line);
for (int v = 0; v < verts; v++)
{
line = reader.ReadLine();
string[] words = line.Split(',');
Tree.AddPoint(double.Parse(words[0], CultureInfo.InvariantCulture), double.Parse(words[2], CultureInfo.InvariantCulture));
Tree.ptList[Tree.ptList.Count - 1].index = Tree.ptList.Count - 1;
Tree.ptList[Tree.ptList.Count - 1].comment = words[5];
Tree.ptList[Tree.ptList.Count - 1].heading = double.Parse(words[1], CultureInfo.InvariantCulture);
vec3 treept = new vec3(Tree.ptList[Tree.ptList.Count - 1].easting, Tree.ptList[Tree.ptList.Count - 1].northing, Tree.ptList[Tree.ptList.Count - 1].heading);
AddBoundaryAroundTree(treept, 4);
}
}
CalculateMinMax();
turn.BuildTurnLines();
gf.BuildGeoFenceLines();
mazeGrid.BuildMazeGridArray();
Then when saving the boundary, I did a check to see if the boundary.isTree. If it was then don’t save it. I do have to say, it takes a few seconds to load the field. There is a small bug. When it is driving around or past the tree, at a point parallel to the front line and back line of the tree, it shuts the tool off for a split second. You can see it in the image below.
A pattern for sure, but I have no idea why it would shut off randomly.
It shuts off because the tool thinks it crosses a boundary momentarily. Path needs to be adjusted to slightly more than half machine width from a boundary.