Re: [BB]: Beta Hardware
 

FRC is the a varsity level robotics competition... What I hear from your post equates to you wanting a sixth grader to step on to the football field and be competitive with high school upper class men. Please don't encourage the dumbing down of this competition, keeping it at a high level is what makes it relevant.

Re: [BB]: Beta Hardware
 

What are you talking about? The 2004 IFI control control system documentation was absolutely amazing. It gave nearly perfect instructions for exactly how to set things up from a starting point of zero knowledge. It came with well-documented default code and a comprehensive guide to how -- and why -- that code worked. There were no mysteries (except perhaps for the existence of the LimitMix() function).

I had extensive email conversations a few years ago with a mentor who was frustrated by what he perceived as a lack of information on how to use the IFI system. The true problem was that he didn't know where to find it, as it wasn't obvious to him that prior years' documentation was still valid. As soon as he started asking questions that made it clear he hadn't read what was available, I pointed him to it and he got much happier.

Kevin created very nice drop-in modules with complete instructions for how to add them to the default code and how to use them. He eventually wrote his own powerful framework around which to build a sophisticated robot-controlling program. But the default code would do a great job of running a driveable platform, and it would even run pneumatics and limit-switch-controlled motors without modification. All the "ordinary team" needed to do was read the instructions describing which joystick inputs controlled which RC outputs.

The CMUcam did its own image processing. The only programming required on the IFI system was for communicating with the camera...and it was in the default code that year.

Re: [BB]: Beta Hardware
 

I agree, we can't shoot the messenger. Let's work with the classmate to improve it's functionality so we can achieve the robustness of the 2004 IFI driver station. Let's start with supporting all the basic functionality including in previous years systems (I/O, E-stop, USB Hub). Then let's try to optimize boot load time to less than 1 minute.

Is there anyway to put the classmate in standby mode so the time to start is less than 5 seconds ?

I'm not too worried about microphones or cameras, but audio playback would be useful.

Off-loading processing to a remote driver station seems inefficient for a real-time OS on a robot.

Having basic terminal access would be nice so we can monitor the system processes. I would trade all dashboard visuals for reliability and speed.

Re: [BB]: Beta Hardware
 

This is probably why the Classmate was picked; you could potentially just throw open the screen and you're good. I'm really excited for the Classmate DS this year and think it's a great solution to a lot of complaints a lot of FIRST had.

My memory's fuzzy, but I don't remember getting a plastic "stop" button in the beta test kit last year...

Re: [BB]: Beta Hardware
 

That all depends. There is enough bandwidth available (in the WiFi specs, but not in the current FIRST packet restrictions) to go around for 6 robots to send small, compressed images in full duplex and still have quite a bit of safety factor.

Re: [BB]: Beta Hardware
 

Why do the goals of ease of accessibility for inexperienced teams and advanced capabilities for veteran teams have to be mutually exclusive? Doesn't having more "out of the box" functionality elevate the level of competition rather than dumb it down?

Reliability, elegance, and better documentation will come with time. Hopefully sooner rather than later.

Re: [BB]: Beta Hardware
 

I agree with Jared.....as a mentor, I enjoy letting the students put the system together and getting it working. The sense of achievement is part of what we must have the students experience. But, then, the fun starts..."wait, there's more...." And with the cRio, there is always another level of complexity for the students to master.

The power of this system is that it is easily introduced, yet allows unparalleled challenges. And by using an industrial grade controller and software (whether C++ or LabVIEW or Java), the students feel an enormous level of confidence and are inspired to do more.

That's what FIRST is all about.

Re: [BB]: Beta Hardware
 

