ΑΙ Turns driving outside field

[GeorgeEarslight]

Using AI turns it seems that the driver doesn't respect the field boundaries, either on the tractor or the implement (sprayer boom).

log.txt

[pvaiko]

There's a solution for these wide turns coming (on the beta branch), using a hybrid A* algorithm, that should fix this one too.

[Gibbanator]

There's a solution for these wide turns coming (on the beta branch), using a hybrid A* algorithm, that should fix this one too.

What the heck is that?

[pvaiko]

https://lmgtfy.com/?q=hybrid+a+star+algorithm

[Gibbanator]

Yep did that but how is that something we change in game? is this something we can adjust? using a hybrid A* algorithm?

[Tensuko]

Yep did that but how is that something we change in game? is this something we can adjust? using a hybrid A* algorithm?

This:

There's a solution for these wide turns coming (on the beta branch)

[GeorgeEarslight]

There's a solution for these wide turns coming (on the beta branch), using a hybrid A* algorithm, that should fix this one too.

Thank for the update Peter. Please ref this when you upload.

[pvaiko]

@Gibbanator hybrid A* is currently used by the combine self unload. But it is a generic solution for any movement planning with fruit and collision avoidance so it may be used in other areas as well, as I said it is coming for some wide turns.

[Gibbanator]

Thanks guys.. is clear now.. looking forward to the fix...

[pvaiko]

358.1 may work but you'll have to disable the AI Turns ...

[GeorgeEarslight]

@pvaiko Tested yesterday late night here but had AI-enabled; wasn't aware I needed to disable it. I'll try to test again today and report, I have some typical test cases with fences near the field edge.

[GeorgeEarslight]

You might also want to check this if you haven't already. https://github.com/AtsushiSakai/HybridAStarTrailer

[GeorgeEarslight]

@pvaiko It seems it's not using proper collision boxes to fit the path? The tractor's width is not taken into account, if you look closely the outer final ark is right on the field's edge, while it should have been offset by at least the tractors width. The implement's width is obviously not taken into account. Other than the generation itself seems to be working great. It backed up and draw the curve quite nicely. One final note, while generating the path the game stutters and I'm running on a fairly strong machine. If I can help with anything feel free to point me to something.

log.txt

[GeorgeEarslight]

OK, tested with a more realistic (and easy) case with 2 runs of the headland. This thing is magic, can I put it in my car, please? Seriously, if you manage to implement the collision boxes just use it for anything.

[pvaiko]

@GeorgeEarslight you can make the collision box visible with cpToggleDevhelperDebug or cpTogglePathfindingDebug (can't remember which one, the latter may crash the game if there is an extensive search, but at least it looks great :)

Currently the collision box of the implements (except combine headers) takes the size given by Giants but that size is used for dropping it on the map after you buy them so it'll be the unfolded size. I can easily change that to use the AI markers but then spreaders/sprayers which are a lot smaller than the work area are suboptimal and I don't currently know how to easily determine the physical size of an implement.

Also, if it is towed the rotation of the implement's bounding box should be considered too which it isn't at the moment...

[pvaiko]

just use it for anything

Yeah, that's the beauty of it, it can also reverse and calculate any turn maneuver, at least in theory. There are still some issues there but you can see it working in the combine unload feature, I saw it doing a 3 point reverse turn between two trees.

I also have the Dubins path implemented which does the same (no reversing) without fruit/collision avoidance.

Looking for a volunteer to port a Reeds-Shepp path algorithm to Lua to have reversing too.

[pvaiko]

One final note, while generating the path the game stutters and I'm running on a fairly strong machine.

I'm using coroutines to spread the iterations over multiple update loops but it will slow down the game. Still not sure if my implementation of the algorithm is as efficient as possible.

If I can help with anything feel free to point me to something.

Any help is appreciated. For example the next step would be to make this reverse with towed implements (like your link)

[GeorgeEarslight]

For starters, I can offer the F5 hitboxes. Not sure if they're the same at the toggle commands you mentioned, because none changed anything on my screen.

[pvaiko]

Oh, sorry, those work only for developers, you can PM me if you want that enabled or enable yourself, just search for sonOfaBangSonOfaBoom.

I use rectangles for simplicity so what I'd need is the definition of the bounding rectangle(s) of the vehicle/implement as in PathfinderUtil.VehicleData:calculateSizeOfObjectList(). These are then used findCollidingVehicles and findCollidingShapes.

So I don't think that the aiCollision boxes would be good for this as they don't seem to correspond the actual vehicle size (and are also translated forward)

[GeorgeEarslight]

sonOfaBangSonOfaBoom... amazing. Anyways here's the box, if you're feeding the algorithm should it, in theory, try to avoid the field's edge?

Concerning the hitboxes I was talking about the fine wrappers lining the implement and tractor, not the AI crash prevention boxes. No idea if those are retrievable from the game engine.

Here's the box on the course

And here's the field's edge

[pvaiko]

if you're feeding the algorithm should it, in theory, try to avoid the field's edge?

No, for two reasons:

1. being off the field does not make a state invalid, it just penalizes it. This is because we prefer staying on the field but as long as there's no collision, driving off the field is valid, at least is still better than not finding a path at all.

2. out of pure laziness I check with a hard coded 3 by 3 meter box for field and fruit, which as long as #1 is true is I think adequate.

By playing with the area size and the penalty in PathfinderUtil.getNodePenalty() one could probably get the path further back from the field edge but in your case you have to consider that the implement needs to arrive at the row start aligned with the row which needs some space too, depending on the turning radius. I think that tractor has a big one, or the implement requires a bigger radius.

[pvaiko]

@GeorgeEarslight also, with F5 you may see the individual (blue) rectangles actually used in pathfinding when you have the debug info toggled.

[GeorgeEarslight]

the implement needs to arrive at the row start aligned with the row which needs some space too,

And this is where the repo I linked earlier might come in handy. The guy uses a pair (tractor+trailer) of models where each has its own grid and heading. I have some catching up with this stuff, hopefully I might help somehow.

PS. Saw the blue boxes, they're adequate I think.

[GeorgeEarslight]

Tested with penalty = penalty + 99. It's better in the sense that the path was further away from the edge, so it cleared the fence poles with some nudges and also aligned itself on the new row with a nice reverse. It still didn't totally avoid the edge, even with the absurd cost.

[pvaiko]

According to the Giants folks the best way to figure out the size of an implement is using the size markers (AIImplement:getAISizeMarkers())

[Tensuko]

What is the status of this ?

[Tensuko]

Should be fixed with V397. If anything, let us know with channel 7 9 12 and 14 active.

Closed.