New climb

[Emma03L]

No description provided.

[github-actions]

Qodana Community for JVM

225 new problems were found

Inspection name	Severity	Problems
Unused symbol	🔶 Warning	125
Unnecessary modifier	🔶 Warning	22
Constant conditions	🔶 Warning	6
Field can be local	🔶 Warning	5
Unnecessary conversion to 'String'	🔶 Warning	5
Unused receiver parameter	🔶 Warning	4
Declaration has problems in Javadoc references	🔶 Warning	3
Unresolved reference in KDoc	🔶 Warning	3
Field may be 'final'	🔶 Warning	2
Busy wait	🔶 Warning	1
Infinite loop statement	🔶 Warning	1
Main function should return 'Unit'	🔶 Warning	1
Mismatched read and write of array	🔶 Warning	1
'size() == 0' can be replaced with 'isEmpty()'	🔶 Warning	1
Call to 'printStackTrace()'	🔶 Warning	1
Unused import	🔶 Warning	1
Class member can have 'private' visibility	◽️ Notice	18
Constant values	◽️ Notice	12
Lambda argument inside parentheses	◽️ Notice	11
Commented out code	◽️ Notice	1
Method can be extracted	◽️ Notice	1

☁️ View the detailed Qodana report

Contact Qodana team

Contact us at [email protected]

• Or via our issue tracker: https://jb.gg/qodana-issue
• Or share your feedback: https://jb.gg/qodana-discussions

[katzuv]

I think the subsystem was simplified too much. IMO it's very important to have a very fast climber. If we can climb (reliably) in a few seconds it will guarantee us a PR, and the "fastness" will increase the chance we climb even if we got stuck somewhere in the field, the driver took a few more seconds to align to the cage, etc.
I would bring back the:

• Second motor: if there is enough weight, the climber will be faster and the center of gravity will be lower.
• Stopper: this will ensure we get the climb RP even if we climbed very little. However, we need to check how much height the robot loses in 3 seconds, at a very low angle (there the moment of gravity is the largest).
• CANCoder: If the subsystem will be power based, we might need to put a low value at the beginning and end of the movement, so to not strain the motor to much and/or hit the cage. Bringing back the CANcoder will make position control possible, and thus probably decreasing the time it takes to climb.

[katzuv]

If there is no CANcoder now, I don't know how reliable the internal encoder will be, so perhaps the software limits should be removed.
Why, though, was the CANcoder removed? It will help us make the climb faster, which is important for a last-second climb (and RP).

[Emma03L]

I did remove the soft limits but didn't commit it because we're not sure if there will be a cancoder