Hello All, I’m struggling in tuning an HD hex motor with the pidf in blocks, I tried as mentioned in the Motor PIDF Tuning Guide - Google Docs to get the P value . But still when I input my PIDF in the PIDF coefficients the motor velocity still plays in the telemetry. Is there any other way to get the PIDF as I can’t find something good in google Thanks
2 Likes
Are you trying to make the motor go a certain speed (velocity), or trying to make the motor go a certain distance?
I’m trying to make it to remain in constant speed ,but in the telemetry I can see that its not keeping stable it plays for example if I set the velocity to 1000 it will play from 980 to 1020 .
1000 what? Rpm? That sounds stable. For velocity controllers a proportinal contrller with a velocity feedforward is good enough
There are a bunch of tuning related docs in the FRC docs: Introduction To Controls Tuning Tutorials — FIRST Robotics Competition documentation
1 Like
Add a small D value
1 Like
If I’m reading this correctly, I think you are talking about FTC! If you’re trying to tune PIDF in Blocks, I recommend reaching out to more FTC-specific forums, like the FTC subreddit.
However, tuning PIDF in Blocks is going to be pretty difficult. Android Studio coding for FTC is a lot more friendly for PIDF tuning- Blocks is going to be very basic, using things like RunMode.RUN_USING_ENCODER and RUN_TO_POSITION.
1 Like
This is fairly stable. I the resolution of the encoder isn’t amazing it might be as good as you’re going to get. You could try decreasing your kI, and just using FP (and maybe some D). That will at least show how much velocity wiggle you get without I.
But is it good how I m getting the value in using the max velocity as it’s what I’m aware now. Other do you guys use some kind of programs so you can tune the motor ?
The code you’re using is good for driving a motor with Velocity control instead of Power control. If you’re just looking to smooth out the acceleration of the motor, you can use the default coefficients. It’s not necessary to set them yourself.
There are some calculations you can do to get an initial set of coefficients. The tuning is done mostly with trial and error. Even professional engineers do most of their tuning with high fidelity simulations or Monte Carlo Analysis.
Given the low cost of testing for teams, trial and error is the best way to tuning your coefficients. Make sure you’re recording every trial in your Engineering Notebook. If you don’t, you’ll run the same values many times without learning anything new.
2 Likes
We tried to use power and velocity in two separate opmodes just using the mode Run_Using_Encoder . I can’t see allot of difference in the velocity compared when using the power. The only thing I’m trying to figure out is when I use the power and in telemetry I make power and velocity it shows Power-1 Velocity -2870 ,and then when velocity is used instead of power and I set velocity to 2700 in telemetry it shows Power -1 velocity -1400 to 1420. This is all happening under the robot load . And still if I try to put the 1400 velocity as how I understood is what it’s capable to lift under load it won’t keep that velocity it will show almost near 800 in telemetry.
Using PIDF-Identify Step
As I was reviewing this thread, I realized that we’re working in a very late step in the Engineering Design Process (Identify, Design, Create, Iterate, Communicate). Some readers may not realize all the work that went into getting this far along in the Engineering Design Process. I’m going to go through a hypothetical scenario using each of these steps to show how we got to the point that we are now trying to tune the PIDF controller.
Start by printing a copy of the FIRST Engineering Design Process and hanging it on a wall near your computer or your workspace so you can always refer to it as you work. It is available at https://firstinspiresst01.blob.core.windows.net/first-energize/fll-challenge/fll-challenge-superpowered-engineering-design-process.pdf.
In this post I want to review some of the work that was done in the Identify Step. The Identify Step is where you define the problem. Different problems have different solutions. If you don’t understand the problem, you may select a poorly suited solution and not get the expected results.
There weren’t a lot of details about the problem in the original post. I’ve made some assumptions and refined them as more information was provided in this thread. The PIDF controller is being used on a winch to lift a robot. There are lots of different situations where you might use a winch to lift a robot.
- Climb above a certain height as fast as possible.
- Climb at least x inches, but not more than y inches.
- Climb to a certain height in a specified amount of time.
- Climb to a certain height when the robot weight can vary between x pounds and y pounds.
I’ll go into more detail about pairing different solutions to these problems when we get to the Design step of the process. Now that we can see that there could be a variety of situations that can use a winch to raise a robot off the ground, I want to look at a couple different options for the problems listed here.
Let’s clarify some terms before I get into some designs that fit or don’t fit with the problems listed here. There are two basic groups of control systems that can be used with a winch or any motor: Open Loop and Closed Loop.
In an Open Loop control system, you provide a command to the motor and then stop the command some time later. This system doesn’t take any information from the environment to make decisions about when to start or stop the command.
In a Closed Loop control system, you provide a command to the motor. The command changes over time based on information gathered from some sensor. You use this feedback from a sensor to update the command. The sensor data closes the loop between the command, how the motor responds to the command, and is used to update the command. A car’s cruise control system is a good example of a Closed Loop control system. It applies more or less gas based on the speedometer to keep the car at the same speed, even when it goes up and down hills.
In our robots, the Power control commands are Open Loop. We set a power setting on the motor. It doesn’t matter what the battery power is or how much weight is on the robot, the motor always gets the same percent of the power available. The Velocity control commands are Closed Loop. The robot adjusts the power going to the motor based on the velocity of the output shaft measured by the encoder on the motor. The robot is always trying to maintain the same velocity using feedback from the encoders.
If the problem is to climb as fast as possible, Velocity control would be a bad choice. Velocity control always leaves some power available so it can be increased if the velocity drops below the desired velocity, like a car going up a hill. If you want to climb as fast as possible, you apply the full power to the motor, regardless of how much battery power is available or how heavy the robot is.
If the problem is to climb to a specific height, between a maximum and minimum value, then you want to control the velocity and the time. Keeping velocity and time consistent will get you to the desired distance even if the battery power is different at different attempts or if the robot weight is different at different attempts. If the robot is lighter, the Velocity control won’t need to apply as much power, but will keep the same velocity for the same time resulting in the same distance.
If the problem is to climb to a specific height in a specific time, Velocity control would also be a good solution. By maintaining the same velocity over the specified time period, the robot will achieve the specified height. The Velocity control will adjust the power settings to maintain the desired velocity as battery power varies.
If the problem is to achieve the same height knowing that the robot weight could be different on different attempts, Velocity control would be a good solution. When the robot is heavier, it takes more power to achieve the desired velocity. Specifying the velocity allows the robot to respond to the slower start and continue to apply more power until the desired velocity is achieved.
From the original post, we know that the problem was not to climb as fast as possible or in the shortest amount of time. If that had been the problem, they would not have chosen to use Velocity control. For the purposes of showing the other steps of the Engineering Design Process, we’re going to say that the problem was to achieve a desired climb in a predictable amount of time. Knowing exactly how much time it takes to achieve the minimum height makes it easier for the Driver to know when to stop with other activities and get in position for the climb. The Driver also knows that the climb will take the designed amount of time whether the robot is controlling no game pieces or lots of game pieces.
Stay tuned for my next post as I go into more details about how to take this stated problem and work through the Design step.
1 Like
Using PIDF-Design
This is a continuation of my earlier post stepping through the FIRST Engineering Design Process (Identify, Design, Create, Iterate, Communicate) to get to the point of tuning a PIDF controller.
In the last post, the Identify step, we looked as some different problems that are well suited to a PIDF controller solution. I said that we’re going to continue this process using the problem that we need the robot to climb to a specified height in a predictable amount of time. By having a predictable time, the Driver doesn’t have to be thinking about conditions that could affect the climb time like the battery power level or the weight of the robot. The Driver knows that the climb always takes the same amount of time, so they can always play up to that time and then get in position for the climb.
For this discussion, we have to remember that we have not already selected a design solution. It is hard in this thread, but try to imagine that all we know is the problem we’re trying to solve and the whole world of possible solutions are available to us.
We start the Design step by deciding on the criteria we’re going to use to evaluate or grade the various possible solutions. These usually come from the problem statements coming out of the Identify step. In the last post I left it with a single statement, but a full Identify step would give you several different aspects of the problem that you want to take into consideration when evaluating possible solutions.
In addition to climbing a specified height in a predictable time, also take into consideration the following criteria:
- The solution needs to be achievable within a month so we have enough time to build it, test it, and iterate it.
- The solution should be something the team (students and mentors) are already familiar with.
- The solution needs to be something that we can afford.
Many times engineers are using these criteria as they are ranking the various possible solutions. These criteria are usually just in their mind and not written down. It is important to write down all the criteria you use for a design decision so the other members of the team can see how you got to the decision you made. If you don’t write all of this down, your teammates, and later your boss, will always be challenging your decision which will delay in getting to work on the Create step.
In general, the problem statement we have is a technical criteria. It focuses on the performance of the robot. In nearly all design decisions criteria for Time (or Schedule), Experience, and Cost are important. In different situations, you’ll find other criteria, like how it looks or balancing a few different competing technical criteria are included in the selection of a solution. (Strong and lightweight are often competing criteria that need to be considered at the same time.) You want several criteria, but not so many that the evaluation process is bogged down. When engineers have too many criteria, they get stuck in what is called Analysis Paralysis.
Once you have a reasonable list of criteria, you need to assign them a priority or weight. I might be able to accept a more expensive solution if it gives a lot of technical performance. In other words when I’m looking at multiple options, I’ll value technical performance higher than cost. If I have two options that are close in their technical performance, I still consider cost so the lower cost option will be a better fit.
Now that you have the criteria for your decision, you set those aside and get a clean sheet of paper or a clean whiteboard and brainstorm all the possible solutions to the problem. Write down all options, no matter how impractical they are. You need to document that you considered it. The really impractical options will get eliminated once we score them against out criteria. By including them in the list, the rest of the team, and later your boss, will see that you did consider the idea they came up with and have a logical reason for not recommending it or pursuing it. When you don’t write these down or include them in the evaluation, for the rest of the process someone will try to get their favored option pushed through and you’ll have to stop and explain why you didn’t select it. I’ve found that if I don’t write all this down, three months later I can’t remember all the little things that came up which caused me to choose the current design than the one they suggest.
At a minimum you need three options. There will be one option that is the first to occur to you. In the moment you’re sure it is the right answer. That is great, so take time to write that one down. Once you have the basics of the design written down, stop. You don’t need to do the full detailed design at this point. You need to give room for at least two more ways of solving the problem. These are ways that are not the first one. More options is better at this point. While three is a minimum, I like to have about five options. I would say that seven is a maximum. Just like with criteria, too many options and you get into Analysis Paralysis.
Now if you can quickly come up with eight, great. Write them all down and move to the next part of Design. I do want to say that a few of the options an be tweaks or adaptations of a single idea, but you need at least three unique ideas. It takes a lo of practice to be able to clear your mind and come up with an out of the box idea. This is where getting three to five of your teammates to help with this brainstorming is helpful.
For our climb problem we can use several approaches to it. Here are a few that I thought of.
- A Lift Arm
- A Reverse 4-Bar
- A Winch
Now that you have the ideas, do not vote on them. You’ll notice that some people have their favored solution quickly. FIRST teams are full of smart people who can think through different situations quickly and will arrive at a preferred option faster then you can write down the option. A key part of why we’re going into detail on the Engineering Design Process is to slow down that process to make sure we have been diligent in our work before we start building things.
Instead of voting on the options, we need to evaluate each option. I like to use a scorecard for this process. At the top of the scorecard I write down the option number and a title that uniquely identifies the option that I’m considering. The card has the list of criteria that I’m considering. Each option gets its own scorecard. Each criteria is scored for that option. After all options are scored, the results are entered into a table or a spreadsheet and they are tallied up. This is when we introduce the weighting of the criteria that we decided up earlier. Once the weights are applied and the scores are tallied, the option with the best score is the one recommended.
This takes a lot of practice to do well the first time through. Everyone on the FIRST team is still learning this process. If someone disagrees with the option that got the best score, let them explain why they think a different option is better than the one with the best score. Sometimes it comes down to a disagreement on the score assigned. Sometimes it comes down to a disagreement with the relative weight given to a criteria. Sometimes it reveals that there is a criteria that is important to the decision that we hadn’t included earlier. Use this as a time to revise and update our decision process and rerun the steps to get new scores.
Now, it is unlikely that everyone on the team will be happy with the selected option. This is where the team needs to follow their own policy on how decisions are made. Some teams use consensus. Some teams leave the final responsibility to the leadership. Some teams use ranked choice voting.
Once a decision is reached, it needs to be written down and everyone on the team needs to get behind it. There is a lot of work to finish the Engineering Design Process for the selected design. We don’t have time to readdress or re-litigate a decision that has been made. If the decision wasn’t your preferred option, you just have a new problem of how to implement the design that you didn’t come up with. In the professional world this is known as Professional Subordination (Professional Subordination - Part 1 | Manager Tools). Teams, organizations, and companies know that the group can achieve more if everyone gives in a little bit to the greater good. If I may, “The needs of the many outweigh the needs of the few, or the one.”
The design process described here is also known as a Trade Study. This is because you’re taking time to study many ways to solve a problem and you usually have to make trades between an option that score well on criteria 1, 3, and 4 against an option that scores well on criteria 2, 3, and 6.
This process is used many times to design a complicated system like a robot. There is a Trade Study for what type of drive train to use. There is a Trade Study for which mechanism to use to intake game pieces. There is a Trade Study for which mechanism to place a game piece. There is a Trade Study to determine if you are going to make the support arms or send them to a local machine shop to fabricate them. You can even use a Trade Study to determine which competition events you want to register for in the upcoming season. A Trade Study can also be used to build a pick list for Alliance Selection.
For this particular situation we found that a winch mechanism is something we have experience with and is easy to build. Using Velocity Control allows us to achieve the needed height in the desired time for a variety of real world conditions like battery power, robot weight, and other factors we had not considered. This also gives us the option to do a Buddy Climb. It will increase the time a little bit, but the robot will make the climb in roughly the same time whether it is lifting a single empty robot or two robots carrying game pieces.
During the evaluation process we discovered that the winch option allows us to keep the heavy motor and gearbox low and centered on the robot chassis. Managing the Center of Gravity (CG) of the robot is a criteria that is important but wasn’t in our original list of criteria. When we add this criteria it took some closely scored options and put the winch option much further in front of the other options. With a low CG we can increase the speed and responsiveness of the drive train without increasing the chances of tipping.
Stay tuned for the next post on taking this Design Decision into the Create step.
2 Likes
This reads like AI output to me…?
I don’t know how anyone is supposed to figure out how to tune from this. It’s all generalities and no specifics.
3 Likes
I never claimed to be more intelligent than AI. 
No, this segment is not specifics about tuning an PIDF controller. I provided my contributions to that earlier in the thread. Based on some of the other posts and some conversations I’ve had around the use of Power control and Velocity control I realized that there are many in our community that aren’t real sure when to use one over another. I have also seen many in our community who aren’t getting the basics on how to apply the FIRST Engineering Design Process to problems they encounter.
I thought this might be a good opportunity to help folks see how the process is used to get to the point that they are ready to tune their control system. I’m sorry for the confusion.
2 Likes
You keep saying this in title case… are you suggesting that there’s some single design process?
2 Likes
I’ve seen dozens of different engineering processes. I’ve used several of them in different situations and on different teams.
I’m saying that FIRST has selected one that they introduce to students in FLL (https://firstinspiresst01.blob.core.windows.net/first-energize/fll-challenge/fll-challenge-superpowered-engineering-design-process.pdf). They even reinforce this one through the FLL Judging Rubric for both the Innovation Project and the Robot Design (https://firstinspiresst01.blob.core.windows.net/first-energize/fll-challenge/fll-challenge-superpowered-rubrics.pdf). It is as good as the best processes that I’ve used.
I think teams should find a process and stick to it. It is great if they choose a process different from the one that FIRST promotes. The team should have documented reasons for using a process different from the FIRST process in case Judges ask them about it.
I’ve talked with many teams over many events and I have yet to find anyone who can clearly articulate a process that they used for doing their engineering. This includes students and adults. I get lots of examples of activities and tasks they performed for this specific robot. I have not heard anyone describe a general process that can be used over many different problems and then have the team members provide specific examples of how they applied their generic process to this specific challenge.
I see no reason not to use the process promoted by FIRST. I’m trying to illuminate to a group of FIRST team members how one example process can be applied to one challenge. I hope they see that if they learn this process, they can apply it to all the challenges they will face in the future. If teams don’t know where to start with a process, I think the best option is to start with the process promoted by FIRST. At least this will give them a commonality with other teams when they collaborate or seek assistance. Most teams don’t have mentors who have studied a variety of processes and who can guide students on how to apply a process to their FIRST work.
I should probably start a separate thread specific to the engineering process that teams have selected so as a community we can review all the available options and select the parts that work best for our unique team. Maybe I can do that after I get my guidebook on this process ready (FIRST Engineering Design Process - Google Docs). You can see that right now it isn’t ready for prime time.
1 Like
Why?
In the real world, engineering problems are generally too complex to fit neatly into some preordained “process”.
Given my 16 years of working at Lockheed Martin on real world complex problems, we always used a process to create smaller, manageable, measurable, incremental steps along the way to deliver a solution sometimes after ten years of work.
Moving from Authorization to Proceed (ATP) to System Requirements Review (SRR) to Preliminary Design Review (PDR) to Critical Design Review (CDR) to Test Readiness Review (TRR) and Pre-Shippment Readiness Review (PSRR) is a process and it is defined by the entry and exit criteria for each of these milestones. And while preparing a next generation weather satellite or a nuclear missile these milestones map really well to Identify, Design, Create, Iterate, and Communicate.
2 Likes