[ajlapp]

Can you explain how an Arduino-based controller will replace many parts of the cRIO that are separate from the processor like the many FPGA's and registers?

It is not designed to be a cRIO replacement. We weren't necessarily interested in replicating it's functionality...only offering a complete controller solution based on a development environment with a large community and broad appeal.

What languages and ides will be supported?

We prefer the basic Arduino development environment. As with all Arduino boards any C/C++ constructs can be used as long as they work with the AVR compiler. Simulink has a complete environment and a thriving community. Labview has some tool sets that allow you to interact with the Arduino. There are also many other projects on-going that have various levels of support.

Everything else--languages, I/O, weight, cost, schedule of more parts--is far more flexible in my eyes when those first two points are hit.

I agree with this viewpoint. The cRIO though powerful, has many open issues. This is likely one of the reasons FIRST is looking for new solutions. It has always been my understanding that NI was sort of short on time when they initially got involved and that they would have preferred a different solution over the cRIO.

Regardless, we believe in open-source. Everything about our new system is completely open and documented. We're looking for users to modify hardware, add firmware and generally improve the product over time.

No native CAN interface?

No. We eliminated CAN to help keep costs down. The hobby market hasn't fully embraced CAN either. We proposed to use a 2CAN to gain access to a CAN network via ethernet. We are also considering licensing the technology inside the 2CAN for future projects.

The Atmega2560 should be able to handle anything robot related thrown at it short of video processing.

Exactly. Outside of FRC we build many robots, especially swerve/crab robots. We run all of these using Arduino mainboards...this is the main reason why we chose to build our own system. It's smaller, cheaper and more powerful than those that we've been assembling with COTS parts.

I'll toss this out to stir up the pot: if you need double precision floats for your FRC software, you should re-think what you're doing.

100% agree again.

One part of our proposal to FRC was to consider including multiple processor options for teams. Many teams, especially those just getting into FRC need only basic functionality. I think many people would be disappointed to learn how many teams are simply fielding a remote controlled car...meaning no sensoring, no feedback, no software based decision making.

We had hoped to bring Arduino into FIRST because of it's popularity in the education community. Being successful in FIRST is increasingly dependent on your ability to design software. Having familiarity with the architecture on day one can be a powerful leg up for teams without a software expert on their staff.