Motion profiling is the process of creating a sequence of positions and velocities to follow a path under certain constraints. In FRC, a widely used motion profile is the trapezoidal motion profile, which begins with a period of constant acceleration, then coasts at some maximum set speed, then decelerates with a constant deceleration to arrive at the destination. Unfortunately, motors do not produce a constant acceleration regardless of speed - once a motor is no longer restricted by its current limit, its produced acceleration will diminish to zero as it approaches its free speed. This means that trapezoidal motion profiles are often not completely appropriate, as the system is unable to keep up with the expected profile as it reaches its higher speeds.
In this whitepaper, an alternative motion profile which I call the trapezoidal-exponential motion profile is derived (a bit of a mouthful, I know). This motion profile correctly incorporates the system’s exponentially-decaying approach towards its free speed. It also handles the cases where the exponential and/or coast portion of the profile is not reached.
Additionally, a Google Scripts-enhanced Google Sheets demonstration is provided to show what this motion profile will produce for a specified elevator or drivetrain.
An ExponentialProfilePIDController is one way you could follow an ExponentialProfile, correct. One thing I’d like to point out is that an exponential profile (which is distinct from a trapezoidal-exponential profile described in this paper) is the natural profile a motor will follow when given a constant voltage, and has already been implemented into WPILib. I believe its use would be more on the prediction side of things rather than the path planning side of things - after all, the best way to get a motor to follow the path it follows when given a constant voltage is just to give it that constant voltage, no complications required.
The flaw with the exponential profile path is that there’s no control over the system’s acceleration, which is why the basic trapezoidal profile was created in the first place. The trapezoidal profile then has a new flaw, in that it might not be feasible for the system to actually follow at higher speeds. That’s where the trapezoidal-exponential profile comes in, utilizing the trapezoidal profile for acceleration limiting and then transitioning to the exponential profile when the system can no longer follow the trapezoidal profile.
So finally, to answer what I think your question actually was, a TrapezoidalExponentialProfilePIDController would likely be the standard WPILib controller to follow a TrapezoidalExponentialProfile. Though you could easily implement that portion yourself by feeding the TrapezoidalExponentialProfile samplings into a standard PIDController.
Is your intention here to produce a repeatable profile that allows a higher acceleration to be requested of the motor earlier in the profile then? This logic makes sense to me… curious to see side-by-side comparison of the control (repeatable mechanism motion) you’re able to achieve. Ideally highlighting that you’re able to achieve consistent, but overall faster, profiles using the technique you’ve proposed here, versus trapezoidal, or trapezoidal+jerk limits.
That’s a feature, not a flaw. If you’re doing voltage control, you aren’t controlling acceleration directly. Unless you hit a current limit (and thus a torque limit), the time-optimal motion profile for a DC brushed motor (or a DC brushless motor without field weakening) is an exponential profile. It’s essentially a bang-bang profile with the control input (voltage) maxxed out at all times.
The ideal way to use an exponential profile is to set the max voltage a bit lower than the true max, so feedback has the control authority to reject disturbances. You get a repeatable motion profile that takes better advantage of the motor dynamics.
Here’s what a trapezoid profile does instead. Note how the full control effort available is never used to reach the max profile velocity.
The profile described in the whitepaper is essentially an exponential profile that also handles current/torque limits.
I disagree. The trapezoid profile was created first because it was the simplest kinematically valid motion profile to implement. That doesn’t make it the best fit for the system dynamics. Very few things have a direct torque input, which would make a trapezoid profile the right fit.
As far as I can tell, the trapezoidal-exponential profile will allow you to more accurately model your system’s motion at higher speeds. For example, check out this graph:
The red represents a trapezoidal profile while the green represents a trapezoidal-exponential profile, solid represents velocity, and dashed represents position. Both have the same acceleration limit, max speed, distance to target, etc.
While it looks like the trapezoidal profile performs better (less time to target), the area shaded in yellow represents distance that the trapezoidal profile expects but that the system is not able to actually produce at that time. If your top speed is less than the critical speed where the two profiles diverge (dotted red horizontal line) then the trapezoidal-exponential profile simplifies to a normal trapezoidal profile.
Another method to keep the trapezoidal profile accurate would be to reduce your max accel so that the critical speed moves higher, but doing that unnecessarily increases your time to target compared to using a trapezoidal-exponential motion profile with your original max accel. This is what WPILib describes in their trapezoid profile doc page when they say:
In this example (and in many others, I suspect) the difference is pretty minor - that said, this should help your controller out since it isn’t expected to produce performance that’s outside of its capabilities, which could cause it to start accumulating error.
You’re correct, my phrasing was imprecise. I would say that not having current/accel limits is a limitation of the exponential motion profile, which makes it suboptimal for current/accel limited systems (e.g. drivetrains and elevators). I believe the main benefit of a trapezoid profile and why it’s so common is that when bang-bang is too aggressive, we intuitively want to make the system move more “smoothly” (with limited acceleration) while minimally limiting the motor’s output (i.e. increase the voltage as the system picks up speed), which ends up giving us a trapezoid profile.
Correct - this is one way to approach it. The other method to arrive at this profile is to take a trapezoid profile and correct it to match the motor’s output limitations.
You’re correct in that these motors will have reduced ability to produce torque the closer they get to their maximum free speed.
The mantra I always go back to with mechanism control is “if you know something about the system, you should probably express that in your control algorithm”. Here, you’re saying we know that the motor will have a reduced, potentially highly reduced, ability to output torque, so we would do well to not “request” it produce that torque through the shape of the motion profile. That’s a good idea.
My question was in your approach to testing this setup you’ve come up with. On our team, we’re usually down-selecting the work we choose to do based on its likelihood to improve robot performance. For motion profiles, that usually means moving faster, if it can be done so in a reliable, repeatable way. That’s why my question to you was surrounding the benefit implementing this would give a team.
This profile, if followed correctly, would be slower due to the yellow-hatched area in your picture above. However, I would hope that we would make up for that lost time by increasing the acceleration for the other sections of the profile. During the tuning process, I would expect to find that the mechanism can “sustain” higher peak acceleration profiles than with trapezoidal because the decrease in possible motor torque towards the cruise section is being accounted for.
Hopefully this clarifies what I was going for in the original post. Trying to outline the test I would do if I was trying to see if this different motion profile proved “useful” for FRCFIRST Robotics Competition.
Yea, their figure isn’t an apples-to-apples comparison between trapezoid profiles and exponential profiles. Their simulation assumes the composite profile would be heavily current-limited, but I had the opposite experience for 3512’s robot in 2020; it was rarely current-limited.
By applying differential drive dynamics constraints in the trajectory generator, we got exponential profiles the robot was able to follow perfectly that took advantage of the higher dynamically feasible accelerations at low velocities (as opposed to limiting oneself to the lower dynamically feasible accelerations at higher velocities with the goal of having a completely feasible trajectory). For our drivetrain’s dynamics, trapezoid profiles were leaving a lot of performance on the table.
I see your point, and I agree that the benefits of this profile for the average team are unclear. Realistically, trapezoid profiles get you at least 90% of the way there in terms of time-to-target (since you can make a trapezoid profile as aggressive as you want), so if accuracy of profile following isn’t a valuable trait for your team (which for most teams I suspect it isn’t) then there is not much upside to implementing this profile in code.
Another potentially valuable application of more accurate simulations is in choosing optimal gearings. I tried to compare the optimal gearing for time-to-target using trapezoid vs trapezoidal-exponential (with same mass, motor, accel/current limit, max speed, etc) and both gave similar results, though it’s possible there are cases where the two are more distinguished from each other.
The most pronounced case I found was when the current/accel limits were set to the peak of what the motors can produce, but even then the optimal gearing differences were marginal (17.8:1 vs 17.2:1 for trapezoid and trapezoid-exponential, respectively). The time to target did differ more substantially (~10%), but that will likely not be impactful for most teams.
This does come back to something that I found with my prior whitepaper regarding double jointed arm dynamics - while novel models can provide some benefit, effectively indistinguishable performance can often be achieved with good ol’ PID or other comparably simple methods.
That’s not really what I’m saying. I’m saying that the benefits of this scheme for anyone are unclear because there has been no test (or simulation? physical test is always best though) that compares best achievable performance under trapezoidal control to best achievable performance under your proposed scheme for the same physical mechanism.
You’re thinking about the right limitations for control here. The test I’m outlining would serve well to (a) show that the improvement is worth putting effort into (like robot code implementation) and (b) convince others that they should try out your approach, if that’s something you would like.
Yep, exactly. Identifying a situation where this would actually be useful is a key aspect to warranting further investigation.
I put together a desmos plot representing the system’s position under trapezoidal (velocity in red; position not shown) and exponential (velocity in purple; position not shown) profiles with the same max accel and speed and it looks like the position error ratio (green) consistently peaks at about 39.8%, regardless of how the max accel and speed are varied:
The trapezoidal-exponential profile will end up with somewhere between 0% and 39.8% peak position error, depending on how high the critical velocity where the trapezoid profile is no longer feasible is.
Use trapezoid profile if your DC motor is always current-limited or you’re doing torque control
Use exponential profile if your DC motor is never current-limited
Use the algorithm in this whitepaper if you’re sometimes current-limited
The assumption is all three algorithms are already implemented such that switching between them is as simple as changing the class name and a few of the arguments (already the case for TrapezoidProfile and ExponentialProfile).
The problem here is you’re being overly conservative with the exponential profile. It’s not a fair comparison. If the trapezoid profile is allowed to do dynamically infeasible things like exceed the DC motor dynamics while obeying the current limit, why can’t the exponential profile also do infeasible things like exceed the current limit while obeying the DC motor dynamics?
What you should see is the exponential profile starting with a higher slope and thus velocity, then being overtaken by the trapezoid profile as the velocity increases. You could shade each curve to show how much each violates the union of the constraints.
It’s more common to set the max acceleration of a trapezoid profile to an acceleration well below the max from rest, so the robot has some chance of achieving it at higher speeds. In other words, the trapezoid slope is deliberately chosen to be shallower so the region of infeasibility is smaller.
The trapezoid profile acceleration limit provides a tradeoff between on-field performance and tracking accuracy, though both are optimized with an exponential profile (assuming your accel limit = 12V stall accel). The original desmos plot shows the least aggressive trapezoid profile that still extracts maximum output at all speeds, showing its tracking error peaking at 39.8%. It is not meant to compare how the system would perform with a trapezoidal vs exponential profile, but rather how wrong it could get (40% is a lot!) if you use a trapezoidal profile and you’re unwilling to sacrifice time-to-target to improve your tracking.
Here is an updated plot where you can lower the trapezoid profile slope as low as you want to reduce your tracking error, at the cost of under-powering the robot at lower speeds:
In this plot, error ratio < 1 = underutilized capacity while error ratio > 1 = overpromised performance.
Example with trapezoid slope = .7x max acceleration:
I think the best single comparison is the differential time to target given two profiles that are as aggressive as possible given no tracking error. You’ll have to shrink the cruise velocity on the trapezoidal profile to make this happen, and there may still be a free parameter there.
The dynamically feasible trapezoid profile performance gets worse as the profile maximum velocity approaches the DC motor free speed, for a given current limit. The slope for the whole profile decreases, with the profile doing nothing when the profile max velocity equals the DC motor free speed.
The dynamically feasible exponential profile performance gets worse as the current limit decreases, for a given motor model. The maximum slope at the profile start decreases, with the profile doing nothing when the current limit is zero.
Imo, you should always design your motion profiles to be dynamically feasible because that’s the whole point of using a motion profile: repeatability. If you run out of control authority, it’s no longer repeatable in the presence of disturbances.
I put together two graphs. Both ignore deceleration in their time-to-target calculation.
The first is one where you use a trapezoid profile and are unwilling to compromise on time-to-target but want to minimize the tracking error under that constraint, so you set your trapezoid acceleration to your stall acceleration a_{max} and your coast speed to your max speed v_{max}. This should give the best-tracking trapezoid which always outputs 12V. From playing around, it seems like your position tracking error caps at 39.8% and your time to target in reality caps at 23.0% higher than predicted in the worst-case-target-distance, regardless of your system’s v_{max} and a_{max}.
The second graph is the one you suggested, where you’re unwilling to compromise on tracking accuracy (so you set your coast speed v_{lim} = v_{max}(1-\frac{a_{lim}}{a_{max}})), then play with your trapezoid slope a_{lim} to minimize your time to target. This one doesn’t have a nice single % number you can work with, but with v_{max} = 1, a_{max} = 1, we get that the trapezoid profile is slower than the optimal exponential control by the following percentages:
Assuming this is in meters, this implies autonomous routines can get 20-30% gains in speed by allowing the use of a higher max velocities. Maybe not useful for many games, but for large sprints this might be handy.
I actually see some use in something like an elevator where you may want to run it close to 100% speed as well.
Hopefully this is the last work I’ll have to do to wrap this up. In order to see what sort of gains we can expect from using trapezoidal-exponential instead of a feasible trapezoidal profile (where the coast speed and acceleration rate are simultaneously achievable), I wanted to compare the optimal trapezoid-exponential vs the optimal trapezoidal profile. Fortunately for me, the trapezoidal-exponential profile is already optimal, so that part was easy. Unfortunately for me, finding the optimal feasible trapezoidal profile was a lot of work and could have been its own whitepaper, but at this point trapezoid profiles should be phased out for exponential or trapezoid-exponential ones anyways.
To keep it brief, after 2 pages of calculus/algebra I managed to get desmos to figure out the optimal balance between coast speed and acceleration rate in an unconstrained trapezoid profile. I then added the casework for when the user-assigned accel limit is below the optimal acceleration rate (so the new optimal coast speed increases) or when the user-assigned speed limit is below the optimal coast speed (so the new optimal acceleration rate increases). This behavior is showcased in the following video:
I then re-ported the trapezoidal-exponential logic into desmos to compare it against the optimal trapezoidal profile. This is showcased in the following video:
As you can see, while the trapezoidal-exponential sometimes simplifies into a trapezoidal profile, it always either matches or outperforms the trapezoidal profile, and sometimes outperforms by a substantial margin.
Here is the desmos link if you’d like to play around:
