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.
So you seem to have a reasonable grasp of motion profiling. The generic form is “given a set of constraints and a target, get there as quickly as possible”, in your case, you want to minimize jerk, likely to prevent the robot’s wheels from leaving the ground which can lead to inaccurate/unreliable movement.
2D Motion Profiling will allow you to say, “I am at (0,0) heading 90-degrees, get me to (-4, -4) heading 0 degrees and I want my jerk not to exceed 10 m/s/s/s” (it’s not limited to a single point, you can set way-points), and the Motion Profiler will output a set of timestamped wheel velocities that you can feed into your robot’s drive train.
Where does odometry fit into this? Well at the start, though perhaps you could hard-code this. But as you stream more motions together (go here, get disc, shoot disc, then go there), there may be some error accumulating in your movements.
In theory, the odometry will tell you where you actually are. You can use this in two ways:
Instead of hard-coding the starting point of a motion profile, use your odometry to set that value. This is relatively easy and intuitive to do.
Use odometry DURING the execution of the motion profile.
For 2, the actual output of the motion profile is usually a data structure such as:
Timestamp
Left wheel speed
Right wheel speed
Expected X location
Expected Y location
Expected heading
Other information
So, given you have accurate odometry, you can now detect at each timestamp how far away from the expected location you actually are and make corrections to the “suggested” wheel speeds to make nearly-instantaneous course corrections, leading to more accurate and reliable robot movement.
The two most common algorithms for doing this are “Pure Pursuit” and “RAMSETE”.
You can use okapilib’s motion profiling without worrying about all of the implementation details. That’s all the code you really need. Do note though that it doesn’t use correct for error it simply follows precalculated voltages.
thank you so much both of you, this is very insightful. where does pid tie into this and if motion profiling determines its own ideal voltage, and pid also determines a voltage to output - which do i use?
PID could be used to help your robot settle at a specific waypoint. Most of what motion profiling is getting your robot to a point and a heading, so a combination of turn and motion PID loops could be used to achieve this.
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:
Accurate odometry
Generate Motion Profile to target from odometry source
Apply Motion Profile, either directly or via Pure Pursuit / RAMSETE (while updating odometry)
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
Do whatever action necessary at the target site and then go onto a new target site and step 1
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
