Closed snowsignal closed 6 years ago
Made requested changes.
Okay I'll merge once it starts to do stuff.
Pretty minor because I can fix it manually, but please use imperative tense in the future. Add blah
instead of Added blah
.
Added things that do stuff, like you requested.
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?
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.
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?
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?
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?
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.
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?
I'll explain more at robotics, but:
I'll show you what we can do with Kotlin's extension functions and a few other niceties from the language.
OK, thanks for the clarification.
Here's my ideal Path library:
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.)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.path.fetchLeftSpeed(encoderValue: Int)
(or similar).OK, cool! I'll rewrite the code when I can.
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.
Are we good to go, @andrewda and @SUPERCILEX?
Made requested changes.
Will take a look
Let's test this out on robot before merging.
Good idea.
Compile latest Pathfinder from sources (https://github.com/JacisNonsense/Pathfinder)
Thanks!
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.