In a previous post, I discussed our mainboard approach for ArduPilot Mega. In this post, I'd like to share our thinking about the expansion boards ("shields", in Arduino-speak).
As you can see in the above diagram, the core ArduPilot Mega will consist of two layers, just like the current ArduPilot. The core autopilot board will remain constant, while the IMU board will come out in versions, improving as sensor technology evolves. But there is also the option to add a third layer, which is an expansion board for additional functionality.
We will break out as many I/O (analog and digital) pins as possible to the expansion board, along with at least two serial ports. Some of the boards, such as the DIY sensor board, will be dual voltage.
Some of the boards proposed above may be ones for which there would be enough demand that we'd make and sell them ourselves. Others may be created by the community. ArduPilot is an open standard, like the rest of Arduino, so we'd like to encourage people to come up with their own shields, just as the community has done with the core Arduino boards.
So what do you think? Have we missed any obvious expansion board candidates? Any design decisions we should be making with the core ArduPilot Mega board or IMU to allow for more expansion options? (Remember, size is at a premium, so suggestions that require bigger or more expensive mainboards tend not to carry the day)
@Chris, so I was just following the logic of your earlier "Arduino Trend" post, and I dug a little deeper. I found:
1. Arduino is trending more popular than Atmel.
2. Arduino is far more Google Trendy than is Arduino MEGA.
The extension of this logic would suggest that the Trendy choice is not "any flavor of Atmel" But exclusively the two chips which make up "Arduino" and would suggest a course of dividing the Autopilot problem into specifically Arduino-sized chunks - neither so small as the Attiny, nor so big as the MEGA.
in this vein I proposed and endpoint to the Trendy logic which was several stacked boards each exactly 1 Arduino in complexity, and each more generically useful than the Ardupilot.
1. An open ArduServo board with servo I/O and failsafe. - derivations of this board could be made to physically mate with certain radios.
2. a GPS/IMU Board with course convergence/RTL capabiities. This is essentially the exportable non-Autopilot portion of the problem - capable of boomerang or RTL flight.
3. the final board is the mission controller with logging, uplinking, updateable waypoint lists, and payload servicing. This board makes the autopilot programmable and could not be exported. (however, a datalinked mission controller and a servo board make an awesome exportable remote robot platform).
These three boards are connected by simple I2C (4 wires) so you have Arduino-sized bites and you keep within the logic of "Arduino rulz".
There are reasons beyond the soldering challenge of the Mega chip - which suggest that many people can grok the complexity of a program the size of Arduino, but the poor trendlines of the MEGA-sized Arduino suggests there are far fewer people comfortable of engaging a program that complex or pins that small, or PCBs with unmaskable traces.
In addition, there are plenty of IMU applications which an Arduino sized IMU can address, as there are many servo problems which an Open Source ArduServo board can address. I for one have three Arduino's on my bench today, all of which might be applications for one of the above boards. So one benefit of more generic - arduino-friendlier boards would be ancillary sales to drive volume and reduce cost.
Mike, every layer breaks out all the pins from the previous layer, so the user wants to just create a ribbon cable to connect another board remotely rather than solder on female headers to stack them, that's fine. But I'm not sure what we would do differently to the design to facilitate this.
I think what bGatti is trying to say what i was trying to suggest, keep everything onboard that is required, IMU ,serial ports, gps, servos etc, but keep remote the loggers, I2c, SPI, etc...
the stacking is a superb idea, IMHO, but maybe just a 20-40pin header to make all the other goodies stackable somewhere else in the airframe.
I could be wrong though...lol...maybe bGatti is being ithiric in his explanation which in its self is ironic......not sure....sounds good though!
There is in another post quite an irony - that web traffic for arduino far outstrips interest even in atmel itself - the chip behind arduino. So the argument goes that from all the chips atmel makes, the only ones of interest are the 2 chips of Arduino.
Graph is Trend of Atmel (falling), Arduino (rising), Arduino MEGA (tiny)
If we started with that assumption firmly in hand - we might well conclude that an Ardu- system, by definition - is one broken up into Arduino-sized tasks onto Arduino-compatible boards. (The current Ardupilot fails this definition by the use of the AtTiny chip for example, and the ArdupilotMEGA also stretches the test as Arduino MEGA is not in the same interest class as Arduino by any stretch.)
I actually agree with this, Dr Mike Black. But one must think of the clutter caused by the IDE-like cables. Plus, you'd probably need to double the number of headers on the board in order to provide stackability.
My giddy Aunt!! If we strap all this to it, it will end up a foot deep resembling half a hous brick, the humble, wheezy, asthmatic easystar (which most i believe are basing thier AP on) would never get airborn, let alone fit inside.
May i suggest, that to attach all of the above, that we use something like an IDE cable, (and before you all shoot me down, as IDE is SOOOOO yesterday) something LIKE and IDE, that way all the widgets and flimflams are remote (magnetometer, SD loging,GPS, SPI, I2C, quadruple switching power supplies, 3.3v, 5v, 12v & 240v AC, kettle, leccy toothbrush, snowblower & Kenwood Chef)
Ok, i wandered off on one there, but my point is only that we keep the form and function onboard, and all goodies offboard (it also helps with debuggin the little blighter when we change more than one thing in setup)
Just a thought guys...great believer in the KISS principle, as the propencity on all new stuff to screw up is very high, unless yo ucan break it down to smaller chunks.
In response to jordi's concerns, and in further support of a mini port expansion scheme, I suggest a 4 wire I2C port with daughter boards having in and out connectors for stacking - but on a flexible wire, so you can accommodate airframe, and magnetic interference issues.
Comments
1. Arduino is trending more popular than Atmel.
2. Arduino is far more Google Trendy than is Arduino MEGA.
The extension of this logic would suggest that the Trendy choice is not "any flavor of Atmel" But exclusively the two chips which make up "Arduino" and would suggest a course of dividing the Autopilot problem into specifically Arduino-sized chunks - neither so small as the Attiny, nor so big as the MEGA.
in this vein I proposed and endpoint to the Trendy logic which was several stacked boards each exactly 1 Arduino in complexity, and each more generically useful than the Ardupilot.
1. An open ArduServo board with servo I/O and failsafe. - derivations of this board could be made to physically mate with certain radios.
2. a GPS/IMU Board with course convergence/RTL capabiities. This is essentially the exportable non-Autopilot portion of the problem - capable of boomerang or RTL flight.
3. the final board is the mission controller with logging, uplinking, updateable waypoint lists, and payload servicing. This board makes the autopilot programmable and could not be exported. (however, a datalinked mission controller and a servo board make an awesome exportable remote robot platform).
These three boards are connected by simple I2C (4 wires) so you have Arduino-sized bites and you keep within the logic of "Arduino rulz".
There are reasons beyond the soldering challenge of the Mega chip - which suggest that many people can grok the complexity of a program the size of Arduino, but the poor trendlines of the MEGA-sized Arduino suggests there are far fewer people comfortable of engaging a program that complex or pins that small, or PCBs with unmaskable traces.
In addition, there are plenty of IMU applications which an Arduino sized IMU can address, as there are many servo problems which an Open Source ArduServo board can address. I for one have three Arduino's on my bench today, all of which might be applications for one of the above boards. So one benefit of more generic - arduino-friendlier boards would be ancillary sales to drive volume and reduce cost.
P.S. there is an Arduino derivative which uses an inbuilt USB port on a slightly different chip with USB bootloader - it may solve your USB dilemma.
the stacking is a superb idea, IMHO, but maybe just a 20-40pin header to make all the other goodies stackable somewhere else in the airframe.
I could be wrong though...lol...maybe bGatti is being ithiric in his explanation which in its self is ironic......not sure....sounds good though!
Doc.
1. Servo IO & Failsafe
2. IMU GPS & Waypoint Conversion (RTL)
3. Mission Control, Data logging and up/downlink
Then these boards (and others) can be used in some combination for generic projects or doubled up on (ie for more servo, or redundant radio)
Graph is Trend of Atmel (falling), Arduino (rising), Arduino MEGA (tiny)If we started with that assumption firmly in hand - we might well conclude that an Ardu- system, by definition - is one broken up into Arduino-sized tasks onto Arduino-compatible boards. (The current Ardupilot fails this definition by the use of the AtTiny chip for example, and the ArdupilotMEGA also stretches the test as Arduino MEGA is not in the same interest class as Arduino by any stretch.)
May i suggest, that to attach all of the above, that we use something like an IDE cable, (and before you all shoot me down, as IDE is SOOOOO yesterday) something LIKE and IDE, that way all the widgets and flimflams are remote (magnetometer, SD loging,GPS, SPI, I2C, quadruple switching power supplies, 3.3v, 5v, 12v & 240v AC, kettle, leccy toothbrush, snowblower & Kenwood Chef)
Ok, i wandered off on one there, but my point is only that we keep the form and function onboard, and all goodies offboard (it also helps with debuggin the little blighter when we change more than one thing in setup)
Just a thought guys...great believer in the KISS principle, as the propencity on all new stuff to screw up is very high, unless yo ucan break it down to smaller chunks.
Doc.
-
1
-
2
-
3
-
4
of 4 Next