Jaguars and FAST PID Looptimes

[Gdeaver]

What is the rational for very fast steering response and why is there a need to expend allot of power to accomplish this?
This is a link to a page showing what we have done with swerve.

http://wiki.team1640.com/index.php?title=Swerve_Central

We use a RS540 and banes bot 1 : 133 trans. Plenty for power and speed. Other designs and drive wheels may need more power but this solution has worked well for us.
I would caution on the use of Jags for positional control. We burned up several on the steering motors. We have used Victors and Talons for the steering motors with out failures.
For auto navigation, Tight PID tuning, well calibrated and accurate steering angle sensor and a good stable gyro - IMU are needed. Swerve does not like to go straight.
For teleop, a looser PID can actually be better. This is especially true if the driver is the button smasher gamer type. Next year we are planning on a very tight PID values for Auto and looser PID values for teleop. This year we tuned it to a value between the 2 ideal settings.
For 2015 we are looking forward to the power distribution boards ability to log current draw of all motors. The excel spread sheet and code TOM LINE posted looks very promising for swerve power analysis under battle field conditions. We don't know what our swerve consumes on the field and we should know this.
So again I ask why is there a need to bash the steering for very fast and precise angle?

[Ether]

Originally Posted by Gdeaver

So again I ask why is there a need to bash the steering for very fast and precise angle?

I think the question here is how fast is "fast enough" to accomplish the desired tasks.

The answer depends on what you want to accomplish with the swerve. Rapid evasive maneuvers require faster response than a gently sweeping curve.

The steering doesn't have to be perfect or instantaneous. But if the steering is way too slow or inaccurate, the vehicle will not behave as desired.

Your team seems to have found an acceptable compromise. Can you link to some videos showing rapid evasive maneuvers?

[RyanShoff]

Originally Posted by Ether

Calling all teams who have deployed successful "Unicorn" swerves with 3DoF driver interface: please share your experience/data concerning steering dynamic response.

Bag motor 90:1 to wheel through versaplanetary.

This loop was minimally tuned to stop any shaking. We didn't spend a lot of time optimizing it. Response of wheels turning 90 degrees wasn't timed. I would guess around 250ms. As tuned, it visibly overshoots a little and comes back on a full speed 90 degree move.

This was all copied from Bombsquad. Looking back on their original code (2013), it looks like we took D from 0 to .2 and increased the STEERPOW from .75 to 1. I don't know what motor or reduction they used.

Next year we'll be looking to decrease the loop period and the tolerance if we do a swerve again. The speed and response was just fine but it could have driven straighter.

PID loops setup like this:

#define CONTINUOUS true
#define P 1.0
#define I 0.0
#define D 0.2
#define F 0.0
#define POTMIN 0.2
#define POTMAX 4.8
#define STEERPOW  1.0
#define TOLERANCE 0.2
#define PERIOD .02
#define RATIO 1

driveTrainFrontLeftDrive = new Talon(1, FLD);
driveTrainFrontLeftPos = new AnalogChannelVolt(1, FLP, true, RATIO);
driveTrainFrontLeftSteer = new Talon(1, FLS);
driveTrainFrontLeft = new PIDController(P, I, D, F,  driveTrainFrontLeftPos,
driveTrainFrontLeftSteer, PERIOD);
driveTrainFrontLeft->SetContinuous(CONTINUOUS); 
driveTrainFrontLeft->SetAbsoluteTolerance(TOLERANCE); 
driveTrainFrontLeft->SetInputRange(POTMIN, POTMAX);
driveTrainFrontLeft->SetOutputRange(-STEERPOW, STEERPOW);

[Ether]

Originally Posted by RyanShoff

The speed and response was just fine but it could have driven straighter.

Thanks Ryan.

When you commanded rapid evasive maneuvers, did it consistently behave as expected¹? Do you have some videos?


¹ i.e. "as expected" according to kinematic calculations.

[RyanShoff]

