MessiahAndrw wrote:I'm receiving a lot of criticism for what I"m trying to do.
...
If your replies aren't going to be constructive then I think this thread would be better off locked, and I'll post my results once I've got somewhere.
Maybe....just maybe, there was a reason for that. If people are not allowed to draw criticism on an idea in a discussion forum, then there is likely no way for the creator of that idea to learn. Here's some constructive criticism (which may or may not hurt your feelings and delicate sensibilities, and will probably be reported and deleted like everything else):
MessiahAndrw wrote:I want to undertake a project to turn an RC plane into a UAV. The way I'd like to do it is to build a light-weight onboard computer, which places me into the realms of embedded programming which sounds challenging yet like a lot of fun (programming for something practical that interacts with the world!)
This is a very cool idea. As I plan to major in cognitive robotics, this sort of field interests me as well, and as such I have tried to research it as best as I can. Embedded computing, which by definition is a based on small, lightweight, resource-constrained devices, shouldn't be approached in the same way that one would approach building a conventional project. They may share traits in development, but they are not the same and shouldn't be treated as such.
MessiahAndrw wrote:I wish to have my own code running on an embedded processor controlling the RC plane. Rather than the RF receiver directly controlling the engines and servos on the plane, I'd like the RF receiver to pass them to the processor which will then control the plane. While flying, the processor will read from an onboard gyro and stabilize the plane, and if it detects it's not receiving a signal from me (out of range) the plane will turn and head back in my direction. I would also like the processor to log the flight's GPS coordinates, record a video of the flight and save this onto an on-board USB flash drive that I can later remove and plug in to my computer afterward and watch a playback from the plane's POV.
This has been done before, in
general, and in
specific. Both projects are based on extremely basic eight (or rarely 16) bit processors. The reason for these is that they are: simple to program for, tiny (including *infrastructure*), use very little power, minimal, robust, and can be programmed to react deterministically in hard real-time operating environments. Newer higher-power devices are much more complex and do not have the same parameters. Think about virtual memory and paging, for an example of non-determinism: although on a desktop it's not too noticeable, a page fault and it's subsequent fetch/map by the processor into virtual memory means time that the processor cannot react to real-time events, and there are no hard upper bounds that one can place on how long that operation may take to complete. The absolute same goes for memory accesses. Even on processors without virtual memory, the caching can make real-time event handling pointless. Both operations are not deterministic and still defeats the *hard* real-time requirements.
As well, in other projects those return-to-home fail safe systems are reliably implemented without requiring secondary motherboard-processor combos because they are programmed to do so. The transmission link between the RF controller on the ground and the bird in the air does not directly control the plane itself, but is routed through other hardware to decode and instruct the board to do it's bidding. This also requires no extravagant hardware to accomplish. It's already been done on many, many, many projects... you just have to look at them. The same goes for GPS, coordinate logging, video capture, way points, fail-safes and just about every other feature you could want.
MessiahAndrw wrote:The problem with all of this isn't the programming involved, but the components I require and, just as importantly, how to connect them.
This has already been solved. Just visit the first and second links above and you'd know that. You don't need to fabricate your own high-end board to do these jobs, you just need the regular run-of-the-mill board that everyone else uses, which also, low-and-behold, happens to be expandable and upgradeable just as you want.
MessiahAndrw wrote:I know that I will need a debugging/flashing kit for the microcontroller. Most microcontrollers I've come across are simple 20MHz systems, that while they will be able to handle flying, I don't think they will be able to handle streaming live video onto a storage device, so I'm looking at ARMs which seem to have decent processing power.
I just wrote about this above. The kit has absolutely everything you could ever need, including toolchain, full support, an entire community of modders and developers and all the information about how the equipment works you could ever need. Also, I don't believe you understand what those clock rates actually represent. NASA sent the space shuttle into orbit and back on an i386. It's clock rate didn't even break 30 megahertz (on an X86 based processor) and it made it into orbit! Clock rates are marketing junk. With very few exceptions, they are meant to glaze over the eyes of people that think throwing more hardware at a problem will fix it, and thus when people see the next order of magnitude clock rate they believe that will solve their programming issues. On an embedded system, more hardware is bad. Embedded programming is about making use of *constrained* resources. I'm not even getting into the differences between what clock rates mean when in the context of ARM<->X86.
MessiahAndrw wrote:--[snipped list of disjoint parts]--
This stuff should begin to appear as 'useless junk' fairly soon here. You want video capture? Look at how others do it. Same goes for GPS, and memory, and every other thing you want. For things like USB controllers and Ethernet hubs, I point at the "embedded" comment above.
You do not, and will never need, to ever use these if you've thought out your project. They are useless junk.
MessiahAndrw wrote:So basically I know what I want to achieve, but no clue where to start. I would appreciate if someone could give me a rundown of the components I require since I haven't done anything like this before. And my mind is filled with a lot of other questions. How exactly do I connect each sensor up to the micro-controller (do I directly connect an IO pin with a pin on that component, or must I de/multiplex it or change the voltage)? How do I calculate the total power consumption of each component?
You know what you want to achieve? What is that, exactly? It's pretty vague from my point of view, because you have not explained it, you have just implied by a disjoint set of random hardware that you want to capture video and use GPS, on an RC plane. You might do better to actually be explicit about what you want to achieve. Detail is the key. The reason you have no clue about where to start is because you actually haven't thought this through.
