Heading vs Holonomic Rotation for holonomic drivetrains

[JCodeShelver]

It seems that when doing on-the-fly path generation, the constructors for PathPoints require passing in a heading before holonomic rotation. For drivetrains with holonomic rotation, wouldn't setting internal points' heading (that is, the wheel directions) towards the next point's position be optimal?

Edit - Correction: wouldn't using the derivative at that point be optimal (towards next point isn't optimal as points could be relatively far where a line towards them (a secant line of the curve) is not remotely close to the tangent line (which would help keep the curve smooth)

[mjansen4857]

I don't think so. The start and end heading would need to be specified at a minimum, and I think having control over the heading at every point is better than having it be automatically determined which could mess up in a lot of situations. The generator has no knowledge of the field, and a calculated heading could cause a path that hits something. The heading at each point really needs to be left up to you. An overload could be added, but I think that would just introduce a lot of confusion. Most of what the generatePath methods should be used for can really be done with just 2 points anyways. It's not really great for doing large paths across the field or anything like that. I have stuff on the backlog for next year that should be good for that which will likely be much better than this would be.

[JCodeShelver]

Ah, I was just wondering because I've been working on some code that performs OtF trajectory generation for a swerve chassis, and we're about to implement A* (though I'm looking to see if there's better alternatives just in case) and get a list of points to go from where we are to a desired destination and avoid obstacles in the process.

[mjansen4857]

Pretty much same thing I'm planning. I want to be able to load a map of the field and use some form of pathfinding algorithm (likely some A variant, but WPILib seems to be looking into informed RRT so I might look into that as well) to generate a full path from A to B anywhere on the field. It would also be cool to be able to pipe in some vision information too, such as detections of other robots, to automatically avoid them and what not. Obviously no shot of that for this season at this point.

If you're looking into doing something like A* yourself, then calculating the heading like this should be an easy addition. I just don't think it makes sense to add it to the library in a generalized way since it will probably be misused a lot, since people may see a simpler overload pop up in their autocomplete and decide to use that without understanding what it does.

[JCodeShelver]

I'm trying to find a solution that doesn't decrease how optimal the solution is due todiscretization of the problem, and that is smooth with splines. I also am trying to find a solution that someone made for a robot, because that takes into account that it has width and isn't a point.

[JCodeShelver]

Pretty much same thing I'm planning. I want to be able to load a map of the field and use some form of pathfinding algorithm (likely some A variant, but WPILib seems to be looking into informed RRT so I might look into that as well) to generate a full path from A to B anywhere on the field. It would also be cool to be able to pipe in some vision information too, such as detections of other robots, to automatically avoid them and what not. Obviously no shot of that for this season at this point.

If you're looking into doing something like A* yourself, then calculating the heading like this should be an easy addition. I just don't think it makes sense to add it to the library in a generalized way since it will probably be misused a lot, since people may see a simpler overload pop up in their autocomplete and decide to use that without understanding what it does.

I've spent the past 4-5 hours looking into continuous alternatives (ie not requiring discretization). I found a 2016 paper that looks promising. I think I'll generate a straight line to the target point from the current position, and everywhere it intersects an object, deform the line to avoid it. Then I'll sample my object functions (gaussian functions) and when any contribute a "significant" change to the input (deforming to avoid an object), I'll add that point to my collection, then feed all the positions into PathPlanner.

[JCodeShelver]

Pretty much same thing I'm planning. I want to be able to load a map of the field and use some form of pathfinding algorithm (likely some A variant, but WPILib seems to be looking into informed RRT so I might look into that as well) to generate a full path from A to B anywhere on the field. It would also be cool to be able to pipe in some vision information too, such as detections of other robots, to automatically avoid them and what not. Obviously no shot of that for this season at this point.

If you're looking into doing something like A* yourself, then calculating the heading like this should be an easy addition. I just don't think it makes sense to add it to the library in a generalized way since it will probably be misused a lot, since people may see a simpler overload pop up in their autocomplete and decide to use that without understanding what it does.

I've been trying to figure out if I can use the velocity of the states to change the headings (using tangent lines, by interpolating a given point with the next point by a small time step to get a slope that is close to the tangent line) but realized that the PathPlanner.generatePath() method returns a PathPlannerTrajectory object which has no getters or publically visible fields for the points, rather, the method converts the points to states. I could yield, and settle for using the angle of the secant line between each point to the forward direction, given I have all of the points before calling generatePath(), but I would like to use tangent lines if possible.

[mjansen4857]

Had someone else message me about the same problem on CD, so I'll tell you basically the same thing I told them. What I would try doing is fitting a bezier curve to the points you get from your A* algorithm. This curve can pretty much be given right to pathplannerlib with the PathPoint class' withControlLengths method since bezier curves are used internally. You can then get the heading for each point of the fitted bezier curve with a tangent line.

Fitting a curve like this has worked well for me in a similar problem before, and is what I will likely try first when implementing this myself. A good fitting algorithm will also reject excess points that you don't need and help smooth out the path. It can yield pretty good results. Can't point you to a specific algorithm since I used a library before, but it should be fairly easy to find one with a google search.

It may be beneficial for me to add some sort of generation method that accepts a raw bezier curve and bypasses the PathPoint stuff to more easily support stuff like this. I will work on that soon.