PIDController not manipulating jaguars

[Alan Anderson]

That's most of an answer to my first question. If I understand you correctly, you want to control the drivebase motors in order to maintain a fixed position on the field, right?

Let's try for an answer to my other two questions now. What kind of drivebase do you have? Describe the number, type, and placement of wheels, number and type of motors, kind of gearbox, chain vs. belt, etc. Where do you have the encoders mounted? I'd rather give advice based on what you really need rather than assume things about what your robot is like.

Here's another question, now that I think you're talking about the drive motors: Does it matter whether or not the robot gets turned in place?

[vigneshv]

It is a 6 wheel tank drive with the encoders on the gearbox. It just matters if the gears on either the left or right gearbox turn. Thanks!

[Alan Anderson]

I am reluctant to offer suggestions when I can't get a straight answer to yes-or-no questions. I'll ask them again:

1) You want to control the drivebase motors in order to maintain a fixed position on the field, right?

2) Does it matter whether or not the robot gets turned in place?

I'm trying to find out if you care about the orientation of the robot (the direction it's facing) or if you just want to stay over the same patch of field carpet. There are several different ways to do it, and the most appropriate one depends on the details of your requirements.

[vigneshv]

1) Yes
2) Yes, whether the robot is turned in place matters.

[gpetilli]

Originally Posted by vigneshv

It is a 6 wheel tank drive with the encoders on the gearbox. It just matters if the gears on either the left or right gearbox turn. Thanks!

Keep in mind that with tank drive, there is no way to protect against what I will call T-Bone. Your encoders wont move, and you have no torque in the X-direction anyway.

Are you using center drop wheel or are you using Omniwheels? If you are not using drop center wheels, I strongly recommend exactly two omnis (front or back) as a good compromise between turning ability and traction.

If you have left and right velocity PID loops to your gearbox encoders, it should allow the robot to old it's ground since any movement will be an error verses the commanded zero velocity. If the two loops act independently, they should also hold orientation. Any slop in your drive chain will limit your ability to sense movement and cause sensor delays (phase errors) which make the PID much harder to stabilize.

That said, we are finding that for external forces, the accelerometer works well for X and Y. For rotation, we are looking at the gyro.

[Ether]

Originally Posted by gpetilli

If you have left and right velocity PID loops to your gearbox encoders, it should allow the robot to old it's ground since any movement will be an error verses the commanded zero velocity. If the two loops act independently, they should also hold orientation.

I question whether velocity PID based on rate feedback from drivetrain gearbox encoders will allow the bot to re-establish its orientation (or even position) after an impact.

[Joe Ross]

It can be a little tricky to get PID control and manual control of the same motors with the WPILib PID Controller class. I posted a short description of the method we used here: http://www.chiefdelphi.com/forums/sh...d.php?t=114061

[Alan Anderson]

2) Yes, whether the robot is turned in place matters.

Then you probably want to do arcade drive with closed-loop control. The forward/backward "Y" input should be driven based on the average of the two encoder values, and the left/right "Z" input should be driven based on their difference. It *might* work to do tank drive with each side of the robot being controlled independently, but I think it makes sense to think of the position and direction as separate measured values. In that case, you won't be driving the motors directly from the output of the PID computation. You'll be providing simulated joystick input to drive the robot back into place when it gets disturbed.

Will this be happening only while the robot is in autonomous mode, or will there be some way of selecting it to "hold position" during teleoperated mode?

[vigneshv]

It would be for autonomous and a "hold position" control in teleop

[Alan Anderson]

Joe Ross posted a link to a previous discussion of the sort of thing you want to do, along with some information about how to make it work for drive motors.

[gpetilli]

Originally Posted by Ether

I question whether velocity PID based on rate feedback from drivetrain gearbox encoders will allow the bot to re-establish its orientation (or even position) after an impact.

We got our velocity loops working this past Saturday (after finally solving a problem with I2C comm to different sensors in independent timed threads corrupting data). The robot clearly actively resisted any movement. When forcibly kicked two feet out of place, I was surprised but the robot actively returned to the original position and orientation . I have not had time to investigate, but I think the PID is integrating the velocity error correction (any velocity is error with a zero commanded velocity) and then "de-integrating" the error. It may also be the loop is too slow, and just happened to stop correcting the velocity error such that it landed back at the starting location.
For our application, returning was not desired behavior. We plan on adding more D term on Tuesday to see if we can limit the "integrator windup".

That all said, I agree that for the stated problem a position loop would be adequate, easier to implement and probably preferred.

[vigneshv]

Thank you everyone

[ekapalka]

Originally Posted by gpetilli

The robot clearly actively resisted any movement. When forcibly kicked two feet out of place, I was surprised but the robot actively returned to the original position and orientation . I have not had time to investigate, but I think the PID is integrating the velocity error correction (any velocity is error with a zero commanded velocity) and then "de-integrating" the error.

Wow... that sounds amazing. Was this just using the simple WPILib PID classes or was it something else entirely? We've been looking into using closed loop control on our robot this year (we haven't ever in the past) and were thinking a "stay in place" button would be a cool [possibly unnecessary] thing to do for learning purposes (our robot is relatively simple).

[gpetilli]

Originally Posted by ekapalka

Wow... that sounds amazing. Was this just using the simple WPILib PID classes or was it something else entirely? We've been looking into using closed loop control on our robot this year (we haven't ever in the past) and were thinking a "stay in place" button would be a cool [possibly unnecessary] thing to do for learning purposes (our robot is relatively simple).

Yesterday we increased the D term and the robot resisted movement more vehemently and only returned about 1in when kicked 1 foot - which is closer to our desired behavior.

As a point of clarification, we are not using encoders on the gearboxes - we have small, undriven follower omni-wheels with encoders to feedback velocity to the PID on the cRIO. This means that if the driven wheels lose traction while being pushed (or we spin wheels during hard acceleration) the PID still detects and tries to correct the movement. The closed loop PID "set point" is the driver commanded velocity. We do not have a "stay in place" special case, the PID is trying to drive to commanded zero velocity.

The WPI PID could potentially do this, but we implemented custom PID because we are using a holonomic drive (modified Killough) where the four driven omni-wheels are at a 30deg angle and we want the driver commands to be Cartesian. We measure the three degrees of freedom (X, Y, Rotation) and derive the four motor voltages.

[gpetilli]

Originally Posted by Ether

I question whether velocity PID based on rate feedback from drivetrain gearbox encoders will allow the bot to re-establish its orientation (or even position) after an impact.

encoders are on follower omni-wheels so they do detect the translation even if the driven wheels slip.