[DFTF] Drinking from the firehose...

[PAR_WIG1350]

Originally Posted by Tom Line

Banebot's RS-775s are very powerful and very hard to smoke, unless of course you get a shorted one, or one with bearing damage, or a locked shaft... which for us, after buying approximately 15 of them last season, runs at a failure ratio of about 50%....

I second this, The main issue is the electrical parts of the motor are often shorted to the case of the motor. Often, this is a manufacturing defect that can be checked for with a multimeter before the motor is put on the robot, although there have been cases of such shorts developing after use. My recommendation is to isolate the motor from any metal on the robot other than the two wires that connect it to the victor or jaguar. Last year we did this by using fisher price plastic transmissions. Watch out for unexpected electrical pathways such as gears and screws. They are a pain, but still awesome.

[Al Skierkiewicz]

Originally Posted by PAR_WIG1350

The main issue is the electrical parts of the motor are often shorted to the case of the motor.

This was true of motors shipped after kickoff last year. Apparently, a new vendor had failed to use a manufacturing technique that would prevent armature shorts. Banebots may have fixed this issue. As the rules have not been released, we are not confidant that this motor will be part of the KOP or allowed motor list yet.

[Jim Zondag]

Labview vs. C++, vs. Java.

This is again very much a matter of preference.
Personnally, if I were working alone by myself, I would use C++. I know C way better than any other language.
But since the whole goal of FIRST is to teach people things, we use Labview.
The Java users are the smallest group, and we have never really considered this, mostly because we know C and LV so well.

I find that, when properly constructed, a well made Labview VI is much easier to explain to students than a chunk of C code.

One thing I will say....Labview makes hard things easy, but sometimes makes easy things harder.

Example: if you want to compare two items and act if they are equal or not, you can do this with just a few keystrokes in C:
(x == y) ? a : b;
While in Labview you need to wire up a equal block to a select block, and a simple operation looks a bit like speghetti.
However, in Labview you can often bring in a single VI block which encapsulates enormous amounts of complexity. Example, I have a single VI function we made once called "Crab", which included all steering and wheel speed code for a four wheel independent steer crab drive system in a single block. The key to sanity in labview is proper style, annotation, and encapsualtion to prevent too much spaghetti. There are tons of great opensource labview VIs out there for almost anything you can think of.

Some other benefits: the Labview support is better, I think because there is a larger community using it. Labview is more or less designed for rapid code construction, so it is good for iterative developement.

To me the biggest benefit of Labview is the fact that it is an instrumentation language. It is not really a true programming langauge and some do not like it for this reason, but in realilty, we are really not trying to do software engineering in FIRST anyway. In FIRST, we are not trying to develop a highly optimized, compact piece of code; we are trying to get a robust solution as fast as humanly possible. The ability to instrument your code while it is actually running is extremely powerful once you learn how. We never need any external instumentation at all anymore....if we need an oscilloscope, just add one to the front panel, if we want to record data to a file for later, then just add a file block to your VI. These things are super easy in LV.

That said, a good coder can make a great robot in any of the 3 language options.

My $0.02

[Alan Anderson]

Originally Posted by Jim Zondag

Example: if you want to compare two items and act if they are equal or not, you can do this with just a few keystrokes in C:
(x == y) ? a : b;
While in Labview you need to wire up a equal block to a select block, and a simple operation looks a bit like speghetti.

I like spaghetti better than oatmeal. You can straighten spaghetti so it looks nice, but oatmeal tends to remain mush no matter how much whitespace you sprinkle through it.

Seriously, if you think a single wire between two blocks (along with the four inputs and one output) looks like spaghetti, you're doing something wrong. This is not an example of LabVIEW making it harder to do something easy. Using the keyboard to type C/C++ is faster than using the mouse to draw using LabVIEW, and compiling a C/C++ program is faster than building a program in LabVIEW. But for someone who isn't already highly skilled in a text-based procedural language, my experience is that having a working program using LabVIEW comes sooner.

This opinion comes from someone who is highly skilled in text-based procedural languages, and who is a relative newcomer to graphical dataflow languages. I just find LabVIEW to be a lot easier to use for the kind of things necessary for FRC robots.