[DFTF] Closing the loop on Wheel Velocity...

[Hugh Meyer]

Originally Posted by Joe Johnson

Has anyone used a Jaguar to close the velocity loop? The standard PID modes do not support this which is a shame (you can input an encoder but the PID loop is then based on position of the encoders not speed).

Joe,

I am confused with your comment here. It does support this; they just call it "Speed Control Mode" See page 12 in the attached manual.

Am I missing something?

-Hugh

[Joe Johnson]

Originally Posted by Hugh Meyer

Joe,

I am confused with your comment here. It does support this; they just call it "Speed Control Mode" See page 12 in the attached manual.

Am I missing something?

-Hugh

No, I guess I have been missing something. I have looked at a lot of Jaguar docs but missed that one.

Looks good.

Has anyone used two (or more) Jaguars driving 1 wheel (or more specifically set of wheels on one side of the robot), with one wheel encoder feeding multiple Jaguars... ...IN VELOCITY CONTROL MODE (phew! that's a mouth full)?

If so, did it work well? Also did you use an I term in the PID loop (i.e. a I gain != 0)?

Finally, digging even MORE into the details, "Speed Ref <val>" command takes an unsigned 8 bit number for <val>. How do you set negative velocities ? Oh... never mind, I see that this is used to tell the Jaguar what is the speed sensor (only the encoder is supported but I guess they are imagining a day when others may be)

Joe J.

[Ether]

Originally Posted by Hugh Meyer

Joe,

I am confused with your comment here. It does support this; they just call it "Speed Control Mode" See page 12 in the attached manual.

Am I missing something?

-Hugh

I think what Joe was saying is that the encoder is inherently a position transducer and the Jag would have to differentiate the signal to get rate... and at low speeds the signal from the encoder is not changing at 1000Hz so you can't get a 1000Hz rate signal from it.

[edit] I guess I was reading between the lines too much [/edit]

[Joe Johnson]

Originally Posted by Ether

I think what Joe was saying is that the encoder is inherently a position transducer and the Jag would have to differentiate the signal to get rate... and at low speeds the signal from the encoder is not changing at 1000Hz so you can't get a 1000Hz rate signal from it.

[edit] I guess I was reading between the lines too much [/edit]

There is that problem as well. But No, I had totally missed the velocity feedback mode.

As to counts frequency, at 256 counts per output of say a CIMpleBox and a 3:1 to an 8" wheel (1ft per rev) youll get 32 counts per inch (256*3/24). At this resolution you fall below 1000hz update at roughly 2.5fps. BUT... the code may use edges instead of periods to estimate speed (4X) if it does then we'd be pretty close the range where we cover all useful FIRST robot speeds (.6 fps seems slow enough for me)

Even without this, a slower update rate may be fine as long as we don't go crazy with the D gain.

We'll have to try it and see.

Joe J.

[Ether]

Or you could gear up the encoder a bit I suppose so it is spinning faster. Kind of kludgy but it might work since the encoder is virtually no load. Have to be careful not to exceed signal processing capability of Jag.

[theprgramerdude]

Originally Posted by Ether

Or you could gear up the encoder a bit I suppose so it is spinning faster. Kind of kludgy but it might work since the encoder is virtually no load. Have to be careful not to exceed signal processing capability of Jag.

It has a 50 MHz Cortex M-3. Unless the PID algorithm onboard is rather complex and heavy on the cycles, how could anything from a digital encoder approach the Jag's limits?

[EricVanWyk]

Originally Posted by theprgramerdude

It has a 50 MHz Cortex M-3. Unless the PID algorithm onboard is rather complex and heavy on the cycles, how could anything from a digital encoder approach the Jag's limits?

The Stellaris microcontroller does quadrature decoding in dedicated hardware, so there is no additional processing burden for running the encoders faster. The upper limit of that circuitry is 1/4th the speed of the processor. For a part running at 50MHz*, that is roughly 750,000 RPM for a 250 count encoder. However, I doubt you'd get clean signals from the poor encoder at those speeds!

The Stellaris has more computational horsepower available than the entire IFI control system put together several times over. It is an amazing show of what Moore's law does to the industry.

* Edit: I can't remember what speed they actually run on the Jag - there simply is no need to run at the full 50 or 80 MHz. Suffice it to say that it is still overkill.

[Joe Johnson]

Originally Posted by EricVanWyk

The Stellaris microcontroller does quadrature decoding in dedicated hardware, so there is no additional processing burden for running the encoders faster. The upper limit of that circuitry is 1/4th the speed of the processor. <snip>

Do you know if the processor "does the right thing" in terms of speed calculations, by which I mean, does it get 4 readings per nominal encoder tick (rising edge channel A, rising edge channel B, falling edge channel A, falling edge channel B) AND create the time as rising edge to (the same) rising edge and falling edge to (again, the same) falling edge?

The reason I say this is that the encoder folks do a much better job at spacing their ticks than they do at getting exactly 50-50 ON-OFF duty cycles and spacing the phasing between the sensors A and B (remember their is only 1 encoder wheel, the 90 degree shift in the signal between the two phases is done by physically spacing the encoders N+/-(1/4) encoder pulses apart.

The reason I ask is that I want to get 4X the speed readings doing it this way provides over just a single speed reading per encoder tick which is the most obvious way to do things (see the above discussion about keeping high PID loop times at slow speeds -- without 1,000Hz sensor reading, it makes little sense to have a 1,000Hz update rate on the PID loop).

Joe J.

[lemiant]

I'm not particularily up on the benefits of good quality control loops as our code on my old team looked something like this:

x = Joystick.x/JOYMAX
y = Joystick.y/JOYMAX

leftMotor.Set((y+x)*100)
rightMotor.Set((y-x)*100)

The first version was written in 10 minutes by 1114's Programming mentor . But I digress.... What I wanted to make sure gets said in here is that as much as stellar control has the potential to help, a lot of the issues you are referencing are pretty blown out of proportion. e.x. A simple 6-wheel drive with reasonable weight balance will drive straight all on its own. Just wanted to make sure we remember that.

- Alex