Lots of things have happened since the last blog post. I've worked very hard to improve the stability of the "FPV" ground station software with excellent success. The first version 1.0 has gone live on the AppStore last week, after a long review time by Apple. I'm now already in the final testing phases to release version 1.1, due next week. This will have important performance improvements, as it eliminates the infrequent jerky playback and reduces CPU usage by 20-30% by preventing some colorspace conversions.
This version is a nice demonstration of the possibilities of a potent ground station hardware and a highspeed telemetry downlink. Although I'm using a simulator here, it could just as well have been an IP camera onboard a mobile vehicle.
As you can see in the video, I made an iPhone/iPad app (called "FPVNav") used for navigation planning. This uses waypoints as 'flight path handles' instead of points to fly through. An algorithm is used to calculate and draw a flyable route between and around these handles, according to the settings for each handle.
Waypoints in typical AP implementations do not explicitly state how the transition from one point or leg to another must be executed, which leaves room for uncertainty and ambiguity, and thus "interpretation". As you can see in these examples, there are a number of possibilities. You can follow the leg of one and exit or enter through the point, go through the point with a turn, follow the leg on both and "cut before" the waypoint in a turn with a specified radius or just circle around a waypoint.
The generated trajectory is sent to the "FPV" app as a message, which uses the data to display a virtual tunnel. In theory, if the field-of-view and the aspect ratio of the lens are matched, this virtual view should line up well. Barrel distortion is not compensated. It will be possible to integrate your own tools in this message exchange, as the specification and method for communication will be described on my webpage.
If you watch carefully, you can also see some limitations in the behaviour of these virtual cues when the vehicle pitches, rolls or yaws aggressively. These rotations seem to drive the virtual cues into the ground or lift them up. It is actually the video image which lags behind a bit (150ms latency vs. around 30-60ms of telemetry). Getting exactly the same latency on both links is going to be very difficult, especially because the latency is variable on wifi, beyond getting lost packets, so this is something that you have to live with. I'm considering relieving some of these effects by using transparency tricks to shift focus to either video or telemetry.
I'm already considering features for the next version. One thing that comes to mind is a total energy display used for landing approaches. This calculates the required energy of the vehicle and compares that to the current situation. It allows you to manage the throttle very efficiently, especially during landings.
The other is a cue which uses raw IMU information. Accelerations and rotational velocities can be used to estimate ahead of time what a vehicle's attitude will be and how exactly it will be moving through space. So, this cue will allow you to understand the dynamics of the vehicle better, because it shows you when to bank out of a turn, increase the turn rate, etc...
The apps in this video are connected through "Bonjour". This allows for a 'zero configuration' setup. Just make sure they're on the same network and they'll do the rest.
Comments
http://www.4stateuav.com/product/long-range-hd-fpv/
Ah. No, I'm not intending that, I mean it would be good if this DVB-T technology would be portable enough such that it could be used on a plane, which it is currently not. Of course, when it does get used, it needs to be changed to use license free bands, which is another hurdle. It is yet also to be seen whether this is technologically possible to upconvert this to a different frequency and how it performs there.
Anyway, it's already obvious that that route is difficult. I think that a very good analog setup with a HD wifi link with a bit of latency is the cheapest and most practical at the moment. If you can get your hands on a COFDM tx instead that's portable, then this improves the robustness and reliability a bit.
I lost you here. Do you mean to use the licensefree 2.4 or 5ghz frequencies to send out a dvb t signal?
Yes, anything which can produce a DVB-T transmission signal and then of course in HDTV. Most DVB-T equipment uses SDTV and MPEG-2, as this is the regular standard, but there seem to be extensions in use that allow it to transmit 720p@25/50 as well for example. I'm far from an expert on these technologies though, I just learned by reading up on it. A lot of this equipment is assumed to be used on the ground, so has heavy enclosures and not uncommonly, split between a modulator that spits out bandwidth or intermediate frequencies (up to 70MHz or so), which is then later increased to the final frequency and amplified to whatever is required.
Hi Gerard
are you referring to such a device:
http://www.tvconverters.co.uk/hdmi-to-dvbt.html
or would you be using WIFI frequencies by using a WIFI device altering its software?
Brazil. Sun rises at 0530 here in the east, summer or "winter".
Latency is very much a factor of the transmission layer in use and its Forward Error Correction capabilities. WiFi is a system where at the radio packet level an acknowledgement is typically required. It is however the TCP protocol which makes the entire transmission robust, but obviously retransmissions increase the overall latency.
WiFi is thus a cheap solution as an alternative to a broadcast system that was specifically engineered for video. You could say that UDP multicast over wifi is a "poor man's" broadcast system. Personally I think DVB-T, which is very resilient against interference, is a better solution, but it's very difficult to find affordable equipment which is also the correct weight. COFDM is also superior, but again not of the correct size, weight or price.
This packet acknowledgement makes things a bit more difficult sometimes. Practically speaking, you should count on a latency around 150-200ms. You could reduce this very slightly under specific conditions at the cost of losing some of the robustness of the signal. Alternatively, you could increase the buffer a bit up to 250ms to increase the robustness. So this is something to play around with and some better antennas and wifi modules can reduce this further.
I'm not 100% sure how much latency goes into H.264 encoding, but I think that can be kept really small if it doesn't use particular extensions and B-frames. The difference is that some of these extensions reduce the total file size, but need a larger number of frames in memory to calculate these intermediate frames. For that reason, a larger number of frames are kept onboard and this would horribly impact latency. I dont' think any of these realtime encoders use those extensions though. It does mean that the stream is not as efficient as it could technically be.
Not sure if openwrt could be used to turn a wifi module into a DVB-T transmitter or receiver. Now *that* would be really interesting!
Hi Gerard,
Thx for your prompt answer. Either your in Holland with Kings day or you stood up early in Brazil? The combi. of Analog with digital is an option. HD TX with 2.4 GHz combined with 5.8G should not pose any prbl.What altency times do you currently have ?
Groet, Michiel
Hi Michiel,
Well, latency is a bit relative. It's difficult to state anything about the practicality if it's not tried. A lot of these FPV guys are going for adrenaline, flying close to trees and stuff, which naturally means their overall reaction time needs to be shorter. At the moment there are additional measures like IMU stabilized flight or supported by GPS which alleviate some of the concerns for keeping a craft well stable.
If latency is still a concern, consider the use of an analog tx @ 5.8G together with the HD system for an engineer. One of the issues of this technology is that it pushes the capabilities forward without thinking about how it will be integrated into the operations. I reckon that this technology always requires 2 people at least. Have a look at what ARCAA in Australia have done though, they have a working setup for exactly this kind of thing, although it's not what you would expect.
Flight times for lipo's can be increased, I've heard about systems that can go up for about 30 minutes with only moderate adjustments to lipo size, type, motor efficiencies and so on. Weight however remains the most important factor.
What are your expectations with regards to range? I reckon that this would especially be useful for those towers that are hard to reach. I still see difficulties however replacing the heli entirely, because the overall range of the transmission line is just too large vs. the flight time of these cheaper platforms. And when scale is increased, eventually you arrive at the same thing. Because the heat cams are usually pretty heavy, this makes it relatively complicated to arrive at a working solution inbetween.
Hi Gerard
did you have a look at :
http://www.airborneinnovations.com/ai/?page_id=469
I just posted them a question asking for the latency of the system.
Out of the video on their website I would guess that latency is still to high for FPV.
I am working for an electricity company in Luxembourg and we would be potentially interested to start inspections of high tension lines with Quads & co. By having long(er) range HD, this could be offering an alternative compared to Helicopter flights. The big issue still being the Lipo capacities and related flight time. I am impressed by all these "grassroot" initiatives by you & others. Respect.
PicoStation M2-HP. It could actually be the very same PCB as the bullet, I have never taken the bullet apart. The difference is the connector. Bullet uses N-type and the pico uses SMA (or RP-SMA).. the module's connector has thread on the outside and a pin sticking out. I need an adapter to connect my antennas.
I only used 2.4 Ghz. I don't think 900MHz is allowed in NL. On the bullet, I use the Luxul CP. On the pico I use circular wireless antennas.
-
1
-
2
of 2 Next