Path planner auton

[marvalarva2929]

The custom Odometry has proved to work to the thousands place and the new Kinematics algorithm has proved to be just as useful.

There is no logical reason at this point to move to SDK when we already have working code.

Global angle PID will be much easier to implement with a simulated pose as well.

If any of you really wish, we can implement the old kinematics algorithm inside the Kinematics.java class and only use the matrix stuff for Odom.

[marvalarva2929]

Another added benefit of this kinematics algorithm is that it runs off of velocities (scaled from our max velocity) rather than a 0-1 scale. This makes it easier to work with when we want precise movements based off of actual units.

[DragonflyRobotics]

We are following a professional git structure called Github Flow. This involves having feature branches merge to development and development merging to main. Also, the approval system's purpose was to ensure that massive code changes that the team didn't help write get pushed to major branches. I would like to continue debugging the spinning problem before jumping into things like this. This also uses the kinematics we didn't write as a team, so I am skeptical to approve the commit. We can work together to make changes Thursday.

[InvisibleTiger]

As Krishna mentioned earlier, we adapted GitHub flow which helps us have a proper commiting system with one branch containing live changes and the main containing final and polished code, hence don't want major rehauls of code pushed to any of the major branches such as main dev etc until we have approval from the entire team. The other thing to note here is that this code is using the kinematics that was causing problems with Module 4, and the reason why we didn't have this error yesterday was because we were using the old kinematics, the one that we tested to work so it doesn't feel great to approve this code to the main branch. I am more than happy to talk more about this in future meetings.

[marvalarva2929]

As Krishna mentioned earlier, we adapted GitHub flow which helps us have a proper commiting system with one branch containing live changes and the main containing final and polished code, hence don't want major rehauls of code pushed to any of the major branches such as main dev etc until we have approval from the entire team. The other thing to note here is that this code is using the kinematics that was causing problems with Module 4, and the reason why we didn't have this error yesterday was because we were using the old kinematics, the one that we tested to work so it doesn't feel great to approve this code to the main branch. I am more than happy to talk more about this in future meetings.

I think I've given ample evidence that Module 4 was not due to the kinematics. The new code was working for several days before the issue arose, and even after switching back to the old code the problem wasn't fixed. We we're even able to fix the issue with module 4 during a period 5 class (I think you remember, it was me, you, and Matthew).

I suspect the issue with Module 4 is due to something else entirely.

Anyways, this isn't the best place to hold a discussion. We should, like you said, discuss this at a future meeting.

[marvalarva2929]

We are following a professional git structure called Github Flow. This involves having feature branches merge to development and development merging to main. Also, the approval system's purpose was to ensure that massive code changes that the team didn't help write get pushed to major branches. I would like to continue debugging the spinning problem before jumping into things like this. This also uses the kinematics we didn't write as a team, so I am skeptical to approve the commit. We can work together to make changes Thursday.

My apologies. I was not entirely aware of the process.