One of my projects is about establishing a solid, low-latency HD video link for FPV, SAR or surveillance and using accessible, affordable technology to do that. This is talking $4,000 for the entire setup here, which is mostly the macmini+720p goggles and which are reusable in different contexts.
The OSD is painted on the ground station (a mac mini) and visualized through the HD goggles (HMZ-T1). Even though the letters look pretty small, it's easier to see them through the goggles than on a regular computer screen.
In the past year I worked on refining this application and all the required settings for wifi, encoding, decoding to establish a relatively low-latency video link (120-150ms, relatively: for this type of technology). The telemetry data link that transmits all data from all onboard sensors at a rate of 30 Hz paves the way for a host of new ground-based applications. Examples include the integration with map and DEM data for improved navigation and virtual 3D overlays to make tunnels or paint the location of "buddies", "spotters" or other points of interest. If the lens properties are known and the camera is precisely fitted, this is not incredibly hard to achieve.
The OSD's bottom bar is also new and requires some explanation. Most OSD's provide raw data as in the top bar, data which has to be interpreted by the pilot during flight. In this app I'm reinterpreting the data based on work done in Cognitive Work Analysis (CWA). An example is that the pilot's primary concern is not the capacity left in the battery, but the distance that the battery still allows him to travel using that capacity and whether that's enough to make it home. The bottom bar thus relieves the pilot of these calculations and the bottom bar can be scanned in short time. If all is green, there are no immediate concerns. Bars reducing in size and changing color to red demonstrate a decrease in the available affordance for that operational concern.
Anyway, I gathered a lot of data and observations in this field test and I'm already working on improving those. This includes the causes for the video stutter, the failure of the telemetry link and so on. Both launches failed because the bungee cord got caught in the motor (twice!). I fixed that and managed to make another third successful launch, but that unfortunately didn't get recorded.
Comments
@Jack Crossfire: I have to disappoint you on that. The 300ft limit is a practical choice of many transmitters, since the tx power of many devices doesn't practically go beyond that limit for common scenarios. There's also a retransmission delay in wifi that needs to be considered and configured in the transceivers, otherwise you only get collisions beyond the 300ft range. The modules I'm using can manipulate these tiny transmission delays, so theoretically have a longer range. See the comments above where someone posted a video of a camera at 15km away. The AR.Drone can't move out of this safe 300ft limit, because it's control link is tied in with the limit of a non-configurable transceiver.
The reason why the framerate looks poor in this test is because there was a specific configuration issue on the decoding pipeline that I discovered after the tests today. This was dropping frames like crazy in specific circumstances as well as leading to an infrequent crash (after ~5 minutes or so) given a very specific scenario. That's why the last launch didn't get recorded.
For the impatient:
The AR Drone is the only thing which has ever consistently gotten 1280x720 transmitted. Getting beyond the ages old 300ft limit still requires soldering a bunch of chips together or using a repeater.
Regarding realtime images ...
This transmitter is AR7240/7241 processor that supports USB 2.0. We fluster the legs processor, to connect the web camera. Recompiling firmware from SDK and get realtime image)
@Peter: Nope.. I'm not working on this as part of a contract. I don't mind clients getting in touch if they're interested in elaborating this more for those platforms that are < $1 million and are allowed to be lost.
Another observation is that the total weight is a bit high for a plane this size. It ought to be installed on something twice the size at least. The sub-standard airfoil surface also doesn't help.
@Alexey: That looks like a VGA stream, which probably has 1/4th of the required bandwidth. Could you also detail the latency for that particular application? The reason is that the latency on this particular test is extremely aggressive (120-150ms). If I used a 2s buffer or so, I'd get crisp, high-quality video @ 720p too :).
@Neil: It's an Arecont Vision, compact megavideo, AV1115. In the end probably not the best choice because of weight and how it's designed. I selected this because it can do 42fps (less latency) and can be powered 12-48V DC. If I had to purchase another one, I'd probably go for an Axis M1054. Easy to power, 30fps is enough given the bandwidth requirements/latency tradeoff.
Простите, вы - Gerard? Нет?
- прощаю. Видимо со зрением у вас проблемы...
Neill McOran-Campbell,
Good day!
This is Ubiquiti bullet m2.
We fly in this set-up for more than two years. On the ground - bullet M2 with a directional antenna 19dbi, and on board - 5-7dbi. The video can be taken from any ip camera(rtsp), but depending on the codec and the manufacturer will delay play 200-1000ms. For example, 720p h.264 is from 2 to 10 Mbps, which allows you to fly at a distance of 15km. If configured, of course - the frequency of the channel, the channel width and a number of points.
May receive realtime images from up to 3km, but we should resolder transmitter, and rebuild the firmware from SDK.
@Gerard, thanks for posting that. I look forward to trying it out when its available....
Many thanks, Gerard :)
Well, I intended to put this Mac App on the AppStore once I crease out the final details. I made a page already here. Since that probably includes more details you're interested in, I could already share it:
http://radialmind.org
The codec is H.264. WiFi is just the affordable, accessible technology for digital transmissions. COFDM is better, but modules are $10k and too heavy for small model planes. Bandwidth varies from 2-12 Mbps, depending on scene variability and the specific frame rate of the camera you're using. Here it's an arecont compact megavideo, which could do 42fps. In the end I tuned this down to 30fps a bit, as the bandwidth and reliability are also related with one another. Transmission is done at fixed MCS-2 (19 Mbps), so the peaks consume 2/3 of the available link budget.
In this particular test the camera was configured for CBR. Probably the scene variability caused the algorithm to panic, dropping frames along the way. That's the stutter you see occurring. If everything works correctly, you should see a 30fps constant video stream on the ground station. (my recorder uses 1080p@24fps though).
@Alexey
Простите, вы - Gerard? Нет?
-
1
-
2
-
3
of 3 Next