search

frc-team-7445 / frc-2019

Robot Code for the 2019 Robotics Season
http://team7445.org
0 stars 1 forks source link

Elevator Needs Better Controller #2

Closed qhdwight closed 5 years ago

qhdwight commented 5 years ago

Motion Magic does not seem to be the best sort of control system for the elevator, as it does not understand that gravity exists.

qhdwight commented 5 years ago

Going to test DemandType with feed forward constant and see how that performs

jkuszmaul commented 5 years ago

Mechanically, what do you have for your elevator, namely:

qhdwight commented 5 years ago

4 Andymark 755 Redline Motors 11.555555 : 1 1 Andymark Redline Encoder mounted to back shaft of 775 No counter-balancing Inertia of elevator's load is around 25 pounds.

When testing the elevator without it's load, it takes about 8±1% motor power to hold at its current position.

jkuszmaul commented 5 years ago

For the gear ratio what you actually care about is the ratio from the motors to the elevator (so meters of elevator travel per radians of motor turns).

I'm not sure whether you will encounter issues with backlash in your elevator, but that'll depend on how things turn out later.

Do you have a plan for zeroing the elevator? Is it just going to start every match in exactly the same position?

What makes you think the MotionMagic (which I personally have never used...) will be insufficient--i.e., what have you had the chance to actually try on your elevator? Even if you don't want to go that route, my suggestion would be to start by just creating a PD controller and to not even bother with integral gains until you get the PD controller dialed in as well as possible. You may find that that gets you close enough that you don't care about the remaining error and so you can avoid the complication of an integral or gravity compensation term--don't add complexity until you need it.

If gravity compensation is necessary, you have two options:

Neither of those methods are fool-proof, but the first is simpler and so generally going to be easier to debug.

When you are trying to safely get your system working, what I generally use is manually find some way to enforce a voltage limit to ensure that it cannot exceed safe limits, while being sure that it is behaving in a sane manner; I am not sure how easy that is to accomplish that on the Talon SRX (you could accomplish it by setting the current limit, if you so desired); you could also unplug all but one motor, although that risks overheating a motor.

qhdwight commented 5 years ago

We have a limit switch at the bottom that resets the encoder back to zero. So far, we have tested with that 8% feed forward and it is looking promising with Motion Magic PDF. I have also set a cap on the closed loop max output for testing to make sure we do not overextend the elevator. In addition to this, I have also put a soft limit on the encoder position upwards so it theoretically should not exceed a maximum height. Eventually, a current limit will be set as well.

Right now, the biggest problem is tuning the four inputs - P, D, F, and FF. To distinguish F and FF, the former is multiplied times the trapezoidal velocity calculated by the talon and added to the output. FF is always added to the output, so it is that 8% value. We just have to come up with a way to best optimize all of these coefficients. I have created a client that uses network tables, so the plan is to dial in these values tomorrow.

jkuszmaul commented 5 years ago

Sounds like you're managing pretty well then... Just be patient and don't rush things unnecessarily.

qhdwight commented 5 years ago

Done for the most part. I'm leaving this here for future reference. Used a routine to test max velocity at a given motor output. Plugged that into motion magic cruise velocity. Used following to calculate F: (1023 * motor output) / max velocity. Set a really small P value and used an initial FF value. Tuned FF value until it was smooth on the way down. Dialed in P until desired accuracy to target was met. Introduced D as 10 * P, then dialed it in. No integral term. Used same gains for velocity closed loop which also works well, except for FF, which is lower.