Motion Magic vs Motion Profiling

It gives you a lot of benefit when you start wanting to do more-accurate feedforward and composition of controllers, because the profile is located in your code and you are able to consume its state for other calculations. You can work around this with motion magic to a degree via the getActiveTrajectoryPoint method (or whatever it’s named - I don’t remember precisely), but it’s clunky and limited.

For a simple implementation, motion magic is fine; but it does have longer-term architectural costs.

Can you provide a specific example / application and explain why is provides a practical advantage? I’m struggling to see a situation where this is necessary. Can’t you just use encoder counts to know the current location of a mechanism? I can’t think of an FRC application I’d ever build that would specifically need to use a DIY motion profile on the rio vs motion magic or smart motion with the exception of some fancy sensor fusion drive train positioning stuff that is over my head (and out of the capability of 99% of teams)

We did some pretty complicated arm control that coordinated elevator position, arm position, wrist position, and 2 independent alignment devices. All the motion control was still done with motion magic in the Talon.

2 Likes

Sure: You have an arm and want to apply a feedforward of the form:

kCos \cdot cos(\theta) + kS \cdot sgn(\dot{\theta}) + kV \cdot \dot{\theta} + kA \cdot \ddot{\theta}

You generally want to get the velocity and acceleration terms from your setpoint, rather than from your measurements, because measurements are usually pretty noisy. With motion magic, the profile generation is offboarded onto the motor controller, so you have to poll the current setpoint through the Talon API, and then reactively adjust the arbitrary feedforward to match it. This is a really circuitous way to accomplish this - it is much cleaner to have direct access to the profile before it is executed, and generate/apply the feedforward proactively.

There are a lot of other, similar cases - any time you want to compose your profile with a controller of your choosing, having that profile be generated offboard is a barrier.

2 Likes

weird flex but ok

11 Likes

At the risk of sounding not GP…

Yeah, but how many wins you got?

One of the things I’ve always felt FIRST did an exceptional job of teaching students is that there’s often multiple valid solutions to a problem and which one your choose should depend on other constraints. Perhaps your solution is technically more correct but for the overwhelming majority of teams it is more complex than required to achieve their goals.

Does the on motor controller approach achieve the objectives of 99% of teams? Are teams perhaps MORE successful by simply treating the how as a bit of a black box? Can it be more inspiring to have something work in a, perhaps, suboptimal method?

Learning the “right” (and I have a hunch some would dispute this, it’s not pertinent for my point) way too do something is important but in a program centered around resource scarcity and inspiration there may be more effective battles to fight.

12 Likes

but…

7 Likes

The target setpoint…as in the destination point you are telling the arm to go to…right? Why would you need to poll the talon for the setpoint? You have that value before you write it the the motor controller…

Do you mean polling the Talon for the current position as the motion is being done?

Not quite; rather, the current target state of the control loop.

1 Like

What is this state you are referring to? Is the the current position/velocity/acceleration of the object being controlled? When you say state of the loop I don’t visualize that beyond like… (at position, moving to position, stopped, etc)

A motion profile is a sequence of target states that interpolates smoothly from your initial state to your goal state.

At any given point in time, the feedback controller is attempting to drive the system to one of these intermediate target states.

It’s often useful to base one’s feedforward for the intermediate motion on the current target state, rather than the end goal state (in particular, because basing it purely on the end goal state makes it impossible to account for velocity or acceleration).

1 Like

Your understanding is correct.

The rio is actually fast enough to generate motion profiles on the fly. You don’t need to do this, however.

Motion Magic is more than good enough for position control of an elevator. Even regular ControlMode.Position is good enough if you’ve properly tuned your gains.

Don’t let perfect become the enemy of good enough.

13 Likes

This is a recurring discussion point in FRC in both mechanical and software realms. On the mechanical side, few teams do any kind of rigorous analysis, and a lot of teams don’t do complete CAD of their designs. There are also a lot of mechanical design practices that work “well enough” for a robot that only has a few dozen hours of operational life but would be unacceptable for other applications. The same applies to software. Black box, off the shelf solutions like motion magic are good enough for a lot of teams’ needs, and if they’re easy to use and get to a solution quickly, that’s great, just like COTS components enable teams to do on the mechanical side.

