Jaguars and FAST PID Looptimes

[Joe Johnson]

First off, I am back. This time I'm working with Overclocked, #246.

Second, you'll all be shocked SHOCKED our Fall Practice Project* is a swerve drive chassis**

Third, since we want to this chassis to go the direction we want it to go and we don't want to be waiting around for the steering error to settle down to an acceptable level, we are going to put as much power as we dare into the steering angle drive . Bottom line, we are using a Banebot RS775-18 on each wheel (and there are 4 of course, 4 wheel independent steer swerve -- how could we do less?). So... we get the torque we need and still have the speed we want.

BUT... speed has a dark side. Speed is hard to control, especially at 50hz update rates typically used in FIRST control loops (I want to have 90 degree step change in steering angle in under 60ms -- probably too fast to have a 20ms loop time). I hear good things about the not yet available Talon SRX (coming soon to a FIRST Legal robot near you) but hearing good things doesn't help me today if it isn't available. So, we are left with Jaguars.

Now comes my question:
Has anyone had good luck using the Jaguar's in their PID mode with high speed actuators and very fast loop times? If so, please let me know in the comments below. I want to know the good the bad and the ugly.

Also, Jaguars are also unavailable for sale these days. Anyone willing to sell (or loan) me 4? If so, PM me with details.


Stay tuned for more results and videos as the project progresses.

Joe J.


*Yes, Fall Practice Projects are a thing. If your team is not doing one or more of them, you should be.

**Super Thanks go to Anthony Lapp and his company, Team221 Robotics, for helping us out with Wild Swerves. Literally wouldn't have been able to do this practice project without building off a solid swerve design.

[billbo911]

Originally Posted by Joe Johnson

First off, I am back......

First off, Welcome back!
It is good to hears from you again. In fact, I was literally just thinking about you this morning while considering a simple transmission design.

I'm looking forward to what you find in your search for the ability to do a 90 deg step change in under 60ms. This should be FUN!!

[AustinSchuh]

Originally Posted by Joe Johnson

BUT... speed has a dark side. Speed is hard to control, especially at 50hz update rates typically used in FIRST control loops (I want to have 90 degree step change in steering angle in under 60ms -- probably too fast to have a 20ms loop time).

