Auto-Aligning in Teleop

[Bo8_87]

Hello CD,
For my team's off-season competition, our team is implementing an auto-aligning feature for our robot. We have been able to align in autonomously using PID successfully, but in teleop, the aligning isn't consistent and sometimes the robot randomly oscillates in large circles.
We think that because the teleop loop is fetching more data (i.e. joysticks) than in autonomous, the feedback from the gyro that we are using to align is not fast enough to keep up with the robot.
Does anyone know of a fix to this issue? Perhaps speed up the teleop control loop rate?

[adciv]

Teleop executes every time a control packet from the driver station is received. Between network latency and other things, this tends to cause inconsistency in the timing between packets (jitter). This jitter causes issues with control loops. Instead, place your PID control loop in Periodic Tasks (if LabView) or an equivalent separate running periodic process if using Java/C++.

[GeeTwo]

Have you tried increasing your D? That usually dampens oscillations.

Without more detail on your setup, it's difficult to be more specific.

[M3rcuriel]

My guess is that this is a combination of your PID needing more tuning, the terrible timing from the Driver Station, and PID not being the best option to overcome the friction with the carpet without over-adjusting.

[martin417]

I do not understand why FRC programmers always want a full PID for every control application. In almost every case, a simple proportional control is more than sufficient. and often even that is overkill. For speed control, a digital or "bang-bang" control works quite well, and for aiming, a proportional algorithm is almost always good enough.

What we have done for aiming is to set the motor speed proportional to error, with the gain set so that when we get very close, the motor output is still being driven, but at a value so low that the motor doesn't actually move any more. The only thing you have to tune is proportional gain. It is quite easy to tune that with trial and error.

[Jared Russell]

Originally Posted by martin417

In almost every case, a simple proportional control is more than sufficient.

"Almost every case" is really pushing it, but the sentiment that not every application requires I and D is definitely correct.

For mechanisms that are well-approximated as a linear first-order system near the expected operating point (i.e. negligible inertia for position control; near constant inertia for velocity control), sure, P might be enough. Flywheels, lightweight turrets and conveyors, and counter-balanced elevators can fall into this category if you don't care about being lightning fast and/or can tolerate some overshoot or steady-state error.

However, drivetrains, arms, and heavier servo mechanisms definitely benefit from damping and/or integral action much of the time. The best policy is to always start with P-only, then add other terms from there as necessary.

To the OP's question: if the same PID gains work well for you in autonomous mode, then you must ask yourself what is different in teleop? It could be timing, other things your robot is doing when in teleop (are other mechanisms drawing from the battery or is your code taking much longer to execute?), or different initial conditions (e.g. are you trying to auto-align when you are much further off target in teleop and/or still moving, in which case you may need to re-tune your controller to these conditions)?

[aeastet]

First I would say that your teleop is running slower than auto. There are many ways to fix this but we need more information:

What programming language?
Can you provide your code?
Do you do anything different in Auto than in teleop?

If you get these answers I would guess that someone can help.

My guess is not the PID tuning. If it works in Auto then it should be fine as long as you are running the same loop rate. If one loop is running faster than the other you will get a different result. Everything in PID is based on time.

Tim

[wesleyac]

As adciv mentioned, placing things in teleop periodic is a Bad Idea. People tend to say that TeleopPeriodic and AutonomousPeriodic run at 20Hz, but they actually run whenever they get a packet from the driver station, which is *usually* approximately 20Hz. The result of this is that they have significant delays in when they're executed.

Ideally, the only things that you should do in your periodic functions is to check for new joystick values. If you're using C++ or Java, you should have a separate thread for your PID controller, so that you can easily control what frequency it runs at.

Once you have a PID controller running in a separate thread, you should see much more consistent results between auto and teleop.

If you let me know what language you're using, I can point you towards more resources for implementing a separate thread for your controller.

EDIT: This post is assuming that everything but the code that's running is the same. Jared Russell gave some good advice on figuring out if that's the case above.

[Bo8_87]

The code for the aligning is the exact same.
We are currently using Java
Could you elaborate more on the multi-threading for the PID Loops?

[adciv]

We don't use Java so I can't give complete details, but basically start a new thread running a custom class that you've programmed. That thread controls your drive train and nothing else. You pass it the commands from where ever and it executes them. Internal to that thread, it runs the PID or executes joystick commands directly or whatever else you're doing.

[Bo8_87]

Would using WPI's PIDController instead of a custom Controller work? According to online sources WPI's PIDController creates a new thread to run the control loop.

[adciv]

I wish I could say yes, but reading over the documentation it doesn't allow output to the drive train. It only allows control of single motor controllers. For controlling the drive train you need to be able to control all your drive train motors at once.

[Joe Ross]

Originally Posted by adciv

I wish I could say yes, but reading over the documentation it doesn't allow output to the drive train. It only allows control of single motor controllers. For controlling the drive train you need to be able to control all your drive train motors at once.

It will output to anything which implements the PIDOutput interface. It's correct to say that single motor controllers do. But it's not correct to say it doesn't allow output to a drive train, just that you need to make your drivetrain implement the PIDOutput interface.

[dmelcer9]

Originally Posted by Joe Ross

It will output to anything which implements the PIDOutput interface. It's correct to say that single motor controllers do. But it's not correct to say it doesn't allow output to a drive train, just that you need to make your drivetrain implement the PIDOutput interface.

Even easier is if you use Java, you can simply use a method reference:

new PIDController(Kp, Ki, Kd, RobotMap.mySensor, Robot.subsystem::outputMethod);

where outputMethod has the signature:

public void outputMethod(double output);

This assumes that you are using the command-based robot, but you get the idea. A lambda would work too.

[WSiggs]

Originally Posted by M3rcuriel

and PID not being the best option to overcome the friction with the carpet without over-adjusting.

What would be the best option for this then?