Mecanum - use of gyro

[Alan Anderson]

Before you do any more with the software, make absolutely sure your hardware is correct. A "stuttering" turn is sometimes a sign that you have your mecanum wheels mounted in the wrong orientation. The rollers contacting the floor should make an "O" or diamond pattern; they should look like an "X" from above.

Also make sure you understand what the inputs to the LabVIEW PID block mean. I haven't looked at it in over a year, but at that time the I and D parameters were not gains. They were time values. That scheme is just as easy to tune as a gain-based one, as long as you recognize that a smaller I or D value yields a stronger response than a larger value.

[Ether]

Originally Posted by Ether

Tell us a little more about your vehicle. What size and kind of mecanum wheels are you using; how are they mounted (can you post a close-up picture to go along with your words)

With mecanum wheels, the mounting is very important, and is a common source of error:

• each mecanum wheel is either right-handed or left-handed. It is important that the wheels are mounted at the correct locations on the vehicle
  
  
• mounting mecanum wheels at the end of a "stalk" that is not stiff enough can cause control issues

[Tom Line]

Originally Posted by Alan Anderson

Before you do any more with the software, make absolutely sure your hardware is correct. A "stuttering" turn is sometimes a sign that you have your mecanum wheels mounted in the wrong orientation. The rollers contacting the floor should make an "O" or diamond pattern; they should look like an "X" from above.

Also make sure you understand what the inputs to the LabVIEW PID block mean. I haven't looked at it in over a year, but at that time the I and D parameters were not gains. They were time values. That scheme is just as easy to tune as a gain-based one, as long as you recognize that a smaller I or D value yields a stronger response than a larger value.

Oh. My. Gosh.

We've been using labview since FRC started using it, and I never even thought to check it: I just assumed it was a normal non-dimensional gain number that would act the way most PID setups expect it to act.

During this year's game we had a very robust targetting system in real time that would turn the robot and shoot after pushing the fire button. However, we removed it because we could not tune in the I and D portions to get the level of speed required: it was slightly slower than our driver's aiming and therefore wasn't effective.

I feel very, very silly right about now.

[jhersh]

Originally Posted by Ether

Are you saying that jitter would be less than 1ms in a periodic task in a ready-for-competition code release that has several concurrent threads competing for CPU ?

I would expect there to be more than 1ms jitter unless you are using a timed loop for your periodic task. Especially if you are running your controller in teleop. That loop timing is based on the incoming UDP packets from the DS, not a local timer.

Even if you aren't, though, the benefit of the automatic delta time calculation is that your controller will still behave well even in the presence of jitter. It simply measures the jitter and uses the actual time instead of the ideal time when computing the I and D terms.

[Ether]

Originally Posted by jhersh

I would expect there to be more than 1ms jitter unless you are using a timed loop for your periodic task.

So you're saying you'd expect jitter in a periodic task to be less than 1ms (in a full-function competition code release with many concurrent tasks)?

You know more about LabVIEW than I do, but I find that surprising. I would have thought that the way LabVIEW protects critical sections would create more software latency than that.

[Ether]

Originally Posted by jhersh

the benefit of the automatic delta time calculation is that your controller will still behave well even in the presence of jitter. It simply measures the jitter and uses the actual time instead of the ideal time when computing the I and D terms.

Capisco. I just misread the LabVIEW documentation.

Out of curiousity I looked at the PID block diagram to see what numerical integration algorithm it uses. Not being very adept at LabVIEW I couldn't parse it (and it wasn't commented). Is it simple Euler or something more sophisticated ?

[kamocat]

For clarification:

Apparentally you can get resolution finer than 1ms using a 1MHz timing source, but I've never had a time-critical task that executes that quickly.

[Greg McKaskle]

I've attached the context help for the PID. It is described as the simple one, but it includes integrator anti-windup, output limits, and bumpless gain changes. It also supports wiring up N values in an array, and it will manage and control all of them using the same control settings.

As for learning to read LV, that is definitely starting pretty deep in the pool, but I'll point out the big chunks.

In the lower left of the loop, it determines what the dt is. It can be user specified or if unwired, is calculated by the function.

Upper left are some comparisons to determine if the PID coefficients are the same as the previous call (to fix the state data and avoid bumps).

