Although V5 does have a built-in PID with the encoder and moving the motor at encoder units, how would one move in encoder units but have variable speed such that the speed is highest when the error is a 50% and is slower when the error is closer 0% and 100%? The idea is that it starts off slow and increases its speed and then decreases its speed when it approaches the target. I have some code that is supposed to allow for a parabolic speed Auton but it doesn’t seem to work. If anyone has a multi speed Auton, I would appreciate some insight.
What you are describing sounds like motion profiles. Have you tried OkapiLib yet?
https://pros.cs.purdue.edu/v5/okapi/tutorials/index.html#walkthrough-tutorials
2 Likes
Does OkapiLib include motion profiles with variable speeds based on error?
move_absolute andmove_relative have a max velocity argument. So you can piece together steps at different speeds.
You might be able to have more fluid movement replicating this using the built in PID to control speed with move_velocity in steps using get_position to determine the change in velocity.
pseudo code example
motor.move_velocity(50);
while (motor.get_position() < first_position) {
pros::delay(10);
}
motor.move_velocity(200);
while (motor.get_position() < second_position) {
pros::delay(10);
}
motor.move_velocity(30);
while (motor.get_position() < third_position) {
pros::delay(10);
}
motor.move_velocity(0);
A more advanced option is to have one while loop and if statements to more gradually control starting and stopping. Then you could add counters to increase and decrease in more steps.
If you are writing your own PID you can use move_voltage.
I recommend NOT changing the built in PID values. That can have some bad consequence.
BTW, I do recommend looking in to OkapiLib examples. But first get the basics of PID and motion planning.
If you need more help keep asking questions.
6 Likes
My team wrote an auton using this idea in the past using move_voltage as described above. We broke down the movement into 3 steps: acceleration, max speed, and deceleration.
The robot would begin accelerating as fast as possible while not flipping over, scaling up the motor voltage as the robot moved forward. Once the robot had reached max speed, it would wait until it became close enough to the end distance to begin decelerating, using the same process used to sale up the power to scale it down. This had the effect you described, with max speed being achieved in the middle of the movement while the beginning and end were much slower.
We did this because the profiled movements in OkapiLib such as move_absolute and move_relative could not be edited due to their PID values being unknown and experimenting with them being dangerous as said by @rpm.
2 Likes
Ah I see you used voltage versus move absolute and move relative. Is it possible to replace the move voltage statements like you said with move velocity because that might increase the accuracy with position regulated movement?
You can create a position PID to control the motor’s built in velocity PID which is what that will do. But you can only tune your position PID. I don’t know what effect the periodic reading of the encoder value for the Pos PID will have on the motor’s built in Vel PID. It should not be an problem but who knows.
2 Likes
In PROS you are able to control the motor in multiple ways which circumvent the motor PID. So what you are describing ahould not be an issue.
I’m unsure. We used move_voltage due to the fact that we knew exactly what it did rather than using other OkapiLib such as move_velocity as we were unsure what they did exactly. You can definitely experiment with it.