Replaced FIRST's Mecanum Class with our own, Modified Lambda Joystick #1

Merged
ifgc merged 1 commit from ishan-test-3 into working 2019-10-01 20:26:14 +00:00
ifgc commented 2019-09-29 05:57:25 +00:00 (Migrated from github.com)

Alex and Jacob helped fix a thing where the Y axis wasn't eliciting the response from the motors we wanted, we ended up fixing it by fixing two values FIRST mecanum class (which i stand by the fact is wrong given the context of the rest of the code (or the rest of the code was wrong, but honestly which is easier to fix?)) and we did this by making our own custom class and replacing all instance of FIRST's Class in the code with ours

There were similar but completely unrelated problem with the (Z, Z Rotate) plane where the Z rotate is the vertical axis, so (and I didn't personally make these changes nor did personally test them) it was decided to modify lambda joystick class to include 4 axis, the 4th being called 'w', and then call the 4th one in the mecanum code. So this apparently worked and fixed the problem, but resulted in the code confusing the two joysticks and talking input of one plane form one and the other plane form the other. I am working on fixing that problem and will include comments in my next pull request, however what I heard of the testing confirms my hypothesis that the way lambda joystick works is it takes the first 3 axis on the joystick, and labels them X,Y,Z regardless of what they actually are. On an Attack 3, our normal joystick, this works fine because there is in fact only an X,Y,Z. But on joy sticks with a Z Rotate, where the Z rotate can be either the third or the fourth axis depending on the specific controller, the code will always treat the third one a Z, even if it's actually the Z rotate or X2.

We also added a diagnostic print statment to figure out how lambda was handling the joystick inputs

Alex and Jacob helped fix a thing where the Y axis wasn't eliciting the response from the motors we wanted, we ended up fixing it by fixing two values FIRST mecanum class (which i stand by the fact is wrong given the context of the rest of the code (or the rest of the code was wrong, but honestly which is easier to fix?)) and we did this by making our own custom class and replacing all instance of FIRST's Class in the code with ours There were similar but completely unrelated problem with the (Z, Z Rotate) plane where the Z rotate is the vertical axis, so (and I didn't personally make these changes nor did personally test them) it was decided to modify lambda joystick class to include 4 axis, the 4th being called 'w', and then call the 4th one in the mecanum code. So this apparently worked and fixed the problem, but resulted in the code confusing the two joysticks and talking input of one plane form one and the other plane form the other. I am working on fixing that problem and will include comments in my next pull request, however what I heard of the testing confirms my hypothesis that the way lambda joystick works is it takes the first 3 axis on the joystick, and labels them X,Y,Z regardless of what they actually are. On an Attack 3, our normal joystick, this works fine because there is in fact only an X,Y,Z. But on joy sticks with a Z Rotate, where the Z rotate can be either the third or the fourth axis depending on the specific controller, the code will always treat the third one a Z, even if it's actually the Z rotate or X2. We also added a diagnostic print statment to figure out how lambda was handling the joystick inputs
Commenting is not possible because the repository is archived.
No description provided.