I am trying to decide on a platform, but I would like to consider the math model being used, an the whether there is a need for floating point on the microcontroller.There are several models available for inertial measurements - some handling drop out of the GPS signal better than others, etc.. I'm trying to decide on a platform to control a multi rotor craft - quad or something similar to Jack's latest iteration using five propellers - but I'd like to have the option (if possible) to plop it into a fixed wing craft too. Paparazzi is the only system I've seen applied to multiple craft types.From a post by Jack Crossfire: "This is called an 'extended Kalman filter'. For best results, U need to integrate the gyros in quaternion form & blend in euler form. The ATMega autopilots don't do this because it's floating point intensive."Other versions of the Kalman remove the need to explicitly calculate the Jacobians an thus seem to require less cycles to compute, an still handle non linearities.Are most of the arduino an other lower power chips not using floating point dependant models (?). Perhaps there is a listing some where that I missed indicating the models used by different UAV platforms an the limits (if any) imposed by the microcontroller for floating point calculations (?).I know there are floating point libraries available for the Propeller, an the PIC's - but I wasn't sure if they were fast enough for inertial navigation models. Do any microcontrollers handle floating point on the chip?I saw this comment on another diydrones post: "Regarding the ARM CPUs (and the PXA used for the gumstix), Adam used these modules for his Vicacopter, but the lack of FPU yield very poor performance for the algorithms he wrote.The beagleboard is nice but it is also suffering from the same problem"However, my understanding of the Beagleboard is that the ARM8 gives it certain advantages over the 2148. Specifically "Cortex has a few unfair advantages over the LPC2148: raw clock speed, and VFP. VFP technology is a coprocessor extension to the ARM architecture. It provides low-cost single-precision and double-precision floating-point computation fully compliant with the ANSI/IEEE Std 754-1985 Standard for Binary Floating-Point Arithmetic.""The Cortex-A8 can calculate the square root of a single-precision floating-point number in 9 cycles. At 600 MHz, this is 15 ns. If you need double precision or full IEEE compliance (exceptions, fancy rounding, etc.), it can take up to 60 cycles (100 ns at 600 MHz). "How do the numbers on the ARM8 stack up against other microcontrollers that people have used?Thanks for any comments!
I think LPC21XX has nice PWM capture features but due to unfortunate pin assignement they lack PWM output possibilities: with 2 UARTS in use (one GPS, one debug) you are left with only 2 PWMouts, SPI SSEL0 kills one more PWMout. Any other candidates that have small package?
Also 2106 has no ADC if I remember.
I agree with Otto Pilot. You can do a lot an ARM7 like the the LPC21XX processors. I implemented a control system for a quad-rotor on an LPC2106 with single point precision. I was able to run the control loop at 150 Hz with plenty of power to spare.
Thanks for the comments, they were very helpful - I think I will give the LPC21xx a try. They're only $5-$10 more than the ATMegas an PIC's but offer much more wiggle room. This cost difference seems minor given the expense of airframe, sensors, etc..
A few points I can speak about from experience here -
1. You can do a lot of floating point math on a 50-60MHz ARM with just a fixed point ALU - about four times as much as a PIC24/PIC30 per clock cycle. The 8 bit ATMegas will be even slower than the PIC24s. The LPC21xx or a cortex-m3 are pretty powerful chips. Play around with one. The Paparazzi project is one testament to how powerful the LPC chip is - if they can pull off a full telemetry/datalink autopilot on one, so can you. None of the stuff Paparazzi does is too fancy. It turns out you don't need things to be too fancy.
2. You can expect to implement a quaternion MARG sensor at single precision in between five hundred thousand and twenty million clock cycles on a fixed point ALU ARM. It really just depends on your requirements for accuracy and response. If you're trying to control a system that is already pretty stable (high wing trainer) you don't need much - after all, those regularly stay in the air using thermopiles, which aren't very accurate at all. The algorithms with proper names may be optimal, but you can get the job done with much less than optimal filtration. Its probably more worthwhile to get the job done, then worry about how to make it better.
3. The Beagleboard is an order of magnitude faster in clock speed than the LPC or cortex microcontrollers. The architecture provides numerous advantages and you can do extremely fast math with one. A quick google search said the Cortex-A8 it could decode H.264 at 350MHz, which is quite formidable. It is Way Overkill for controling a simple system like a UAV. That OMAP processor also has a DSP on board which can do math even faster than the ARM- signal processing type math (fft and matrix multiply) is about an order of magnitude faster on the DSP than the ARM. If you want to use one because you can run Linux and watch youtube videos and control your UAV simultaneously, cool. If you think you're running into performance issues with one, you're doing something terribly wrong in software. One problem is that Linux isn't particularily well suited for real-time control.
Comments
Also 2106 has no ADC if I remember.
1. You can do a lot of floating point math on a 50-60MHz ARM with just a fixed point ALU - about four times as much as a PIC24/PIC30 per clock cycle. The 8 bit ATMegas will be even slower than the PIC24s. The LPC21xx or a cortex-m3 are pretty powerful chips. Play around with one. The Paparazzi project is one testament to how powerful the LPC chip is - if they can pull off a full telemetry/datalink autopilot on one, so can you. None of the stuff Paparazzi does is too fancy. It turns out you don't need things to be too fancy.
2. You can expect to implement a quaternion MARG sensor at single precision in between five hundred thousand and twenty million clock cycles on a fixed point ALU ARM. It really just depends on your requirements for accuracy and response. If you're trying to control a system that is already pretty stable (high wing trainer) you don't need much - after all, those regularly stay in the air using thermopiles, which aren't very accurate at all. The algorithms with proper names may be optimal, but you can get the job done with much less than optimal filtration. Its probably more worthwhile to get the job done, then worry about how to make it better.
3. The Beagleboard is an order of magnitude faster in clock speed than the LPC or cortex microcontrollers. The architecture provides numerous advantages and you can do extremely fast math with one. A quick google search said the Cortex-A8 it could decode H.264 at 350MHz, which is quite formidable. It is Way Overkill for controling a simple system like a UAV. That OMAP processor also has a DSP on board which can do math even faster than the ARM- signal processing type math (fft and matrix multiply) is about an order of magnitude faster on the DSP than the ARM. If you want to use one because you can run Linux and watch youtube videos and control your UAV simultaneously, cool. If you think you're running into performance issues with one, you're doing something terribly wrong in software. One problem is that Linux isn't particularily well suited for real-time control.