[BB]: Beta Hardware

[Fe_Will]

Originally Posted by Abrakadabra

Most of the IFI lovers seem to be multi-year veterans who most likely had good, knowledgeable mentors who could teach them the mysteries of that system and how to maximize its potential. They came to know it and love it and still wonder why anyone would need anything else. They may think it was "bulletproof", but what they often forget is that it was a very daunting platform for most kids who were probably encountering their first embedded programming platform, usually without any kind of expert guidance, and certainly with very little entry-level documentation. Until Kevin Watson came along and cleaned up the code and wrote a little documentation, most ordinary teams were lucky to just get a drivable platform working. And forget about a mere mortal getting any kind of camera image processing working!

If we really want to grow the FIRST experience, we need to make the steps to success as easy as possible for teams that don't have a full staff of experienced engineers from a large corporation at their beck and call. To my reckoning, the new control system (plus the vastly improved software libraries) is a good step toward that, plus it gives the veteran teams lots of room to expand and stretch the limits of what is possible. The best of both worlds!

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.

[Alan Anderson]

Originally Posted by Abrakadabra

Most of the IFI lovers seem to be multi-year veterans who most likely had good, knowledgeable mentors who could teach them the mysteries of that system and how to maximize its potential. They came to know it and love it and still wonder why anyone would need anything else. They may think it was "bulletproof", but what they often forget is that it was a very daunting platform for most kids who were probably encountering their first embedded programming platform, usually without any kind of expert guidance, and certainly with very little entry-level documentation.

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.

Until Kevin Watson came along and cleaned up the code and wrote a little documentation, most ordinary teams were lucky to just get a drivable platform working.

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.

And forget about a mere mortal getting any kind of camera image processing working!

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.

[lynca]

Originally Posted by Jared341

I think you guys are jumping the gun big time. Assuming they put the USB hub, E stop, and I/O breakout into a single, well-designed enclosure, what's the big deal?

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 ?

Originally Posted by Jared341

3) The clamshell has audio playback, a microphone, and an optional camera. There is opportunity for innovation here. Imagine a game where in "autonomous" mode you could talk to or gesture to your interface without touching buttons.

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

Originally Posted by Jared341

4) The clamshell is much more capable a computer than even the cRIO. If they let you write code for it, you can suddenly offload some complicated (computer vision) tasks.

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

Originally Posted by Jared341

5) Every team now has access to a sort of dashboard app without having to pony up their own laptop. This helps not only the teams, but also potentially FTAs and staff to troubleshoot problems from the driver stations.

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

[Chris is me]

Originally Posted by lynca

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

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

[Jared Russell]

Originally Posted by lynca

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

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.

[Jared Russell]

Originally Posted by Fe_Will

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.

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.

[Jon236]

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.

[Gdeaver]

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.

[AdamHeard]

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

[Jon Jack]

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.

[Chris is me]

Originally Posted by Gdeaver

I like the big E-stop button. For to many years the enable - disable and E-stop implementation has been less than ideal.

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.

[Gdeaver]

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.

[Jon Jack]

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

[Cory]

Originally Posted by Abrakadabra

<soapbox>

It is amazing to me how some people on this thread are reacting so negatively to change. Not just this year, but even last year, where the benefits of the new control system were even more obvious, it was the same folks making the same complaints. And again, they were generally doing all their griping before all the details were known.

It is even more amazing to me that these people represent teams that have built their reputation on building state-of-the-art, cutting edge robots. Honestly, I really have to wonder how much better these teams might be if they didn't have to deal with so much negativity in their midst.



</soapbox>

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.

[DonRotolo]

Originally Posted by Jon Jack

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

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?)