Add pathfinding functionality

[snowsignal]

This doesn't execute commands to move the robot yet, because I want to build that off of our own command system, but the class at least exists now.

[snowsignal]

Made requested changes.

[andrewda]

Okay I'll merge once it starts to do stuff.

[andrewda]

Pretty minor because I can fix it manually, but please use imperative tense in the future. Add blah instead of Added blah.

[snowsignal]

Added things that do stuff, like you requested.

[andrewda]

Also I was wrong, please add the pathfinder jar and fileTree stuff. You're going to need Pathfinder-JNI and Pathfinder-Java. See: https://github.com/Open-RIO/GradleRIO/commit/86eda2a4afc0eaf27626adbba511a51260fbb26b#diff-1373a7db9df0e916c1cf63b9aec8f0e4R113

@SUPERCILEX: How is Jaci hosting Pathfinder?

[andrewda]

Yea, taking a step back and looking at this, it seems to just complicate things, not make anything simpler, which is the point of the Sertain Framework.

[snowsignal]

I don't really see what it is complicating here. @SUPERCILEX, could you elaborate on what part of the code has the potential to be bug-ridden, as you mentioned?

Also, @SUPERCILEX , I don't quite understand what you mean by 'hard-coding the units', since virtually all elements that go into the trajectory generation can be modified via the configureTrajectory function. The ones that are hard-coded are because they remain constant regardless of the robot path we are generating or the field we are on.

My biggest question is, if this is the wrong approach to aliasing the PathFinder library, what is the better way?

[andrewda]

I still don't see why we need to alias Pathfinder?

And right now generateEncoderFollowers() isn't returning anything so how are we going to get our encoder followers?

[snowsignal]

You can access the EncoderFollowers using PathController.left and PathController.right, defined at the end of the generateEncoderFollowers() function.

I thought we were going to alias PathFinder because we wanted a path generator for this library?

[andrewda]

I guess I don't really see the use of running generateEncoderFollowers() if it's just going to initialize stuff? That could probably be built in more smoothly.

If we do want a path generator in Sertain, then we should probably consider doing it ourselves. It's not that much code (see: meanlib) and it would be well worth it to have a better understanding of how path finding works. I just don't see much of a use aliasing Pathfinder here, unless it's made significantly easier and cleaner, which is difficult to do since it's already a pretty well written library.

[snowsignal]

The reason for creating generateEncoderFollowers is so that other configuration functions like addPath and configureTrajectory can be run first to set up the variables.

I mean, we could make our own path generator, but don't we want to avoid unnecessary complexity?

[SUPERCILEX]

I'll explain more at robotics, but:

• You're using an object which means state is shared and not synchronized across threads. That's very bad and scary, ideally everything is immutable.
• Performance will take a hit since you're wastefully copying lists
• Iteration is made more difficult since you're essentially wrapping a list without implementing the full interface.

I'll show you what we can do with Kotlin's extension functions and a few other niceties from the language.

[snowsignal]

OK, thanks for the clarification.

[andrewda]

Here's my ideal Path library:

• Create a new Path class which we pass a list of Waypoints and configuration options which won't change (distance between wheels, wheel diameter, delta time, PID etc.)
• An initialEncoderPosition (or similar) which we can set whenever, right before beginning to use the path. Maybe also be able to pass it in the Path above.
• Begin accessing the information with a call to path.fetchLeftSpeed(encoderValue: Int) (or similar).
• Maybe some other features as we discover what we need today.

[snowsignal]

OK, cool! I'll rewrite the code when I can.

[andrewda]

We should discuss at robotics and see how we're actually going to be using the library first. Might also be nice to integrate it with some deeper autonomous tools, like an AutonConfig that I discussed in the Google Doc.

[snowsignal]

Are we good to go, @andrewda and @SUPERCILEX?

[snowsignal]

Made requested changes.

[SUPERCILEX]

Will take a look

[andrewda]

Let's test this out on robot before merging.

[snowsignal]

Good idea.

[andrewda]

Compile latest Pathfinder from sources (https://github.com/JacisNonsense/Pathfinder)

[SUPERCILEX]

Thanks!