Colour graphical OSD for multirotors and RC aeroplanes

[Batperson]

Hi!

This is my first post here. I'm working on an OSD system for radio-controlled aircraft.
What is an OSD? Many RC pilots put a camera on their aircraft with a video transmitter. From the ground they get an "in the cockpit" first-person view (FPV). It's useful to overlay the video feed with the aircraft's altitude, speed, GPS position, battery state etc. A system which will do this is called an "on-screen display" (OSD).
There are many open-hardware and software OSDs, and some of them are quite sophisticated. But they are nearly all black and white. I'm not aware of any open-source OSD that supports colour graphics yet.

I'm using an ADV7184 video decoder and ADV7341 encoder from Analog Devices, driven by an STM ARM chip. It will be an open project, all schematics and source code on Github and I will try to make the final product available as cheaply as possible.

Attached are some screenshots of what I've been able to do so far.

Please come and check out the project at https://wekaosd.home.blog. I'm very much a beginner in electronics, it has been a real learning journey getting this far and I will greatly appreciate any feedback I receive. I'm sure there is much that can be improved.

[rs20]

Nice! That's really impressive and ambitious stuff for a "beginner"! I assume the OSD circuitry lives on the ground (i.e., it's not flying on the plane?)

If so, (and take this with a grain of salt because I'm just a pleb in the peanut gallery,) I'm intrigued that you're performing the overlay on the composite signal. I would have assumed that these two items would exist "out there":

• A composite-to-HDMI converter (like this ?)
• HDMI composition/overlay widgets (miniSpartan6+ ?)

In fact, taking this reasoning further, a composite-to-USB3 converter could allow any reasonably modern laptop to do the business too.

With those, your overlay could be far crisper and more readable. But I haven't done any research on this at all, so . Curious to know what I might be missing? Is the idea to keep the signal composite to maintain compatibility with standard composite-input drone video display devices?

[Batperson]

Thanks! You can see I really am a beginner, the power supply was my first attempt at a circuit board (around a year or so ago) and the first time I tried SMD soldering. It works, so I'm still using it 

The OSD circuitry is normally carried on the model along with the video transmitter. In my case I made a development board, if I get to the stage of releasing a finished product I will make a much smaller and lighter version.

There are a few reasons why the RC world is still mostly using analogue TV:

• Hi-def video systems are still expensive closed systems (there is 1 open-source project using RPi but there isn't an ecosystem of compatible cameras, transmitters etc yet).
• Latency is important, especially for racing. It's not possible to send hi-def video over the air without compressing it and decompressing at the other end. This is OK for streaming a movie but it adds latency
• Analog TV degrades better. If you have a weak signal you can usually still see well enough to fly back, but a digital video stream you will lose the picture entirely.

[rs20]

Right, so in short, my initial assumption was wrong. I didn't realise this circuitry lived on the flying craft. I guess my suggestion was to have a separate downlink for avionics data (you know, attitude, speed etc) and have all of this composition happening on the ground.

[Batperson]

Right, so in short, my initial assumption was wrong. I didn't realise this circuitry lived on the flying craft. I guess my suggestion was to have a separate downlink for avionics data (you know, attitude, speed etc) and have all of this composition happening on the ground.

It can be done that way, some craft send telemetry to a ground station which can log the data and/or display it. This way is potentially better, but you wouldn't want to be using a laptop to display the video because it will introduce too much latency.
The ideal setup would send both telemetry and digital hd video over a data channel, but for this you need a very fast downlink.
One thing you can do with an on-board OSD, which I hope to support, is use the vertical blanking interval to send a datastream like teletext or closed captioning. Some OSDs are already doing this.