Building an embedded circuit for a UAV

[Owen]

FPGAs are VERY power hungry devices; they are really not designed to be used for anything battery powered. And yes, the device tends to come in a variety of sizes, packages and speed grades; the bigger devices (What you will need for something like a H.264 encoder) all tend to come in BGAs. And, sure, you could use a development board - but will it fit your UAV's form factor? Additionally, are you comfortable enough with VHDL or Verilog to program the needed glue logic?

Really, your best option for now might just be to get an AVR, dsPIC or PIC32, and one of the cameras with a builtin JPEG codec. With a bit of work you should be able to build a semi-decent MJPEG stream and store it on an SD card. You'd probably want to look up one of the many micro controller FAT drivers.

I'm not saying that what you want to do is not possible; quite the opposite. But it's a hell of a lot for someone's first major electronics project; you want to start with something which you can work on in chunks and build up eventually to what you want a you get experience.

[AndrewAPrice]

FPGAs are VERY power hungry devices; they are really not designed to be used for anything battery powered.

Okay.. let's go to the other end of the scale. How about a Beagleboard and a HD webcam?

While the Beagleboard claims not to be able encode/decode anything above 720p in realtime, surely the 600MHz ARM processor could handle saving 1920x1080@30fps video directly to storage in the same format it is received from webcam in without any transformation.

Most-likely (and worst) case scenario is that it's uncompressed meaning:
8 bit RGB @ 1920 x 1080 @ 30fps = 119 MB/sec = 417 GB/hr.

Recording a few minutes at a time isn't a problem since I can always have my laptop on hand. And for long flights I could use 720p and use the hardware encoder.

[Combuster]

119 MB/sec

Which brings us to another problem: According to wikipedia, the peak data rate for SD cards is currently 30MByte/sec

[bitshifter]

Very cool!
I have done it with PPM transmitter/receiver and UHF broadcaster.
UHF range is very small but PPM goes out couple miles on 1 watt.
My airframe is 120 inch Bird of Time (no ARF, but built from blueprints)
It took me a short time to frame it but many months of sanding etc...
This is a thermal glider (which i also have gas engine pod optional)
It stay up on minimal lift as long as you like but it get boring
after about an hour of flying, and my brain start to wobble.

More generic info on airframe...
http://customers.swcp.com/~tandberg/Lin ... OfTime.jpg
http://www.google.com/search?hl=en&clie ... =&aqi=&oq=

[Owen]

119 MB/sec

Which brings us to another problem: According to wikipedia, the peak data rate for SD cards is currently 30MByte/sec

And thats 30MByte/sec is not sustained; expect pauses of up to 500ms if the card has to do wear leveling.

[whowhatwhere]

I think you're missing the point that you really aren't going to get anything close to real-time control with a full blown 32 bit processor. If you really, really want to, then try dual-boarding it with an Atmel for bird control and the ARM as a secondary cooperative processor that goes along for the ride and piggybags on the air<->ground transmission signal.

[earlz]

119 MB/sec

Which brings us to another problem: According to wikipedia, the peak data rate for SD cards is currently 30MByte/sec

And thats 30MByte/sec is not sustained; expect pauses of up to 500ms if the card has to do wear leveling.

Of course, this just means *YET* another level of complexity added to his *first* project.

Sure, it could be possible to somehow fit a hacked up RAID implementation so that you can write to 6 or 7 SD cards at a time to get a good sustained rate(so that each SD card is only needing like 5-20MB/s) but really... dude, your project is overkill.

[AndrewAPrice]

If the DSP on one Beagleboard is able to encode and compress 1280*720*30fps in real-time (27.6M pixels per second), then I could use an cluster of 3 Beagleboards connected using a passive ethernet hub each encoding 640x1080@30fps (20.7M pixels per second) on their own SD cards.

One of the CPUs could be purely in charge of demultiplexing the video from the webcam into 3 independent raw streams, another the other two CPUs is charge of flight control (with one as a backup that lands the plane if the other becomes unresponsive).

The 3 Beagleboards should only use a total 6 watts (excluding the webcam).

[AndrewAPrice]

Because each Beagleboard weighs 37g and has a peak power usage of 2W.

The webcam with the lens but without the casing is also around 30g (not sure of the power consumption).

And I know I was going to need an extra battery regardless.

And finally, because if I wanted SD video I would have bought an OSD Pro. Bundle that with a camera and receiver and it'll come near the cost of 3 Beagleboards anyway.

[Owen]

Because each Beagleboard weighs 37g and has a peak power usage of 2W.

The webcam with the lens but without the casing is also around 30g (not sure of the power consumption).

And I know I was going to need an extra battery regardless.

And finally, because if I wanted SD video I would have bought an OSD Pro. Bundle that with a camera and receiver and it'll come near the cost of 3 Beagleboards anyway.

And whats controlling the motors, servos and other avionics? Because the BeagleBoard can't. It doesn't have the hardware.

[AndrewAPrice]

I'm receiving a lot of criticism for what I"m trying to do.

I figured the old adage still applies: "Just because you can, doesn't mean you should."

You'd think there could be one or two semi-intelligent people on a board for operating system development.

To both of those quotes: I can call you crazy for being on an OSDev board in the first place.

And whats controlling the motors, servos and other avionics? Because the BeagleBoard can't. It doesn't have the hardware.

I was going to get a board and test to see if I can get the DACs for the stereo output to output a constant voltage.

But actually, I've rethought my idea. I could compromise slightly and go for 720p30 video (which a single BeagleBoard can do natively), connect the webcam via the USB port, and record on to an SDHC card. Use the PowerVR chip on the BeagleBoard to overlay text (GPS coordinates, battery status, remaining memory) and render to a 1280x720 texture which I'll send to the DSP to encode and store on the SDHC card. I'll also render the texture to the screen, which'll output at a PAL 720x576 resolution via the video output, and send that through a transmitter where I can see the RC plane from FPV from the ground in standard definition yet record in HD.

The BeagleBoard will be connected to an Arduino Nano via serial. The Arduino will handle input from the RF receiver and control the motors and servos, handle input from the gyro, GPS receiver, and battery sensor, and be in charge of the flying logic. The GPS position and battery power level will be sent to the Beagleboard to be overlaid on the video. The Arduino will also be connected to a relay or flip-flop so that I can toggle the power to the GPS receiver, beagleboard, and transmitter based on commands from the RF receiver.

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.

[Owen]

That sounds a lot more sensible, and, as a plus, you can get the flight mechanics working before you have to start messing with the complexity of the BeagleBoard.

Just a warning though: The Arduino works at 5v (Some versions 3.3v). All of the BeagleBoard's IO is 1.8v. You'll need level translation between them else the BeagleBoard is toast.

[whowhatwhere]

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):

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.

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.

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.

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.

--[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.

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.

[Brynet-Inc]

I think NASA used the 8086, not the 80386.

Today, in newer designs.. they probably use radiation hardened designs, and something with a little more oomph.

[whowhatwhere]

I think NASA used the 8086, not the 80386.

Today, in newer designs.. they probably use radiation hardened designs, and something with a little more oomph.

Today's design yeah. My point still stands as the 8086 alone didn't break ten megahertz.