Hi everyone! So our robot has an arm driven by two NEO/SparkMAX setups–one for each side running together. I’m trying to use the built in encoders to create “positions” for the arm to be deployed to–e.g., homePosition, scorePosition, etc. Currently, I have the arm being driven by an arm control command and arm subsytem using the left and right triggers on the controller. It works well enough, but I’d like to be able to drive the arm right to a specific position OR have the arm out/in stop at specific points to avoid over rotating the arm and to improve efficiency.
I tried implementing a version of REVs 2024 FRC bot’s armControl code, but the arm subsytem was quite complex and trying to do much more than I need. I’m looking for the cleanest way to do this–thanks!!!
Thanks for the reply–I’m looking at your code now.
Actually, I’m hoping to do both of those things. I’d like to set rotation limits for the arm while it is used as a ‘blocker’ to deflect our ring shot into the amp–but the arm is also used for climbing on the chain–there I’d like to hold a position if possible…
It’s implementation is fundamentally flawed, and it can’t correct for position error.
Instead for a similar effect, generate a trapezoid profile in WPILib, and send a stream of position setpoints to the Spark Max in regular position mode.
You can absolutely use similar rotation limits to what I did, but do have a manual override that can be used if it would ever exceed those limits, otherwise, the arm will get stuck there.
For climbing on the chain you could maybe use a similar position holding method as everything else, but have a increased feedforward facing down as to keep the robot up. Also remember that you have to stay up 5 seconds after disable so I hope that your gear ration is immense or that you have a brake.
/**
* REV Smart Motion Guide
*
* The SPARK MAX includes a new control mode, REV Smart Motion which is used to
* control the position of the motor, and includes a max velocity and max
* acceleration parameter to ensure the motor moves in a smooth and predictable
* way. This is done by generating a motion profile on the fly in SPARK MAX and
* controlling the velocity of the motor to follow this profile.
*
* Since REV Smart Motion uses the velocity to track a profile, there are only
* two steps required to configure this mode:
* 1) Tune a velocity PID loop for the mechanism
* 2) Configure the smart motion parameters
...
They’ve stated that it only uses velocity to track a profile, and you have to tune the mechanism for velocity PID in order for this to work correctly.
So your saying when you are at your “set point” the motor will be getting zero velocity, and therefore falls out of range and then applies more velocity to correct and that why you get the accumulated, position error? if this is the case, couldn’t you counter this with a robust PID tune.
Sure, but you’re still solving the problem in a less than optimal way. And its much easier to induce oscillation this way, as you’ll inevitably add more kP to make it keep its position. And its just more difficult to tune velocity on a position based mechanism.
Makes sense, we spent a good week fine tuning our PID, for our angled shooter, and was able to get it to a stable and accurate place. but in the future if we have issues i will look into the trapazoid profile tuning.