Team 39, 2008 LabVIEW Beta Code

[BornaE]

http://hhsrobotics.org/forums/viewtopic.php?f=4&t=3

We just released the first revision.
More coming soon.

rev0.1--
this revision only includes the teleoperated mode. it has been tested on the robot.



Enjoy!

[dmlawrence]

Could you post images of the VIs? My team does not have access to LabView yet.

[BornaE]

Originally Posted by dmlawrence

Could you post images of the VIs? My team does not have access to LabView yet.

Sure, I was going to do that.
I will post the pics sometime tonight

[Kevin Sevcik]

For the health of your board there, you might want to set permissions so people don't have to register to download this file. Else you'll be getting a rather lot of one-time registrations.

EDIT:

Second point, pictures are going to be slightly more meaningful, because all of us out here are lacking the dozens of WPI VIs needed to make sense of your code. Nevertheless, I'd like to suggest that you look into "Enumeration Constants" for passing your states around, instead of variable length strings. Eric will probably swoop in here and declare that we have so much processing power that it doesn't matter... But I think some things just shouldn't be done. Plus, enumeration constants will make your state-flow code immune to typos in your states.

[BornaE]

Originally Posted by Kevin Sevcik

For the health of your board there, you might want to set permissions so people don't have to register to download this file. Else you'll be getting a rather lot of one-time registrations.

Oops, I thought phpbb did that by default. I will change it.

Originally Posted by Kevin Sevcik

Second point, pictures are going to be slightly more meaningful, because all of us out here are lacking the dozens of WPI VIs needed to make sense of your code. Nevertheless, I'd like to suggest that you look into "Enumeration Constants" for passing your states around, instead of variable length strings. Eric will probably swoop in here and declare that we have so much processing power that it doesn't matter... But I think some things just shouldn't be done. Plus, enumeration constants will make your state-flow code immune to typos in your states.

That code was cramped in one day. I have cleaned it up but want to test it before posting.
Thanks for the suggestions.

[BornaE]

HTML version just posted.
http://hhsrobotics.org/forums/viewtopic.php?f=4&t=3

[Russ Beavis]

The cRIO's PowerPC/FPGA combo is obviously far more processing-capable than the old IFI setup. However, that's no reason to write sloppy and inefficient code.

With a bit of LabVIEW experience, you'll learn to appreciate the value of the enumerated type (as in C/C++). I would strongly encourage every LabVIEW programmer to use this datatype wherever possible. It's always good practice to remove "magic numbers" from your code.

Russ

[Tom Line]

I looked through the code - and I have to wonder if it isn't time for FIRST to release some explanations of how the system is going to function.

I looked at it and was completely confused as to how it was supposed to work - and I'm betting other people are going to have the exact same reaction.

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