A query to Embedded MCU Gurus:

[Wulffy]

This query is most likely to have many subjective answers...

As such, in the interests of experienced objectivity, I would like to ping those who are Professional Embedded Systems Programmers, who are also UAV/RPV enthusiasts, that have successfully employed their professional skill-sets to arrive at real-world Hobbyist (or Semi-Professional) Level RPV/UAV solutions.

I pose this query in order to try to try to arrive at as meaningful an answer (& guidance) as possible, as it relates to using the many variables present in our operating environment, to aid in arriving at a few key suggestions as to where a new hobbyist in this arena, can begin to narrow down their choices and aid in making a better informed determination, based upon their own skill-sets and aspriations...

What I am looking to determine is what is the best custom embedded MCU/Development System for UAV/RPV use?

Now, I understand that a question simply stated as such would not be very useful at arriving at meaningful responses...

My questions stem from an overwhelming information overload :eek:. I have recently been in search of the best solution for what I have in mind. 20 years ago, there were not that many MCUs on the market, and even less systems that had adequate development tools (my first MCU trainer was an MEK-6800-D2 kit - man, those were the days...). I am finding, now that I have re-entered the quest, that there are a plethora of options that are available. The sheer volume of potential candidates that are available is enough to make one throw their hands up in exasperation, and make a wildly blind (and almost-guaranteed incorrect) selection.

As with my impending project, I am sure that many have gone down a similar path in the (recent?) past of making a determination of which micro to use. Hopefully some of those either currently on this path, or those who have arrived at workable solutions, will find it in their heart to contribute in helping me, and undoubtedly many future persons, to make better-informed choices.

There are some obvious considerations that must be taken into account:

Development Tools/IDE, Digital/Analog I/O, Reprogram-ability, High-Level Math Capabilities (Kalman Filtering, etc.), Processing Speed/Power, Programming Language (ASM, High level, etc.), Size, Price, Power Requirements/Utilization, Modularity/Format (PC/104, etc), etc. etc. etc.

What I have in mind is a platform that will have eventually have the capability to possess the following characteristics:

