There are currently plans for the following OSDs to be produced:
Lite:

• Entry level module - will be introduced first
• 2-layer FR4 PCB design.
• Open source firmware and hardware.
• Dual video input (switch between inputs as required.)
• 2x RC inputs for playing games.
• Single board, 4.5mm thin form factor (when no connectors installed.)
• Single channel +3.3V @ 400mA buck supply. Operational from +4.8V to +30V. Can withstand -40V to +36V for up to 30 seconds. 85% typical efficiency.
• 2 megabyte DataFlash serial memory for datalogging. Up to 10 entries per second.
• Small form factor (w x d x h): 40mm x 73mm x 8mm.
• GPS and UART ports (up to 115200 bps.)
• Shared I2C port (same I2C bus for internal and external.)
• 6x fully buffered analog inputs. 3x 0-40V inputs, 3x 0-2.5V inputs. Specified tolerance better than ±0.7%. (Precision ±0.2% voltage reference.) All inputs ±45V tolerant.
• Variometer and beeps/alerts
• Audio modem (2 kbps) and video modem (12.8 kbps)
• Illuminated (dark usable) buttons.

Pro:

• Powerful PIC32 based graphical OSD (360 x 288/240 pixels 4-bit greyscale.)
• Fast PIC32 secondary processor. Probably running Python.
• 2-layer (PSU + OSD) + 4-layer (MCU + buttons) FR4 PCB design.
• Open source firmware and hardware.
• Dual video input (switch between inputs as required.)
• Stacked board configuration: two boards mounted on top of each other.
• Datalogging to microSD card (MMC & SPI mode.) Up to 4 GB cards supported. Uses FAT32 filesystem (using open source FAT32 drivers.) Up to 200 entries per second.
• Autopilot based on either Paparazzi or similar open source autopilot.
• 8 channel servo input, 8 channel servo output, and PPM input/output.
• A three/four rail switch mode power supply: +12V @ 1.0A, +5V @ 750mA, +3.3V @ 400mA, +3.3VSB @ 100mA. All rails fully operational from 6V to 32V input. The 12V rail can be adjusted over an 8V-12V range in software. Input can continuously withstand -40V to +60V, although outputs will be off. 80% typical efficiency.
• RTC for keeping time with lithium coin cell battery backup (optional.)
• 4 channel high current output (500mA per channel - max 1A combined.) Ideal for driving LEDs.
• 10x fully buffered analog inputs. 5x 0-30V inputs, 5x 0-3V inputs. Specified tolerance better than ±0.2%. (Precision ±0.05% voltage reference.)
• GPS and UART ports (up to 115200 bps.)
• Dual I2C (one port for internal bus, one for external.)
• Full speed USB serial interface for upgrading software and changing settings.
• Small form factor (w x d x h): 35mm x 75mm x 20mm planned.
• Variometer, recorded voice and beeps/alerts
• Audio modem (2 kbps) and video modem (18 kbps)

Original post

On screen displays with a graphic HUD, such as RVOSD and Eagle Tree Pro OSD, are too expensive for me. But, I want to have a graphical HUD? What is one to do?

Being an electronics enthusiast, I came up with my solution to this problem. My own graphical on screen display. No, it is not a text only display like Remzibi (which is still a pretty cool OSD and I have to admit to considering it in my search.) It is a fully graphical, 256 by 192 pixel on screen display for PAL and NTSC video signals. It uses less than £10 ($15 as of writing) of parts. It is a work in progress and I will be updating this post as I make additions to it.

This will be an open source project. That means, anyone can build their own hardware and download the open source software. They can also modify it, and even sell it, provided they contribute the changes back to the community (and me.) The code is not yet released, I am finishing off an "alpha" release before putting it out. The code is written in dsPIC assembly language, over 1300 lines of it.

See this quick demonstration. I am still working on a full blown demo... stay tuned!

Super OSD: my on screen display project (1 min 20 sec)

Some of its features:

