-
Notifications
You must be signed in to change notification settings - Fork 0
Sprocket Overhaul Plans
- Spaces, method naming
- Running the code through a linter for automatic styling
- Standardize naming scheme
- Abstract away the state machines into plug and play turns and modules for autonomous
- Clean up base state machines
- Have autonomous modes with autonomous states inside it
- Split up functions of convoluted drive train class
- Drive Train -> Drive Modules -> Motor Controller Wrapper
- Use real-world distances internally instead of power units (percent of max power can be used, but is converted to a speed inside the class)
- Include distances into vectors
- Rewrite distance class
- Store all vectors as rectangular and convert to polar
- Document as we go
- Nobody can use what we've made if nobody knows how to use it!
- JavaDocs isn't enough but it's a good start
- Clear and concise JavaDocs goes a long way to allowing developers to do program more advanced and technical robots using methods that may not be covered in the broad tutorials that we'd post on GitHub
- Use GitHub wikis to create basic tutorials
- How to utilise all the supported drive trains
- Using gyro lock, taking advantage of all of DriveTrain's features
- How to program autonomous modes
- Using multiple cameras with camera server
- Joystick inputs
- Create more later on, start with the basics though
- Also freshen up the README
- Create debug options for each class
- Track method timings and be able to post them to Smart Dashboard
- Extend on dashboard class to print debugs
- Other tools and extensive documentation to help debug
Sprocket: Empty class, redundant
Action: Try and find a use, if none, delete
AutoAlign: Aligns a vision target within a certain X/Y zone using a drive train object
Action: Update and document. Is useful, we could make it more clear and concise.
AlignButtons: A class that contains classes associated with autonomous functions
AlignButton: A button that, when pressed, aligns with the auto align class
Action: Get rid of classes within classes and overly-specific canned tasks for the library. Probably best to just trash AutoButtons and leave it up to the end user to create
AutoChooser: A selectable chooser for smart dashboard that lets you switch in between autonomous modes
Action: Flesh out autonomous code, make it more autonomous specific rather than a generic state machine. See above.
AutoStates: A wrapper class with some pre-canned auto states
Action: See above autonomous plans. Remove wrapper class and separate autonomous modules out.
Zones: Class for X/Y zones for auto align
Action: Document
Button: Class for buttons, binding to a stick and button id to allow for actions to be taken on a button press
Action: No action. I did write this class though so I may be biased, double check.
ButtonAction: Empty interface for button actions. Allows for use of lambdas or for separate classes when defining button actions.
Action: No action. Consider evaluating alternatives though.
Joystick: Empty class extending the WPILib joysticks
Action: Delete if no other use can be found
SJoystick: Joystick class with deadzone. Doesn’t extend WPILib class, but forwards relevant methods to the WPILib object instead.
Action: Consider renaming to Joystick and deleting other class. Implement all other WPILib methods.
*Motor classes: Motor modules for specific use cases and drive trains.
Action: Reimplement with planned drivetrain improvements shown above. Make it simpler. Discuss these later
DriveTrain: Class that wraps drive modules and motors to accelerate the robot with various inputs. Includes safety features and gyro lock
Action: Reimplement with above changes. Discuss.
HTTPServer/Mjpg: Internal classes for reimplementing the WPILib camera server
Action: Make private and put all the camera server stuff together
State/StateObj: State is an interface with some basic methods we'd want in states. StateObj is just an abstract class implementing State? Not sure why
Action: Choose between StateObj or State (abstract/interface). Use only one of them in all the necessary cases. Reimplement accordingly.
StateMachine: Keeps track of all the states and handles transitions
Action: Recode. Currently a messy implementation. Could be a lot cleaner.
Updater Classes: Keeps track of what needs to be updated every loop and updates in order of priority.
Action: Revisit update class naming
Angle Classes (Degrees/Radians): Classes used for angle measurements and arthimetic operations
Action: Look at negative in Radian class? Needs documentation
Area/Volume: Calculates areas/volumes of various shapes
Action: Evaluate if necessary. If needed, document code.
Camera Servers: Overrides default WPILib camera server in favour of allowing for using multiple USB cameras
Action: Try to make it more user-friendly? If not feasible, scrap it.
Dashboard: Allows for easily togglable debugs to SmartDashboard
Action: No action needed. Useful functionality coded in a straightforward way.
Distance classes: Stores real-world distances and allows for easy conversion
Action: Restructure for use with new drivetrain code.
Motion classes: Models parametric/falling body motion
Action: Evaluate if necessary. If needed, document code.
Grip/Contour Report: Interacts with GRIP to obtain contour reports and fills in contour report objects
Action: Clean up and document. Generalize contour report class.