20 ms is the old Victor update rate. You can hit 5 ms (might need to tweak the WPILib constants, can't remember, but the hardware can do it) with the Talon SR. That gives you 12 cycles to settle, which might be enough.

How did you come up with 90 degrees in 60 ms?

[Chadfrom308]

I remember seeing something that said although the jags can do PIDs, they are hard to implement.

[Joe Johnson]

Originally Posted by AustinSchuh

20 ms is the old Victor update rate. You can hit 5 ms (might need to tweak the WPILib constants, can't remember, but the hardware can do it) with the Talon SR. That gives you 12 cycles to settle, which might be enough.

How did you come up with 90 degrees in 60 ms?

I've had mixed results with deducing the update times with WPILib. I am going to have 4 loops running at all times this isn't a burst mode. I remember some very odd behavior showing up in other, unrelated bits of the code. I think it was something related to the threading that WPILib was doing in the background.

Kinda creeped me out frankly.

I know that the Jaguar comes with it's own baggage but at least it lets me find out if an updated loop time allows for sufficient control. I may try a half measure where for this project (not FIRST legal obviously) where I put a coprocessor between the CRio and a Talon that is doing the PID loop itself. Kind of a Kludge but answers the question of "can a Talon SRX do this?"

As to the oddly specific spec of 90 degrees in 60ms, it falls out of a calculation for path following at the various speeds of interest. But in actual fact, it is somewhat arbitrary (faster is better could have been the spec), but part of the point if a Fall Practice Project is to discover the edges of what is possible. The easiest thing in the world is to slow the steering rate down. And I may have to go there, but i am not starting there.

Joe J.

[Alan Anderson]

Originally Posted by Chadfrom308

I remember seeing something that said although the jags can do PIDs, they are hard to implement.

Position PID on a Jaguar is not hard to get working well. That's what would be needed for swerve steering.

On the other hand, velocity PID on a Jaguar is much harder to do. Fortunately, once you understand why it doesn't work the way it "should", tuning it becomes a lot less frustrating.

[Joe Ross]

Here's a summary of update rates

Servo: 50hz
Victor and Talon: 100hz (changeable with SetPeriodMultiplier)
Jaguar PWM: 200hz
Jaguar PID: 1000hz, but you can't read status or set setpoints anywhere close to that fast
Driver Station: 50hz
Java iterative methods: synced to driver station
C++ iterative methods: synced to driver station by default, changeable with SetPeriod
WPILib PIDController: 50hz, changeable by changing period parameter in constructor

[JDNovak]

Good to see you coming back to your roots with swerve.

The issue with all this is available energy and where it gets absorbed.

We used window motors for steering for years until the rules limited them to 2.
Then we decided on AM9015 motors because the range of BaneBot motors is more versatile. It became quickly obvious that four 85 amp motors and four 120 amp motors all turning on at the same time was more than the battery could supply as the voltage at the terminals of a fully charged Enercel fell to 8 volts. We monitor battery resistance and cycle test and haven't found another brand that is better yet. Some are worse. Most battery specs list max current draw at 20 or 50 amps. We know that isn't possible. We also shorten the 6 gauge wire as much as possible and use 10 gauge to larger motors. This actually makes the problem more acute.

This year we are limiting the AM9015s to 75% output but if driving aggressively, the two 775s driving the catapult don't get enough energy to fire. They draw close to 40 amps to start. We used Talons for the drive motors and Jaguars for the rest so we couldn't deduce all power consumed. Next year should be easier as the PDP will allow monitoring of all current sources. The robot will just make it through a 2 minute match with normal driving and defense before the battery charge is reduced to the point that it affects operation. That reads about 80% charge on a Battery Beak after a match. More aggressive steering with defense or a less than absolutely fully charged battery hinders performance by the end of the match.

Bottom line is you can choose to steer fast or accelerate fast but not both at the same time. Whatever is left has to operate also. If the Catapult delays firing for a second the shot is usually missed.

I'm looking into improving steering efficiency and reducing motor size but until then power management is the only option. This never seemed to be a problem before the larger steering motors arrived.

[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.

[Richard Wallace]

Originally Posted by JDNovak

... The issue with all this is available energy and where it gets absorbed.
... Bottom line is you can choose to steer fast or accelerate fast but not both at the same time.
... I'm looking into improving steering efficiency and reducing motor size but until then power management is the only option. This never seemed to be a problem before the larger steering motors arrived.

Dr. Joe and John, too? Wow, there is a lot of horsepower in this thread!

How much acceleration is needed for swerve steering? Is Dr. Joe correct about 90 deg in 60 ms? What trajectory, maybe some kind of spline to reduce or eliminate jerks?

How important is swerve module moment of inertia about the steering axis? How important is scrub? Will overhung motor mass and fat treads be significant factors?

(Is Ether reading this?)

John, what do you think are the window motor attributes that kept this from being a problem in the past? Can a motor engineer help with this?

[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

[JDNovak]

Originally Posted by Richard Wallace

How important is scrub? Will overhung motor mass and fat treads be significant factors?

what do you think are the window motor attributes that kept this from being a problem in the past? Can a motor engineer help with this?

My previous post was a little from the hip so I used some numbers loosely. My intent was to point out that trying to start moving a load with higher powered motors takes a lot of energy. The Denso window motors are rated at 23 watts and the AM9015 is rated 179 watts. The latter is rated at 69 amps stall current. I haven't tried metering them individually but steering is a significant hit on the battery. We use wedge-top tread and 1" wide wheels because they seemed to cause less turning force on carpet. Those things were more important with the limited torque of the window motors. We are getting the performance we want out of the current steering motors but the energy hit on the battery was a surprise. I didn't mention that the drive train is geared about 9:1 which is around 12 fps actual top speed. It takes quite a bit of energy to accelerate a 145 lb to that speed. The battery just isn't an infinite supply.

One thing I blew over was whether the strategy is to turn to the intended direction before driving the wheels. Our main driving mode relies on constantly correcting the direction which means running all motors at once.

[Ether]

Originally Posted by Richard Wallace

(Is Ether reading this?)

I am lurking <smile>.

The 90deg/60ms discussion reminds me of a sentence in the last two paragraphs in the swerve inverse kinematics paper¹ I posted in March 2011.

The 4 wheel speed and wheel angle pairs are now suitable for sending to a control algorithm which will decide how to actuate the steering and drive motors to achieve those speeds and angles for each wheel...

This is a separate and interesting problem, which may involve, for example, logic to reverse the wheel speed instead of steering the wheel 180 degrees (and similarly for other steering/speed commands). This control logic is highly dependent on the limitations of the vehicle design, such as the response of the steering motor...

Does anyone have data showing how wheel speed and driving torque affects steering response?

¹ 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.

[Joe Johnson]

ChiefDelphi never disappoints.

Thanks to all for the great input.

As to John Novak's comments, you've definitely given me a lot to think about. When the Bomb Squad speaks about swerve, you'd have to be a fool not to listen.

I am curious about a window motor working better than a higher power motor. It's not obvious why you couldn't gear the higher power motor down to the point that it was pulling less power than the window motor (which is purposefully designed to be inefficient so that it will not backdrive and let your windows fall as you drive).

In any case, I will take your advice to keep an eye on overall current draws, especially when shooting mechanisms that are current sensitive are involved.

I have a question about the speeds you discuss. You say you have a 9:1 ratio and I think you guys are a 4" wheel shop these days (which roughly checks with your 12 fps top speed). You happy with that? Do you guys wish you had a bit more metal in the pedal when zipping back and forth across the field? Do tell.

As to Joe Ross, do the Jaguar's really have 1ms update periods when in PID mode? I don't need to read the sensor anywhere near that fast so that doesn't both me but I would like the faster loop time. (Yes, I know Jaguars have other baggage - but remember this is a Fall Practice Project -- I can afford to take risks now that I would be very hesitant to take come January).

Finally, a question for Ether, but of course, all are welcome to comment. Given a 4 wheel independent steer swerve, with the 12fps top speed our good friends from Mountain Home report, what is the minimum steering angle speed you'd recommend before the vehicle kinematics would be compromised?

Joe J.

[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.