The code in the center and lower right calculate the terms. Note that this uses the academic form with Kc, Ti, and Td. The two icons at the upper left of the switches were used to document which term was being computed.

Other comments are sprinkled inside the cases for the exceptional cases such as reinitialize, dt=0, etc.

Note that I'm describing the PID.vi, the simple one. There are several others in the full Control portion of the palette -- Advanced, Auto-tuning, etc. I didn't write any of these, but may be able to help you read them if that is what you are asking.

Greg McKaskle

[Greg McKaskle]

Concerning the loops and timing jitter, the normal while loop inherits the priority of the VI it is within. Note that by default, subVIs inherit their caller's priority as well. Initially everything in the FRC framework is set to normal priority. If you decide you want to bump something, you change that subVI's priority in its properties/execution page, and it typically propagates as you intend.

The delay used in the while loop that was shown has a resolution of 1 ms, and is not considered low jitter, though it typically performs fine IMO. The low jitter and higher resolution delays and timing functions are located in the real-time palette.

The timed loop incorporates these timing functions into the loop and performs many of the common calculations for you. The timed loop lets you choose between a 1ms, 1us, or device specific clocks which may be available. It lets you choose between a few different timing policies concerning missed periods. It lets you set priority on each loop without needing to embed it in a subVI. It lets you more easily measure actual start times vs scheduled start time, actual and scheduled finish times, whether the loop met or missed the deadline and by how much, etc.

From what I've seen, common FRC tasks are fine with msec resolution and aren't bothered by a few ms of jitter, so the framework starts simple. Meanwhile, if you find that an arm or other mechanism needs it, the real-time mechanisms are there to lower the jitter. Similarly, the framework uses simple globals to share information between loops and subVIs. To gain determinism, you would trade those for RT FIFOs which are more complex, but can offer jitter or performance benefits and offer more control in corner situations.

Greg McKaskle

[mwsmith78]

Lots of posts since my last one ... I will try to knock off all the questions.

Using 6" Mecanum wheels with tapered rollers (from AndyMark). Wheels are correctly mounted. The robot drives correctly w/o PID loop - although it does tend to have rotation error. Given that it works well before attempting closed-loop control, I believe that points to the software.

If I understand correctly about the PID post - the I & D gain values are time constants and for tuning purposes should start HIGH and work down. Meanwhile, the proportion gain should start low and work up. That may explain why we were having trouble tuning. When we inserted I and/or D values, we started very small. If we want it to function as a P-only loop, is setting I and D to zero correct?


http://www.youtube.com/watch?v=KL7iZXCRtPw

[mwsmith78]

Direct-driven using CIMs and Victors.

Have another post pending that will answer other questions. It includes youtube video and requires moderator approval.

[mwsmith78]

Lots of posts since my last one ... I will try to knock off all the questions.

Using 6" Mecanum wheels with tapered rollers (from AndyMark). Wheels are correctly mounted. The robot drives correctly w/o PID loop - although it does tend to have rotation error. Given that it works well before attempting closed-loop control, I believe that points to the software.

If I understand correctly about the PID post - the I & D gain values are time constants and for tuning purposes should start HIGH and work down. Meanwhile, the proportion gain should start low and work up. That may explain why we were having trouble tuning. When we inserted I and/or D values, we started very small. If we want it to function as a P-only loop, is setting I and D to zero correct?

[Ether]

Originally Posted by mwsmith78

The robot drives correctly w/o PID loop - although it does tend to have rotation error.

Could you please clarify what you mean by "rotation error"? Are you saying that when you give a "straight ahead" command, the bot wants to turn?

Or are you saying that when you give a "turn" command, it doesn't respond as you think it should?

(or something else?)

Are you using the built-in vi to compute mecanum wheel speeds, or did you design and code your own algorithm ?

[MartinB]

I can anwser the question about the rotation error. What he means is that the robot drifts when we do not expect it to and that is why we wanted a software solution to the rotation error.

[kamocat]

Originally Posted by mwsmith78

If I understand correctly about the PID post - the I & D gain values are time constants and for tuning purposes should start HIGH and work down. Meanwhile, the proportion gain should start low and work up. That may explain why we were having trouble tuning. When we inserted I and/or D values, we started very small. If we want it to function as a P-only loop, is setting I and D to zero correct?

Yes, you are correct.