|
|
|
![]() |
|
|||||||
|
||||||||
This is the first step of my solution to the programming challenge proposed here last week. It scales linearly with dimensions and logarithmically with iterations. A 3d visualizer will be coming soon.
03-07-2015 11:08
SenorZThis visually reminds me of a research project I did in college. Trying to find out if a branched dendrimer chain (polymer) could form a hollow ball, or if it would "fill in".
Always filled in.
03-07-2015 14:23
faust1706To add context to this because I feel most people don't understand the significance of this:
Marlow (re)created a n dimensional path finding algorithm that is magnitudes times faster than the standard a* algorithm. While the path constructed is virtually never the most optimal path, it finds the path fast enough such that it can be implemented in real time and does not matter how refined the grid is because it uses a floating point grid at all times. With a trajectory smoother algorithm, a discrete path using this RRT (rapidly exploring random tree) may be found, and then smoothed using gradient descent in real time.
This is what the robots in the DARPA robotics competition were doing in real time when they were climbing over debris or getting their hand in position to turn a valve, except the search space had many more dimensions than 2.
03-07-2015 19:08
MarlowTo expand on @faust1706's explaination:
My method constructs 2 RRTs, one from the initial state, the other from the goal state. The program is constructs these 2 trees independently and simultaneously. After every few iterations, the program checks to see if the shate a point, or roughly share a point, in space. It goes until they do, then the path is going down the tree based at the initial starting point and then it goes up the goal tree from the shared point.
While this method isn't the greatest for low dimensionality search spaces, it shines when the dimensions start getting big as it scales linearly with dimensions.
I'm curious to see if any team will ever actually implement this. Alas I don't think teams have the ability to given the amount of moving pieces it has. It seems like it'd be a nightmare.
03-07-2015 19:25
MarlowTo expand on @faust1706's explaination:
My method constructs 2 RRTs, one from the initial state, the other from the goal state. The program is constructs these 2 trees independently and simultaneously. After every few iterations, the program checks to see if the shate a point, or roughly share a point, in space. It goes until they do, then the path is going down the tree based at the initial starting point and then it goes up the goal tree from the shared point.
While this method isn't the greatest for low dimensionality search spaces, it shines when the dimensions start getting big as it scales linearly with dimensions.
I'm curious to see if any team will ever actually implement this. Alas I don't think teams have the ability to given the amount of moving pieces it has. It seems like it'd be a nightmare.
03-07-2015 20:25
kylestach1678|
I don't think teams have the ability to given the amount of moving pieces it has. It seems like it'd be a nightmare.
|
03-07-2015 20:59
MarlowIt'd be cool to see a robot recalculate its autonomous every game, though.
03-07-2015 21:21
GeeTwo
I cannot tell where the start or end points are; I thought this was searching from one point (presumably 57, 56), not two. It would be helpful if the nodes were color-coded by the iteration number. If it would not be too cluttered, displaying the obstacles would be nice, as well.
Finally, I'm not sure if I misread the original problem statement, but I understood that the goal was to optimize the route, not the search for any route. In optimizing the route, you would probably want to use the corners and edges of the obstacles as search nodes, as well as random points away from the obstacles. This tactic would also help locate paths through narrow gaps that the unconstrained exploring tree would be likely to miss.
03-07-2015 22:07
kylestach1678|
It'd be cool to see a robot recalculate its autonomous every game, though.
|
03-07-2015 22:16
kylestach1678|
It'd be cool to see a robot recalculate its autonomous every game, though.
|
03-07-2015 22:52
Peter Johnson|
That won't really be necessary until there is a game that has an autonomous where things aren't in the same place every time. Autonomous endgame, anyone?
![]() |
04-07-2015 11:55
Marlow|
I cannot tell where the start or end points are; I thought this was searching from one point (presumably 57, 56), not two. It would be helpful if the nodes were color-coded by the iteration number. If it would not be too cluttered, displaying the obstacles would be nice, as well.
Finally, I'm not sure if I misread the original problem statement, but I understood that the goal was to optimize the route, not the search for any route. In optimizing the route, you would probably want to use the corners and edges of the obstacles as search nodes, as well as random points away from the obstacles. This tactic would also help locate paths through narrow gaps that the unconstrained exploring tree would be likely to miss. |