Our team has not used Motion Profiling in the past(to my knowledge), although we did use Motion Magic(of which I have little recollection) for our elevator several years ago, so I do not have a lot of experience with it, although I have been looking into the different control methods recently. I have heard several teams say they have either an end effector or superstructure(a common example I have heard is an elevator) controlled with Motion Profiling. My understanding is that Motion Profiles have to be generated before-hand(unless there is some way to compute them on the RIO?) and are then loaded into the buffer on the Talon and used. My understanding of how Motion Magic differs it that it generates Motion Profile trajectory points on the fly and then loads them into the Talon as needed. How can a team actuate an elevator with a Motion Profile if it has to be computed beforehand? I could see how they could generate a number of different profiles to cover most circumstances but that seems both messy and limiting. Are these explanations for the different control modes correct?
Team 195 has 2 quite long youtube videos on motion control and goes over the difference between motion profiling and motion control and how to tune PID. The second video shows how to implement 254’s 2017 control code onto a robot.
We’re a team whose design and manufacturing capabilities greatly outpace software and control systems. So, we’re basically using these videos as a starting point.
I agree with @kl26436 on watching the 195 videos.
Speaking in a general sense, when teams “motion profile” an elevator or superstructure (or even a drivetrain), it typically refers to characterizing the movement (move to setpoint at x speed and z acceleration) (and whatever other factors the user wants to control)
The motion profile mode on the Talon refers to the user generating motion profiles (could be done on the fly, could be done at compile) and streaming them into the Talon.
Motion magic is a form of motion profiling, in which the max acceleration and velocity are configued and the Talon internally generates a profile to move to the target position.
Here’s a link to some of the code I use to generate motion profiles for simulation purposes, which could also be used at runtime on the roboRIO. That code uses 254’s 2019 motion profiling (which they didn’t end up using this year for their superstructure)
And while I believe your question was aimed more towards the understanding of each and less pros/cons of each, I’ll throw out there that motion magic is going to be way easier to implement and get quick results out of. I’d lean towards using custom motion profiling code before using the
Motion Profile Control Mode on the Talons (and by custom profiling code, I mean whatevers in 254’s current Github repository)
Motion magic now supports continuous velocity / trapezoidal acceleration. Note that the input passed to control jerk is a [0,8] value, not units / s ^ 3
The thread here: Motion Profiling
from 2012 is a really good discussion of motion profiling and how it is used. This pre dates the Talon and many of the principles in the Talon follow similar algorithms.
The algorithm I document in that thread was used by FANUC Robotics to do real time profiling of robot arms. This profile is then fed into the PIDF of the robot controller to make sure the prescribed motion is followed with minimum error.
One thing to note in general, motion profile is just a fancy word for saying “something other than full throttle”. At FANUC we preferred either trapezoidal acceleration or triangular acceleration profiles. You can pick whatever you want or just use the options found in motion magic. I believe motion magic has an option for the method we discuss in the 2012 thread, but others on 3310 deal with talons and software stuff.
Your understanding is entirely correct.
I strongly recommend avoiding the Talon’s motion profiling mode; the asynchronous nature of the follower makes the API somewhat clunky and difficult to work with. 449 used motion profiling mode for years, and while it certainly works as advertised, the long-term impact on our code structure was less-than-ideal.
Motion magic is a good option to get a simple profiling implementation working with minimal changes to the rest of your code. In the long term, however, you will likely find it best to generate motion profiles on your RIO rather than on your controller, as you then have full control over the “plumbing” of the process and can access the relevant state at any time. WPILib 2020 will ship with a TrapezoidProfile class to help with this.
Edit: Also, I just want to give you some props for a well-articulated help request in which you clearly laid out your current level of understanding and obviously put effort into thinking about the problem before posting. That’s rarer than it should be.
Probably not an answer that you want to hear, but I recommend instead investing your time into getting a basic closed loop on elevator position working first. The knowledge learned there will more easily apply to basic PID loops on other parts of your robot and is often faster to get a minimal POC robot working.
That said, if you want to learn more about motion profiling simply because it’s cool, ignore this post. But it’s not necessary to control any mechanism on an FRC robot.
Going to strongly disagree with this. Direct PID-to-position is extremely rough on hardware and much more difficult to tune than even a basic motion profile.
The majority of mechanisms on FRC robots can be controlled with just a P loop and maybe a constant feed forward, but, sure.
Feedforward is unusable for most position control (except for negating gravity) without a motion profile, because without some sort of motion profiling your commanded velocity is a delta function.
This is the same reason that direct PID-to-position is so rough on hardware; you’re essentially telling your mechanism to immediately jump to the next position, something that it is mechanically incapable of doing. This makes the control loop tuning far more difficult than it should be, because in addition to reducing error to within acceptable margins, you also must ensure that the transient dynamics of the system are gentle enough to respond acceptably to a step-function input.
Thus the “maybe”…
I don’t know what kind of mechanisms you’re building but to imply that you need to sit through a control systems 101 lecture for a month before tuning an FRC elevator (or any mechanism) is a little much. Every mechanism I’ve helped kids tune the last 3 years has been just a P loop and sometimes a FF to counter gravity, and all of those robots have done more than fine. You don’t even need a FF if you throw a big enough reduction with counterweighting at it.
All I’m trying to do is prevent kids online from biting off more than they can chew in a misunderstanding about what is required to make a robot “good.”
Why isn’t there an FRC industry standard so there isn’t so many programming questions every build season.
While I mostly agree with you, you don’t always have to make your PID controller critically damped. This seems like a great place to overdamp your controller. Obviously, that controller will reach your setpoint slower that a motion profile that accounts for the dynamics of the system.
A PD controller acts theoretically identically to a spring-damper system, which is nearly ubiquitous itself in engineering.
So if that’s the answer, why the OP question and why are there several posts suggesting different solutions?
It seems like whenever there’s a post asking for help there’s usually 3-4 possible solutions that individuals have used that only confuse those looking for a single, simple answer. It only gets worse during build season and it seems that similar questions get asked every year. Sometimes these get the “Do a search before asking” response.
Is there a way to raise the FRC programming floor, or CAD floor, or Fab floor, or Mechanical floor, or electrical floor, so that knowledge seeking mentors and students can move past a show stopping problem and increase the level of inspiration for their team?
Because complicated technical questions do not, in general, have simple, unambiguous single answers. That’s the nature of the problem-space. Learning to deal with this is an important part of the experience that students get out of FRC, because this is how it is in the real world, as well. You have to think.
If you think there’s a “baseline answer” that should be the starting point for most people asking a given controls question, open a PR to frc-docs and submit it; that’s a large part of why WPILib has open-sourced the docs for 2020. But there will never be a single reference that settles these issues unambiguously, because the world is more complicated than that.
Though, I think it can be helpful and useful to get a response along the lines of “here are some resources you can use to learn more about this, but in MY opinion, here is a great/simple place to start.”
Both you and Swami_dm have good points here. Teams are often stonewalled because they think a problem is too challenging for them when there are at least 1 or 2 somewhat simple paths forward, but they also need to be given the opportunity to learn about the problem in depth.
2791 won two regionals on the #1 alliance and was the first overall pick in our division in 2019. We controlled our elevator with a P loop. KISS.
I think we more or less have that in this very thread, though - prior to this digression (which should probably be moved into another thread, out of courtesy for the OP), there were several to-the-point and cogent answers that gave the OP several directions that could be pursued.
We won DCMP’s with a P-controlled elevator in 2018. For 2019 we went to the Spark MAX’s “Smart Motion”, and it was just as simple to do as a P-gain, with some extra benefits for some extra effort -
- Set a low max speed (for now)
- Set a high-ish max acceleration going up, but a low acceleration going down
- Set a low value for P (ours was 0.0005), and test. Tune P (there are plenty of resources on what this means).
- Slowly ramp up max speed until we’re comfortable with how the elevator moves; re-tune P as necessary. In particular, ensure the elevator doesn’t crash into the mechanical stops.
Smooth as butter.
Maybe it’s because my understanding of the more finite details of motion control are lacking, but I wouldn’t think generating your own motion profile gets you that much benefit for the time invested over using Motion Magic. I’ve seen plenty of the best teams in FRC using it.