Jaguar Speed & Position Control with Encoders

[DavisDad]

Originally Posted by Joe Ross

This thread shows the required calls for setting up a CAN Jaguar in position mode. http://www.chiefdelphi.com/forums/sh...d.php?t=102909 You also need to using the imaging tool to set the appropriate CAN Jaguar plugin (Serial or 2CAN).

Hi Joe,

Thanks for the link and info in previous post. I work with industrial control systems (not programming) and I like distributed control over a network. My bias from work makes me lean toward using the Jaguar's controller for the feedback control and send setting over the BUS.

I really appreciate the real-world experience with the FRC electronics.

[nuttle]

I spent a fair amount of time using CAN and the Jags and this architecture has a lot of potential -- in my opinion, the problems were all in the implementation and the current Jags seem to have addressed the most severe problems. I also designed and built my own smart motor controllers that used different silicon and was very happy with how these turned out. I'm really looking forward to seeing a second-generation motor controller with these capabilities generally available -- and therefore legal for competition use.

I'd second the points about watching the serial bandwidth if you go this way and about using the 2CAN to open up this potential bottleneck. There at least used to be a source (eStop robotics, IIRC) for pre-made serial-to-CAN converters and terminators, as well as cables. Some teams have trouble with these, particularly the terminators. You'll need a serial converter for using BDC-COMM with a PC anyway. And BTW, making sure things work under BDC-COMM is a good first step and troubleshooting tool.

I've also seen people tripped up because the encoder connector on the Jag has a different pinout than the standard one used by US Digital, so pre-made cables at least need to be modified. Also, the space around the pins is very tight and so you have to have the right connector for this.


I sent this for a fix to the problem where the index signal messes up position control, AFAIK, it never made it into official firmware, but I haven't tried to use this in the past couple of seasons (this refers to a source file for the Jag firmware):


Note that this is in the ControllerPositionMode() function in controller.c.

Briefly, the problem was that when using PID position-based control with an indexed encoder, things don't go well when the index is hit and the position count wraps.




static void
ControllerPositionMode(void)
{
long lTemp;
//
// Get the motor position.
//
[...]
//
// Compute the error between the target position and the motor position.
//
lTemp = g_lPositionTarget - lTemp;
[
The preceding line is deriving the position error, but neglects that there are really two errors and this code need to evaluate both of these and pick the smaller of the two. The second error crosses through zero and when this is the smaller of the two, the existing code does not do the right thing.

This shows up especially when using an indexed encoder where the count gets set to zero when the index is encountered. Note that if using a pot, you really don't want to move through zero, so the logic change only applies when dealing with an encoder!

One possible fix is to leave the preceding line as-is, but add this code:

// When using an encoder, handle the case where the most direct way to reach the
// desired position crosses through zero. If the encoder lines global has not been set,
// this will be zero, meaning the count wraps at QEI_MAXPOS_M. If the position
// error is more than halfway through a full revolution, going through zero is the shorter
// distance. If the error is exactly half-way around, it would make sense to keep going
// in the current direction, but PID behavior should adequately cover this case.
// This code should really be gone over to be sure there are no issues mixing signed and
// unsigned 32-bit integers. Also, it might make sense to use QEI_MAXPOS_M in the
// case where the encoder lines global has not been set (but this is more a usage problem).

if (HWREGBITW(&g_ulFlags, FLAG_POS_SRC_ENCODER) == 1 && g_ulEncoderLines != 0)
{
if (lTemp > g_ulEncoderLines / 2)
{
lTemp = lTemp - g_ulEncoderLines;
}
else if (lTemp < -(g_ulEncoderLines / 2))
{
lTemp = lTemp + g_ulEncoderLines;
}
}
]
//
// Run the PID controller, with the output being the output voltage that
// should be driven to the motor.
//
[...]

[nuttle]

Another thing that can trip people up is if the controller resets for any reason (power brown-out, bug?, bandwidth saturates on serial link and something bad happens?). Or maybe the cRIO resets but the Jaguar does not, or maybe something bad happens around losing the safety heartbeat, ...

Anyway, there is a possibility that the configuration parameters will all be lost and things will revert to the defaults. You want to have some sort of error handler in the cRIO code and probably also to periodically read at least something from the Jag to be sure things seem good.

There are some old threads on this topic and also that go into more detail on some of the issues in my prior post.

[DavisDad]

Originally Posted by Joe Ross

...One option would be to invest in the 2CAN. Another option would be to limit the amount of CAN traffic. Setting a setpoint every few seconds isn't a problem. Changing setpoints at 50hz to multiple jaguars and requesting lots of status can be a problem.

Hi Joe,

I've read about the 2CAN but the price scared me away. I'll put that on my list to investigate.

Thanks!

[DavisDad]

Originally Posted by Ether

The point Joe was making is that the built-in PID in the Jag's firmware closes the loop at 1000 Hz. You can't do that with cRIO. You can't do that with Victor or Talon.



Victors will accept 200 Hz input PWM frequency.




Other systems might.

Hi Ether,

First- I've read many of your posts and want to compliment you on your contributions to the teams. Your to-the-point, thorough, and expert responses are a pleasure to read. Thank you!

I've begun following your links and have a lot of studying to do...

[DavisDad]

Originally Posted by Jared

The PID functionality of the Jaguars does work, but adding CAN can be expensive depending on which adapter you use.

The PID on the cRIO is just as fast and as powerful as the one on the jaguar, but works with all types of speed controllers and sensors. If you're looking for basic getting started examples, there are plenty for PID on the cRIO.

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

[DavisDad]

Originally Posted by nuttle

Another thing that can trip people up is if the controller resets for any reason (power brown-out, bug?, bandwidth saturates on serial link and something bad happens?). Or maybe the cRIO resets but the Jaguar does not, or maybe something bad happens around losing the safety heartbeat, ...

Anyway, there is a possibility that the configuration parameters will all be lost and things will revert to the defaults. You want to have some sort of error handler in the cRIO code and probably also to periodically read at least something from the Jag to be sure things seem good.

There are some old threads on this topic and also that go into more detail on some of the issues in my prior post.

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.

[nuttle]

Originally Posted by DavisDad

The "picture that is emerging" seems to be that CAN architecture with the Jaguar is finicky bur 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/sh...2&postcount=74>.

[yash101]

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

[EricH]

Originally Posted by yash101

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.

[magnets]

Originally Posted by Ether

Victors will accept 200 Hz input PWM frequency.

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?

[Ether]

Originally Posted by Ether

Victors will accept 200 Hz input PWM frequency

Originally Posted by magnets

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.

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.

[Joe Ross]

Originally Posted by magnets

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.

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.

[magnets]

Originally Posted by Joe Ross

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

[DavisDad]

Originally Posted by yash101

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

Hi yash,

My son and I have implemented speed control on a FTC design using Matrix motors (~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.