KOP Contest (Cash Prizes for FRC teams)

[Kevin Sevcik]

I suspect some people might be interested in languages that are a little more generally applicable and not so tightly bound to a specific vendor's hardware. And from a pedagogical standpoint, Labview hides a lot of details that are important for a budding computer scientist to learn. It's certainly useful for many things, but it's not a great stepping stone to any other programming languages.

Also, could we please, please not do the iPhone car thing? As I've ranted elsewhere, it's very, very difficult to do that safely with the FRC Control System. You need to think long and hard about fail safe mechanisms and how your actuators will react to a loss of communications or power. Personally, I'd really hate to read about an FRC team losing someone due to a run away cRIO controlled car.

Basically, whatever you're planning, ask yourself if your FRC bot has ever done something completely unexpected that you don't understand, and then ask yourself how bad it'd be if your offseason project did that.

[Alan Anderson]

Originally Posted by Kevin Sevcik

I suspect some people might be interested in languages that are a little more generally applicable and not so tightly bound to a specific vendor's hardware.

I don't know what you're trying to imply, Kevin. LabVIEW is a very capable general-purpose language that runs on a wide variety of hardware. I'm using it right now on a system built around an Intel CPU and sold by Dell Computer. Around the corner from me it's running on a generic AMD-based box running Windows XP, and I've seen it used on Apple Macintoshes and on HP systems with Linux. And we all know it runs on the CompactRIO.

And from a pedagogical standpoint, Labview hides a lot of details that are important for a budding computer scientist to learn. It's certainly useful for many things, but it's not a great stepping stone to any other programming languages.

If FRC were a computer science competition, I'd be agreeing with you wholeheartedly. But it isn't a computer science competition, any more than it's a materials science or RF design or metallurgical competition. We're mostly giving students exposure to and experience with good use of appropriate tools and materials. We're not really expecting them to learn the details of tool design, are we?

It's arguably true that LabVIEW is not a particularly effective language for teaching low-level CS concepts, but LabVIEW programmers are certainly able to take advantage of those concepts, and it's a fantastic language for use by domain experts who don't happen to be expert programmers.

[santosh]

Originally Posted by Alan Anderson

If FRC were a computer science competition, I'd be agreeing with you wholeheartedly. But it isn't a computer science competition, any more than it's a materials science or RF design or metallurgical competition. We're mostly giving students exposure to and experience with good use of appropriate tools and materials. We're not really expecting them to learn the details of tool design, are we?

True, but in many instances, these kids are learning above and beyond what they are expected to learn. Why inhibit that?

[Kevin Sevcik]

Originally Posted by Alan Anderson

It's arguably true that LabVIEW is not a particularly effective language for teaching low-level CS concepts, but LabVIEW programmers are certainly able to take advantage of those concepts, and it's a fantastic language for use by domain experts who don't happen to be expert programmers.

I'll agree that labview vastly simplifies things for domain experts with little programming experience, but you don't have to do anything particularly complex for the over simplification to bite you. I had a colleague doing basic motor control and datalogging on a labview RT+FPGA system. He appended the data to be logged to an array every control loop. And didn't have a clue why he started missing loops after a few seconds of runtime. Labview was, of course, dynamically resizing the array after an append pushed it outside its reserved memory. That array copy eventually bogged down the control loop, causing missed loops. The mere fact that a beginner doesn't need to think about where all this data is going is a pitifall waiting to trip you up later in your labview programming adventures.

As for hardware compatibility, yes, labview runs on lots of platforms, as long as you're primarily interested in working with NI hardware to interface with the rest of the world. Once you step outside the NI garden, doing things with labview can quickly become complicated.

And that's as far OT as I'll drag this thread. If we want to further discuss the merits and deficiencies of Labview as a general and FRC language, we should start up a new thread.

[Greg McKaskle]

Just a few comments.

I wasn't involved in writing the rules for the contest, but I don't believe they say you have to write all the code in LabVIEW. Perhaps it would be more impressive to the judges to write some code in LV and some in C/C++ and integrate them to do things that are difficult using just one alone. But, a bit of advice -- using the word sucks in relation to a product from company X on the entry form for a contest about products from company X will probably not get you bonus points. You may be good enough to pull it off, but probably not.

Car thing: I wholeheartedly agree. Please do not treat this as a license to build stuff even as dangerous as FRC robots. No parachute deployment systems for skydiving. No robots throwing knives at blind-folded assistants. Use your brain. Use your common sense. Be careful.

LV comments: All languages, all of them, abstract and hide details, otherwise what are they worth. If it hides what you want, awesome. If it hides something you don't, not so awesome.

Tightly bound: LV is able to call DLLs or the equivalent on every platform. It incorporates .NET, ActiveX, even AppleEvents. It can call command scripts, communicate using TCP, UDP, serial, quite a bit of USB and other protocols. LV has better support for NI HW than that of other companies, but not surprising since, much of the HW support for NI products is done by the NI HW teams, and that is what most customers request. Where there are good open standards they are generally adopted and further open the platform. I'd be happy to discuss what you feel should be more open, but as suggested, on the other thread.

Greg McKaskle

[qnetjoe]

Originally Posted by Greg McKaskle

Just a few comments.

I wasn't involved in writing the rules for the contest, but I don't believe they say you have to write all the code in LabVIEW. Perhaps it would be more impressive to the judges to write some code in LV and some in C/C++ and integrate them to do things that are difficult using just one alone. But, a bit of advice -- using the word sucks in relation to a product from company X on the entry form for a contest about products from company X will probably not get you bonus points. You may be good enough to pull it off, but probably not.

Car thing: I wholeheartedly agree. Please do not treat this as a license to build stuff even as dangerous as FRC robots. No parachute deployment systems for skydiving. No robots throwing knives at blind-folded assistants. Use your brain. Use your common sense. Be careful.

LV comments: All languages, all of them, abstract and hide details, otherwise what are they worth. If it hides what you want, awesome. If it hides something you don't, not so awesome.

Tightly bound: LV is able to call DLLs or the equivalent on every platform. It incorporates .NET, ActiveX, even AppleEvents. It can call command scripts, communicate using TCP, UDP, serial, quite a bit of USB and other protocols. LV has better support for NI HW than that of other companies, but not surprising since, much of the HW support for NI products is done by the NI HW teams, and that is what most customers request. Where there are good open standards they are generally adopted and further open the platform. I'd be happy to discuss what you feel should be more open, but as suggested, on the other thread.

Greg McKaskle

You took the words out of my mouth. I hope that everyone sees this as an opportunity to push the limits of their understanding and learn new things.

After all FIRST is about education and not software training!