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
Agree Rob the kake is almost ready, why not put a cherry on the top of it: Bicopter support.
Bill, I agree. We are close to feature complete, most of the issues on your list are fixed in 2.7.4. We are concentrating on tweaking a few minor things to improve performance and stability. We should also work on usability.
Then have a look at where we want to go from here, and make sure the next hardware provides what we need to get there. If we adopt Due "just because", then it will be a questionable enterprise.
I expect what will happen is once Arducopter is ported to PX4, a bunch of the devs will go nuts with some pretty awesome stuff. But then when the Due comes, it will be back-tracking to get it to run on the slower processor.
It sounds like the current hardware is far from maxed out.
I'd prefer the devs to continue to refine the existing platform since the Due doesn't seem to address any relevant hardware shortcomings. The biggest issues I see (as a lowly forum troll) are ROI inop, last way-point bug, sonar (though I suspect that the Sonar hardware is crap), bounce on landing (maybe a working sonar would fix?), and I think there was a camera gimbal issue or two?
Then, instead of asking what can we do with X hardware. Ask what people want to do, and adopt hardware that suits the requirements.
Such as:
Orbital flights.
Circumnavigate the globe autonomously.
Artificial Intelligence for obstacle avoidance, etc.
And so on.
I didn't want to be cynical. It's always the bad side not being a native that one can be misunderstood.
I understand the historical aspects but in that quoted sentenced I had in my mind the future (so basing on Arduino in next, 32bit version).
Sorry if anything sounded offensive for anyone.
Marooned, I think you are right, generally speaking, but this statement:
Sounds a bit cynical. That's not what happened at all. Originally, the Ardupilot project was actually using an Arduino as a base, and was fully written as an Arduino program. It was only the evolution of the project that took it away from the Arduino standard. Two things happened, one was the creation of the Ardupilot board, which was very much like an Arduino, but just specialized in some ways, rather than having to add a few stacks of daughterboards, and carry around a bunch of weight that wasn't needed. Second, we had to modify the code a lot as we outgrew what the Arduino code could do. Example of this is since we wanted to be able to run SIL simulation, we needed to rigidly define how long an Integer was. For Arduino, and Int is 8 bits. But when we go to compile for SIL running on a real computer, an int was... 16 bits by default? This would mean that SIL simulations would miss out on int overflows that would happen when actually running on an APM. So, they created the int8_t class, which rigidly defines an int to 8 bits, even when compiled for SIL.
So just one example, and I may be wrong, but I believe that's what happened.
Ok, but this is achievable with any Atmega with proper bootloader, am I wrong? So it looks like that bootloader is the key and any Atmega with it can be named as Arduino compatibile.
To be honest, I'm also surprised when hearing on using Arduino for flight controller. To my knowledge Arduino is just a mix of:
1) uC with some standardized outputs so you can attach multiple daughterboards without wire mess
2) bootloader in uC so you don't need a programmer
3) bunch of functions/macros for C to make programming a bit easier
So, ArduPilot is named as "Arduino compatibile" only because it uses a bootloader and some functions from Arduino library? And what if you don't use those extra functions? Is it still Arduino?
So if I'll create my custom board with Atmega, flash it with a bootloader and create a C program that blinks a LED, can I name it "ArduLedFlash" and say it's compatible with Arduino?
I don't see any reason to stick with Arduino for this flight controller. You can make your own custom board that meets custom needs. You can flash uC with bootloader so people with out a programmer can program it. You can port some fancy functions either from Arduino lib or just create your own if that functions speed up programming process. And that's it.
I'm having a feeling that using "Arduino" word for this project is only to be better searchable in Google and bring more people.
I would be grateful for anyone who will enlight me that I'm wrong.
That might be possible with a 100% Arduino sketch using only standard Arduino functions. But the APM code has long since stopped using Arduino standard commands, since most of them are much to slow and with limited functionality (done so in the name of user friendliness).
Most of the APM code talks directly to the the hardware, and just use the Arduino system as a "bootstrap" to get the system up and running.
-
1
-
2
-
3
-
4
of 4 Next