PDA

View Full Version : Discussion Problems and Methods of/for Streaming Real Time Video


FirmamentFX
May 19, 2007, 07:16 PM
Hi guys,

I would be interested to hear people's thoughts about problems they have had streaming real time video from UAV to ground.

As far as I can see, the biggest problem is bandwidth. This is the mother of 'em all, and determines everything that is done.

Encoding/Decoding

Another problem is the actual encoding/decoding methodology. There are many protocols and codecs out there, but are any of them suited to this kind of work? The one that immediately springs to mind is MPEG-4. This has become pretty standard now.

There is also Quicktime and Windows Media (itself an extension of MPEG-4), although these are probably not particularly suitable.

Data Processing

To an extent, it all boils down to what you want to do with the data in the UAV and on the ground. If there are any machine vision / tracking systems on the UAV, then the video feed needs to be split "at source" to go to the onboard systems and the downlink.

On the ground, do you simply want to view the image on a screen (in which case a simple commercial wireless video Tx/Rx unit will do), or do you want to integrate it as part of a bespoke software system (to overlay it with HUD data perhaps, or to process it further, or even to simply record it to a hard disk)?

Multiple Cameras

Finally, there is the multiple camera option. If you have 2 or 3 cameras (perhaps 1 IR for example) on board, you can either a) use a switch control from the ground to adjust which feed is sent, or b) try and work out some way to encode multiple streams in one downlink feed.

If you take option a) you are limited to only seeing/recording one feed at any one time, which may be fine in some cases, but if you were flight testing, you could well want to compare 2 or more camera angles from the ground...

With b) you come up against the problem of bandwidth again, only (at least) doubled...



A long post. My apologies. This is something that has been turning over in my mind lately though, and as I said, I would be interested to hear how others see and approach this problem.

typicalaimster
May 19, 2007, 07:55 PM
=
Encoding/Decoding


Don't forget delay as the video is encoded for transport.. Then the decoding of it on the other end.

hg1
May 19, 2007, 08:28 PM
Though the bandwidth usage is higher, you're better off with JPEG, as the latencies are minimal, it is a lot easier to recover from data loss, and you won't suffer from motion artifacts.

I'm assuming you will have a reasonably capable processor onboard, and are capturing uncompressed images locally which can feed into image processing routines as well as compression routines.

802.11 is the best option at present for getting reasonable throughput at reasonable cost. We use the Lantronix WiPort WLAN module for this type of application.

If you have enough computing power, you can certainly manage multiple cameras from the same processor. Then it's just a matter of how you allocate your bandwidth for sending data back to base.

FirmamentFX
May 19, 2007, 09:47 PM
Of course, there is a delay issue. It is not *so* critical on decoding though as the ground control station can be as powerful as required (within reason - I can't see quad cores being "underpowered" :) )

I am planning to have several processors on board the UAV - one dedicated to image processing. While the flight control systems will probably be running on ARM processors, the image processing board I imagine with be an x86 based SBC. Windows CE 6.0 SP1 has some pretty nifty digital processing and recording features out of the box. I haven't worked out yet if that locks the format to WMV though - probably, given MS's plans for world domination...

Cheers,

Martin