Jaguar Speed & Position Control with Encoders

Jared,

By “adapter”, do you mean something like 2CAN? Isn’t the CAN system intended to be done directly from the cRIO? My understanding is that using a device like 2CAN improves CAN speed and has some improved functionality, right?

Thanks for the imput

Hi nuttle,

Thanks so much for the thorough response and links. The “picture that is emerging” seems to be that CAN architecture with the Jaguar is finicky but powerful if devilish details are worked out.

Yeah, this is a good way to put it. You can get things working without too much trouble, but if you don’t leave enough time to test everything very well, you run some risk of having something go wrong at an inopportune time. Could be a transient glitch you barely notice or could be worse…

I’ve personally had pretty good results, but things like the position control with an index not working (a couple of years back but maybe still not fixed?) are limiting and cost and reliability made it so that it was really only worth the trouble if you could gain an advantage by using the CAN function. It is nice to be able to read the current and even temp, but few teams do anything with this, so closed-loop PID control seems to be the main feature that gets used. It is also nice to have another way to interface encoders, particularly since the cRIO is only set up to handle a limited number of these.

There’s a lot more that could be done with this type of architecture. I put some thoughts on this in this post: <http://www.chiefdelphi.com/forums/showpost.php?p=1279562&postcount=74>.

Isn’t position and speed control what the analog interface is for? just hook up something like a pot or a limit switch (or even a hall-effect sensor if you are sly like that) to control speed, etc.!

Actually, a pot or a limit switch will be rather useless for controlling speed. Pots are good for position, maybe you can get speed but only for a short time. Limit switches are good for telling you that you need to stop right before your code ignores that and manages to destroy them! (OK, I’m mostly joking–you have to mount them so that they don’t get destroyed if the thing that’s moving hits the hard stops. Past experience.)

For speed, encoders are the way to go, generally speaking, and seeing as the Jags have the capability to handle them and run PID, that can be a lot more useful than just using the analog interface.

Yeah, but the point Jared was making was that the pulse width coming from the sidecar is about 20 ms, so you still can’t get better than about 50 hz.

Also, I’m having a really hard time thinking of an FRC application where you need to update 1000 times per second over 100 or 200. It seems to me that in a single millisecond, a negligible amount of change can be done to the speed of a motor, and that some sensors won’t show a change over 1/1000 of a second.

Has anybody really seen a benefit from really fast PID loops?

The pulse width is not 20ms. The period is 20ms. The pulse width varies from roughly 1ms (full reverse) to 1.5ms (zero command) to 2ms (full forward.

You can change the PWM period coming from the sidecar, so you can send commands at a higher frequency.

The PWM pulse repeat rate can be as high as 200hz. By default, it is 200hz for Jaguars, 100hz for Victors and Talons, and 50hz for Servos.

I was unaware that this works. A while back (2009 or 2010) I looked at the signal with a scope, the pulse width was somewhere between 1-2.5 ms, and the delay in between was 20 ms, no matter what speed controller was selected (in LabVIEW).

Hi yash,

My son and I have implemented speed control on a FTC design using Matrixmotors (~120 rpm, planetary 27:1, hall effect encoder 757 lines) controlled by LEGO NXT. You can see our progress here: Modular Drive System

Our prototype works well as follows:

  • The pain for getting the motor controllers configured was relatively small (~ 8 hrs).
  • PID control of encoder speed tracked well with little control oscillations
  • The mecanum omni directional control scheme went together smoothly
  • The prototype controlled smoothly from the game controllers
  • Power was good
  • The bot tracked straight with a small amont of drift to the left

We’re planning to make a video tomorrow to show the driving performance. We were delighted scooting around the kitchen, pushing around chairs. Sending the desired speed to the motor controller and letting it do the “local maintenance” is a solid architecture.

My son and I made these movies (link to post below) to show Mecanum with speed control. This is the FTC teams prototype; not FRC. This is the design from which we’re scaling up.

FWIW, CAN Starter Pack is worth checking out, for teams that plan to use CAN.

Hi nuttle,

Thanks for the link. For $25, it’d save some time making cables.

We have had a very positive experience using the closed loop PID in the Jaguar with Speed Control. Less than .25 seconds to reach proper speed from 0, even shorter times when returning to speed after a shot.

It doesn’t require the CRIO PID to process it which free resources that can be used for other things.

Note to rookies:

Fast spinup and recovery times are strongly influenced by mechanical design: operating speed, motor(s) selection, gear ratios, wheel diameter, and moment of inertia of the load (including wheel and flyweight). With a proper mechanical design, you should be able to get fast spinup and recovery times with other controllers as well.