Arm code

[12sliu]

The arm will be powered by a large motor. It will go over the robot, for easier scoring.

[12sliu]

Realized I'm going to have to use feed forward + PID for this, and I can't copy over the LiftComponent from last year because Oliver removed brightoncollege.libs, meaning I'll have to figure out multiple things and then tune feedforward. At least this is functionally very similar to the linear slide, meaning I can (hopefully) change some values.

[12sliu]

Alright, did some investigation, research, and wrote a little bit of code. Thought we didn't need PID, but apparently feedforward + PID provides optimal results. If time pressure is too much, we can get away with not using PID and using 0, 0, 0 as the values.

I've not been able to work much on this because apparently I chose test weeks for everyone to begin proper coding: that was a really bad idea in hindsight, should have distributed tasks before half term... Will note for next year.

Minor thing: the PID controller and feedforward objects are both protected in the Motor base class for some reason? Mikhail wrote BCLibMotor, inheriting Motor, which basically just adds public methods to get those two objects; why are these methods not in the base class? (I'm guessing something about fancy coding principles that say accessing a object which is a property of another object inside the class is bad practice. Eh, is inconsequential.)

[12sliu]

Alright, I've run into a roadblock.

Feedforward takes in desiredVelocity and desiredAcceleration. In last year's code, desiredAcceleration was the current acceleration of the motor from the motor encoder (??), and desiredVelocity was provided by the motor profile which told it exactly what speed the thing should travel at. Also in last year's code, the PIDF controller took in the actual and desired velocities, not the actual and desired position.

This time, I decided not to use motor profiles because I just wanted the thing done quickly. So I did a PIDF controller that takes in actual and desired positions. And then now I have no idea how to do the feedforward. Feedforward wants me to give it a speed and acceleration: I only have a position I want it to be in. I haven't been able to find other examples of feedforward, so as of now I see two options (although there's probably one I'm not seeing)

A. Use motor profiles by shoving lots of old code into my thing. It's not ideal because reusing loads of previous code isn't great. B. Not use feedforward, which is stupid.

(I don't quite understand why desiredAcceleration was named that, should have been just currentAcceleration)

[12sliu]

To phrase my problem better: Feedforward is used for following a trajectory, and I have only a setpoint. Do I make a trajectory reusing old code, do I not use feedforward leading to worse performance, or is there another way to solve this?

[12sliu]

ececb94b7db37f619aa0bd673b8d145980088ed3

Did more research and looked at the 2022 code; apparently there is a class called a PIDFController which has feedforward, but works by having one kF value which is multiplied with the SetPoint of the controller? From what I understand, that works differently to SimpleMotorFeedforward somehow. I'll ask Olly on Friday and just use PIDFController for now.

[12sliu]

Forgot to make the OpMode for determining positions. Will do that after EN stuff (i.e. 5 centuries later)

Also forgot to investigate Mikhail's UserFeedForward thing that was used to compensate for gravity too. I think it's similar to gain scheduling, but somehow different; have to look into it. Arm is almost done on engineering front, need to hurry the hell up.

[12sliu]

OpMode for testing positions made.

Mikhail's UserFeedForwardOperator thing is a mystery and I am confused by it; I will write my confusion down in the EN later.

[sbottingota]

https://github.com/Brighton-FTC/2024/commit/7beb77160747f0ebbf6c79348c1d35c488fc75b5

Made arm code into a component class.
Please could someone check it?