• Fully graphic. Each of the 256 by 192 pixels can be individually set or cleared.
• Only 21 components. Three ICs (an LM317T voltage regulator, a dsPIC33FJ128GP802 microcontroller, and a LM1881 sync separator), plus assorted passives and an electrolytic capacitor to filter out EMI. The dsPIC is only $5, and is the most expensive part. It's designed to accept +5V, so on my plane I will take the 2S LiPo thru a voltage regulator to reduce it to +5V.
• Double buffered/dual buffers. This means very little or no flicker when the screen updates.
• Lines, text, bitmaps. Pretty much every shape is supported. Circles, rectangles and a bigger font are coming soon.
• Fast. Like, really. 20, 30 even 40 frames per second would not be unusual for a basic HUD. As a guide, I wrote an early, unoptimised version in C. Doing an RVOSD-like HUD, it managed 12 fps; I reckon at least double that is possible, if not more. Because it is double buffered, the screen changes instantly, so even when it slows down it doesn't appear to flicker. Of course going faster than about 25 fps is not going to really work (that is, it will only appear as 25 fps) as the video signal isn't fast enough!

Now, this OSD is not just for RC planes as the others I mentioned are. Depending on the HUD code that is programmed into it, it can be used on a RC car, and since it does not cost much (and can be usually repaired as the components are common and low cost), you could even use it in hazardous environments (e.g. RC boats, rockets, kamikaze robots, whatever you want.)

The microcontroller, the dsPIC33F, is the core of the OSD. It handles the drawing and the output. There are no dedicated OSD parts in this.

I appreciated any comments on this... supportive, constructive, critical. Please let me know!

Current Plans

• NTSC support Aiming for V3, before December
• Revision 4 PCB Done!
• Settings/Datalogging GUI (will also be open source, based on Python and runs on Windows, Linux and Mac OS X computers)
• Modular design
• FPV version: datalogging @ 25 Hz, 8 inputs (4 HV, 4 unscaled), GPS/I2C, upgraded using FTDI cable or RS232 TTL: initial price $107 USD
• LITE version: no datalogging, only 2 HV analog inputs + 3 normal, GPS/I2C: initial price $71 USD

Current Features (V2)

• Datalogging to SD card, up to 25 times per second
• Outlined graphics (work in progress.)
• 7 analog inputs which can all be recorded (3 x 0-30V, 4 x 0-3V)
• I2C support for virtually unlimited other devices (temperature sensors, gyros, accelerometers etc.)
• GPS support: NMEA over UART

Excellent project!

Will this have GPS capability? This is probably the most important feature of an OSD.

How will you configure it? What options will it be capable of putting on the screen?

-Alex

GPS support is definitely going to be added, when I get my GPS module. Because the dsPIC is processing video at the same time (and thus its 'free time' is somewhat random), I *may* need another chip to handle the continuous readings of sensors. Fear not though, the minimalism will continue with easy to find parts.

A modular system is planned for version 2.5. However, the beta version will just have the sensors hardcoded. A plan for configuration is to use a menus system to program the FLASH memory, or perhaps a computer to generate a settings file. However, all of these are subject to change.

The most important part of this is that it is open source. An interface to other devices is planned. For example, you can attach an Arduino, and put all your code on that, and send commands over an easy to use serial bus to update the display. Or, you can modify the source code if you want. Some programming knowledge is required, but it's easy enough to change values for positions and sizes and so on. So that means you are virtually unlimited in your choice of sensors. Of course you are constrained by the device's limitations, for example don't expect to fit 100 read outs on the screen at 30 fps, but within reason, *anything* is possible.

Excellent project, i watch with anticipation

Thanks for the encouragement guys!!

Things I need to work on:

• There's a bug in the horizontal and vertical line drawing which causes the processor to reset. I had this working earlier, so I think I've just messed about with it too much and need to fix it (was doing some work away from the real circuit.)
• Actually getting a HUD on there. Whilst I don't yet have any data, my prototype just simulated data, and I shall copy this. When I get my GPS in a few weeks or months, I'll see what real data I can get. Then, I want to put it on my real plane.
• If I decide to do so, the modular system. Things like GPS modules and suchlike. How to decide if there is a barometer and a GPS device which to use for say altitude (well, the barometer, but the code needs to know this.)

Here's a picture (screencap) of the original prototype OSD working. The hardware was pretty much the same then. Note that it is incomplete and much more difficult to see. The older version had very poor contrast, that is fixed in this version as you can see. This one was inverted (clear on slightly lighter) because that worked well with its poor contrast. This version had a lot of bugs. The major one, which was the one which convinced me to write the new version in assembler, was its tendency to suddenly reset itself. Due to obscure bugs. Also, the resolution was only 256x128 (I could never get 256x192 working...) But, all those bugs are fixed. This should give you some idea of what I had planned originally.