Whoa, such negative vibes in this post. A net book being a commercially mass produced and Supported product makes a whole lot of sense. May be First should be praised for this move. Intel is the 800 Lb gorilla in the semi conductor world and now they will be supporting First. Is this a bad thing?
One concern I have is the custom IO beak out board. Is it full protected so that students can't do some thing stupid and fry the netbook? Is it capable of being a conduit of static into the net book?
I like the big E-stop button. For to many years the enable - disable and E-stop implementation has been less than ideal. These robots are dangerous and there has to be a quick reliable method for killing them. How is the E-stop implemented? Is it fault tolerant. What happens if the USB cable is pulled out? What if the switch in the E-button is defective or fails? I still have the vivid memory from 2 years ago when the robot went berserk and the fumbling of the kludged up dongle all most resulted in what could have been a serious mangling.
Scared the hell out of me. For 2010 let the E-stop be done write.

Re: [BB]: Beta Hardware
 

My negativity comes from the increasing complication of our control system.

When I programmed in high school, we only "needed" two programs. MpLab, and ifiLoader. Neither were hard to setup or took long to install. Radios were configured logically by a manual entering of the team number.

Yesterday, I attempted to help my new programmer make some changes to our practice bot so we can use both this weekend. There's just so much you have to do, to so many different things, with so many different pieces of software.

The techie in me loves getting more sophisticated equipment, but the engineering student in me disagrees. If a simple solution works just as well, adding more complexity (which comes with decreased reliability) is just not a good idea.

Compound this with the fact that it is related to and/or has caused a restructuring of entry fee and what we are given in the KOP, and I am rather dissatisfied.

Call me negative if you like, but I feel I have valid points. All of you have valid points about the Pros of this system, I'm just stating the cons. We'll find out down the road who is more right (but as I'm "disagreeing" with Joe... I think my odds of being right are slim).

Re: [BB]: Beta Hardware
 

How has the current e-Stop implementation been less than ideal? Are you talking about the competition e-Stops or the little dongles included with the DS last year?

Either way, I don't see how this is an improvement. You cant get much more fault tolerant than a mechanical switch that shorts two pins together. This new solution (a USB switch) seems much more prone to failure.

Re: [BB]: Beta Hardware
 

The competition E-stop button wasn't that much smaller than this and was clearly visible and labeled. The toggle switch for enable-disable was completely "quick and reliable" this year off field. If it was too small or something you could always just attach a handle to it or something (there's a 6 inch piece of polycord attached to my team's 09 switch). If anything this stop button is slightly more prone to failure, but I imagine the robot would be auto disabled if it could not detect the E-stop.

Re: [BB]: Beta Hardware
 

My point exactly. How fault tolerant is the USB switch? Having a big button with STOP on it included in the kit is a step forward. As long as it works when needed period.

Re: [BB]: Beta Hardware
 

What difference does it make if it's a little gray dongle or a big red stop button. If you wanted a big red stop button instead of a gray dongle you could've gone to DigiKey or Mouser and bought all the parts to make your own for less than $10.

I don't see how this is a step forward. Replacing a reliable, elegant, mechanical switch with an over sized, ugly, USB switch...

Re: [BB]: Beta Hardware
 

The benefits of the control system were obvious? Maybe to you, but not to a lot of other people. I value reliability over everything else, and the initial release was anything but reliable. Contrast that with a system that had been bulletproof for nearly a decade, which we actually received new hardware for every single year, and I'm still convinced that no matter how superior the technology may be, the IFI system is superior in usability. We're still paying $6000 every year, and now we're getting $1000 less in electronics than before. That's a huge negative.

In short, I don't like change, just for change's sake, or change forced by politics. Let's not kid ourselves. FIRST did not switch to the cRIO because it is superior. They switched because of politics.

P.S. As you may have noticed by our results on the field, 254 seems to be doing just fine.

Re: [BB]: Beta Hardware
 

Ugly is in the eyes of the beholder.

Folks, this is what you will have to work with. Get over it.

With all the whining about IFI and KwikByte, you'd think we should revert to timing motors and cam-operated sequence switches for goodness sake. Who needs a CPU?

Sure, IFI was wunnerful and all, but it's can't cast a shadow on the cRio for versatility and power and ribustness and... well, almost everything but weight. Oh, don't get me wrong - The IFI team was just great, but how many of you still use DOS on your x86??

If the technology is overwhelming, try FTC. <sheesh>. (In other words: Who wants some lemonade?)