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.
That’s great!
Very nice. What kind of tree?
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.
Poplar Trees
i will try soon.
so will it be possible to go in reverse?
However…after a few hours I learned to stop in the exact spot on the first try.
Trying to do reverse. Will need to test. May get hung in reverse. I’ve seen this happen a few times in the simulator.
Hi KentStuff why don’t you put your AogTree modified source code in github?
Here it is. Ugly, but here it is. It is not linked to update with the commits.
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!
@KentStuff - Did you draw the boundries in Google Earth? It’ll make a good way to trim around trees.
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.
When you get it all done could you make a vid on how to do that? 
Well there is the problem. When is done? Or should I ask “What is done?”
Understand. If it can do that, can it be made to do this? It never ends. I am interested to see how you do this in the code.
(When you’re done with it.)
This is the routine to as the boundary.
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.
But why would it shut off a run that is not part of the path? Normal abline with no obstacles. You can see this in the first image.
A glitch in the gridlines maybe.
Also weird action on why has it not chosen the shortest path around each tree?
A bit more testing. I found the bug. When creating the boundary, you must run PreCalcBoundaryLines before and after FixBoundaryLine. The FixBoundaryLine may or may not remove one line segment then it does not match the calcList. Then you have a mess. The first run with the diamonds, I had both. Then I got smarter than it was and removed one because “it must be a typo.” Works much better now. The drive around function can still crash if an inner boundary is too close to an outer boundary. It does not know what to do.
Been there, done that. Proves we get dumber as we age.