However, I would hope these comments don’t shut down conversation about the pros and cons/limitations of different design approaches (both in mechanical and software). It’s possible for teams to run into limitations, or be interested in seeing what’s beyond the off-the-shelf solution, and discussions like this one are important to inspiration as well. Just like we talk about how custom gearboxes, full robot CAD, or mechanical analysis can be beneficial when the resources are available to do it, talking about higher level software/controls architecture is something we should be doing.

6 Likes

I agree with your statement. We just have to be careful to stay in the discussion side of things and not fall into evangelizing.

2 Likes

I definitely think the exploratory learning of the more in depth and more versatile way of calculating the motion profile is worth doing. However, I also want to ensure that it is understood as several people now have said that there is a much easier way to do things to get it done. Via Motion Magic, P-Loop, PD Loop.

I have seen in person now two years in a row…teams that try to take the hard route towards the more perfect way of solving the problem…sacrificing performance in the process instead of improving it in the end… instead of using something that just works.

1 Like

Never intended on it. But to respond to “can you say when this is useful” with a string of complicated looking math comes across as elitist and could be off putting to students who maybe aren’t quite there. Far too often I see people dismiss solutions that are simpler as “garbage” and instead refer people to whatever crazy thing 254/971 is doing these days.

Not all systems need accurate motion profiling, sometimes you can get away with a limit switch or two :stuck_out_tongue: It’s an important business lesson to.

Recently I had one of our C suite folks declare he wanted to redo how we manage version numbers internally. I pushed back as we are a small team and tried to understand the problem he was really solving which, as it turns out, was that he didn’t like how they were displayed in the UI. So we were able to bunt a complex change (lots of different systems use that version number) into a relatively low risk UI change because we understood the problem space.

Now, I am a fairly experienced engineer who also happens to have a bit of a reputation for not biting my tongue on things. I have absolutely no problem pushing back to understand the problem. However, when a 10th grader who barely groks PID sees some of us talking about arbitrary feed forwards and calling solutions that ARE viable ■■■■ they aren’t going to be able to identify the particular circumstances under which PID isn’t enough.

Communication is hard yo, we should strive to suck less at it.

5 Likes

For what it’s worth, this isn’t what I intended to communicate at all - my very first post states that “Motion magic is a good option to get a simple profiling implementation working with minimal changes to the rest of your code.”

As for the complicated equation, as it happens there’s an open-source tool for system identification that will give you the best fit parameters for that exact equation - WPILib 2020 will also include a helper class for calculating the feedforward. I probably ought to have just linked this in the first place, rather than stating the equation.

2 Likes

“Not having all the information you need is never a satisfactory excuse for not starting the analysis.”
Akin’s Law # 9

Do you maybe see how what you posted is either beyond the scope of the thread or, barring that, poorly communicated as it makes it appear far more complicated than your prior postings? Additionally, I’d be remiss if I didn’t mention that I admit my interpretation of your postings is often colored by previous ones which have, in my estimation, erred on the side of overly complicating problems. Take from that what you will.

Stating the equation rather than linking to the tool was certainly a poor communicative choice; unfortunately the thread had already wandered out-of-scope a while back, but I don’t think that particular reply was out-of-scope given that I had been directly asked for a concrete example of when motion magic might be architecturally troublesome.

3 Likes

I’d assert even linking the tool would be a poor choice - neither is a concrete example. Mike asserted that for his fairly complicated arm (having poked at the code for said arm I’d second this) he found motion magic to be adequate.

What sort of applications would arbitrary feed forwards be required for or, more specifically, under what sort of applications would the built in motion magic be less ideal than streaming a motion profile to the Talon or other options?

Across the applications I’ve dealt with (single DoF arms, elevators, swerve modules) I haven’t found the in built systems lacking.