Hey, so in preparations for the upcoming season our team is trying to take our code a few steps forward.
We successfully genaretad and followed paths and motion profiles using Jaci’s pathfinder and used Vannaka’s motion profile generator to generate the csv files and as a visual aid.
I am now trying to improve the way we code mechanisms, and I have a few questions.
First of all, I noticed during my years in frc that there are 2 types of mechanisms.
Mechanisms like an elavator or an arm that can’t go further than a certain range of motion, I’ll call them in this post limited mechanisms.
On the other hand there are mechanisms like shooters and feeder that can go on and on and don’t have a movement limit, I’ll call them in this post free mechanisms (I’m sorry if I’m not familiar with the technical terms).
So, these are my questions:
Which sensors are recommend to use on which type of mechanism?
During autonomous, what is the best way to move mechanisms? I’m guessing the options for the limited ones are using position PID loop or maybe generating a profile.
For the free ones, I’m guessing a velocity PID loop. Are there better ways or am I on the right track?
Same for teleop, what is the best way to move mechanisms? For the free ones is there a better way to run them other than SpeedController.set(pwmvalue)? For the limited ones, what type of control loop should I run on the limited mechanisms during teleop and does it take into account the range of motion?
Remember simpler is better. If your mechanism works well without sensors or closed-loop control, adding it will not necessarily help you. As a rule, our team does closed loop only when absolutely necessary.
Once you’ve determined you need some sort of closed loop control:
Encoders to measure rotation (or rotational velocity) through a continuous range, potentiometers to measure rotation through a fixed range. Limit switches to measure contact at specific points, ultrasonic or lidar distance sensors to measure linear displacement. Check the spec sheet on all of these prior to purchase to be sure they match your requirements. If at all possible, connect them such that they measure the endpoint manipulator (the thing you actually care about the position/velocity of), not some intermediate variable. The analogy here is for your drivetrain - encoders should go on the output shaft, not the input.
2 & 3) Structure your software such that the control logic for the mechanism accepts a “desired state” as input - could be the position, velocity, etc. In teleop, derive this desired state command from operator inputs. In Autonomous, derive this from some code that’s controlling the sequence of your autonomous routine overall.
There are other types of controllersthan PID too - “Bang Bang” is another common controller seen in FRC. Take-back-half is another one that’s made the rounds here. Again, keep in mind, to maximize success, simpler is usually better.
^^^ This - measure what you need to measure, preferably through the fewest number of proxy stages.
Another sensor type to keep in mind is the absolute encoder. This is used for continuous rotating sensors where you need to know not only the speed or total amount of motion, but directly need to know the angle of your rotating item; examples include swerve module rotations and full-cycle four-bar linkages.
On rangefinders, if you’re on a tight budget, IR is usually a better choice at short ranges (less than about a foot) and ultrasonic at longer ranges.
As you move your sensors farther out to the edge, they become harder to protect. The more critical the measurement is to your activities, and the more expensive the part is, the greater a concern this is.
Always try to determine up front how well and how quickly you need sensor information - often this will result in a significant change in your sensor selection.