Jordi spent the holiday well, laying out the physical ArduPilot Mega board. The last bit of this process is the routing of the traces, which will ultimately determine the size of the board. In the picture above, you can see the progression as the board gets smaller and smaller through each revision, finally ending up with the release candidate ("RC"), shown next to the current ArduPilot. It's surprisingly small, despite us using a much larger core processor with twice as many pins as the current Atmega328.
The main chips you can see in the board printot are the Atmega1280 (main processor), an Atmega168 for the PPM conversion/failsafe, and a multiplexer chip (failsafe).
You may not have realized it, but you've been watching much of the ArduPilot Mega development already:
The IMU, which is modular and will plug on to the top of this board, is functionally the same as the current ArduIMU+ and will use the same code. If you already have an ArduIMU, we will release an adapter board that will allow you to use it so you don't have to buy another one. But the custom ArduPilot Mega IMU will also have a differential pressure sensor (airspeed) and an onboard FTDI chip and USB port so ArduPilot Mega will have native USB support (hurray!). If you're not using the custom IMU board, you'll be able to program ArduPilot Mega through the usual FTDI cable, like regular ArduPilot.
The core ArduPilot Mega code will be built on the current ArduPilot 2.5, but with extensions for the new functionality that comes with 2-way communications, more memory and eight channel control. We'll also be adding more powerful mission scripting and event triggers, now that we have so many spare I/O pins and channels.
The PPM/failsafe circuit is based on our current 8ch PPM board.
The result of all this parallel development is that ArduPilot Mega will move pretty quickly now that we have a release candidate board, since so much of the tricky stuff like the IMU is already done, tested and mature. I'd predict a release in March or April.
FYI, the board is also build for expansion, and one of the four serial ports will be available to expansion boards, as will several I2C/SPI pins. So, for example, adding magnetometer, absolute pressure sensors (altitude), or ultrasonic sensors could be an option.
I am just getting to the point of purchasing my first ever ArduPilot. Is the Mega supposed to be like a replacement of the standard one out now or is it more like a newer upgraded version that will be available but not getting rid of the current one? I am just wondering if I should go a head and order the ArduPilot or wait for this to be released.
Has any thought been give to making it easier to intergrate Ardupilot mega and Remzibi OSD?
I was just looking at the intergration thread betwwen Ardupilot and Remzibi running on RC Groups.
"Yes theres an easy way". Using the other input capture to read the PPM coming from the receiver. Also the code from the failsafe could be changed just to bypass the PPM pin directly.
Ok, I guess a interrupt driven PPM decoder will be pretty efficient. Another bonus using PPM would be the possibility to feed the original PPM signal straight from a receiver to the 1280 using a singe wire (bypassing the failsafe). Maybe there should be an easy way to "unplug" the failsafe connection for such usage?
John, that's correct. Although you might think that a digital standard like I2C would be more efficient, in practice it isn't. The Atmega1280's hardware approach to reading PPM is much faster than the I2C data speed, and it requires very little processing overhead. And wasting a serial port on this is unnecessary.
Looking great! Chris mentioned that the PPM/failsafe will be based on the current 8ch PPM encoder. Does that mean that the communication between 168 and 1280 is PPM? If that is so, would it not be more efficient using the atmega hardware with proper 2-way communication? (ISP/I2C/RS232)
can't wait! Thanks Jordi / Chris for everything, and Jason for 2.5 code, and anyone else involved.
IMHO, it would be ideal if pins are available to use both i2c and spi devices at same time, and not have to take pins that have other typical mainstream use.
I would dream that all pins of the 1280 would be brought out to hole pads on the board, even if not all nice out at the edge of the board. On current V1 IMU, and ArduPilot, there are a couple of extra pins not brought out, I very carefully hooked on to them to be able to do spi. With spi, do need dedicated slave select lines for each device, and some other devices (SCP1000 baro) can also use a data ready line in addition. (sounds to me like a good plug there for i2c). The picture looks like they all come out, looks great!!
And even more fabulous and incredibly selfish to suggest: on the shield, split the i2c & spi lines into 3.3 and 5v busses with level shifters. this would enable many more people to add on other devices and functionality: on board sd card datalogging, baro sensors, magnetometer, you name it. I imagine soon there will be more examples of code to do spi & i2c, with ArduPilot / ArduIMU, even though seems to not usually be used with Arduino. IMHO, this would help pull in more users to ArduPilot.
Comments
If you want to start learning, get the regular Ardupilot, and either a thermopile or ArduIMU setup for stabilization.
I was just looking at the intergration thread betwwen Ardupilot and Remzibi running on RC Groups.
IMHO, it would be ideal if pins are available to use both i2c and spi devices at same time, and not have to take pins that have other typical mainstream use.
I would dream that all pins of the 1280 would be brought out to hole pads on the board, even if not all nice out at the edge of the board. On current V1 IMU, and ArduPilot, there are a couple of extra pins not brought out, I very carefully hooked on to them to be able to do spi. With spi, do need dedicated slave select lines for each device, and some other devices (SCP1000 baro) can also use a data ready line in addition. (sounds to me like a good plug there for i2c). The picture looks like they all come out, looks great!!
And even more fabulous and incredibly selfish to suggest: on the shield, split the i2c & spi lines into 3.3 and 5v busses with level shifters. this would enable many more people to add on other devices and functionality: on board sd card datalogging, baro sensors, magnetometer, you name it. I imagine soon there will be more examples of code to do spi & i2c, with ArduPilot / ArduIMU, even though seems to not usually be used with Arduino. IMHO, this would help pull in more users to ArduPilot.
-
1
-
2
-
3
-
4
of 4 Next