At Maker Faire NYC this weekend, Arduino's Massimo Banzi announced that the long-awaited ARM-based Arduino, called the DUE, would be out in November.
Engadget reports:
The Due is roughly the size of the Mega 2560, but swaps the 16MHz, 8-bit processor found in your standard issue Arduino for a 96MHz Cortex-M3 [Corection: it's 84MHz by default but can be overclocked to 96]. Predictably, the Due is a much more capable development platform, and could easily replace multiple AVR-based Arduinos in products like DIY Drones' UAVs. The Due isn't expected ship till at least November in large quantities, but preview boards are currently being handed out to select developers.
I was there and spent a lot of time with the Arduino team discussing the latest details, including debugger and USB interfaces. We've been working with them for a year on this, and some of the APM team helped with the Due software. Right now the APM team is focused on the PX4 board and bringing ArduCopter and ArduPlane to that ASAP, but that ARM-based and RTOS-based code will also be the foundation of a future Due-based APM board.
Given the delays in Due, we're going to wait until it's out and the community can spend some time with it before pushing out a new APM board; the transition to ARM is not trivial for Arduino, and we've already got a great ARM platform with PX4. But we are working closely with the Arduino team and are committed to Arduino as one of our platforms for the future. It's less about the hardware power and more about the ease-of-use of the programming toolchain and the inclusivity of the community, and Arduino has served us very well on that.
A full video of the Arduino/AVR presentation at Maker Faire is here:
Here are the technical specs, from this PDF:
Comments
F11, you don't have to go very far. The PX4 system use a RTOS. https://pixhawk.ethz.ch/px4/start
when do we expect the APM code to be ported to PX4. And i think u are right once the PX4 version is out some unimaginable miracles can be expected.
Andre, I agree that there is a need for a simple, robust autopilot. But the irony is that a RTOS system is actually much simpler to work with and also much, much more robust by design, compared to low-level hard coded stuff like the current APM base.
With RTOS you can specify high priorities for certain functions like IMU/sensor etc, so that no matter how much user code is added at a lower priority they still run on time. Even if you tried making the code fail with an infinite loop doing nothing but stealing cpu cycles, it would still not affect the high priority functions. So experimenting with new code would be easier and safer.
And you could even take this one step further if you wanted. Imagine having "custom user code" run in an Arduino virtual machine on the RTOS. Meaning that inexperienced users could program and try out high level autopilot functionality using a standard Arduino environment with easy Arduino like functions to access relevant autopilot functions. All totally separated from any time critical, or low level hardware stuff.
IMHO, even with all the RTOS autopilots and evolving hardware, there should be space for an extensible open-source autopilot that is part of the arduino ecosystem (if you want to call it that). Note that most folks would be perfectly happy with a simple, robust, easy-to-use autopilot with waypoint capability for say mapping missions and RTL/FBW capacility for FPV with easy-to-use extensions such as OSD and antenna tracker. Note that not everyone wants to use the latest and greatest object recognition, collision avoidance and what not for which you actually need all that processing power. That's just my 5 cents... I consider APM more of a the LegoMindstorm of autopilots (I know that's not the best comparison).
LOL. I don't think Open Pilot is very likely to do anything that would make it easier for us to use their code. ;)
I think one potential advantage of the Due, even though it doesn't have as much performance as we'd like, is that it could probably run the existing stabilization code at 400 Hz instead of 100 we are doing now. This would allow us to send a new, freshly updated command to the ESC's at 400Hz, which would benefit anybody flying with SimonK ESC's. Currently, we basically repeat the same signal out 4 times, because we are pushing 400Hz, but only updating at 100Hz.
Developers will have to change a lot of the code if it is ported to RTOS but the benefit would be worthwhile. Just imagine if PX4, Autoquad, Openpilot, and VRBrain wich are using the same processor, can standardize on a RTOS, how easy would I be for them to reuse each others code with little to no modifications.
To me, one of the main advantages of running a full blown 32bit processor, is that you get a proper DMA and interrupt system. But to take full advantage of the new hardware in a sensible way, you usually need to have a RTOS over the hardware so that you get a task scheduler. That way you can execute code using time slicing and task priorities. In the long run this can greatly simplify code management and be used to making sure time critical code always run on time no matter how busy the system is.
But the downside is that this will more or less require a TOTAL rewrite of the current APM code. But it is only a matter of time before we are forced to go that route if we plan on using a more advanced/faster system then the SAM3X in the future. Just imagine trying to run and take advantage of a dual/quad core CPU with the current code..
Jani, doesn't the fact that we created all these custom math definitions (uint8t, etc.) make the job much easier?
I still wonder why they choose that SAM3X as there would be better ones available on market. Oh well at least they finally announced it.
Porting ArduCopter and others to this board will take some effort as many things needs to be fixed on it. Ok main code is main code and don't need to much tweaking but then all variables and how they are handled needs to be fixed.
We are talking two different architectures. One that has 8 bit system and another that is 32bit. That already makes huge difference on software it self. But for sure, it will be done eventually.