Xmegapilot GPS - On or Off board ?

[Michael Zaffuto]

XmegaPilot is designed around a Mediatek MT3329 based GPS module. One of the cornerstone applicatons for this board will be quadcopters. Should the production boards include the GPS right on the main board for space savings and simplification along with product homogeneity?

[Maximus]

Hi,
Little advise, you must be able to "disconnect" GPS in flight in case of bad receptionb of satelittes...
Cheers
Maximus

[Michael Zaffuto]

Hello Maximus, the gps may be monitored for health. The AHRS will continue to function in this case for some time using magnetometer, gyros and accelerometers. Airspeed and direction will have been extracted from magnetometer and course over ground from last good known gps readings. It will be interesting to see how long the system can survive without gps before integration effects take hold. Otherwise, do you prefer an all in one auto pilot board for a neat and clean installation, or do you prefer the gps module to be located on a separate module that can be placed elsewhere in the airframe?

[Maximus]

Hi Michael,
I think the GPS should be on separate module.
If you use a closed box to protect your electronic parts (not like on MK) and if the box is in carbon fiber, you'll have to cut the top of this box to let the GPS antenna "seeing" the satelites...In this case, it is so better to have separate module...
cheers
Maximus

[Michael Zaffuto]

Hi Maximus, It's nice for me to get some feedback! I will appreciate any input you may have to offer regarding all aspects of this autopilot i'm working on. Some things I have been wondering about is how many servo outputs should be offered. The atXmega really shines in its PWM output...tons are available. Unfortunately, it's weakness, as I understand it at this moment is Input Capture. I/O pins that are to be routed to a timer for input capture must pass through the atxmega's event router multiplexer, there are not dedicated input capture pins. The multiplexer handles 8 total signals. This multiplexer also connects to every peripheral internally to the processor. These internal or external signals can be used to trigger events such as DMA and lots of other stuff. Since there is a resource limitation, 5 servos can be samples using input capture, leaving 3 for Uart DMA for example and other stuff. So question is how many servo inputs are necessary generally? How many servo outputs...is 8 enough, 12, 16? All of these can be handled by the timers themselves so they aren't interrupt driven, therefore cpu loading is not an issue. If I have for example throttle, rudder, elevator, ailerons as ch 1 to 4, control input on ch5..this seems to be enough. Later on, I was going to send a uart or spi output stream for stabilizied camera control....I figured pan left, right, up, down, still capture etc servos can go to that board with its own atxmega (self stabilization taking into account user input as well) The atxmega has lots of SPI, I2C and UARTs. Does this all seem reasonable? Finally, I have been thinking hard about weather or not to include an additonal processor on board to provide 32-bit floating point capability. The "lighter" processing requirements from 'vector matching' type algorithms don't really need it....would it be forward thinking to include a processor which could take advantage of MATLAB code generation and in the loop Simulink code development? In this case...the atxmega would be the main In/Out of the board handling the servo in/out...I2C sensor readings...data logging etc...allowing the floating point processor to run at full bore. What are your thoughts? Thanks!

[Maximus]

Hi Michael !
I think you already have the answers !!!
I am ok with you !
Maximus