Java x axis on joystick

[Ozuru]

Originally Posted by GeeTwo

Which programming model are you using (Sample, Iterative, etc)?

What model of joystick are you using?

What motor controller are you using (Talon SR, Talon SRX, Jaguar...)?

Essentially, you need to declare a motor controller and a joystick axis, and do a motor.set(joystick.getX()) several times a second.


Here's a recent snapshot of our current "elevator" at github. It's built on the IterativeRobot template.

Hi GeeTwo,

What is the purpose of a PID subsystem? I have never understood why PIDSubsystems are used -- couldn't this have been accomplished using just a regular subsystem? What are the advantages to using a PIDSubsystem and when should it be used?

[GeeTwo]

Originally Posted by Ozuru

Hi GeeTwo,

What is the purpose of a PID subsystem? I have never understood why PIDSubsystems are used -- couldn't this have been accomplished using just a regular subsystem? What are the advantages to using a PIDSubsystem and when should it be used?

PID is a feedback technique. Feedback systems automatically adjust the inputs to a system (e.g. voltage applied to the motor) to seek a specified output (e.g. lift the tote so that it is 12" above the carpet). For Recycle Rush, we believe that this will help us perform line-up, pick-up, stack, and score actions more quickly than a human driver is likely to manage. While I don't think that the code as posted has it yet, we are going to limit the speed of lift/lower (specific number TBD, but probably about 2 fps) and provide "stop points" for various pickup, stacking, and scoring tasks.

PID allows you to set a target speed or position (or any other measurable quantity), and the code automatically seeks to attain and maintain that value. The key requirement of PID (or any other feedback technique) is that you are regularly measuring the output state of the system. This year on our lift, we're using a 10-turn potentiometer as a sensor. The current mechanical setup is the electrified tape measure similar to the one shown in this post. One of our mentors doesn't trust return springs in cheap tape measures, so we may switch to something that engages a 22-tooth idle sprocket with our lift chain. Tuning the PID to minimize settle time, overshoot, oscillation, and droop is at least as much art as science, but we're going to take that plunge again this year.

We have also used PID loops in the past (and will again this year) to automatically aim our game piece manipulators. For Rebound Rumble, Ultimate Ascent and Aerial Assist, this meant driving the robot so that we were properly positioned to score when we threw the game piece. For Recycle Rush, our goal is to align on the totes (and RCs) so consistently that they form a neat, stable, stack. For these applications the sensor has been, or at least included, a camera. The desired "output" in this case is the size and location of a vision target as reported by some openCV scripts.

[Ozuru]

Originally Posted by GeeTwo

PID is a feedback technique. Feedback systems automatically adjust the inputs to a system (e.g. voltage applied to the motor) to seek a specified output (e.g. lift the tote so that it is 12" above the carpet). For Recycle Rush, we believe that this will help us perform line-up, pick-up, stack, and score actions more quickly than a human driver is likely to manage. While I don't think that the code as posted has it yet, we are going to limit the speed of lift/lower (specific number TBD, but probably about 2 fps) and provide "stop points" for various pickup, stacking, and scoring tasks.

PID allows you to set a target speed or position (or any other measurable quantity), and the code automatically seeks to attain and maintain that value. The key requirement of PID (or any other feedback technique) is that you are regularly measuring the output state of the system. This year on our lift, we're using a 10-turn potentiometer as a sensor. The current mechanical setup is the electrified tape measure similar to the one shown in this post. One of our mentors doesn't trust return springs in cheap tape measures, so we may switch to something that engages a 22-tooth idle sprocket with our lift chain. Tuning the PID to minimize settle time, overshoot, oscillation, and droop is at least as much art as science, but we're going to take that plunge again this year.

We have also used PID loops in the past (and will again this year) to automatically aim our game piece manipulators. For Rebound Rumble, Ultimate Ascent and Aerial Assist, this meant driving the robot so that we were properly positioned to score when we threw the game piece. For Recycle Rush, our goal is to align on the totes (and RCs) so consistently that they form a neat, stable, stack. For these applications the sensor has been, or at least included, a camera. The desired "output" in this case is the size and location of a vision target as reported by some openCV scripts.

That makes a lot of sense. Ether also sent me a very helpful video by Brad Miller on the purposes and applications of PID loops. Thanks for the helpful explanation.

Would it make sense to setup your Drive Train subsystem itself as a PIDSubsystem using encoders?

[notmattlythgoe]

Originally Posted by Ozuru

That makes a lot of sense. Ether also sent me a very helpful video by Brad Miller on the purposes and applications of PID loops. Thanks for the helpful explanation.

Would it make sense to setup your Drive Train subsystem itself as a PIDSubsystem using encoders?

You could do that. Or you could use a PIDCommand instead. Our team prefers using PIDCommands over PIDSubsystems. But I know others prefer it the other way around.

We like to keep our subsystems as simple as possible and do the bulk of our work in the commands. This is one of the reasons we prefer the command route.

[Ozuru]

Originally Posted by notmattlythgoe

You could do that. Or you could use a PIDCommand instead. Our team prefers using PIDCommands over PIDSubsystems. But I know others prefer it the other way around.

This is my first year using Command Based and I haven't used PID-anything yet. I'm going to have to look into them -- what makes you prefer PIDCommands over PIDSubsystems?

[notmattlythgoe]

Originally Posted by Ozuru

This is my first year using Command Based and I haven't used PID-anything yet. I'm going to have to look into them -- what makes you prefer PIDCommands over PIDSubsystems?

I edited my response to include some of our reasoning. We also like that PIDCommands will stop any PIDControllers when they are finished. With a PIDSubsystem you have to manage this yourself. Here is our code so far this season, feel free to look around and let me know if you have any questions.

One class you can take a look at is our DriveAtSpeed class.

[GeeTwo]

Originally Posted by Ozuru

Would it make sense to setup your Drive Train subsystem itself as a PIDSubsystem using encoders?

If you're interested in controlling speed, yes. If you're going to use it to drive a precise distance and stay at that location, no. This is because as you approach the desired condition (stationary), you aren't getting feedback. And no, I would not consider "drive into the AutoZone" as requiring a precise distance measurement for this purpose.

[cstelter]

Originally Posted by Ozuru

Would it make sense to setup your Drive Train subsystem itself as a PIDSubsystem using encoders?

We set up a PIDSubsystem that had a constructor to accept a SpeedController and an encoder. We also then gave this PIDSubsystem the SpeedController interface via the implements keyword.

Something like

public class NordicSpeedController extends PIDSubsystem implements SpeedController {
   SpeedController m_motor;
   Encoder m_encoder;

   public NordicSpeedController(SpeedController motor, Encoder encoder) {
       super(1.0,0,0);  // pass PID to PIDSubsystem construtor
   }

   public void usePIDOutput(double output)  {
         motor.set(output)
   }
   
   public double returnPIDInput() {
       //Be sure encoder setDistancePerPulse() is set such that this returns
       //values between -1.0 and +1.0 over the full range of speed you can go
       return encoder.getRate();
   }

   //Next functions implment SpeedController Interface
   public void set(double speed) {
       enable();
       setSetpoint(speed)
   }

   public void set(double speed, int syncGroup) {
       //We don't need syncGroup so simplify implmenetation
       set(speed)
   }

   //Not entirely sure this shouldn't return getPIDController.getSetpoint()
   public double get() {
       return encoder.getRate();
   }
}

With the above class definition, we could create 4 NordicSpeedController objects each with a different Talon and encoder. We can then pass those 4 NordicSpeedControllers to RobotDrive() constructor which requires 4 SpeedControllers and since we implement the SpeedController Interface it is happy to accept our PIDSubsystems as SpeedControllers.

This allows us to call driveTrain.mecanumDrive which in turn calls m_robotDrive.mecanumDrive_Cartesian() and we can request that we drive 0.1 (10 % of full speed). To move the robot, the PID can apply 1.0 power for a few ms and as the wheels start turning our rate increases until the robot can move, then the PID keeps increasing/decreasing motor power to maintain 10% speed. Without PID, 0.1 power would likely not even overcome friction.

You can then create PIDCommands to act on the drive train as a whole for DriveToDistance or RotateToAngle or DriveAlongAngle and it will call tankDrive or mecanumDrive in the usePIDOutput() function and read the distance off an appropriate encoder or the angle off the gyro to make adjustments to the rotation or forward speed.