n(6+) DOF IMU w/ GPS (WAAS/DGPS)
Dead-reckoning with possible VPU (Virtual Position Unit)
2-Way RF Telemetry & Control
Analog Sensors such as Baro, Fuel Qty, Temp, Voltage, etc.
Digital/Discrete Inputs such as RPM, Weight on Wheels, etc.
(Wireless-?) In-Circuit Re-Programmability & Development Tools
Wireless connectivity for Iterative Flight Parameter Definition/Control (Flight Management/Payload Configuration/etc.)
Gimbal'd Sensor Pack with Positional Feedback/Control
n Channels of Video downlink and/or relay
Autonomous 3-D Terrain Avoidance/Following
Autonomous & Dynamic (Flight-Re-programmable) Flight-Path Management (i.e. programmability of the flight plan with way-point parameters that predicate the approach, arrival, and subsequent tasks when arriving at a way-point. Being able to program the Lat, Long, Alt, Speed, Time, Bearing, Attitude (Pitch/Roll), Signature (Acoustic, Thermal, etc.), Station-Loitering Parameters, WPT Sequencing modes, etc.
Programmable Semi-AI Self-Preservation Principles - Autonomous monitoring of endurance vs. mission requirements - i.e. making an informed decision about proceeding or returning when/if requirements exceed capabilities - Point-of-No Return (PoNR) logic for power/fuel/telemetry/etc.
Autonomous Deployment & Recovery
Emergency System's Deployment (Parachute/Floats/EPIRBS/etc.)
I am just looking for some guidance for my obviously overzealous and admittedly extremely-lofty goals. With the right embedded systems on-board, a lot of the desired capabilities detailed above could be distributed to the GCS.

Needless to say, if I accomplish only a small-portion of what I have regurgitated above, it will be quite an accomplishment:rolleyes: . But that is down the road...

What I am needing now is some direction as to which MCUs options one should consider in a basic RPV/UAV embedded computing system...

Thanks, in advance.

-t

[Unterhausen]

I would just pick a processor. You probably are not going to be unhappy if you start out with an ARM. A few years ago, one of the Motorola 68k derivatives would have been your best choice, but ARM seems to have taken over the 32 bit microcontroller market.

[Dan_Jones]

I have worked with PICs, AVR, and now MSP430. I think your feature set has already passed that level of MCUs. It sounds like an ambitious project and it would be a shame to have to switch processors in the middle. So start with a beefy one and you can always downsize later. Right now it looks like you will need at least 64 pins and a variety of peripherals. How many servo inputs and outputs are you expecting as well? Plan on that consuming two internal timers just for the servos. It is very tempting to break out the functionality into different processors, but you will save yourself a lot of time by keeping one single processor no matter what.

[Wulffy]

Unterhausen - Yeah, I hear ya. Before drafting my post, :rolleyes:, I broke down and purchased an ARMmite eval board kit (http://www.coridiumcorp.com/catalog/product_info.php?products_id=58), just to get some exposure to the seemingly very popular MCU. It was only after many hours of trying to arrive at any decision that I did just as I described in my post (threw up my hands are said 'Frak It!' and got the ARMmite from Coridium (http://www.coridiumcorp.com/)).

I was struggling between the ARM and a C-Stamp (http://www.c-stamp.com/) (with a PIC, I believe). I couldn't shake the feeling that I was handcuffing myself when thinking about the C-Stamp, however.

Conversely, with regards to the C-Stamp, I do like the DAC feature, and the IDE seems to be much more capable then that which I have gotten from Coridium's site for their product.

I meekly admit that I have only programmed in lower level languages such as ASM, Forth, and Basic. The learning curve with an OO language such as C is something that I view as an additional hurdle that would have to be jumped as well.

Admittedly, I do feel that the higher level languages would be beneficial in regards to code compartmentalization, Variable/Array functions, and obviously higher level math capabilities.

The nice thing about the Coridium product is that they provide a BASIC interpreter that was coded in C, so when I get comfortable with the hardware, and I feel that the ends will justify the means, I can over-write the Basic Interpreter with compiled C-Code during my C-learing-curve...

Dan (err Dano - a couple of great friends of mine are named Dan(o), and it sounds so foreign to call someone simply 'Dan') - Yes, I would agree with you on all counts. I do have some very-minor questioning on the Single CPU philioshophy, however, I am ignorant so I will just shut my mouth ;-). I am interested in learing a bit more about your approach to controlling servos via the timers.

Thank you both for your time in replying. It is greatly appreciated! -t

[clolson]

This query is most likely to have many subjective answers...

As such, in the interests of experienced objectivity, I would like to ping those who are Professional Imbedded Systems Programmers, who are also UAV/RPV enthusiasts, that have successfully employed their professional skill-sets to arrive at real-world Hobbyist (or Semi-Professional) Level RPV/UAV solutions.

I pose this query in order to try to try to arrive at as meaningful an answer (& guidance) as possible, as it relates to using the many variables present in our operating environment, to aid in arriving at a few key suggestions as to where a new hobbyist in this arena, can begin to narrow down their choices and aid in making a better informed determination, based upon their own skill-sets and aspriations...

What I am looking to determine is what is the best custom imbedded MCU/Development System for UAV/RPV use?

Now, I understand that a question simply stated as such would not be very useful at arriving at meaningful responses...

My questions stem from an overwhelming information overload :eek:. I have recently been in search of the best solution for what I have in mind. 20 years ago, there were not that many MCUs on the market, and even less systems that had adequate development tools (my first MCU trainer was an MEK-6800-D2 kit - man, those were the days...). I am finding, now that I have re-entered the quest, that there are a plethora of options that are available. The sheer volume of potential candidates that are available is enough to make one throw their hands up in exasperation, and make a wildly blind (and almost-guaranteed incorrect) selection.

As with my impending project, I am sure that many have gone down a similar path in the (recent?) past of making a determination of which micro to use. Hopefully some of those either currently on this path, or those who have arrived at workable solutions, will find it in their heart to contribute in helping me, and undoubtedly many future persons, to make better-informed choices.

There are some obvious considerations that must be taken into account:

Development Tools/IDE, Digital/Analog I/O, Reprogram-ability, High-Level Math Capabilities (Kalman Filtering, etc.), Processing Speed/Power, Programming Language (ASM, High level, etc.), Size, Price, Power Requirements/Utilization, Modularity/Format (PC/104, etc), etc. etc. etc.

What I have in mind is a platform that will have eventually have the capability to possess the following characteristics:

n(6+) DOF IMU w/ GPS (WAAS/DGPS)
Dead-reckoning with possible VPU (Virtual Position Unit)
2-Way RF Telemetry & Control
Analog Sensors such as Baro, Fuel Qty, Temp, Voltage, etc.
Digital/Discrete Inputs such as RPM, Weight on Wheels, etc.
(Wireless-?) In-Circuit Re-Programmability & Development Tools
Wireless connectivity for Iterative Flight Parameter Definition/Control (Flight Management/Payload Configuration/etc.)
Gimbal'd Sensor Pack with Positional Feedback/Control
n Channels of Video downlink and/or relay
Autonomous 3-D Terrain Avoidance/Following
Autonomous & Dynamic (Flight-Re-programmable) Flight-Path Management (i.e. programmability of the flight plan with way-point parameters that predicate the approach, arrival, and subsequent tasks when arriving at a way-point. Being able to program the Lat, Long, Alt, Speed, Time, Bearing, Attitude (Pitch/Roll), Signature (Acoustic, Thermal, etc.), Station-Loitering Parameters, WPT Sequencing modes, etc.
Programmable Semi-AI Self-Preservation Principles - Autonomous monitoring of endurance vs. mission requirements - i.e. making an informed decision about proceeding or returning when/if requirements exceed capabilities - Point-of-No Return (PoNR) logic for power/fuel/telemetry/etc.
Autonomous Deployment & Recovery
Emergency System's Deployment (Parachute/Floats/EPIRBS/etc.)
I am just looking for some guidance for my obviously overzealous and admittedly extremely-lofty goals. With the right imbedded systems on-board, a lot of the desired capabilities detailed above could be distributed to the GCS.

Needless to say, if I accomplish only a small-portion of what I have regurgitated above, it will be quite an accomplishment:rolleyes: . But that is down the road...

What I am needing now is some direction as to which MCUs options one should consider in a basic RPV/UAV imbedded computing system...

Thanks, in advance.

-t

Hey! Just add "refuel itself, do all service and maintenance tasks itself, hanger and unhanger itself, assemble and disassemble itself, and charge it's own batteries" to your list of requirements and you could sell one to my boss in a heart beat!

Curt.

[Wulffy]

Hey! Just add "refuel itself, do all service and maintenance tasks itself, hanger and unhanger itself, assemble and disassemble itself, and charge it's own batteries" to your list of requirements and you could sell one to my boss in a heart beat!

Curt. :) ROFLMAO... How is it they say, "Shoot for the stars and hope for the moon?" :rolleyes: Yeah, I know...

I DID acknowledge in my diatribe that what I was purporting was over-zealous (probably one of the under-statements of the century...:p ). Also, a bit of a disclaimer - I said "...capability to possess...", no where did I say I was going to actually try to cram all of that into a single platform. Heck, u gotta have dreams, right? :D

[clolson]

Let me bite here and insert a few of my own comments ... I'm working with a Xbow MNAV and a stargate (or gumstix) as the flight computer, so I'm scaling my expectations and goals around that level of sensor technology and compute power.


* n(6+) DOF IMU w/ GPS (WAAS/DGPS)


Yes, the default xbow code isn't all that great for sensor integration, but we are working on improving it. The MNAV gives you a 3 axis gyro, 3 axis accelerometer, 3 axis magnetometer, gps (4hz), dynamic pressure sensor (pitot tube), static pressure sensor (altitude), and the ability to sense/decode your transmitter stick inputs. Probably equal or better quality than any other mems based package on the market, but the open-source sensor integration code leaves a lot to be desired.


* Dead-reckoning with possible VPU (Virtual Position Unit)


Not sure what you mean here, but solid state gyros are so noisy and crappy that you won't get too far if you lose gps.


* 2-Way RF Telemetry & Control


We are using a maxstream 900mhz radio modem and have observed about 1-1.5 miles range using the default little antennas and with no particular attention paid to doing anything smart. Supposedly if you get smart about directional antennas you can go much further with this hardware. Aerocomm makes a similar product.


* Analog Sensors such as Baro, Fuel Qty, Temp, Voltage, etc.
* Digital/Discrete Inputs such as RPM, Weight on Wheels, etc.


The one limitation of the stargate is that it doesn't really have a mechanism for additional inputs. It does measure it's own battery voltage power and has dynamic and static pressure sensors. But it would be nice to have some sort of fuel qty sensor (even if it's a single trigger when you hit a certain low threshold) as well as additional temps and voltages of other parts of your power system. Let me add prop rpm to your list as well.


* (Wireless-?) In-Circuit Re-Programmability & Development Tools


The gumstix and the stargate both have mechanism to add additional non-volatile storage. The gumstix I have been playing with has a 512Mb MMC card. You could probably put an entire gcc based devel system over there if you wanted to.

Note that I'm programming my software to be ultra configurable with the goal to minimize the need to recompile the onboard code to do simple configuration changes or change autopilot gains, etc. That will all be stored in config files.


* Wireless connectivity for Iterative Flight Parameter Definition/Control (Flight Management/Payload Configuration/etc.)
* Gimbal'd Sensor Pack with Positional Feedback/Control
* n Channels of Video downlink and/or relay


All sounds great ... :-) We have run 2 video channels on one of our aircraft with some success.


* Autonomous 3-D Terrain Avoidance/Following


One nice thing about linking your airborne system into FlightGear is that FlightGear has a pretty accurate 3d world map. So if your UAV is sending it's position, you could extract the local terrain elevation (estimate) from FlightGear and send that back to the UAV.

There are of course more direct ways to do this. Given enough storage, you could load the entire SRTM terrain database onto your UAV and query and do flight planning and virtual terrain avoidance computations right on board. But for a 400Mhz Xscale CPU, I think I'll be happy to just have FlightGear send back the local terrain elevation for the UAV to use.


* Autonomous & Dynamic (Flight-Re-programmable) Flight-Path Management (i.e. programmability of the flight plan with way-point parameters that predicate the approach, arrival, and subsequent tasks when arriving at a way-point. Being able to program the Lat, Long, Alt, Speed, Time, Bearing, Attitude (Pitch/Roll), Signature (Acoustic, Thermal, etc.), Station-Loitering Parameters, WPT Sequencing modes, etc.


When the dust settles here, I will have the ability to create an large variety of autopilot modes that can be individually selected or disabled on the fly.

If I get really ambitious I hope to add a higher level C/Perl-like scripting system. Worst case scenario, I move that to a second gumstix so that I'm not impacting the performance of the core GNC code. But that would allow you (within the your ability to write and execute scripts) to create a huge variety of dynamic higher level behavior. The higher level scripts can then turn on/off and configure the specific autopilot modes to accomplish the higher level (possibly dynamic) objectives.


* Programmable Semi-AI Self-Preservation Principles - Autonomous monitoring of endurance vs. mission requirements - i.e. making an informed decision about proceeding or returning when/if requirements exceed capabilities - Point-of-No Return (PoNR) logic for power/fuel/telemetry/etc.


This also might be an interesting use for a higher level scripting system to run onboard (a second) flight computer.

These higher level management type tasks really seem to be a good fit for a flexible high level scripting language.

I realize that by even seriously mentioning the idea of running a scripting languange onboard a flight computer, 99% of the sane and experienced people here will write me off as a crackpot ... but we'll see! I'll show you! I'll show you all!!!!

:-)


* Autonomous Deployment & Recovery
* Emergency System's Deployment (Parachute/Floats/EPIRBS/etc.)


All good stuff! From a practical standpoint, each one of these points will be a hard fought battle. But with enough time and persistance, it's certainly reasonable to expect to be able to check off a majority of those items. And there are much more powerful flight computers options available ... but the arm processor (i.e. gumstix/stargate) is a pretty good balance of cpu power, size, and power consumption so they seem to be pretty popular these days

Curt.

[Wulffy]

Dead-reckoning with possible VPU (Virtual Position Unit)Not sure what you mean here, but solid state gyros are so noisy and crappy that you won't get too far if you lose GPS.It is a concept that I was introduced to a number of years ago when I received some Allied Signal (Now Honeywell) training on their GNS-XLS Flight Management System. Ditto on the Universal FMS'.

Basically, the position solution algorithms take GPS as their primary inputs and blend in other non-GPS inputs to further refine the position solution. Now, with the accuracy of GPS, the weighting given to the INS, Air-data, and terrestrial based systems (VOR/DME/TACAN/ADF) inputs is very small (with the exception being altitude, of course).

However, in the event of a degraded, or completely invalid, GPS solution, the FMS greatly adds weight to these other inputs and uses a blended solution in deriving the real position, and angular velocities, of the airframe - listening to Attitude corrected accelerometer inputs and Air-data inputs for determining position deltas, and then comparing the new calculated position to that derived when triangulating somewhat dampened terrestrial based inputs to get a 3-axis determination as to the aircraft's true position in 3-D space. Granted, the H/V/P-DOP may be higher than if GPS was functional, but it is better than plain-old dead-reckoning using only heading and air-speed alone...

Furthermore, if a GPS Rx is on-board the GCS, and it does have a valid position solution with an acceptably low H/V/P-DOP, and is capable of tracking the distance & bearing to the airframe, then it's input can also be factored into the ship's position solution, provided that the GCS's position information is fed to the ship's systems, and the ship's systems also have a means of determining Distance and Bearing from the GCS. Heck, the ship's Dist/Bearing information (from the GCS) that the GCS is aware of can even be transmitted with the telemetry/control to the ship.

Yeah, I talked in a bit of a circle in that last paragraph, but I think that I got across what I was trying to...

The software entity, on-board the airframe, that does these calculations, weighting, blending, and reporting is called the VPU. Hope that this helps to explain what I was meaning, and where my thoughts are taking me.

EDIT: It sounds as if the VPU may yet be another cadidate for the scripting approach that you touched on above. Your concept begs serious further consideration. I am glad that we are having this dialogue, so that appropriate planning on the front-end will hopefully serve to reduce the re-writes that will enevitably have to happen as thing mature. With proper source documentation, and code compartmentalization, I think that the inefficiencies could be kept to a manageable level...

[Tom Harper]

Wullfy,

Sounds like you are embarking on a mega-project. One that is more one of system integration than a board level project. For an application that size I would use one of the small PC motherboards. That way you have unlimited resources and a viable operating system.

Worth considering.

[Blue Sky]

I think Tom has the right idea.
PC motherboards intended for automotive AV purposes are small, robust and powerful.
Via has a new 1GHZ Pico ITX in the works.
It measures less than 3" X 4" !
http://www.linuxdevices.com/news/NS2154184680.html

-Dave

[Wulffy]

...Sounds like you are embarking on a mega-project...Nah, just a LONG journey with many stops along the way. I believe that it is not the destination that truly makes the journey a memorable experience...

I think Tom has the right idea. PC motherboards intended for automotive AV purposes are small, robust and powerful...Tom & Dave - Regarding your platform suggestions, both of your comments are appreciated and well taken. I think that if I were to start out trying to tackle the whole darned thing at once, with full-blown PC architecture, that I would end up being unsuccessful, becoming over-whelmed, and having the project slowly loose interest as there would be no mini-victories. I have found that I have to have some fun mixed in with the work, in order for it to continue to hold interest for me...

As such, I am going to get re-acclimated with low-level interface and control with some imbedded MCUs (and experience a few small victories :) ), the selection of which will be partially driven by the response herein.

If I ultimately don't go with an imbedded system, but rather a more 'main-stream' approach (which BTW, I am somewhat more skeptical about from a weight/power/OS overhead perspective), I have placed in the back of my mind, a post-it-note to seriously consider the PC/104 architecture with a fault tolerant low-overhead RTOS with the applications possibly being coded in a lower level language such as Forth or, of course, ASM.

It appears that this combination of hardware/os/application development language could yield a result that is small, extensible, and potentially really reasonable as it relates to cost vs. benefit. Again, I admit that I do not have enough of the knowledge or wisdom that I need to make the right decision ... yet...

Thanks for taking the time to offer your input. It is appreciated.

-t

P.S. Regarding Forth - I have done just a small bit of Forth coding in the past - it is one of those things in the world that fills a near-perfect niche between the most basic way of doing something (i.e. ASM/Mnemonics), and the easiest way (a high-level (OOP) language such as (Visual-)BASIC/C(++)/LISP)). Quite often the results can be the more elegant than if it was done either at the lowest or a higher level. There are plenty of sites out on the web (www.forth.org (http://www.forth.org/) being one), in case I have peaked anyone's curiosity...

[Wulffy]

...When the dust settles here, I will have the ability to create an large variety of autopilot modes that can be individually selected or disabled on the fly.

If I get really ambitious I hope to add a higher level C/Perl-like scripting system. Worst case scenario, I move that to a second gumstix so that I'm not impacting the performance of the core GNC code. But that would allow you (within the your ability to write and execute scripts) to create a huge variety of dynamic higher level behavior. The higher level scripts can then turn on/off and configure the specific autopilot modes to accomplish the higher level (possibly dynamic) objectives.

This also might be an interesting use for a higher level scripting system to run onboard (a second) flight computer.

These higher level management type tasks really seem to be a good fit for a flexible high level scripting language.

I realize that by even seriously mentioning the idea of running a scripting languange onboard a flight computer, 99% of the sane and experienced people here will write me off as a crackpot ... but we'll see! I'll show you! I'll show you all!!!!...

Curt, If you decide to go down the road of building a scripting infrastructure, I'd like to recommend that you take a peek at Forth, for consideration. At the bottom of this page (http://www.forth.org/compilers.html#Embedding), they have a few imbeddable compilers developed specifically for the purposes of what you eluding to in the above:

"These compilers can be used to create ordinary Forth systems but their real strength is their ability to be built into a C/C++ application as a scripting language within the application"

[tomp]

I've been looking at higher performance micro's for work and I've convinced management to switch to one of the NXP LPC2000 series processor. The 2000 series is based on the ARM7 (32 bit) and they've really come down in price to the point where it makes a lot of sense to upgrade one of our products that are now too overtaxed in its tasks. Free development tools are available (too many people forget about development tools), but I've read where they aren't as good as the ones you pay for in terms of compiler efficiency. Inexpensive development boards are also available.

That's my recommendation.

tom
p.s. Sorry, but for some reason this really bugs me: I consider myself an "embedded" design engineer. Although "imbedded" is just a variation of "embedded", it just doesn't look right! It looks too much like "imbibe"!! :rolleyes:

[Wulffy]

I've been looking at higher performance micro's for work and I've convinced management to switch to one of the NXP LPC2000 series processor. The 2000 series is based on the ARM7 (32 bit) and they've really come down in price to the point where it makes a lot of sense to upgrade one of our products that are now too overtaxed in its tasks. Free development tools are available (too many people forget about development tools), but I've read where they aren't as good as the ones you pay for in terms of compiler efficiency. Inexpensive development boards are also available.

That's my recommendation.

tom
p.s. Sorry, but for some reason this really bugs me: I consider myself an "embedded" design engineer. Although "imbedded" is just a variation of "embedded", it just doesn't look right! It looks too much like "imbibe"!! :rolleyes:Thanks so much for the reply. I have a inexpensive and simple NXP LPC2103F based eval board that i just got my hands on. It is the ARMmite from Coridium. It is nice getting back into micros - it has been too long...

Regarding your quirk, I have fixed it... :rolleyes:

[Wulffy]

...Free development tools are available (too many people forget about development tools), but I've read where they aren't as good as the ones you pay for in terms of compiler efficiency...Tom, If you could please take a moment and advise what information you have regarding the free (& low-cost) development tools that you are aware of for the NXP LCP210x series, I would greatly appreciate it. TIA.

-t

[tomp]

Tom, If you could please take a moment and advise what information you have regarding the free (& low-cost) development tools that you are aware of for the NXP LCP210x series, I would greatly appreciate it.TIA.-t

I'm not at work and that's where most of the info is saved. From what I can remember, the compiler that is free (but might not be the most efficient from what I've heard) is the GNU ARM toolchain: http://www.gnuarm.com/ I once looked at installation procedure and it was pretty complicated. But it is free and actively updated. Maybe it's easier for Unix geeks.

Another option is to download IAR's ARM Kickstart, which is a free version of their Embedded Workbench development environment. The free version doesn't handle all the NXP LPC2xxx parts, and it's limited to a max of 32K of code-space (plus a few other limitations). I've used their 8051 version for work and like it. The dev kits are at: http://www.iar.com/kits

I was intrigued by the Coridium ARM kits, since they offer BASIC for it.

tom

[MX]

For my WPS2 work, I got the LPC2138 board from www.embeddedartists.com. They include a CD that has a GNU based toolset built and ready to install. I've also programmed the LPC2138 and LPC2106 with the Keil ARM tools - not cheap, but the IDE incorporates the compiler/assembler/linker and debugger. The Keil ULINK JTAG emulator works with it too.

MX

[treehog]

@ blue sky
thanks for the link
http://www.linuxdevices.com/news/NS2154184680.html

if somebody k nows more about this one let me know

I prefer to have too much computer power than to little

1ghz is very interesting

pity the price looks to be probably $350 plus

any body with info mayby start a thread on it

Ralf

[Blue Sky]

Hi Ralf!

The 1ghz isn't as meaningful as the fact that it has enough power to perform some
"hard" AI tasks and there is alot of AI software already developed to run on small PC's.
The mini ITX is a popular board for use in autonomous robots. The nano ITX is it's successor and the pico will be smaller still. There are a number of diffrent mini ITX
boards. Within the VIA family, at least, the chip sets are fairly consistent.
I recently found a 1ghz nano ITX board on sale for 199.00. It measures a scant 120mm X 120mm and draws less than 20 watts when running full tilt. It defaults to a low power mode when it isn't busy.
The main reason I brought this up is because UAV's are really nothing more than flying robots.
As for me, I don't really want nor do I have the time or possibly the talent to build a
large UAV.
What got me into the UAV scene is the desire to use an autopilot as a failsafe mechanism for my AP planes.
This in turn has rekindled my interest in robotics. I've been an electronics hobbiest for many years.
If I get back to work on larger robots I'll probably keep them on the ground for now.
I'll post some links for you later.

-Dave

[treehog]

AP for me too nothing to big sub 5kg mostly 2kg

Relly all i want is enhanced RC flying with terrain avoidance AI that will stop plane letting me commence a lawn dart manover :eek: all within visual and RC range :D

I dont want to be doing umpteen board iterations so prefer to have way overkill process power so I can add on without to upgrade boards to often

Also the gear would do surface robotics which i also want and need

Ralf

[Blue Sky]

You're probably familiar with the FMA Copilot.
It may be all you need to keep from lawn darting.
You've probably seen it used around here as part of an
autopilot on simple UAV's. It can't hurt to have one.
You could always use it as part of a larger system.
http://www.fmadirect.com/
The new propeller chip development board from Parallax
is on sale for an amazing 19.95. I just ordered two to play with.
http://www.parallax.com/detail.asp?product_id=32212
I like the Pic Axe chips for simple projects.
They're dirt cheap and they can be programmed with a 3 wire hookup
right off your serial port. They make writing software for most rc projects
bonehead simple. The free programming software is bug free and easy to use.
http://www.rev-ed.co.uk/picaxe/
Here is some PC robotics stuff for you:
http://oap.sourceforge.net/
http://www.ai.sri.com/centibots/tech_design/robot.html#vsbc-8

-Dave

[Wulffy]

...I was intrigued by the Coridium ARM kits, since they offer BASIC for it.

tom

Actually, ARMbasic has come a long way in the last couple of weeks. See the following copied from this thread (http://www.rcgroups.com/forums/showthread.php?t=672136). I recommend that someone not quickly dismiss their product line, when looking for an embedded control solution...


Have any of you guys tried this development kit from coridium?...

Actually, I have gone radio silent here for nearly a month. The reason is that I am heavily into coding up a project using Coridium's Products (http://www.coridiumcorp.com/Products.php).

I have the horizontal navigation stuff working - not as well as I'd like, but none-the-less working. It appears that I am getting sub-meter (~.1% with respect to GPS-reported position) accuracy with my navigation solutions, when the waypoint distances are closer than ~15KM. When the distances are greather than that, the accuracy degrades. Angular accuracy for Desired Track/Course is accurate to .1 degrees, I believe (rolling tests have confirmmed).

I have also successfully demonstrated simultaneous control of 5 Futaba Servos using the hardware - more is very feasible.

I must say that I have had tremendous support from the principles at Coridium. I have worked with them over the last couple of weeks to refine the IDE.

My source-code is here (http://tech.groups.yahoo.com/group/ARMexpress/files/UAV_Project_Files/). It is VERY MUCH A WORK IN PROGRESS, and is in dire need of having the comments cleaned up. I have just came to the realization that I will most likely need to integrate a Floating Point Unit in order to get the GeoNav solutions truly working the way that I want. More on that in a minute.

The GPS module that I am using is the USGlobalSat EM-411, however, with the code, I am confident that it can be altered to parse any NMEA GPS receiver. The EM-411 is a 1hz unit. I will eventually get a 4+ Hz unit as the production module of choice. I have configured and am successfully parsing the GPS sentences that are being transmitted at 115.2K.:D

The latest ARMbasic IDE software has just been released yesterday (and he was kind enough to throw a thanks my way for all of the effort). It allows for pausing the source code execution, looking at variable contents, and resuming execution.

Regarding the FPU. Today I have spent several hours researching and I have made a selection. The unit I will order is the MicroMega uM-FPU-v3 (http://www.micromegacorp.com/umfpu-v3.html). It seems that it may actually have its roots in a project similar to what I am involved in. Regardless, it seems to be the best solution for an embedded FPU coprocessor. It will also allow for me to dump some of my horribly inefficient code and be able to focus on the main application functionality and not worry about developing integer based navigation algorithims...

Regarding the IDE - the Coridium product line can be either ARMbasic or C. With the latest enhancements, ARMbasic has a much friendlier Development environment cycle than what C does, at the moment. Coridium is also looking to enhance the debugging capabilities of their IDE further, as well.

I'd recommend evaluation of their hardware in any embedded control application. The true value is that one doesn't have to pay a penalty for a learning curve if they already are comfortable with BASIC...

I hope that this helps.

Have a good one!

-t

EDIT: Oh, one thing to note is that I am planning on using both an ARMexpress and an ARMmite. The 'mite will be my Airframe Interface/Flight Data Acquisition Unit/Flight Data Recorder (see the data logging thread on Coridium's yahoo group). The 'express will be interfaced to the telemetry transceiver, the 'mite, the FPU, and other nodes of the system. The 'mite is based on the NXP LCP2103F MCU. While having a nice set of I/O capabilities, it does not have the memory that my application will be needing. This is why I have also secured a NXP LCP2106F based 'express and am using that as the Master with the 'mite/FPU/etc. being Slaves. I am also working to determine if I want to use I2C or SPI as the communication medium between the Master/Slave modules. I'll attach a picture in a minute...

[julian@astro]

To throw my two cents in

These are very good for the price
http://www.gumstix.com/

and at least there is a pretty big knowledge base for them

You will need an interface board(s) to your sensore, but at least that sorts out perhaps ypur higher level functions

Julian

[Wulffy]

...

I have the horizontal navigation stuff working - not as well as I'd like, but none-the-less working. It appears that I am getting sub-meter (~.1% with respect to GPS-reported position) accuracy with my navigation solutions, when the waypoint distances are closer than ~15KM. When the distances are greather than that, the accuracy degrades. Angular accuracy for Desired Track/Course is accurate to .1 degrees, I believe (rolling tests have confirmmed).

...

My source-code is here (http://tech.groups.yahoo.com/group/ARMexpress/files/UAV_Project_Files/). It is VERY MUCH A WORK IN PROGRESS, and is in dire need of having the comments cleaned up. I have just came to the realization that I will most likely need to integrate a Floating Point Unit in order to get the GeoNav solutions truly working the way that I want. More on that in a minute.

...

Regarding the FPU. Today I have spent several hours researching and I have made a selection. The unit I will order is the MicroMega uM-FPU-v3 (http://www.micromegacorp.com/umfpu-v3.html). It seems that it may actually have its roots in a project similar to what I am involved in. Regardless, it seems to be the best solution for an embedded FPU coprocessor. It will also allow for me to dump some of my horribly inefficient code and be able to focus on the main application functionality and not worry about developing integer based navigation algorithims...

...


Woo Hoo! I have received the FPU. Upon integrating it with the dev system that I am working on, and modding the source to work with the FPU, I am now getting accuracy errors with the Great Circle navigation on the order of <0.0001% for distance and course to next waypoint (with respect to reported GPS position).

Furthermore, with the FPU handling the nav math, I have been able to demonstrate that the code should work from/to any point on the planet - i.e. even across the Equator or the Prime Meridian.

I am using the information and formulas compiled by Ed Williams. The various Aviation-Related Great Circle math formulas are detailed here (http://williams.best.vwh.net/avform.htm). My ARMbasic source here (http://tech.groups.yahoo.com/group/ARMexpress/files/UAV_Project_Files/) has been updated. Now I can move onto the vertical navigation algorithms and other functionality (Has anyone found a cheap 6-DOF IMU yet?:confused: )

Regarding the FPU, I need a grin-ectomy... :D

EDIT: Be advised that if you are planning on using the FPU code I have available for d/l, you will want to obtain the latest IDE. The uM-FPU IDE v1.2 is NOT the version that you are wanting. During my efforts to implement the Great Circle nav algorithms, I discovered a bug is v1.2 that has to do with multiple argument functions. The latest IDE is still in beta, but appears to resolve the bug and also adds support for code generation for ARMbasic (what the ARMmite and ARMexpress use). Until such time as Cam sees fit to put the latest IDE up on the uM-FPU website (http://www.micromegacorp.com/index.html)for download, and you are too impatient:), hop on the uM-FPU Yahoo Group page (http://groups.yahoo.com/group/uMFPU/messages) and put a request into him to provide the beta to you. I am sure that he will be placing the latest version up for download on the FPU website when he feels comfortable that it is indeed functioning as expected. Good Luck and Have FUN!!!

-t

[shanghai_fool]

Mr. T,
Just wondered if you are still happy with the ARM? I have asked in another thread (http://www.rcgroups.com/forums/showthread.php?t=752440) about possible MCU's and have come up with the AT91SAM7A3 version due to more I/O pins. Just wanted to know if its quick enough to do what you wanted and more?

Very interesting thread BTW.

Donald

[zik]

Unlike most of the other AT91SAM7 processors the AT91SAM7A3 doesn't have the SAM-BA boot loader on board. This means you need to use JTAG to program it at least once. This was enough to turn me off it since I wanted to avoid JTAG.

[shanghai_fool]

I thought the Jtag was necessary for ICE and debug. Is that not correct?
In any event, I need the 32 I/O pins that are not shared. This seems to be the problem with most of the devices I have looked at. They all have numerous peripherals but when you examine them closely, maybe half can be used as they share the same pins. This gets very frustrating.

[Wulffy]

SF & Zik - Thanks for reviving the thread. It is good to see that others are still reading & trying to glean guidance from herein.

SF - The 32 non-shared GPIO device that you are requiring is going to be a bit of a Challenge, I suspect.

To answer you previous question directly, I am extremely please with the ARM7-based Coridium devices that I am using.

IMHO, the Coridium products are quickly becoming not only the fastest compiled (NON-interpreted) BASIC devices out there (60MHz clock executing code @ up to 10MIPS), but also the easiest to implement as the ARMbasic language is continually being built upon month after month.

The latest enhancements bring functions/sub with parameters to the table. The next enhancements being discussed are broadening the scope of String Handling to rival VB's string handling/manipulation (important with text based devices such as GPS and GHI Electronics' uAL-FAT (http://www.ghielectronics.com/products.php) (A FAT-32 USB/SD/uSD MS-DOS solution)). Yesterday, I received a Beta of the compiler that includes the first pass at this enhanced string functionality - it has a bug or two, but will be resolved in the coming week.

ARMbasic is SO EASY to pickup on, and is quite powerful. Many look at many different BASICs and think, 'hmmm, a grade-school level development environment', but conversely, ARMbasic is starting to be able to rival the functionality of C (without OOP), yet be very easy to pick up on, not having to worry about class/scope/etc. if one doesn't want to, yet being able to support local and global scope, if one is more comfortable with that implementation...

Some of the other enhancements that are on the radar are Hardware Interrupt support for BASIC (EINT1, EINT2, & Timer Interrupt) which will allow a user to code up RTOS support, Hardware Timers, Floating Point Math, etc. I suspect that Float will be next, after the String Handling is refined, but that is a bit of a look into a crystal ball, ya know. Personally Floats are low on my list as I have been using MicroMega's uM-FPU for my number crunching. The Floating Point Co-Processor allow a bit of parallel processing and offloads the number crunching algorithms and allows the host MCU to carry on with other tasks while the FPU does the math. The parallel processing is a nice benefit that, if making use of native float support on the host MCU, would not be 'realizable'.


Speaking of parallel processing, this is a good segue into the next point you made, SF, regarding desiring a single device with many independent GPIOs. Why not consider having a couple of MCUs?


Having to code a single host MCU with an entire Free-Flight OS will lend itself to yielding an application that possess' a plethora of integrated spaghetti code.


Now, let me qualify that a bit before someone goes to break out the torches to flame away: a few months ago, ARMbasic was upgraded to include the functionality of a Preprocessor. Basically, the implementation of C's CPP.exe/CPP0.exe was realized. What this now allows is to have source code neatly packaged into logically separated library files. This has been a tremendous aid in easily realizing and maintaining logical/functional code segregation.


With that, it also serves to drive leveragability of existing code modules, provided facilities for driving same were coded into the software modules, or if existing are modified to make use of conditional-compiling macros features and makes use of some well-thought-out #defines.

I have also come to realize that non-hardware-based code debugging is greatly simplified with the #inclusion of library files that are written to facilitate broadened debugging functionality.

I digressed a bit there to make a point: As is the case with code segregation, if a user was to break up functionality of an application across multiple pieces of hardware, a couple of things take place - First and foremost, the # of dedicated GPIOs are increased, and parallel processing efficiency is realized.

Now, one could argue that the splitting of high-level functionality across a couple of host MCUs comes at a price, and that it true. Hardware costs are obviously increased. Also, having to have a programming and development infrastructure that serves to minimize redundant effort is important. Another 'cost' is having to have a target-end-system 'infrastructure' that supports, and serves to yield, maximum leveragability of the increased horse-power. Simply throwing a 2nd MCU host at a problem rarely, if ever, will yield a two-fold increase in 'Productive-MIPS' (if that makes sense).

One of the challenges I have had in my multi-MCU platform (implemented for the EXACT Reason that I wanted MORE IO [and increased horse-power ;)], has been figuring out how to multi-task independently of one-another, yet arrive at a 'solution' where each MCUs operations maintain maximum throughput individually, with the net result being that both MCUs ARE working in a coordinated fashion each solving their own portions of the 'equation' and having said efforts combined in a efficiency-improving, and net-result increase, that justifies the additional tangible and non-tangible expenditure of 'resources' - in terms monetary, effort (infrastructure/code dev), and time. I am implementing a hardware based solution, that once completed, should serve to drive these improvements...

It has been my recent experience that the single biggest inefficiency inducing element is the inter-MCU communications. To have to halt 'productive-MIPS-expenditure' to facilitate information/command transfer from one MCU to the other, could effectively take focus away from both MCUs for the period of time that said Communication & Command transfer (C&C xfer) was to be effected. If one of the MCUs was in the midst of effecting a time critical event (such as updating servo pulse-widths or in the middle of a communications event with an SPI slave), then either the sender has to wait until the intended recipient is ready to receive the C&C xfer, or the recipient has to halt it's activities and respond in a timely fashion to the C&C xfer event request, in order to minimize Productive-MIPS impact. I am sure that you can extrapolate that there could be some pretty pricey delays in having to effect inter-MCU C&C xfer, unless some obtuse timing mechanism is implemented, or other esoteric solution is effected (such as having only one host servicing critical functionality, and it being the initiator of the C&C xfer).

As a frame of reference, it is my belief that SPI is faster than I2C and 'RS-232' serial. Granted it comes at a price of more GPIO, but that is a price I am willing to pay, with the result being increased efficiency, and more horse-power from having two MCUs working independently, yet together, to reach a common goal. What I propose, and am working with other's to implement, is a Multi-Master, SPI-based, Shared Memory solution. What this will do is to allow both (or 3 or 4...) MCUs to work their tasks at the highest possible rate, and when ready to effect a C&C xfer event, 'touch' the shared memory to effect a C&C xfer event, independent of the other Peer MCUs in the system. The net result is that either master can push & pull data from the shared memory at a iteration rate that independent of any other MCUs activities/location in their control loops, and at a data xfer rate that is limited only by the interface speed capabilities between the Master and Shared Memory Device. I could go on and on here (and I have in other threads/forums), but I won't as that horse is bloody enuf (in my mind) and frankly I feel that I'd be wasting my time in being redundant.

It is my totally unsubstantiated SWAG that, when my design matures, I will see a net performance increase, via the use of two MCUs, with the Shared-Memory solution, on the order of 1.8-1.9. This comes at an initial price in terms of development and hardware costs, but is worth it to me as if I were to SWAG a net increase in just using two MCUs and having to communicate directly between them, that I'd see a net increase only on the order of 1.4 to 1.6, and run the risk of having timing issues that could have catastrophic results.

The whole point here is that I feel that you would be remiss if you did not consider a multi-MCU solution to your GPIO (& processing power) needs. Furthermore, I respectfully suggest that you consider the use of products offered by Coridium Corp (http://www.coridiumcorp.com/Products.php), and MicroMega Corp (http://www.micromegacorp.com/products.html). Both organizations are very ACTIVELY DEVELOPING/REFINING their products, are VERY RESPONSIVE in considering requests/suggestion, provide TOP-NOTCH SUPPORT, have GOOD DEVELOPMENT ENVIRONMENTS, come in a number of packages, and are FAIRLY PRICED. (No, I am not on either's payroll... :D)

Feel free to PM/email/Reply for further details. I can be emailed at Tod dot Wulff at comcast dot net OR Tod dot Wulff at inbox dot com.

Thanks for reading the diatribe. Have a good one. Fly safe!

-t

[Wulffy]

Mr. T, ...I have asked in another thread (http://www.rcgroups.com/forums/showthread.php?t=752440) ...

Very interesting thread BTW.

Donald

SF, you will want to fix the link to the other thread - you copied the 'report post to moderator' link, not the post's link... :D

Thanks on commending on the nature of the thread. I like to think so, too! :cool:

-t

[shanghai_fool]

WOW!
Great info t. At this point, I am dismissing nothing. Single CPU is just desired simply for the reasons you presented so well. It also may go to multiples, especially in the case of the MPU addition. As far as Coridium is concerned, I looked at them but they were only offering the "reduced pinout" versions of the Arm. I certainly will, however, consider the compiled basic for the "meat & potatoes" part of the solution. I think a "mixed" language concept is a very viable solution. Even C uses asm for some places where speed and timing are a factor. The I/O interrupt structure is particlularly where asm should go and do the number crunching and other logic in a much easier to use language. I especially like basic as that was my second language back when.

My intended selection of that particular main CPU is the additional I/O pins. I wanted a "shell" where at least all the receiver outputs could be looked at simultaneously. Without timing "sensitivity" on those inputs, I feel you cannot get the resolution needed to keep jitter to a mininum. If I can live with 14 in and 18 servos out, it would be nice. It is much easier to add servo outputs though. I also wanted to be able to use the plethora of other devices already on the chip such as 10 bit A/D, SPI, serial, etc. I can already see that I will probably add a higher resolution A/D chip for some sensors.

The ARM was not my first choice as it needs a lot of massaging just to get started (clocks , etc). I thought I could do it simpler but to make a universal framework, it just needs a 32 bit cpu. I'm not married to anything yet so I will take a look at anything else that some of the very smart and resourceful people on this forum may throw at me. I'm only smart enough to know when someone makes a good point, to listen good. I'm going to try and see what is available here tomorrow and get to breadboarding and testing. Its been a week long holiday here so not much has been open.

Thanks again Tod and I fixed the link above.
Donald

[zik]

Hi shanghai_fool,

I do programming and debugging via USB. The debugging is limited to printf()-style debugging but that works well for me.

Incidentally if you want more I/O you could consider the AT91SAM7X series. OTOH they have 62 GPIO pins. I'm using one in my other autopilot (ie. not the Flying Fox one).

Cheers,
Zik

[shanghai_fool]

Incidentally if you want more I/O you could consider the AT91SAM7X series. OTOH they have 62 GPIO pins. I'm using one in my other autopilot (ie. not the Flying Fox one).

Cheers,
Zik

Maybe I'm missing something but it looks to me like the 2 32 bit ports are partially shared with internal devices.

[zik]

Maybe I'm missing something but it looks to me like the 2 32 bit ports are partially shared with internal devices.

Yes, for sure. But let's say you wanted to use about 30 pins worth of internal peripherals and have 32 GPIOs also available then it would do exactly what you want. You just assign the ports how you want. Am I missing something here?

You don't need the internal peripherals to be separate from the GPIOs as long as you get access to enough of both, right?

[shanghai_fool]

Actually, looking closer, it the same on both devices. the 7A3 has portA (32 bit) and portB (30 bit) that shares functions. The 7X has 2 - 31 bit ports.

It looks like If I use portA for direct I/O, I give up SPI and serial ports which I don't want to do.

I could split the I/O but I really want the 14 inputs together sequentially for faster interrupt handling. i.e. A single high input can give a direct memory offset into storage location.

I will do further research and see if I can come up with a part that gives more options. I really want the I/O, A/D, SPI, & serial if possible. I am also limited to flat pack as I don't think I can breadboard a ball grid chip. I have read of it being done on an electric skillet but I'm not that brave (or lucky).

[Wulffy]

WOW!
Great info t.

...
If I can live with 14 in and 18 servos out, it would be nice. It is much easier to add servo outputs though. I also wanted to be able to use the plethora of other devices already on the chip such as 10 bit A/D, SPI, serial, etc. I can already see that I will probably add a higher resolution A/D chip for some sensors.
...

Thanks again Tod and I fixed the link above.
Donald
Thanks. You're welcome.

Just curious, am I understanding things correctly in interpreting that you are going to use 14 of the GPIO pins to 'listen' to 14 servo inputs?

(I qualify the following with a disclaimer - I haven't yet done this, but I understand that it is easily done.)

If so, have you considered hacking a receiver, grabbing the PPM signal before it is demux'd internal to the RX, and running said PPM into a single input on an MCU, to listen to all of the servo timing signals via a single GPIO line?

It is how the papparazzi project does it on their platforms. More info can be obtained here (http://www.recherche.enac.fr/paparazzi/wiki/index.php/Other_Hardware).

Also, MaxVTOL has also done just that and will have his airframe working reasonable well (once he gets a new BEC! :)) - check out his efforts (http://www.vertiplane.com/index.html):

http://www.youtube.com/watch?v=GLMoKYmFsLY

[shanghai_fool]

Thats the whole point. I DON'T want to hack a receiver. I want to be able to just plug in ANY receiver including PPM, PCM and whatever the 14 chan. radios use. The "14" is just thats where we are now in terms of available systems. There may be more in the future. basically, a "black box" in between receiver and servos that can do whatever we want. Additional I/O for sensor inputs (A/D), other I/O (SPI) and serial (GPS, Display, tx to ground data and/or video). Internally, you can mix any inputs to outputs and do whatever scaling, ATV, reversing, etc.

I have followed Max and others especially in the UAV and AP forums. The problem is they are very defined as to their purpose and are only usable on certain systems.

This quest is just for a universal I/O handler that any or all these other solutions can be incorporated into. I like all the ideas I've read here. Its just too many boxes. Maybe it can be simplified. Its more like a desktop PC for R/C. It handles the I/O and you can run any application inside. The applications can be anything from mixing to logging to autopilot or anything else it has the horsepower to do all at the same time. I have thought about the single board computers but they have too much of what we don't need and not enough of what we do. Instead of disk drives, printer ports, video monitors etc, we need barometric pressure sensors, current, voltage and temperature sensors, gyros and accelerometers all on the motherboard and let everyone use them for their own purpose.

I have many of the devices so now I have too many wires and some work well together but others don't and there are still things I want to do.

Maybe it just a dream but I wont know until I try.

[shanghai_fool]

Yes, for sure. But let's say you wanted to use about 30 pins worth of internal peripherals and have 32 GPIOs also available then it would do exactly what you want. You just assign the ports how you want. Am I missing something here?

You don't need the internal peripherals to be separate from the GPIOs as long as you get access to enough of both, right?

You can't access both. For example:

In the AT91SAM7A3 Port B bits 14-29. They use the same pins as the A/d converters. You can't use them for both at the same time. In both the devices, the pins can be used in multiple ways but not at the same time. Most of the pins will have a connection to a single source or destination so unless you use an external multiplexer to switch them (which you can't do for most things), you have to decide what you want to use them for.

[zik]

I think you may find it difficult to find an MCU of this size which doesn't multiplex its internal peripherals with GPIOs. Alternatively you could just use an ordinary LPC or a SAM7 and write a few extra lines of code to handle the I/O line individually. This is the way people usually do it.

Good luck finding a solution!

[hg1]

I'm jumping in here a bit late, but wanted to add a few observations...

I have done a lot of work with the NXP LPC2106, and I really like the processor, but found that it just didn't have enough horsepower or memory for some of our robotics requirements, including higher resolution real-time image processing. I looked at a number of alternatives, including ARM9 on Gumstix and Compulab, TI DaVinci, x86 derivatives, faster ARM7's, etc, but ended up choosing a processor from Analog Devices called "Blackfin".

Analog Devices isn't known for general purpose computing architectures, but they teamed with Intel on the design, so there's a 32-bit RISC core with dual ALU's for fast parallel numeric processing. The particular Blackfin I'm using is the 500MHz BF537 which actually burns 1000MIPs because of the dual ALU (they also build a dual-core version - BF561 which is rated at 2400MIPs). The BF537 processor has some very nice i/o features, including a built-in digital video interface, SPI, I2C, JTAG, etc, etc, but the power consumption is VERY low - comparable to the ARM7. We built our own board with a camera interface for our robotics applications (see http://www.surveyor.com/blackfin/ ), but it's starting to get integrated into some UAV applications as well.

There are a couple of software development approaches to the Blackfin. One approach is to use Linux, similar to the Gumstix or Compulab. There's an active community supporting Blackfin Linux here - http://blackfin.uclinux.org , and a variety of scripting options are available, including Python. The other approach is to run code on the "bare metal", using the GNU bfin-elf toolchain to build code. We're supporting both approaches.

I am seeing a lot of robotics activity around the Gumstix, and it definitely represents the right level of computational capability in the next generation of robotics controllers. We chose a slightly different path with the Blackfin, though the concept is similar, and the more I work with the Blackfin, the happier I am with our decision.

As regards the requirements for navigation-specific interfacing, I don't see a way around adding a separate processing unit to interface to the IMU, altitude, ranging, speed, compass, and whatever other flight sensors (having purchased all of the above from Sparkfun and others to experiment). There are a number of projects addressing this specific goal, and I expect there will be some attractive alternatives within 12 months.

[shanghai_fool]

I hope Tod hasn't forgotten this thread. He should be very far on the path by now. After much disapointing experimentation with interrupts, Myself and others have concluded that it is NOT the way to go for universal receiver capability. We are going to the FPGA approach for the basic receiver input/servo output. I have still decided to marry the FPGA to the ARM AT91SAM7A3 because of all the peripherial support. I did provide a socket for the uFPU that you suggested but have not yet tried talking to it. I think this chip will work very well for the main stabilization and logging part. You are probably right about needing a higher CPU for long distance but that is not in my immediate future. My first attempt at prototyping required 2 boards 65mmx100mm stacked. I think it will be hard to get all the I/O and multiple CPU's in a small enough package. Just the connectors take lots of space.

I looked at all the suggestions made here and everything has pros and cons. The Blackfin looks nice but BGA is not on my capability list. I have enough trouble with .5mm spacing on some devices. I think that just getting the elaborate mixing and sensor/data logging will be as much as I can do.

I hope you will start a build log for any devices you have chosen to use.

Donald

[hg1]

I looked at all the suggestions made here and everything has pros and cons. The Blackfin looks nice but BGA is not on my capability list. I have enough trouble with .5mm spacing on some devices. I think that just getting the elaborate mixing and sensor/data logging will be as much as I can do.
Donald
Donald - fyi, the Blackfin BF-532 comes in an LQFP package, though it's really not something you would want to try to solder by hand.
Howard

[shanghai_fool]

I did look at that but it only has 16 GPIO pins which would severly limit the I/O. Also requires separate memory. Not good for mininum part count. I think the Gumstix would be a better choice for this much power.

[hg1]

I did look at that but it only has 16 GPIO pins which would severly limit the I/O. Also requires separate memory. Not good for mininum part count. I think the Gumstix would be a better choice for this much power.
Be careful not to compare apples and oranges. The Gumstix is a processor card that includes an ARM9 processor and lots of memory. The Blackfin is just a processor which actually has quite a bit more computing power than the ARM9 at comparable clock rates. Here are some examples of small Blackfin-based processor cards (note that my company builds the first one) -

http://www.surveyor.com/blackfin/
http://www.camsig.co.uk/products.htm
http://www.hvsistemas.com/en/prod/H8606.html

[zik]

Hi hg1,

The blackfin is a great device - in fact I'm using it for a non-UAV-releated project I'm designing at the moment. You're right in saying that the blackfin has great processing power. But unfortunately that doesn't make it a good processor for a UAV.

The blackfin has a rather special architecture. It's a DSP (digital signal processor) with a conventional processor core added on the side. It's brilliant for things like audio processing or image processing. These are the kind of applications it's intended for.

You have to keep in mind that it's a special purpose processor. If you want to do lots of image processing on your UAV it'd be a great choice for the image processing work, but probably not for the flight computer. For that I think you'd be better served by a general purpose processor.

I think if you used the blackfin on a UAV you'd find that the vector-based design would result in disappointing performance in this non-vector task. It'll work, it just won't work well.

Cheers and best of luck with your project,
Zik

[hg1]

Hi hg1,
The blackfin has a rather special architecture. It's a DSP (digital signal processor) with a conventional processor core added on the side. It's brilliant for things like audio processing or image processing. These are the kind of applications it's intended for.

You have to keep in mind that it's a special purpose processor. If you want to do lots of image processing on your UAV it'd be a great choice for the image processing work, but probably not for the flight computer. For that I think you'd be better served by a general purpose processor.

I think if you used the blackfin on a UAV you'd find that the vector-based design would result in disappointing performance in this non-vector task. It'll work, it just won't work well.
Zik
Zik -
The Blackfin has a very conventional 32-bit RISC architecture (designed by Intel) with a dual ALU for fast multiply/accumulate and some specialized pixel operations. It really doesn't look much at all like a DSP, and I would argue that it is actually a very nice architecture for UAV. We use it as our core robot controller in place of an ARM7, which also had a nice architecture, but a lot less horsepower. Also, there are 6-8 PWM counters, 2 UARTs, SPI, I2C, some very nice parallel and serial interfaces, etc.

Are you perhaps referring to the Analog Devices SHARC processor ? That matches your description a lot better than the Blackfin.

Howard

[zik]

Hi hg1,

Analog Devices says it's for "multi-format audio, video, voice and image processing; multi-mode baseband and packet processing; control processing; and real-time security". That's very much DSP territory they have in mind for it. I'm sure it can be use for more than that though.

If you like it then please don't let me put you off! The great thing about these projects is we can do whatever we like.

Cheers,
Zik

[Wulffy]

I hope Tod hasn't forgotten this thread. He should be very far on the path by now.
...
I hope you will start a build log for any devices you have chosen to use.

Donald
Hey Donald!

No, I haven't forgotten this thread...

I am on a professionally-mandated sabbattical from the project. Life gets in the way sometimes, and in this case, thankfully, it was my professional life. We simply have too much work, and not enough production/engineering staff. This means that I get to do not only the departmental management tasks, but also the sales, integration engineering, and production lead activities on some very big programs on some heavy iron (EFIS on an MD-87, IFE and FMS' on a B737-200, etc. etc. etc.), not to mention a plethora of work on the smaller airframes (Hawkers/G-IVs/Challengers/etc.). It is frustrating, but it is what it is.

Regarding my recent hobbyist activities, I took a break from the project directly, and am working on developing a Win32 IDE for the Coridium product line. The TCL based toolset that the OEM provides is fine and all, but is lacking in some areas - namely just the bells and whistles aspects, but with my roots being Win32, I have gotten spoiled... :)

Because I can focus on it like I want, I took a break away from the UAV avionics program, & I am focusing on the IDE at the moment. Later this year, I will get back to the UAV avionics suite. The good thing is that I am young, and this is not a time-sensitive project, so I'll plug away as I am able.

The IDE related activities are also serving to broaden my programming aptitude a bit, while not directly related to embedded programming, the foundational knowledge base and skill sets are being improved and that will surely pay for itself down the road.

At any rate, wanted to chime in here seeing as it has been much too long.

How are you doing on your project? What hardware platform did you settle on?

When I get back to it, I will start up a build-log. Nice suggestion.

Thanks guys & gals. I hope that 2008 is being nice to you all, and that the rest of the year is a productive and enjoyable one!!!

Until next time...

-t

[shanghai_fool]

Hey Donald!


How are you doing on your project? What hardware platform did you settle on?


-t

Glad to see you check in with us from time to time. I am now working with another processor which looks promising but very confusing. I am using the IAR IDE (kickstart) as I find it much easier to work with. I'll let you know when I've finished testing it.

Donald

[dnile]

Hey Wulffy,

You were talking before about using multiple MCUs. That certainly seems like a good ideas considering that a lot of the processing done in a UAV lends itself well to parallelisation, but have you ever considered using an FPGA?

I'm currently working on a UAV project (just the navigation system, at the moment), and the beauty of FPGAs is that you can instantiate as many 'processors' (soft cores, which can be anything from 8-bit micros to 32-bit processors with integrated FPUs) as you have room on the device for. Also, if you want to really squeeze as much performance as you can out of it, you can write your own modules in an HDL like VHDL or Verilog.

The other great thing about FPGAs is that they have heaps of GPIO (~150 pins on an average device), all of which is completely configurable (even the voltage levels each bank runs at), and you don't need to worry at all about using up processor time to sample multiple SPI/I2C/Serial ports, because this is all done by dedicated modules.

Really the only downside is that there's a fair bit to learn, and you'll probably have to design your own hardware.

Cheers,
Daniel

[Wulffy]

dnile,

Thanks for your input. Actually the dev of ARMbasic is an old time FPGA guru and has been nudging me in that direction somewhat. I must say that the learning curve scares the heck out of me, however, so for now, I'll trod forward like I am, with the understanding that I may end up at the front door to FPGA Towers at some point.

Again, thanks for taking the time to offer your input. Please keep us posted on how things are going for you.

Take care.

-t