tom66,
This is great ! This is the missing part in the current chain.
There is an opensource autopilot (ardupilot) but no open source and cheap graphic OSD . Remzibi uses indeed a text based OSD which limits its usage.

1/ If you could plan to have some kind of generic input to display stuff coming from ardu(air pressure, waypoints,...) , that would be excellent. Creating a shield would be nice as well.

2/ Have you look at solution not using sync separator ? it may lower the price : www.elenafrancesco.org/arduino/baroneosd/ but it complexify the solution as well on the software part...

I am not an expert on the electronic part but should be able to help on the software part and I was dreaming that somebody would work on such a thing.

Last thing : Are you planning to put this on google code or equivalent ?
Thx

I was considering doing something similar for my own. It's as shame that you are going to use PIC, not AVR... There are too many people (including me) not allowed to use these by their religion.

Anyway, best of luck for this project.

subbed

what religeon boesnt allow this? lol sorry dont me to be rude

Thanks everyone!

@badzz:
Generic input? Like I2C? Yep, that's on the list of things to do. One of the things I need to work out is how to do clock stretching, and also the command structure.

The sync sep at the moment was used to reduce the complexity of the design. If I can figure out a way to replace it with a comparator, I will, but for now it has enabled me to get a prototype working.

@jedaz:
The dsPIC is not really a PIC. It's completely different. For one, it's a 16 bit architecture.

Also, there are no

movf REGISTER, w
movwf SOMETHING_ELSE

type instructions, which, I have to admit pissed me off with the 16F and 18F chips.

The ONLY few similarities between PICs and the PIC24/dsPIC series is that the dsPICs have a 16 entry working register (W0..W15) which is similar to the idea of the working register W on PICs, and that they are made by the same company, Microchip.

I'm quite a Linux fan (typing this on Ubuntu at the moment), but I do run Windows XP, as seen in the video, to program my micro. It's running in a virtual machine. Just because you like one platform doesn't exclude your from the others. We don't bite, us PIC'ers!

Originally Posted by tom66

...This will be an open source project. That means, anyone can build their own hardware and download the open source software. They can also modify it, and even sell it, provided they contribute the changes back to the community (and me.) The code is not yet released, I am finishing off an "alpha" release before putting it out. The code is written in dsPIC assembly language, over 1300 lines of it.
...

That means will be cloned next month after you issue it and will see it for sale in FPV shops, without even thank you. Don't do this mistake !

GPLv2 software. If they clone it, they HAVE to contribute their changes back or I can sue their asses off. Plus, the hardware is very simple, there is not really anything to clone. The key to this is the software; that's what makes this work. I have made a promise and I will keep it. Just look at Arduino, for example. That gets cloned, right? But most people buy the original Arduino boards!

@tom66 : I was indeed thinking about SPI/Serial bus
@jedas : Indeed there are some beginning of solution using AVR stuff (my link above is currently dead).

http://garydion.com/projects/videoverlay/
http://www.viennawireless.org/balloo...rlay/index.php
http://webcache.googleusercontent.co...ient=firefox-a

Yeah, I've seen those. But unfortunately, you really need a micro with a lot of RAM (~16K) for this project to work. I'm sure Atmel make some, but I had a PICkit 2 already and didn't want to have to get more equipment to program them, so I chose a dsPIC as the quickest way. Also, the dsPIC has a DAC, so I might even be able to give it a voice or at least a variometer.

Oh, and since I2C is open collector, you can do clock stretching on it (delaying processing until the chip is ready.) I don't think you can do the same with SPI, but I could be mistaken.

BTW, I have just got fast vertical lines and rectangles working.

ok make sense and anyway if I get cheap OSD that can display a proper artificial horizon, I would be happy enough.
As for RENATOA's concerns, I don't know if you want to make some money out of it but personally if you can keep it opensource I would feel more comfortable using it.

I wouldn't mind making money out of it. You can still make money out of an open source project.

This one will probably have an artificial horizon, but I won't use it on my plane because I don't have any horizon sensors yet.