Team 39, 2008 LabVIEW Beta Code

[Kevin Sevcik]

Tom,

I think the code looks.... reasonably straight forward. But then, I'm a bit used to deciphering Labview code. It looks like most every function is going to be run through those XYZ-Open,Something,Close function blocks. Open XYZ on Port B at Slot A, either when the robot is turned on or when initializing into a mode. Do something to it. Close it when your robot turns off, stops needing it, or stops running the Labview code. I imagine the latter is important to not forget, since it could possibly confound things if you don't close these ports when you stop the code to make a programming change.

I'm a little concerned that I don't see any DaqMX tasks in this code. I realize it's slightly advanced stuff, but it's important slightly advanced stuff. You can set up hardware timed data sampling tasks that run at much higher frequencies than your background processing tasks, as well as setting up custom scales and all sorts of other things. Hopefully it's just that beta teams haven't gotten around to looking at that sort of thing yet, as opposed to it not being an option.

Borna,

A few followup questions from an interested bystander:
1. I assume the pink wires in and out of the various modules (DigMd, AnlgMd) are carrying module configuration info. Are the shift registers you have on these module configuration lines actually necessary? Could they instead just be simple tunnels, as with the Joystick in your main loop?
2. Is 25 Hz just a random loop timing decision on your part, or is it the recommended max loop rate?
3. The Victor/PWM modules seem to have some sort of deadband and transform setup. Does that configuration happen in a separate module?

[Joe Ross]

Originally Posted by Kevin Sevcik

1. I assume the pink wires in and out of the various modules (DigMd, AnlgMd) are carrying module configuration info. Are the shift registers you have on these module configuration lines actually necessary? Could they instead just be simple tunnels, as with the Joystick in your main loop?

