LabVIEW WPI library suggestions

[Chris Hibner]

I know NI and WPI are working on updates and improvements to the WPI library for next year. I know people have made a few complaints and suggestions throughout the year, but I wanted to create this thread to give people a chance to express their desires after they've had some time to look back on the season.

I know NI regularly looks at these forums so I'm sure they will see the feedback. If not, I could bundle this up into an e-mail and send them to the appropriate people.

PLEASE do not turn this into a firestorm of complaints and negativity. Both NI and WPI did a great job. It's hard getting everything 100% perfect while suiting everyone's tastes. Try to provide positive, constructive feedback.

[Chris Hibner]

I'm going to start out:

1) I want to be able to command the gyro calibration routine via a boolean input to some "Cal Gyro" VI. It's hard to guarantee the robot is perfectly still right after power up, especially with all of the demands of the field reset crew. They want your robot on right away so it can link to the field ASAP, and I don't blame them.

For all of our other sensors, we reset them when the driver selects a new autonomous routine from the driver station. We do this because we can guarantee when no one is touching the robot. Our coach/driver sets up the robot on the field, turns is on, then moves it around a lot until it's in the proper position. Sensors may be out of whack at this point due to the movement. As soon as our humans leave the playing field, the driver changes the autonomous routine which triggers all of our sensor resets. At this time, I would also like to kick-off the bias-calculation (i.e. calibration) routine for any inertial sensors, or any other analog sensors.

2) I want an "Encoder Get" VI that will read multiple encoders at the SAME TIME. Yes, there are other ways to try and make this happen, but it's not obvious for a lot of LabVIEW newbies. At one point this year we couldn't figure out why our robot's heading was always off in autonomous mode. Then we figured out is was due to the timing of the encoder reads. The code was reading the right encoder, then arm and elevator, then it would execute the arm and elevator control, then it would finally get around to reading the left encoder and execute the heading and position determination. All that time between reading the left and right encoders caused the left encoder to read about 0.25 inches higher than the right, even though the left and right side of the drive system went the same distance. Because of this, the robot thought it had turned to the right, so it would start turning to the left to compensate. After we figured out what was going on, we reconfigured the software to guarantee the left and right encoders would be read back-to-back, but it would be nice to have a large "get" to read all encoders simultaneously.

One last thing: Last year I asked for a status bar on the imaging tool, and I noticed that there was great status feedback this year. Thanks a LOT! I've been meaning to say thanks all throughout this year, but I kept forgetting by the time I got to CD.

[vhcook]

I have been generally delighted by the level of support provided by NI and WPI, and I'd like to start off by thanking everyone involved for their efforts. Each year, things have improved, and I'm sure I'll be delighted with the new framework/tools again next season.

3) I'd like a VI to handle the Parallax PING))) module (or some good advice if there's already a way to do this), which is an ultrasonic sensor that requires an outbound pulse on the same pin that it will subsequently provide the range input. I haven't been able to get it to work on my own. Here's a data sheet.

[siggy2xc]

Latch and switch when pressed (and the other abilities they give you for a button). Definitely very simple to make but it would have helped as a complete n00bie.

[apalrd]

A few things I would like:
I have already written a gyro calibration VI (modified WPI Gyro Open VI) and included it in the zip attached. If you set the Center input to 0, it will autodetect the center and feed it to the Center output. If you set Center to a number, it will use that as the centerpoint. It also has the gain pulled out so you don't need another VI (WPI Gyro Set Gain) to set the gain.

Battery voltage - I found it only one level down in WPI Start Communication, but it is never given to teams in an easy way. I wrote a simple data cache in my attached zip, but there are other ways to implement this.

Relay set only one coil - I know how to set the coils separately using the four states of the enum, but sometimes it is nice to set one coil in a totally different place in code (for example, forward in minibot.vi and reverse in lights.vi), and there is no good way to do this. I propose a SetForward and SetReverse VI which sets each coil separately.

[Alan Anderson]

I don't know if this counts as a library thing, but I've always felt that the motor function palette was organized upside down. The generic motor VIs are too many levels down in the hierarchy.

Lots of people ask how to toggle on a button press or to do things once when the button is first pressed. It's not hard to create code to do that, but it might help to have pre-packaged functions for teams to use.

The refnum registry is a great concept but it seems not quite polished. It creates a context in the code where exact spelling matters. I'd like to see a provided facility that can do the same thing just as easily but with multiple-choice selections instead of unconstrained string constants.