Grievances with motor library

[jimmyli97]

Right now I think that the state of our code currently warrants the question of whether we should create a task to handle motor updates. Currently we have to deal with:

• Encoder targeting (which is already messy, see #60)
• Motor min/max powers
• Possible inclusion of our own version of PID control

I think it's getting sufficiently complex that we should just delegate it to a task running parallel to the main task because it's going to get really complicated doing it as a function because of having to pass so many parameters.

Thoughts?

[jimmyli97]

Oh and we want to add stall protection in the future too (#9)

[jimmyli97]

Ok this absolutely needs to be implemented because the encoder limit of 32000 is just far too limiting... like our lift at full extension basically causes the encoder to overflow.

Creating a task would let us aggregate encoder values as they occur (e.g. check difference in encoder, add to aggregate, reset encoder).

Making this a critical issue.

[jimmyli97]

Ok actually none of these issues require a task except for stall protection because none of these are time based... it's basically turned into a list of grievances for the motor library. Sorry about that I'll rename this

[jimmyli97]

Many of these issues will require adding variables to DesiredMotorVals and DesiredEncVals (such as DesiredTimeExpiration, etc.). This means that the size taken up by DMV and DEV will grow quite quickly as they have array size kNumbOfTotalMotors.

We can solve this by making DMV and DEV size NUM_MOTORS, index them to motorList, and then every time a motor library function is called we call a lookup function to translate the motor into a motorList index. This will keep total memory size down, and let us add really cool stuff!

[jimmyli97]

Also add ability to put encoder limits on motors (e.g. for the lift)