Mecanum - use of gyro

[Ether]

Originally Posted by EricVanWyk

The second sentence of the documentation you quoted states that it uses a timer to calculate delta t, which sounds like "automatic delta time calculation" to me.

OK I get it now. The internal 1ms resolution timer keeps track of the elapsed time since the PID was last executed, and uses that elapsed time for the computation (derivative & integration) for the current iteration? So the elapsed time used for the computation can (will) be different (due to jitter) from iteration to iteration?

[kamocat]

Yes.

In this case, I would expect it to be accurate within 1 millisecond.

[Ether]

Originally Posted by kamocat

In this case, I would expect it to be accurate within 1 millisecond.

I'm surprised to hear you say that. Please elaborate.

Have you ever measured the realtime jitter in the Teleop loop of the FRC Framework ?

[kamocat]

I have.

I was actually expecting this to be placed in a Periodic tasks, and estimating. I know this code is not likely to take 20ms to execute, and in looking at time-to-execute in loops, it's usually the value wired into the wait function (occasionally plus or minus a millisecond).

As for the packet jitter from the DS, I have done more detailed testing.
Packets tend to arrive in multiples of 20ms, but and are usually within 2 milliseconds. (This is assuming you're only running the DS and robot for 1 match. Strange things happen over several hours.) Most packets arrive at 40ms (that is to say, half the packets the DS sends aren't received by the robot). It's likely a packet-free period greater than 500ms will occur 10 times within 1 match.

EDIT:
I'm assuming it's inconsequential, but I measured from the loop in Robot Main, and from the DriverStation StartCommunication.vi, not from Teleop itself. The purpose of the tests was to examine the reliability of the Driver Station, not the determinacy of Teleop.vi and RobotMode.vi.

[Ether]

Originally Posted by kamocat

I was actually expecting this to be placed in a Periodic tasks, and estimating.

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 ?

[kamocat]

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 ?

[EDIT]
Oops, I forgot to answer your question.
Yes, that's what I'm saying.
I'll take the chance of making an untested estimate, assuming no-one hangs their life on it.
[/EDIT]

It's be interesting to do a decent test.
(I didn't use image processing last year, so that probably made a difference)

I wonder if it would be more deterministic if we made the wait function sequential (using a flat sequence structure)?

[mwsmith78]

Thanks for all the great feedback. We tried out the example VI last night. We inserted it in the Timed-Tasks area with a 20ms wait loop.

We had to debug some other problems that ate up much of our time last night, but once we got past that it sort of worked. PID gains were VERY sensitive. We had lots of trouble getting a stable AND responsive control loop. Tried using a P-only loop, but responses ranged from 1) robot studdering to get to desired angle or 2) robot overshooting and wildly rotating back-forth. Had to keep P<0.02 in order for it to be stable (but not really responsive). Will try tweaking the gains more next week. Have others had this much trouble tuning a PID loop?

[Ether]

Originally Posted by mwsmith78

Thanks for all the great feedback. We tried out the example VI last night. We inserted it in the Timed-Tasks area with a 20ms wait loop.

We had to debug some other problems that ate up much of our time last night, but once we got past that it sort of worked. PID gains were VERY sensitive. We had lots of trouble getting a stable AND responsive control loop. Tried using a P-only loop, but responses ranged from 1) robot studdering to get to desired angle or 2) robot overshooting and wildly rotating back-forth. Had to keep P<0.02 in order for it to be stable (but not really responsive). Will try tweaking the gains more next week. Have others had this much trouble tuning a PID loop?

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); are the rollers contoured and do they spin freely. And are you using direct-drive or chain drive, and how much free play is there at the wheels (ie if you lock the motor shaft, how much - what angle - can you rotate the wheels back and forth).

[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

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

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

[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