That is one point on which several beta teams are confused. It really depends on whether the references carry state information (best I can tell, some do and some don't). There have been a lot of ideas thrown around on how to improve things, both through examples and added documentation.

Originally Posted by Kevin Sevcik

2. Is 25 Hz just a random loop timing decision on your part, or is it the recommended max loop rate?

It is the rate at which the driver station sends data. That should be raised soon. I have not seen any recommendations as to a maximum.

Originally Posted by Kevin Sevcik

3. The Victor/PWM modules seem to have some sort of deadband and transform setup. Does that configuration happen in a separate module?

There are 4 PWM type VI Libraries, a raw PWM, a Victor, a Jaguar, and a servo. The Victor, Jaguar, and Servo have different types of deadband and scaling control. You can use the raw PWM, if you want to implement your own methods for scaling and or deadband elimination.

For example, The deadband control for Victor is a boolean value, whether to scale the inputs to eliminate the victor deadzone and center on 127 (rather then 132) or not.

[BornaE]

Originally Posted by Kevin Sevcik

Tom,

1. I assume the pink wires in and out of the various modules (DigMd, AnlgMd) are carrying module configuration info. Are the shift registers you have on these module configuration lines actually necessary? Could they instead just be simple tunnels, as with the Joystick in your main loop?

The pink Wires pass the device refrence information, but there are some subVIs that can change the parameteres in that cluster.
too keep the new data for the next loops, shiftregisters are needed.

but in our case as of now, tunnels would work the same.


================================================== ====
For our code as of now, we dont need to sample the inputs more that 25hz since thats the only time they are needed. once we get to gyros or accelerometers, sampling fater would come in handy.

I promise the next revision looks much better.

[Kevin Sevcik]

Originally Posted by Joe Ross

It is the rate at which the driver station sends data. That should be raised to 40hz soon (same as IFI). I have not seen any recommendations as to a maximum.

Ah. Good to know, then. One more followup while I'm on my lunch break. Is it possible to run separate loops at higher rates for improving PID control? For example, with the IFI RC, you could set up the "fast loop" to update some of the PWM outputs at whatever speed you liked. Given that the Victors can theoretically handle update rates of 120Hz, I'd dislike having to throttle them to whatever the update rate of the DS is.

[BornaE]

Originally Posted by Kevin Sevcik

Ah. Good to know, then. One more followup while I'm on my lunch break. Is it possible to run separate loops at higher rates for improving PID control? For example, with the IFI RC, you could set up the "fast loop" to update some of the PWM outputs at whatever speed you liked. Given that the Victors can theoretically handle update rates of 120Hz, I'd dislike having to throttle them to whatever the update rate of the DS is.

Yes, you can run other loops simultaneously at different rates.
Also a new Driver Station update was released today that changed the update rate to approximately 50Hz
you can also run this loop faster, it is best if the loop OS run at a multiple of DS update rate. eg. 100Hz - 200Hz and make sure your processor doesnt run out of time.

[Greg McKaskle]

Responding to the question about DAQmx usage, the cRIO and other reconfigurable I/O devices don't have a traditional driver API to their I/O. The I/O is defined by VIs that run on the FPGA, and accessed by VIs that run on the RT target. In other words, the WPI library really is the API. It is built upon/incorporates the FPGA, and is DAQmx is not in the picture.

Greg McKaskle

[Joe Hershberger]

Originally Posted by Kevin Sevcik

Tom,
I'm a little concerned that I don't see any DaqMX tasks in this code. I realize it's slightly advanced stuff, but it's important slightly advanced stuff. You can set up hardware timed data sampling tasks that run at much higher frequencies than your background processing tasks, as well as setting up custom scales and all sorts of other things. Hopefully it's just that beta teams haven't gotten around to looking at that sort of thing yet, as opposed to it not being an option.

The FPGA is implemented to execute hardware timed analog acquisitions in the background. You can specify different sample rates for each module (which is more flexible than DAQmx) so that you can better tailor the measurement to the sensors connected to that module. In addition, there are hardware accumulators (DAQmx doesn't have them), oversampling / averaging engine (DAQmx doesn't have it), 8 analog triggers (DAQ boards usually have 0 to 2) and the triggers support rollover detection (DAQ triggers don't)... the list goes on and on.

Custom scales are implemented by you wrapping the GetVoltage VI with the calculations you want for your scale. The voltage values that are returned to you are scaled with factory calibration constants stored for each channel on each module during manufacturing.

Originally Posted by Greg McKaskle

Responding to the question about DAQmx usage, the cRIO and other reconfigurable I/O devices don't have a traditional driver API to their I/O. The I/O is defined by VIs that run on the FPGA, and accessed by VIs that run on the RT target. In other words, the WPI library really is the API. It is built upon/incorporates the FPGA, and is DAQmx is not in the picture.

The goal was to create an API that, while not as general purpose as DAQmx, provides more of the features that teams will need to excel. I hope you find that to be true. Oddly enough, for my day job I'm a driver developer for DAQmx.

[BornaE]

New Revision posted here: http://hhsrobotics.org/forums/viewto...f=4&t=3&p=6#p6

[Greg McKaskle]

It looks like you have lots of things hooked up and working. I don't see any timing in your BIG loop with all of your dig I/O stuff. That of course means it runs all out in parallel with everything else. If you can determine a time for it to run based on response, that will likely help with the responsiveness of the other loops.

My guess is that you can put a Wait of 20ms, similar to the camera loop. If that seems too slow, lower the number.

Greg McKaskle

[BornaE]

Originally Posted by Greg McKaskle

It looks like you have lots of things hooked up and working. I don't see any timing in your BIG loop with all of your dig I/O stuff. That of course means it runs all out in parallel with everything else. If you can determine a time for it to run based on response, that will likely help with the responsiveness of the other loops.

My guess is that you can put a Wait of 20ms, similar to the camera loop. If that seems too slow, lower the number.

Greg McKaskle

Oops, I forgot to put that in there.
I was using a Timed loop before that but since that was not provided with the default FRC labview, i switched it to a while loop.