On Discord, I saw many people referencing this video, so I got curious and watched it. Good job in presenting this, btw. I do have a few questions though. The ff term (gravity compensation) in this code is assuming the arm is zero degree at horizontal. With this assumption, it means people need to zero calibrate their arm at perfectly horizontal position. Also, the ff calculation is applying cos on the target. Shouldn't it be applied to armPos instead? Applying on target means the gravity compensation is not correct until the arm has reached target position. It may be more natural to allow people to have their arm zero at "resting position" where that's the most likely position when you first power up the robot that will reset the motor encoder. To allow this, it may be better to assume zero degree at vertical down position which means the ff calculation should use sin instead of cos. To account for the zero position not at vertical down, the code needs to add a Zero Offset to the calculated arm degree. Therefore, the ff line should be: ff = Math.sin(Math.toRadians(armPos / ticks_in_degree + zeroOffset )) * f;
You are correct. The feedforward could be calculated here based on the current position of the arm to help the pid along all the movement, but the end effector should reach the same end position(or close) with a feedforward based on the target too. When it comes to resetting the position of the arm, that's up to the teams. In the end this video (and a lot of other videos) shouldn't be used as a plug and play solution, but more of an explanation of how it works and how to tune. (They also use a mp at the end so this is kinda cheating the ff based on end target a bit, but you get the point). Anyways good points!
Hi. great video. We implemented it with no problem in our code, but, we want it to hold for a certain time in that position and then move back to the initial one and we havent figured out a method to do that. We tryed using sleep() but the arm falls because of gravity, then we tryed using a EllapseTime variable but it doesnt stop in the position, it continues to move. Any ideas?
Our team was using this code to tune our PID values, but when we went to FTC dashboard we got a message saying "Op mode controls have not initialized". The config pops up but we are not able to run the opmode. We aren't using any special sensors if that matters. So is there a specific reason this may be happening? Do we need to change something in our code?
First of all amazing video. I was just wondering how I would be able to implement this into roadrunner or something of that sort? (More specifically into markers as they can't have a while loop within them and I was worried about the arm pos not being updated)
The PIDF controller built into DcMotorEx operates at only 20hz, whereas the PIDF controller on our robots subsystems update at 250hz. This increase in refresh rate leads to significantly better performance, both accuracy and efficiency wise
Hi, I encountered a problem while trying to implement this code for an arm controlled by 2 Yellow Jacket goBILDA 5202-2402-0014 DC motors. I found out that no matter how close I've got with tunning the controller, it will allways oscillate arround the target position, because it will never reach it exactly. I want to know if this is a common issue for a PID controller or if it's something in my code. Also, I'm not sure what's the value for the ticks per revolution for these motors. On their website I saw 384.5 PPR but it doesn't seem right to me
I'll also add that sometimes PID systems are best with a deadzone, that is, errors close to 0 are clipped down to exactly 0 so that you don't get micro-oscillations in systems where the precision of the encoder is greater than the max realistic precision of the motor
It's not a motors ticks per degree but rather your encoders ticks per degree. Typically you know this cause your encoder will say it on their website what the ticks per revolution is but if you can't then you could record your tick position at 0 degrees then spin the rotor a revolution and get the difference between them then divide that by 360
Hello, i have a question, how do i implement the pid into a subsystem, i tried every method, followed what they said on the ftclib docs but to no result, please help.
So good. Such a great representation of what’s needed for PIDF Loops.
Thanks for the explanation, we are here from Brazil, FTC #23069 and FRC #9047
Awesome video! Gonna show this to my teams new members
On Discord, I saw many people referencing this video, so I got curious and watched it. Good job in presenting this, btw. I do have a few questions though. The ff term (gravity compensation) in this code is assuming the arm is zero degree at horizontal. With this assumption, it means people need to zero calibrate their arm at perfectly horizontal position. Also, the ff calculation is applying cos on the target. Shouldn't it be applied to armPos instead? Applying on target means the gravity compensation is not correct until the arm has reached target position. It may be more natural to allow people to have their arm zero at "resting position" where that's the most likely position when you first power up the robot that will reset the motor encoder. To allow this, it may be better to assume zero degree at vertical down position which means the ff calculation should use sin instead of cos. To account for the zero position not at vertical down, the code needs to add a Zero Offset to the calculated arm degree. Therefore, the ff line should be: ff = Math.sin(Math.toRadians(armPos / ticks_in_degree + zeroOffset )) * f;
You are correct. The feedforward could be calculated here based on the current position of the arm to help the pid along all the movement, but the end effector should reach the same end position(or close) with a feedforward based on the target too. When it comes to resetting the position of the arm, that's up to the teams. In the end this video (and a lot of other videos) shouldn't be used as a plug and play solution, but more of an explanation of how it works and how to tune. (They also use a mp at the end so this is kinda cheating the ff based on end target a bit, but you get the point). Anyways good points!
is that mason stuart talking?
Hi. great video. We implemented it with no problem in our code, but, we want it to hold for a certain time in that position and then move back to the initial one and we havent figured out a method to do that. We tryed using sleep() but the arm falls because of gravity, then we tryed using a EllapseTime variable but it doesnt stop in the position, it continues to move. Any ideas?
Our team was using this code to tune our PID values, but when we went to FTC dashboard we got a message saying "Op mode controls have not initialized". The config pops up but we are not able to run the opmode. We aren't using any special sensors if that matters. So is there a specific reason this may be happening? Do we need to change something in our code?
First of all amazing video. I was just wondering how I would be able to implement this into roadrunner or something of that sort? (More specifically into markers as they can't have a while loop within them and I was worried about the arm pos not being updated)
Whoa! that was an amazing video! 😃😃😃
Thanks!
Have you used the PIDF controller that is available in the DcMotorEx class? How does it compare to implementing this?
The PIDF controller built into DcMotorEx operates at only 20hz, whereas the PIDF controller on our robots subsystems update at 250hz. This increase in refresh rate leads to significantly better performance, both accuracy and efficiency wise
Very helpful video! Also, did you mean to spell maven like that in the url 2:27
I think they did Mr. Thopunadorripunoori!
Hi, I encountered a problem while trying to implement this code for an arm controlled by 2 Yellow Jacket goBILDA 5202-2402-0014 DC motors. I found out that no matter how close I've got with tunning the controller, it will allways oscillate arround the target position, because it will never reach it exactly. I want to know if this is a common issue for a PID controller or if it's something in my code. Also, I'm not sure what's the value for the ticks per revolution for these motors. On their website I saw 384.5 PPR but it doesn't seem right to me
Hey, try increasing your D term if you are seeing oscillations
I'll also add that sometimes PID systems are best with a deadzone, that is, errors close to 0 are clipped down to exactly 0 so that you don't get micro-oscillations in systems where the precision of the encoder is greater than the max realistic precision of the motor
where could I find my motor's ticks per degree?
It's not a motors ticks per degree but rather your encoders ticks per degree. Typically you know this cause your encoder will say it on their website what the ticks per revolution is but if you can't then you could record your tick position at 0 degrees then spin the rotor a revolution and get the difference between them then divide that by 360
Hello, i have a question, how do i implement the pid into a subsystem, i tried every method, followed what they said on the ftclib docs but to no result, please help.
Hey, could you share what you have right now?
What about the integral part, do we change that?
integral is usually left alone in most cases
7:27