Contents
Virtual Cockpit / OSD Cockpit
In 2010 I did a project called OSD Cockpit (initially Virtual Cockpit), to add a virtual 3D cockpit on top of a drone video feed :
Here the rcgroups thread : https://www.rcgroups.com/forums/show…ockpit-for-FPV
It includes a lot of features, the instruments on the cockpit are animated to reflect the real data from the drone.
(It should be noted that the name Virtual Cockpit was used for this project 4 years before it was used by Audi for its now famous system.)
At the time there was no fast telemetry system. But for that project to work well, there was really a need for fast telemetry, to have smooth movements on the needles, artificial horizon and 3D radar.
There was already the 3DR radio telemetry system, but it didn’t provide RC control, and was only 100mW. OpenLRS didn’t exist yet, and DragonLink was RC only.
The timing is interesting because it was two years before the drone hype that started in 2012, and also before the augmented reality hype, but this project was using both technologies :
OSD Decoder
So I did something a little crazy, and unusual : a software to read the OSD data from the video feed. So it recognizes the characters on the video.
That was crazy because the characters can be on any background, tree, sky, buildings, black, white and so on. So it was a real challenge to read them correctly, and display the plane on google maps, show altitude graphs and so on.
On the good side, at the time the GPS was provide 5 updates per second, which means 5 successible frames with the same data so there was some good redundancy.
It worked quite well :
It was discussed on rcgroups thread here : https://www.rcgroups.com/forums/show…lemetry-system
But I wasn’t completely happy about this system, especially because some characters differ from other characters by only one pixel. For example the 6 and the 8 on that OSD font were more likely to be mixed up because they’re very similar.
So I imagined to modify the OSD font, to add them small black and white bars that would encode 4 bits per character.
In this way the character was still human readable, and the computer was able to read with huge redundancy the 4 bars. That worked very well whatever the background video. You can see an example in the virtual cockpit video above.
In addition there were many consistency checks for example the plane position could not jump suddenly in Africa or it meant a bad reading.
So the virtual cockpit video is on 30/04/2011, and a few weeks later Flytron invented the OpenLRS system. That was very good news, it was now possible to have telemetry with a cheap module.
Well, almost.
OpenLRS
It was working for RC and telemetry but not really usable because too slow to even connect to Mission Planner. That was a deception for me because it was just so much slower than the OSD decoder.
So I started to examine the code and found out some ways to improve it. It was a crazy period, reading and rereading the datasheet of the module, learning all of the registers, testing new ways to improve the telemetry and so on.
I pushed a first version on the flytron forum (doesn’t seem to exist anymore), which more than doubled the original telemetry rate, and had some improvements for example the distinct packet size for upload and download, which found its way in the official openlrs code.
Don’t forget that at the time I was absolutely not known in that domain, just a simple user, so it was pretty cool to see some people interested in that development. And I continued to work and improve my version oriented on telemetry for APM because I thought everyone will want telemetry in the future.
That wasn’t clear for everyone at the time, and to illustrate that, there were separate sections in rcgroups, one was called FPV, and the other one was called UAV. The word drone wasn’t even coined, and most users were flying pure FPV with an OSD and no flight controller. So telemetry wasn’t getting a lot of attention but I was sure it would become something very common.
And that continued for a long time, I worked on a version that I proposed to Flytron.
One year and a half year later, Flytron stopped developing code for openlrs, someone else brought maintained it and suddenly stopped, and in December 2012 the openlrsng branch started.
So that could have been very good, and I thought to myself OK so that’s all good, all I have to do is drop my version and use openlrsng. Which I did.
Until I realized it didn’t work so fine, was unstable, I wasn’t able to get some modules to connect, and the telemetry was still too slow.
That was again a deception, as my version was just working fine for RC and for fast APM telemetry.
I provided several improvement ideas in the openlrsng thread, such as using a higher RF rate, and provided the RFM parameters for 57kbps and 125kbps which are still today in use in openlrsng.
Then I explained some other improvements that should be made to the packet management, and how to use two 1W TX to make a bidirectionnal 1W link, but there was a strong reaction against it and I was told that it would be technically impossible.
Of course impossible is a challenge so I implemented an example on my code to show that it works, and that it’s possible to have long range fast telemetry and RC for the price of two OrangeRX 1W modules.
And that was the beginning of…
