how does motion profiling work for a drivetrain

Motion profiling controls a drivetrain by gradually and consistently changing its desired speed over time, rather than instantaneously setting the motors to full power . This gradual change prevents uncontrolled movements, inconsistent autonomous runs, and mechanism damage caused by the drivetrain taking time to physically catch up to instantaneous full-power commands .

For FTC drivetrains, trapezoidal profiles are recommended over S-Curve profiles . While S-Curve profiles assume constant jerk to reduce wheel slippage, they are not optimal for controlling 2D trajectories like driving . Trapezoidal profiles instead accelerate the system at a constant rate .

In practice, a motion profile algorithm calculates target velocity and acceleration values over time . These calculated outputs are then passed into a PID and/or feedforward control loop to operate the drivetrain's position smoothly and predictably .

These profile ramp inputs can also be used to estimate the velocity (Kv) and acceleration (Kₐ) gains needed for a feedforward controller . Because these gains change based on the robot's mass and friction, they must be re-estimated whenever significant changes are made to the robot .

More advanced motion profiling for drivetrains is covered in the restricted Road Runner documentation at Road Runner — Motion Profiling and Road Runner — Motion Profiling .

Was this right?

Sources16

Control Loops > Motion Profiles

Game Manual 0·CC BY-NC 4.0

Tip: Motion profiles are not a specific type of control loop, but rather a technique that works well in combination with other control loops such as PID and feedforward.

Motion profiling is a technique popularized in FRC® that is starting to find its way to FTC. A motion profile is a function used to change the speed of a power transmission system in a controlled and consistent way by changing desired speed gradually rather than instantaneously.

Let's illustrate this with an example: say you want your drivetrain, which is initially unmoving, to drive forward at full speed. Ordinarily, you would set all drivetrain motors to full power in the code. However, this can be problematic because even though you tell the motors to move at full speed instantaneously, the drivetrain takes time to get to full speed. This can lead to uncontrolled movements which have the potential to make autonomous less consistent and, perhaps more importantly, damage mechanisms.

Motion profiling attempts to solve this issue.

Open Game Manual 0

Control Loops > Motion Profiles > Disadvantages

Game Manual 0·CC BY-NC 4.0

Can be slower

There are two main types of motion profiles: Trapezoidal profiles and S-Curve profiles. Trapezoidal profiles accelerate the system at a constant rate, and S-Curve profiles assume jerk (the speed acceleration changes) is constant. Given that S-Curve profiles are not optimal for controlling 2d trajectories (such as driving) and exist to reduce slippage (which usually only occurs when driving in FTC), trapezoidal profiles are recommended for most FTC applications.

Trapezoidal profiles get their name from the shape of the graph of velocity over time:

(Figure: These are the "magic functions" for velocity and acceleration over time alluded to in the feedforward section.)

Here is some pseudocode for a trapezoidal profile:

while True:
   current_velocity = get_current_velocity()
   current_time = get_current_time()

   direction_multiplier = 1

   if position_error < 0:
       direction_multiplier = -1

   # if maximum speed has not been reached
   if MAXIMUM_SPEED > abs(current_velocity):
       output_velocity = current_velocity + direction_multiplier * MAX_ACCELERATION * (current_time - previous_time)
       output_acceleration = MAX_ACCELERATION

   #if maximum speed has been reached, stay there for now
   else:
       outputVelocity = MAXIMUM_SPEED
       outputAcceleration = 0

   #if we are close enough to the object to begin slowing down
   if position_error <= (output_velocity * output_velocity) / (2 * MAX_ACCELERATION)):
       output_velocity = current_velocity - direction_multiplier * MAX_ACCELERATION * (current_time - previous_time)
       output_acceleration = -MAX_ACCELERATION

   previous_time = current_time

The results of the above pseudocode are then used in a feedforward and / or PID loop to control the position of the system in a smooth and predictable way.

A more advanced example of the math for motion profile generation as used in the Road Runner library (https://github.com/acmerobotics/road-runner) can be found in this Jupyter Notebook (https://mybinder.org/v2/gh/acmerobotics/road-runner/HEAD?filepath=doc%2Fnotebook%2Froad-runner-lite.ipynb).

Open Game Manual 0

Control Loops > Motion Profiles > Advantages

Game Manual 0·CC BY-NC 4.0

More controlled and predictable movements
Reduces rapid change of applied motor voltage

Open Game Manual 0

Motion Profiling

This source does not publish a licence, so its text is not reproduced here. Open the source to read it.

Open Road Runner

Motion Profiling

This source does not publish a licence, so its text is not reproduced here. Open the source to read it.

Open Road Runner

Control Loops > Feedforward Control > Kv Ka Feedforward Model

Game Manual 0·CC BY-NC 4.0

The most common feedforward and the one used by libraries such as road-runner is the Kv-Ka feedforward model:

f(t) = Kv · Velocity + Kₐ · Acceleration

Where Kv is the velocity gain, Kₐ is the acceleration gain, and f(t) is the feedforward output sent to your motors.

These gains can be estimated by giving the controller a series of ramp inputs (such as those computed with a motion profile), measuring the output, and then changing these gains till the robot matches the desired motion.

Note: The gains will change based on the robot's mass, friction, and other factors. It is recommended to re-estimate these gains every time you make a significant change to your robot.

Open Game Manual 0

Control Loops

Game Manual 0·CC BY-NC 4.0

Control loops are software used to operate power transmission systems (such as a drivetrain or linear slide) in a fast and controlled fashion. Not only do control loops let you run mechanisms quickly without fear of losing control, in many cases, they help preserve the longevity of mechanisms by reducing rapid change of applied motor voltage.

Open Game Manual 0

Drivetrain Control

This source does not publish a licence, so its text is not reproduced here. Open the source to read it.

Open CTRL ALT FTC

Dead Wheels

Game Manual 0·CC BY-NC 4.0

Warning: This is a very niche aspect of design in FTC®. Generally it is something done by more experienced teams who have had time to repeatedly test their designs and mechanisms with software during the off-season.

The term dead wheels, tracking wheels, odometry pods, and odometry are often conflated in the FTC community. However, there are a few key differences one must keep in mind. Odometry is an umbrella term and refers to the general use of motion sensors for localization purposes. Meanwhile, dead wheels, tracking wheels, and odometry pods are all synonymous terms.

Term: Dead Wheel — A small unpowered wheel (usually an omni wheel) that tracks the distance the robot has traveled through the encoder attached to the wheel's axle.

Usually, there will be two or three wheels - one or two on the x and y axis each to track the front-back and left-right position relative to the starting point. Generally, odometry wheels are sprung so that the wheel is in contact with the floor tiles at all times to ensure accuracy.

Odometry refers to the use of motion sensors for localization. Localization is a means for being able to locate the position of the bot at some point in time. Localization is crucial in path following and advanced autonomous modes as one needs to know where they are to generate the necessary movements needed to reach a desired destination. Localization software plays a major role in odometry; however, in order to produce accurate results, reliable and accurate hardware design is a necessity.

The simplest form of odometry is drive encoder localization. This is the use of encoders measuring the rotation of motors that power the drive train. One is able to read the encoder data and feed it through the kinematic equation for that specific drive train to derive the body's velocity. Drive encoder localization is generally quite simple and easy to setup as almost all of the FTC legal motors have built-in encoders. Getting drive encoder localization setup is simply a matter of plugging in wires, no additional hardware needed.

Open Game Manual 0

Trajectory > Trajectory Generation

This source does not publish a licence, so its text is not reproduced here. Open the source to read it.

Open FTCLib

goBILDA > Notable components

Game Manual 0·CC BY-NC 4.0

goBILDA uses 8mm pitch chain and HTD 3 or HTD 5 belts for motion.
goBILDA mostly uses clamping hubs (called Sonic hubs), eliminating the unreliable set screws.
goBILDA shafts are metric (6mm D and 8mm rounded hex).
The primary structural component is the 48mm aluminum U-channel, shown below.

(Figure: goBILDA U-channel (48x48 mm))

Low-Side channel (smaller profile channel) complements full size channel. Low-Side channel is just 12mm in height and allows for more compact builds. Additionally, Low-Side channel opens up possibilities such as a kit-based parallel plate drivetrain. Low-Side channel also forms the basis of the cascading kit with a 2 or 4 stage option.

(Figure: goBILDA low-side channel (12x48 mm))

Mini-Low-Side channel (even smaller profile channel) that compliments Low-Side channel. Mini-Low-Side channel is 12mm tall and just 32mm wide, making it great for small structures.

(Figure: goBILDA mini-low-side channel (12x48 mm))

Viper-Slides are goBILDA's version of the commonly used drawer slides for linear extension in 336mm and 240mm lengths. Notably, goBILDA sells a Viper-Slide kit, which contains all of the parts to assemble either a 2 stack or 4 stack of slides. In addition, they are one of the few vendors who sells a belted version of these slides. The 240mm slide is also uniquely bidirectional, sliding both ways.

goRAIL is extrusion that complements the channel offerings well. goRAIL is used in the linear actuator kit for extending mechanisms.

Open Game Manual 0

Control Loops > PID > Simplification of the PID formula

Game Manual 0·CC BY-NC 4.0

Here is a simplified version of the PID formula: f(t)=Kₚ P(t)+Kᵢ I(t)+Kd D(t)

All we have done is simply take the full formula and replaced part of the terms with functions: P(t), I(t), and D(t).

The first component of the function, Kₚ P(t), is by far the most simple and easy to understand, as P(t) = e(t). For the sake of example, let's pretend that Kᵢ=0 and Kd=0 (a PID controller with only a proportional constant is known as a P controller). How will the system behave? Well, if the error is large, the output will be large. Likewise, if the error is small, the output will be small. Also, ideally, given enough time, the system always approaches its destination, assuming Kₚ is of the correct sign.

Say we apply this to a drivetrain. You want to drive a distance D, and you decide to set your motor powers using a P controller to accomplish this. In this case, your error is how far away the robot is from the desired location. As you start to drive forward, your error is large, so you drive forward quickly, which is desirable. After all, you aren't concerned with overshooting the target yet if you are far away from it.

But as the robot's distance to the target approaches 0, you will start to slow down, gaining more control over the robot. Once the error is zero, ideally, the robot will stop, and you have reached your destination. If you happen to overshoot, the error will become negative, and the robot will backtrack, repeating the process.

Open Game Manual 0

Trajectory > Transforming Trajectories

This source does not publish a licence, so its text is not reproduced here. Open the source to read it.

Open FTCLib

Trajectory > Manipulating Trajectories

This source does not publish a licence, so its text is not reproduced here. Open the source to read it.

Open FTCLib

FTC SDK API > com.qualcomm.robotcore.hardware.configuration > ExpansionHubMotorControllerVelocityParams

FTC SDK API·BSD 3-Clause

When ExpansionHubMotorControllerVelocityParams annotations are placed on a motor type, the indicated PID coefficients are automatically initialized when instances of that motor are used.

Open FTC SDK API

Motion Mounting > Zombie Axle (Coaxial)

Game Manual 0·CC BY-NC 4.0

Term: Zombie Axle — Zombie axle is when one shaft serves as a dead axle for one mechanism and a live axle for another mechanism. This means one mechanism is mounted on the shaft via bearings, but the shaft is free to rotate independently to power a second mechanism. This setup can be used to transmit power to two things using the same revolution point, making it easy to power mechanisms like arms with intakes, or suspension drivetrain pods. Zombie Axle is only recommended when two mechanisms must be powered coaxially to each other.

Open Game Manual 0