This post was made in vf, but im figuring that i’d get more help here -

Currently working on motion profiling and improving my code, and after reading several forums and resources - I’ve gotten a little confused.

So what i have understood is that 2D motion profiling is a control algorithm that controls the robot’s acceleration and velocity to minimize jerk.
I’m also aware that it outputs the robot’s position, heading, velocity, and acceleration that the robot is at after controlling it to minimize jerk.

What is the need for the robots position and heading if you can simply use odometry and/or inertial, or GPS?

How do i integrate this with my 3 wheel bot code and pid?

Do i use the pid output for chassis power, and run it through motion profiling and then power the chassis with tuned numbers? i think thats kinda how slew works, but idk about motion profiling.

Most of what i learned is from here - 2D Motion Profiling | OkapiLib A PROS library for programming VEX robots

(I also feel kinda misled from this article - is that all the code needed for motion profiling? what else do i need?)

I explained what I knew about motion profiling above - but if someone could clarify more about how it decides on the ideal acceleration, that would help. Like does motion profiling need a path, or need to compare robot position or something like that? Pretty confused, so any help or resources will be clutch.

Thanks

There are many different ways to implment a motion profile.

This doesn’t have to be true. The most bacic motion profiles don’t contorl jerk at all and actually have infinity amount of jerk. At its core a motion profile doesn’t even do anyting; all it does is map out a set of velocitys that a motor could spin at to get to the target distance. Motion profiles have to be couppled with a motor controller system to make the motor actually move at said velocity with said acceleration(you don’t even need to contorl the acceleration really). This web site Motion Control Tips is a really good resource.

Since the motion profile is a path for your motors to follow at a certain time stamp you could use a velocity PID (your P term is the target velocity) to get your motors to run at that velocity.

Cross-posting my response from VF

The purpose of PID is to quickly get to a target position (or, less commonly, velocity) by taking the difference from the observed state and the desired state and applying a linear transform and then iterating.

Motion profiles will go thru a round of interpolation of waypoints, creating motor instructions at short (I believe 20 ms for OkapiLib) timeframes - basically the same scale that a single pass of a PID loop would operate at. At that point, a PID implementation may be updating its target point every pass thru the loop and one would need to determine what the “right” way to handle error accumulation for the I term.

But, the point of a motion profile is to provide tuned constraints so that the profile can be followed with little need for adjustment. As Jeff Atwood once said, “The best code is no code”. It should be possible to generate a motion profile that a robot can follow precisely by configuring the motion profiler with realistic and tuned constraints.

Barring this, approaches like Pure Pursuit and RAMSETE seem to me to be better approaches to use to follow a motion profile than PID. That said, I believe some teams have found success with using motion profiling to handle “coarse-grain” movements, track their position with odometry, and then make fine corrections, potentially using PID.

So:

0. Accurate odometry
1. Generate Motion Profile to target from odometry source
2. Apply Motion Profile, either directly or via Pure Pursuit / RAMSETE (while updating odometry)
3. When MP Follower completes, based on Odometry, make any small course corrections. Ideally these are small - possibly small enough that PID may not provide any benefit
4. Do whatever action necessary at the target site and then go onto a new target site and step 1

Thanks for all the help everyone!
Since I won’t be able to have pure pursuit done by my next comp - what should be my route?

Here’s my understanding of what everyone said -

The type of PID used with motion profiles is not what i expected - I won’t be needing any sort of my heading PID, drive PID, or turn PID, right (correct me if im wrong)? If I need PID at all, it will be for a velocity PID.

As soon as we have Pure Pursuit ready we will need accurate Odometry, and all the PIDs I listed above to follow way points. Until then, it’ll just be accurate Odom and Motion profiling?

While I don’t have Pure Pursuit - how can I make this work with Odom and the PIDs listed above - I apply the motion profile directly rather than through pure pursuit? Correct me if I misunderstood, but PID is completely unecessary with motion profiling?

Is a tuned motion profiling more accurate than a tuned PID? Should I scrap my drive, heading, and turn PIDs if I have motion profiling?

I have a RAMSETE controller but I’m having trouble generating the motion profile. I tried using squiggles but vexcode is cpp 11. I tried changing it to cpp 17 but that didn’t work. Is there any other way to generate them?

Hard to say; you’ll have to try-and-see. I would say my perception is more teams use PID than Motion Profiling for whatever that is worth.

My advise - work on getting accurate odom first, then decide between PID and Motion Profiling.

You are welcome to use or reference the WPI library port I created for VexCode: GitHub - VexWPILib/vpi: Vex V5 port of WPILib from FIRST

For example:

I need to update this example program to reference newer versions of the library, but conceptually you can see how one would use the VexWPILib: TrajectoryTester/src/main.cpp at main · VexWPILib/TrajectoryTester · GitHub

Hmmm. But if I don’t have Pure Pursuit or ramsete, why do I need odom for my motion profiles? I should be able to code motion profiling without it right?

Could someone also clarify - if I do motion profiling, I don’t need my drive, turn, and heading PIDs? - And can you clarify how I would without pure pursuit if i wanted to?

You don’t need them, but I’m assuming you probably still want to turn without driving, so you will want to keep at least your turn PID. My team is going to use both Pure Pursuit and PID movements in our auto skills.

Technically you don’t need Odom for motion profiles, but if you know your robot’s position you can generate the profile slightly differently to account for errors. It also allows you to debug a little easier if you graph all the positions your robot goes and allows you to add RAMSETE later if you don’t think your motion profiles are accurate enough by themselves.

Oh kk, this makes sense. Thanks so much!

So what if I were to run a 2D motion profile to get the ideal values for velocity to output the best acceleration and minimize jerk. Then I run my drive PID, and if the velocity that the PID would like to output exceeds the limits given by the motion profile, it caps it - but if not, then it keeps it.

Would that be a good way to run motion profiling and PID together?

Personally, I don’t think so.

The point of the motion profile is for you to supply it with constraints on jerk/acceleration/velocity that your robot both

1. Can achieve
2. Allows the robot to make reliable movements

Your mileage may vary, but I think running a velocity PID on top of a motion profile is not beneficial and increases complexity unnecessarily.

Maybe I’m misunderstanding what a velocity PID is, but to go with motion profiling I mean a drive PID that outputs increased/decreased voltage to your motors based on the distance you are from the destination. Are you saying that using that with motion profiling is unecessary, and will still be very accurate without that kind of PID?

Yeah, I think you are misunderstanding what a velocity PID is. Think of it in terms of a flywheel. You have a target velocity that you may under- or over-shoot, so you use a PID to more-accurately hit that target speed. You want to use a PID (or other control-system) on a flywheel because external forces (e.g. the disc passing thru the flywheel) will disrupt the actual speed of the flywheel.

In the case of moving a robot around the field during auton (especially skills), the likelihood that an external force will disrupt your movement is much less likely, which is where I base my opinion that Velocity PID+Motion Profiling is needlessly complex and probably not beneficial.

The point of Motion Profiling is to produce a set of motor commands that the robot can execute to reliably produce the same motion.

What about motion profiling and a drive pid? I explained how i would do so above, but im wondering if its possible at all

Almost anything is possible.

Go back to first principles. What does motion profiling do? What does a drive PID do?

hmmm, so we’re just going to use okapi’s 2D motion profiling because it seems the simplest - but almost too simple. How can i integrate that with my drive pid and odometry? is it possible? i have no clue how cause it’s barely any lines of code, and it uses its own functions and stuff. Do you recommend coding it myself without okapi to integrate it, or is there a way to make the okapi code work with my pid and odom drive code