Skip to content
This repository has been archived by the owner on Apr 29, 2024. It is now read-only.

Rewite how motors are controlled and declared #5

Open
RED-M0CKING-LINE opened this issue Aug 9, 2019 · 0 comments
Open

Rewite how motors are controlled and declared #5

RED-M0CKING-LINE opened this issue Aug 9, 2019 · 0 comments
Labels
enhancement New feature or request

Comments

@RED-M0CKING-LINE
Copy link
Owner

Summary:
At the moment we interface directly with the motor's API with no control of how the motor is declared, handled, or removed. This will also interface with the encoder classes to declare and handle the encoder by passing arguments through the declaration of each motor.
THIS MUST BE COMPLETED AFTER THE IMPLEMENTATION OF THE FEATURE IN ISSUE #2

Goal:
Make a dynamic class for each type of motor that allows easy declaration, control, and easy access to it is assigned or defined encoder.
Also, allow the class to return whether the motor is connected or not and if it is not, do not initialize whatever subsystem it belongs to and print a message that says: "____________ subsystem was not loaded due to motor ____________ being disconnected." This will require heavy testing of all the different motors and will need to be checked for reliability in detecting the presence of a motor controller.

Note:
If the above feature is not possible (any part of it), state here that it was not or cannot be completed, push the commits that implement this feature that also say this issue is now closed, and close this issue.

@RED-M0CKING-LINE RED-M0CKING-LINE added the enhancement New feature or request label Aug 9, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant