Skip to content

Add Why Run To Position Mode Is Not A Good Idea #38

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions src/contributors.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,3 +9,5 @@
- j5155 [(github)](https://github.com/j5155) [(discord)](https://discord.com/users/496774369054425109)
- Arush [(github)](https://github.com/ArushYadlapati) [(discord)](https://discord.com/users/764258716463529986)
- ZachWaffle [(github)](https://github.com/zachwaffle4) [(discord)](https://discord.com/users/522513851942436867)
- NN [(github)](https://github.com/NipunNagendra) [(discord)](https://discord.com/users/667550773181415425)

Original file line number Diff line number Diff line change
@@ -0,0 +1,59 @@
# Why Run To Position Is Not A Good Idea
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This title could be better phrased.

"Not A Good Idea" is fairly weakly worded, I think a simple "Why Not Use RTP" or "Do Not Use RTP" is more direct and better.

When using a PID(F) controller to move a motor to a certain position, it is often tempting
to use the `RUN_TO_POSITION` mode, especially since it appears in many examples.
This motor run mode is built into the FTC SDK and is designed to move a motor to a certain encoder position autonomously.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

explain why RTP is so weird here; it's because it runs on the expansion hub/control hub's internal expansion hub
then explain how the other errors connect to that (it's the cause of them)

However, this mode is not ideal for a few reasons (ordered from most to least significant):
## Locked at 20 HZ

The `RUN_TO_POSITION` mode is locked at 20 HZ,
meaning that the motor will only update its position every 50 milliseconds.

**Why this is a problem:**

Imagine a scenario where you are trying to move a motor to a certain position.
If the motor is moving too fast, it will overshoot the target position and then have to correct itself.
However, if the motor is only updating its position 20 times per second, it will not be able to correct itself quickly enough,
leading to overshoots and even oscillations.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mention that this can especially be a problem with arms but RTP can sometimes work well on slides


Here's a [demo](https://www.youtube.com/watch?v=fusr9eTceEo&t=133s) of this effect.

### Why going Custom PID(F) is better:
With a custom PID(F) controller, you can update the motor's position every loop. Since most FTC loops run at higher than 20hz,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change to every loop of your OpMode, also give an example of what rate FTC loops run at (such as 100-200hz) and compare it to RTP

a custom solution will update the motor's position more frequently solving the problems mentioned.

## Syntax Requirement and Crash Errors
The `RUN_TO_POSITION` mode requires that you set the target position before you start the motor.
```java
motor.setTargetPosition(1000);
motor.setMode(DcMotor.RunMode.RUN_TO_POSITION);
motor.setPower(1);
```

First, this syntax is required to be followed exactly. This means that if you want to switch between manual and automatic control,
you will have to change the motor mode every time you switch. Programming any FSM or even any complex auto becomes quite difficult.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change "Programming any FSM" to "This can add significant complexity to coding autonomous" or something like it


While this seems like a minor inconvenience, if done in the wrong order, it **crashes the entire bot without outputting any useful error messages**.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change "if done in the wrong order, it" to "messing it up"

This can be a significant issue not only when debugging but also in games if it's precisely not controlled.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

games -> matches, precisely not -> not precisely
mention here that there's no way to deal with the issue except power cycling, so it can't be fixed during a match
if you want you can mention that 12087 directly experienced this last year and it led to them getting 23/23 at alaska state

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe yours was caused by the setting of targets and modes at the end of an OpMode, that then caused the next startup to have issues as they weren't cleared? Correct me if I'm wrong, this could be a legit SDK bug.


## Customizability and Tuning
Although the 'RUN_TO_POSITION' mode allows for some basic PID tuning, most teams don't do it and just use the default values.
This can lead to scenarios where the motor improperly responds to disturbances or even fails to reach the target position.

Moreover, the RTP mode is a simple PID controller, meaning that it doesn't have the advanced features that a custom PID(F) controller has.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say just remove this line
rtp is actually really weird and has some strangely fancy features, like velo PID, but cookbook doesn't need to get into those

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see no harm in documenting that RTP runs a nested controller


For example, for systems like arms and slides, you may want to add feedforward gains to counteract gravity or friction. RTP will not allow you to do that.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

counteract gravity depending on the arm angle or slide position


- https://www.ctrlaltftc.com/feedforward-control
- https://www.youtube.com/watch?v=E6H6Nqe6qJo
# Sooo, how do I solve it?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sooo -> so

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or remove entirely "How do I solve this?" / "What are some better approaches?"

PID(F) controllers seem scary, but they really aren't. All they do is try to get a motor to a certain position and hold it there.
Here's a [guide](https://www.ctrlaltftc.com/pidf_controllers/integrating_a_custom_PIDF_controller) on not only how to implement one but the logic.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change to something like Here's a guide explaining both the implementation and the math behind them.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add the gm0 page as well.


And of course, if you don't wanna do that or code your own, there are libraries like [FTCLib](https://ftclib.org/) and [Homeostasis](https://www.ctrlaltftc.com/homeostasis-by-thermal-equilibrium/what-is-homeostasis) that have PID(F) controllers that are just plug-n-play (with tuning of course).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wanna do that or code your own -> want to code your own

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mention dairy, potentially don't mention homeostasis? is it updated?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a line recommending that students try programming one at least once.


If you're using Roadrunner, you can use this [recipe](https://cookbook.dairy.foundation/roadrunner_056/how_to_integrate_a_PIDF_controller_with_roadrunner/how_to_integrate_a_PIDF_controller_with_roadrunner.html#pidf-controller-and-gains)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

something like "this recipe shows how to integrate them into your Road Runner autonomous"


Happy coding! 🎉

*Last Updated: 2024-11-02*