Nothing every works exactly the way you'd hoped. We're testing the new ArduPilot boards
and it's looks like we'll need to tweak a few more things. One stems from our decision to run the CPU at its top speed, 20Mhz. That's the best way to get maximum performance (it gives us 20 MIPS), but it introduces some incompatibility with the standard Arduino bootloader and libraries, which for legacy reasons run at 16Mhz or 8Mhz.
The usual solution is to recompile the bootloader for 20Mhz and ship the boards with that already loaded (and tweak the way we use clock-dependent libraries), but because this is an open source project that we expect people to modify, this would force DIYers to jump through some pretty gnarly hoops if they want to use libraries affected by clock speed. We could do it anyway and just advise people on what to watch out for, but I worry that it's not user friendly enough (to say nothing of the support and documentation nightmare).
So we're thinking about switching the resonator on the board to 16Mhz to make it 100% Arduino compatible. That's a 20% decrease in computational power, but our code is pretty efficient and will still run fine. Still, it's slightly painful to declock your board, and I suspect that we'll be switching back to 20Mhz as soon as Arduino supports that natively.
(Needless to say, we'll continue to advance ArduPilot at the pace of Arduino overall, which means switching to a 32-bit processor as soon as that''s supported. Arduino is very much designed to evolve with computer technology, so by hooking our wagon to that horse, we're hoping to future-proof ArduPilot.)