Beyond the few missing subsystems we have not completed (likely 30 lbs with_holdings) We found that our two sided arm is hard to control. The arm is heavy though 80% of the travel but at the top it finds a counter balance. Tuning the PID control has been a challenge since at the bottom we need a higher P-Gain to start movement and to hold positions but at the top it is real light and need a lot less. We are considering adding a break of some sort to induce some drag or clamp the position when we get to the set point. Also the 170deg potentiometer reading at the 100:1 gearbox output shaft has some bad backlash with the 2:1 chained sprocket to the pivot point. We are looking at way to get the pot on the final axle but currently have no room to install it to the ends of the shaft. Maybe a simple 3D printed 1:1 Gearbox. This is all on the second stage of a elevator so Versaplanitary encoder mods are not likely with the ~7" ribbon cable or CAN wires that would have to be ran out to the encoder.
What are some of the break solutions you may have used or seen to hold an axle from rotating?
One thing I suggest that you do is use a feed-forward for your arm control. You can do this by calculating the torque on your arm from gravity at any given arm angle using the weight of your arm, its center of mass, and some trig. This will make your arm much easier to control.
I can really second what @robinsonz is suggesting here, read this for at least a cursory understanding of the forces that act on your robot’s arm. It’s an easy thing to miss but a really good one to improve upon. This is more commonly known as an “arbitrary feedforward” and it can be handled both RIO and motor controller side in many cases.
Yes section 3.3 is the problem. So does our PID(F) controller need to change the F-gain as it travels through its motion? Can we not use the caned PID subsystem in the Java WPI Libraries but a custom controller feed-forward calculator?
Last year we used a double jointed arm to place power cubes on scale. A feed forward system really works wonders (allows arm to work in zero gravity for all of control). To hold the arm in different positions we used a mountain bike brake (will link) but it was insanely strong when used with a 1 in bore 3 in stroke piston. Maybe a smaller piston would induce the drag you are looking for.
Also consider adding a pidgeon imu to your arm to measure angles. I’ve heard it works well but haven’t done it before. Relatively easy mounting too…
Also when your arm is up you may want to limit the motor power and acceleration of drivetrain to prevent tipping.
Let me know if you have any other questions,
Correct, hence the idea of it being “arbitrary”. Your multiplier (kFF) should still be tuned though. As to using WPILib’s “canned PID controller”, while functional by definition it’s far from ideal. It was actually rewritten for the 2019 season but it didn’t make it in. For a far more understandable PIDF controller, I suggest looking at 254’s SynchronousPIDF class. Despite being fully synchronous by default (within your main robot loop) it’s still very effective at what it does. You’d just add a function every loop you call .calculate to also prior generate some value for F and set it to the controller.
EDIT: So your feedforward for an arm whose angle was zero at the east direction on a compass rose as a side profile might be some value * cos(theta), where theta is the angle of your arm measured as it travels around. Some value is going to be wholly dependent on your system.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.