http://www.thebluealliance.com/match/2014wimi_qf3m1
This is high def match video from Wisconsin. It ended up 3 vs 1 so we have lots of room to drive around at the end.

[Joe Johnson]

Originally Posted by Ether

FWIW, I recently wrote an integer-math implementation of swerve reverse kinematics for Anthony Lapp for a project he was working on to run swerve on ATmega2560. He has a video posted here

Ether,

Nice try making the font small so we'd not follow the link. But I'm on to your tricks ;-)

Very cool chassis. Can you provide details on the ratios and motors involved on that swerve or do I have to go pester Anthony? It seems like there is a point in the video where one of the steering angles is close to 90 degrees in 100ms. I could be wrong because I am just eyeballing it but even so, that's some pretty zippy steering.

My kind of swerve if you know what I mean...

Joe J.

[Ether]

Originally Posted by Joe Johnson

Can you provide details on the ratios and motors involved on that swerve or do I have to go pester Anthony?

Hi Joe,

I'd like to help but you'll have to ask Anthony for those details. He contacted me because he needed help implementing integer math. He had coded the swerve inverse kinematics in floating point, and the floating-point emulation library was chewing up all the processing power on the ATmega2560. I sent him an integer-math implementation scaled for his inputs and outputs.

[Mr. Lim]

We used the on-board Jaguar PID for position control for our shooter turret in 2012.

Don't know if that qualifies as "similar" to your swerve application, but I do have a working knowledge of the pitfalls of the Jag's PID (both position and velocity).

The bottom line is that we did get it working, although it wasn't pretty, and there was still a lot left to be desired. While we were able to get the turret to go to a commanded position effectively, I wouldn't say we had it "perfectly tuned," nor did our system have a lot of dynamic forces on it. The turret was pretty free-spinning, and remained that way throughout.

It was powered by a single RS550 through a planetary. I don't think we were close to hitting your 90 degrees in 60ms spec though. There is a 10-turn pot that you can see in the picture as well.

Here's a pic of the setup:


Here is our competition code for the turret on Google Code:
https://code.google.com/p/robotics61...ms/Turret.java

You can navigate through the source path section to find the PID constants we used as well.

Good luck!

If you have any other questions, post here, and I'll try and find time to share what I can.

[NotInControl]

I believe the microcontroller on the jag runs at a rate of 50MHz and the encoder is read at 1/4 of that rate. Not clear on how fast the control loop on the jag is running, but I think it is safe to say it is orders of magnitude higher than the software loop.

However you can only command it and read from it as fast as CAN packets are being sent/received.

In your requirement for 90 degrees in 60ms. How much of that is actuation time, and how much of that is settling time?

If you want to be at 90 degrees confirmed in 60ms, then you need the mechanical system (wheel/gear) and anything else that is tied to the motor load including friction between wheel and floor to accelerate and decelerate in that amount of time.

If your target is 60ms, then you should target an actuation time of 40ms, and a settling time of 20ms. Can your mechanical system move that quickly? That is pretty fast by any FRC standard.

If you also plan to run 4 independent loops, they each will settle differently because each motor will react differently. As your speed requirement increases, your engineering tolerances reduce, naturally. You will need very tight tolerances on the manufacture of the assembly, sensor mount, and backlash in order to have reasonable reaction time across all pods. Also take the time to test the motors you are using to ensure their drive characteristics are very similar to each other.

We typically run our control loops at 100ms and give our actuators a settling time of around 100-150ms on top of that because that is a very safe margin, and very achievable with the manufacturing tolerances on our team.

Although we have not done motion planning on FRC(yet) and all of our control loops run in software.

For the motion planning model on my work outside of FRC, a 100ms control loop was more than efficient to follow a waypoint path on a skid steer chassis. Not sure how that equates to the dynamics of a swerve, but I would hope they are somewhat comparable.

Plus, the baggage of CAN error implementation, preventing CANTimeOutErrors and all that other good stuff will need to be user implemented as part of the CAN baggage.

Regards,
Kevin