[DFTF] Drinking from the firehose...

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

[Al Skierkiewicz]

Joe,
I knew you couldn't stay away forever. You have my email so you can ask me anything you like. Some answers will come from Al the others may come from the Chief Robot Inspector for FRC.

[Gdeaver]

It's still September. Keep the focus narrow at first.

Money, money, money where is the rest of the money going to come from. No money, no team.

Team and school administration. Right now get together with the principle and make sure you are on the same page. Find out now about the school policies and procedures. Questions like when and how do you gain access to the building. Can students use power tools with out a licensed shop teacher present. Who pays for the teachers substitute when at competitions. Will the school pay for busing to the events. What is the school policy for over night trips. Can you travel to a regional that would require an over night stay, or will it have to be day trips to a local event. Find out now so a regional selection can be made. You have a whole lot off administration to figure out. Do it now.

Students, It helps to have good involved students. How do you present robotics to suck them in.

After the administrative issues are addressed, You can then start to think about the robot . The school policies, money, additional mentors and sponsors will determine how complex the robot can be. Will it be a cheap KISS bot or can you go for some complexity. The c-rio and programming needs to be looked at in the fall.

First has allot of resources available. Develop a project management style with a time line like thing.

Go for it. Full speed ahead. The hell with the day job.

[Brandon Holley]

Joe-

First of all, welcome back. We've certainly missed you.

Next, whereabouts in the Boston area are you? My team (125) has spent a great deal of time over the past 7 seasons helping to foster growth in the greater Boston area. We've been heavily involved in helping teams get up and running (and sustaining) after an FRC explosion occurred here back in the 2005-2006 range.

We'd be happy to help in anyway at all. Feel free to PM me, or send me a message on LinkedIn!

-Brando

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