Hi everyone, my team is currently working on programming our robot’s arm with falcons, I have yet to have time to test our code but I have it planned to use the TrapezoidProfileSubsystem to counter gravity, at least that is my understanding but I am feeling slightly confused on whether I am doing things correctly. Would anyone possibly have any working examples for me to review before possibly breaking an arm?
A TrapezoidProfileSubsystem is one way to solve the problem. This particular thread is about using the trapezoidal profile built into the CTRE motors called MotionMagic.
There are pros and cons to either approach.
CTRE’s github has MotionMagic code examples, and there are many others available.
The WPILib examples project has an entire section in the documentation about how to use the TrapezoidProfileSubsystem.
1 Like
You may need to implement a sine-based element to your arm PID since it’s a rotational value, meaning the most load is when your arm is parallel to the ground, and greatly reduced force is required as you approach perpendicular angles to the ground. I’ve seen this mentioned in other thread before and linked a couple here:
Went through the whole procedure again, I can’t seem to get the arm to resolve a slight overshoot (that it then corrects for very accurately) on long ranges of motion.
Particularly, when rotating the arm over the top of the robot its almost like theres a mechanical difference the motor controller can’t really be aware of. Gets slightly too much velocity
Two things:
- Momentum is a real thing, so they are very likely differences in the physical mechanism.
- If you’re doing radial motion over the top, then your feedforward probably needs to account for where it is in physical space. As you move over the top, you probably want the feedforward to be sine based, but as you pass 45 degrees from vertical, transition to a cosine based feedforward.
Thirdly, it’s possible that the motion in one direction is quite different physically than the motion in the other. Sometimes motors spin at different rates depending on how the mechanisms are assembled.
Sorry I didn’t share these earlier. I’m on a PC so sharing is easier. Here are two Videos I posted over the years; The first is Motion Magic focused on Elevator and similar systems. The video also has links to the Google sheets I created to help calculate the values. When you click the link make a copy for yourself.
The second video was a live presentation I did for team 2846 The Fire Bears. At the end of the video I talk more about arbitrary Feed Forward.
Thanks for this feedback. Its 1000% momentum, pretty much strictly with radial motion over the top. Honestly even at slower speeds the arm it will slightly overshoot by like 2/3 degrees and then quickly correct. its not a major problem just more a lets see if we can tune that out problem.
Sin thing is interesting.
Right now our arms motion looks like a unit circle. we treat straight up and down as 90 degrees and this no KF compenent. If we went to a sin function we’d be at max arb ff there? I guess your concept is as we push down through that upper quandrant you’d want arb ff working the other way to slow you down?
I think when they say to add a sine term, they’re suggesting a linear combination of sine and cosine, or else sine with an offset.
For the arm coordinates you described, you’ll probably want a gravity compensation of T=mgL_{CG}\cos(\theta)
In our code we did offset so horizontal was 0deg
thats how ours works. its bidirectional, Horizontal one side is 0, other side its 180 at horizontal
OH. Interesting… I see what you mean
There is the trade-off between speed to target and over-shoot. That could be in play if kP (or the total voltage) is still too high to get down to critically damped.
And you might be referring to motor speed which effects how far the arm moves between position measurements and the lag to use those measurements. There are tunable filters in the Talons measurement of sensors that effect the accuracy and lag. I’m sorry I don’t know enough about your particular situation to be specific. These might not apply at all to your position target and may be only for velocity but I’m not sure. And for those using the roboRIO for motor control the StatusFramePeriod is critical.
configs.neutralDeadband
configs.voltageMeasurementFilter
configs.velocityMeasurementWindow
configs.velocityMeasurementPeriod
1 Like
Does you share the code here yet? I would like to poke through it.
Here is the Arm Code:
setArmAngle(…)
is the function that controls the arms rotation.
I don’t really think were doing anything wrong. more just about how to improve it
yeah so far with the tradeoff I’ve found that were better off just getting there fast and correcting.
Ideally we maybe slow down a part of our motion, which might be what is being suggested
You might check the .1 value in line 101 of your Arm.java file (“double FF = .1;”) – should that be .2 instead? You had said in an earlier message here (message 5) that you thought that value was .2, so maybe it got changed by mistake.
In message 11 above [Fletch1373] pointed out, correctly I think, that that FF value should be large enough so that your robot’s arm will remain in a horizontal position, even without any other inputs, without drifting down, and that you should increase FF until just before it barely starts to move the arm up. Once you do that, getGravity() should return the correct amount of ArbitraryFeedForward, and you can start working on P, and then D, and you should be able to eliminate the overshoot.
yeah should say, we recently retuned.
I’m not sure if this is tuneable out with PID constantly
are you recommending that basically from the angles 45->135 instead of COS I use SIN?
Basically to help slow down the momentum on the back end?
For my team I would probably just either: A) Be fine with the overshoot and correction if there wasn’t going to be damage to the arm or B) Slow down the acceleration/velocity for the motion magic to hit the mark cleaner.
However, if you want to maximally efficient you could think about taking into account the sine and cosine for your arbitrary feedforward calculation. Something like this might work, untested so maybe not:
double arbFF = cos(angle) - sine(angle)
You’d have to model that out to see if it gets you the right values, and you may have to reduce your kF to even notice the change but you may be able to dial it in that way.
good point!
yeah I’m mostly fine with the overshoot because it corrects pretty quick. Were also going to add some logic on longer arm moves to slow it down to account for momentum.
But I’m curious what could happen using that arbFF as well. going to test it for sure.
Thanks for all your help!