[taichichuan]

Originally Posted by dcherba

This thread has really touched on a number of issues without really taking a top down approach to identify them.

Well, that happens some times when you throw out ideas to generate discussion. You can't always know where the discussion will lead. But, I believe that I summarized the key points a couple of posts ago.

Originally Posted by dcherba

The Crio is a very capable box outfitted with the interfaces that were developed for the robot application.

The Crio is expensive when low budget teams look at the expense of multiple units. This will drive the teams to exploring alternative solutions for code development and practice robots.

I don't think that that issue has ever been in question. The cRIO is a very rugged piece of equipment. It's the cost of the unit and it's interfaces that are in question. So, we're simply exploring alternatives.

Originally Posted by dcherba

Some of the standard software methods embedded in the hardware libraries are not as realtime friendly as they need to be. (image handling let a lone processing an image) I spent a lot of time digging in the libraries so that I would not shotgun solutions. The library skew on some of the releases and the multiple copies of things really caused a lot of confusion when trying to identify were the actual problems were. Having copies of the WPI libraries in three places was confusing.

Yes, that was an issue as well. You're an experienced developer, so I would certainly hope that you wouldn't shotgun problems. But, many of the kids are not and they do. So, I feel that part of the issue to help them avoid that pitfall is to be able to provide a low-cost alternative so they can have more "ground time" to learn how to systematically debug failure modes.

Originally Posted by dcherba

The WPI library is an awsome start to robot control language interface.

I don't think that folks have questioned the validity of the WPI library as a good starting point. There are things that need to be fixed and we're starting a dialog to make that happen.

Originally Posted by dcherba

The WindRiver tools with license issues can be a limiting factor.

The movement towards Java would reduce the dependency on the more expensive development tools and make the code development environment more available to more students.

There is no reason we can not develop a simulator for the basic WPI library that will run on either windows, or linux. The level of simulation and how to provide feedback is however complex.

This is one of the reasons that I brought up Wind River's Simics. It's meant to be a simulation of a physical device with all of the I/O. However, the licensing is an issue. That's why it may be easier to emulate with real, low-cost hardware than simulate in a total software environment. I've found this to be true in many real-world applications.

Originally Posted by dcherba

I spent 20 years designing and applying programmable logic controller. The reason regular computers were not used in these control application is that the standard OS methods of thread control produce undesirable issues that degrade quality of control.

PLCs are great little devices for a number of control applications. However, whether you believe to be a good thing or not, there are a lot of operating systems in use in real-time and embedded control applications. And, those operating systems are in highly mission-critical applications. The PLCs are frequently adjuncts in such systems as the systems grow in complexity.

Originally Posted by dcherba

While the hardware is a great platform diving into the libraries to fix some of the quality of control issues will require a style of software methodology that we do not teach in computer science or engineering. In fact as faculty we would fail students if they used some of the methods required to solve the realtime control issues. (ironic actually)

I find this comment somewhat disturbing. This is precisely the subject of a paper I wrote for IEEE a couple of years ago:

http://www.todaysengineer.org/2008/Feb/help-wanted.asp

There has to be a place for taking the collective knowledge of our real-time and embedded engineers and passing them on to the next generation. The theory of software development needs to be tempered with the reality of meeting processing deadlines in safe and secure ways or we end up with the Toyota Prius problem. I'm working on pieces of the WPILib as we speak to try and make it more capable of running the robotics code without maxing out the CPU in polling loops. This will both teach good real-time engineering principles through example and make the cRIO more responsive. As a side effect, the WPILib can then be more easily ported to alternate platforms in the future.

In the FWIW category, the U.S. military has found that commercial of-the-shelf (COTS) boards are more than capable of operating in harsh and ruggedized environments. As someone who's gone through Navy tactical qualification with COTS hardware (they strap 2lbs of C4 to a barge w/ your equipment on it and detonate), I can attest to the resiliency of low-mass processor boards. So, I'd request that you don't reject a small board out of hand because it doesn't fit into the Allen-Bradley PLC form factor. You'd be surprised at how sturdy COTS equipment is.

Of course, equipment in FIRST isn't in the same "I set it up once and it has to last for 20 years" kind of environment. Our problems are much more fluid as the students experiment to find solutions to the problems posed by the GDC's *evil* imagination So, the cRIO is a good solution, but I don't think it's a cost-effective solution for cash-strapped school systems. I'm just trying to explore the alternatives.

Mike