Hi all.For the past few weeks I have been working on a personal project in my spare time before I start my first day of college.The project is to develop a high resolution graphical on screen display for PAL, NTSC and possibly SECAM video signals. The intended application in my case is to stick a camera, OSD module and video transmitter on my model plane and fly it away, whilst getting readouts of various statistics.It already works. I have a graphical OSD working, with shapes, fills, lines, text and images working. It works better than I expected. :)The current specifications are:- At the core, a Microchip dsPIC33FJ128GP802 processor. This was mainly chosen because it's got the most amount of RAM/FLASH in a DIP package and I can easily get them on my breadboard. Also because I already have a PICkit 2 programmer. This processor runs off the 7.37 MHz fast RC oscillator with PLL to boost it to just about 39.7 MIPS slightly under its rated 40 MIPS.- Dual buffered 256x192 pixel display; pixels are either transparent or white. 12K of video RAM is used. Dual buffering allows a new display to be written to the DRAW buffer and then swap the buffers; this makes the screen change instantly; no flickering is seen.- An LM1881 is used to syncronise to the signal. I would like to eliminate this, however, it makes the initial design easier. It also improves the stability of the OSD; I found using a comparator has the difficulty of determining the vertical blanking period of the signal.- Has a 5x5 font which is hand designed by me (based off the Silkscreen font but fixed to 5x5 whereas Silkscreen has some non-5x5 chars.) This font is quite small on the screen, so I am considering a 8x14 terminal style font. 256 pixels allows about 50 characters horizontally and 38 characters vertically with the 5x5 font.- Powered from +5V (+3.37V supply for dsPIC33F, using an LM317T.)- All code written in assembly language. The first version used C, but that had too many problems, so I decided to rewrite it in assembler, which made it much faster and fixed many bugs.- Accelerated drawing of horizontal and vertical lines of any length. Accelerated drawing of any line in odd quadrants.- All video processing done during the horizontal blanking interval and vertical blanking interval. Only 3 MIPS out of the 39.7 MIPS are available for processing, so the code has to be fast (see above.) Previous C version reached 10 fps doing a full F-22 OSD, target is at least 20 fps for this version and possibly even 30-40 fps (faster than the video signal!)- Doesn't yet support NTSC... however, this is trivial to add, as all it requires is changing the scaling factors for the display and adjusting some timing parameters. No code changes should be necessary, as NTSC and PAL signals are very similar. SECAM support is being considered but I have seen very few SECAM cameras so this is not planned yet.I'm currently away from my project at the moment, so I can't post any pictures, but I'll have some up soon. So please, everyone let me know what you think, and if you want to see this go further. I'm certainly going to be using it myself on my model plane, and I hope other people can benefit from my 2 weeks or so of work on this project.This will be an open source hardware and software design most likely.
You need to be a member of diydrones to add comments!
As far as "features" for an open source OSD, I would make getting the source code back to C or some high level language a priority. I don't have the patience for trying to understand and then modify assembly ;)
Great work Thomas. I have been looking for a while something like this due MAX chip only supports raw text on screen. But there are big need for lines and things like that.
As for data logging and extra cpus on board. Yes if you plan to have standalone board then you can add those but if you plan to have it co-working with ArduPilot, UAVDevboards and other, no don't put anything extra. All extra also creates more weight and biggest thing is that every component eats more those precious mAh's
On your screen capture picture all characters were blurred? Is that on real life like it too or just in picture due sync issues?
Would people prefer an OSD with black/white support but with a reduced resolution of 192x128? It would still have double buffering. I am considering the idea. Let me know your opinions on this.
Lots of questions. Maybe I didn't understand some, and maybe my opinion would change if I though about it overnight. But here is my current think:
"* Would people like to see a populated (i.e. no soldering required) PCB for sale? Is it worth me manufacturing and selling PCBs? I'm only a student, but the extra cash flow could really help!! Also, it would be a great way to see my project go somewhere."
Pizza money would be nice. More important is the practical experience you can offer an employer, or for your own business later.
"* If people wanted to save a bit of money, would they like kit PCBs, with all the components supplied, but soldering and a steady hand required?"
That would be a good idea. Do like others do: (1) Bare board. (2) Kit of board, possibly pre-mount SMT devices & let people put on thru hole components and connectors & wiring. (3) Already assembled.
"* Would you like buttons on the OSD module so menus and settings can be activated? Or would some RC channel have to be used?"
RC channels are in short supply. A limited number of buttons are OK. Think EASY to use.
"* Sensors: Voltage, current are definite. How about RSSI? AHI? How much resolution? I was thinking two digits (like 7.32V), but three digits are definitely possible (7.323V.) It depends on the range used. Precision would depend on the voltage divider but no more than about ±1% (about what you would get out of a <$100 multimeter.)"
So you want to have analog sensors on board? Makes it a lot more complex. And is duplication. (We already have voltage, etc.) I guess if you want to have a couple of analog inputs for people who want them, you can. Maybe put those parts on a shield? As far as I'm concerned, the critical parameters are already known to the autopilot so let the autopilot communicate them to you digitally. Don't require a second GPS. Don't require a Y-cable to share a GPS.
Recognize a handful of common parameters and define where on the screen they will go, and whether they are text or horizontal or vertical tape measure, or a horizon reference. Let people mod the code to add additional parameters. (Make it clear and heavily commented.)
ex. You recognize the string "Alt:340; Pitch:5; Roll:0" and print altitude on the screen and use pitch and roll to draw an artificial horizon. You may want to accept a compressed, binary format.
Possibly recognize some sort of position command to place the cursor for undefined (text) parameters or override the default placement.
ex. "Beer:4@12,2" Would draw the text "Beer:4" beginning on row 12, in column 2. (or column 12, row 2 as you prefer)
Resolution/precision issues. Probably two after the decimal is enough. Really depends on what you are showing. In reality, anything more than 3 or 4 significant figures is (a) within the noise; (b) hard for a human to process in real time. Motor current of 105 amps is good. 105.34 amps doesn't make it better. Altitude of 3450 meters is good. 345.0 meters is good. 34.5 meters is good. 3450.12 meters is not better.
"* Would people mind an extra microcontroller? It would be dedicated to handling GPS and other sensors like magnetometers. It makes it less simple, but more versatile. It might even be an AVR (or be compatible with PIC or AVR, solder in your choice); the choice of micro is not too important here."
Prefer to not have more more parts & more mA's. How much processing power do you have left to work with?
"* How about a PC interface?"
Use the six pin interface that Arduinos & such use, so that we can continue to use our multi-platform (PC/Mac/Linux) FTDI cables to connect to computers. No new interfaces. No new drivers that only work with just 1 platform & version.
Write a test program in Processing / Java, so that it car run on most any computer, that feeds serial data to the OSD.
"* Arduino or other microcontroller interface?"
5v or 5v tolerant TTL level serial. 3.3V TTL serial if you must.
"* Finally, would people buy any of these? The price would be low. I estimate less than $65 (~£41) for the populated PCB and $35 (~£22) for the blank PCB + components.
If the video quality was good and it was easy to use.
"* I was also considering datalogging through an SD card. A 2GB SD card (about $3.99 on eBay) has at least 4 million x 512 byte sectors. Each sector could store a single datalogged point. That means, even if you are logging 25 times a second, you have 160,000 seconds (just over 44 hours) of recording!! Would people be interested in seeing this?
Last time I tried writing to an SD card using an Arduino, it was an exercise in frustration. If you can make the data logging (and reading back out on the ground) EASY, and multi-platform, you would add value.
I posted the same questions on RCGroups; but I'd like some more opinions:
I want to ask a few questions about where to go from now:
* Would people like to see a populated (i.e. no soldering required) PCB for sale? Is it worth me manufacturing and selling PCBs? I'm only a student, but the extra cash flow could really help!! Also, it would be a great way to see my project go somewhere.
* If people wanted to save a bit of money, would they like kit PCBs, with all the components supplied, but soldering and a steady hand required?
* Would you like buttons on the OSD module so menus and settings can be activated? Or would some RC channel have to be used?
* Sensors: Voltage, current are definite. How about RSSI? AHI? How much resolution? I was thinking two digits (like 7.32V), but three digits are definitely possible (7.323V.) It depends on the range used. Precision would depend on the voltage divider but no more than about ±1% (about what you would get out of a <$100 multimeter.)
* Would people mind an extra microcontroller? It would be dedicated to handling GPS and other sensors like magnetometers. It makes it less simple, but more versatile. It might even be an AVR (or be compatible with PIC or AVR, solder in your choice); the choice of micro is not too important here.
* How about a PC interface?
* Arduino or other microcontroller interface?
* Finally, would people buy any of these? The price would be low. I estimate less than $65 (~£41) for the populated PCB and $35 (~£22) for the blank PCB + components.
* I was also considering datalogging through an SD card. A 2GB SD card (about $3.99 on eBay) has at least 4 million x 512 byte sectors. Each sector could store a single datalogged point. That means, even if you are logging 25 times a second, you have 160,000 seconds (just over 44 hours) of recording!! Would people be interested in seeing this?
I have a basic HUD almost complete. Compass and airspeed indicator working. Flashing text working. Next step: altitude. Also, an artificial horizon.
Replies
As for data logging and extra cpus on board. Yes if you plan to have standalone board then you can add those but if you plan to have it co-working with ArduPilot, UAVDevboards and other, no don't put anything extra. All extra also creates more weight and biggest thing is that every component eats more those precious mAh's
On your screen capture picture all characters were blurred? Is that on real life like it too or just in picture due sync issues?
Keep up the good work.
https://www.youtube.com/watch?v=z-XPvLYYHSI
http://dl.dropbox.com/u/1134084/Screencap%20dev%201.jpg
More features coming soon!
"* Would people like to see a populated (i.e. no soldering required) PCB for sale? Is it worth me manufacturing and selling PCBs? I'm only a student, but the extra cash flow could really help!! Also, it would be a great way to see my project go somewhere."
Pizza money would be nice. More important is the practical experience you can offer an employer, or for your own business later.
"* If people wanted to save a bit of money, would they like kit PCBs, with all the components supplied, but soldering and a steady hand required?"
That would be a good idea. Do like others do: (1) Bare board. (2) Kit of board, possibly pre-mount SMT devices & let people put on thru hole components and connectors & wiring. (3) Already assembled.
"* Would you like buttons on the OSD module so menus and settings can be activated? Or would some RC channel have to be used?"
RC channels are in short supply. A limited number of buttons are OK. Think EASY to use.
"* Sensors: Voltage, current are definite. How about RSSI? AHI? How much resolution? I was thinking two digits (like 7.32V), but three digits are definitely possible (7.323V.) It depends on the range used. Precision would depend on the voltage divider but no more than about ±1% (about what you would get out of a <$100 multimeter.)"
So you want to have analog sensors on board? Makes it a lot more complex. And is duplication. (We already have voltage, etc.) I guess if you want to have a couple of analog inputs for people who want them, you can. Maybe put those parts on a shield? As far as I'm concerned, the critical parameters are already known to the autopilot so let the autopilot communicate them to you digitally. Don't require a second GPS. Don't require a Y-cable to share a GPS.
Recognize a handful of common parameters and define where on the screen they will go, and whether they are text or horizontal or vertical tape measure, or a horizon reference. Let people mod the code to add additional parameters. (Make it clear and heavily commented.)
ex. You recognize the string "Alt:340; Pitch:5; Roll:0" and print altitude on the screen and use pitch and roll to draw an artificial horizon. You may want to accept a compressed, binary format.
Possibly recognize some sort of position command to place the cursor for undefined (text) parameters or override the default placement.
ex. "Beer:4@12,2" Would draw the text "Beer:4" beginning on row 12, in column 2. (or column 12, row 2 as you prefer)
Resolution/precision issues. Probably two after the decimal is enough. Really depends on what you are showing. In reality, anything more than 3 or 4 significant figures is (a) within the noise; (b) hard for a human to process in real time. Motor current of 105 amps is good. 105.34 amps doesn't make it better. Altitude of 3450 meters is good. 345.0 meters is good. 34.5 meters is good. 3450.12 meters is not better.
"* Would people mind an extra microcontroller? It would be dedicated to handling GPS and other sensors like magnetometers. It makes it less simple, but more versatile. It might even be an AVR (or be compatible with PIC or AVR, solder in your choice); the choice of micro is not too important here."
Prefer to not have more more parts & more mA's. How much processing power do you have left to work with?
"* How about a PC interface?"
Use the six pin interface that Arduinos & such use, so that we can continue to use our multi-platform (PC/Mac/Linux) FTDI cables to connect to computers. No new interfaces. No new drivers that only work with just 1 platform & version.
Write a test program in Processing / Java, so that it car run on most any computer, that feeds serial data to the OSD.
"* Arduino or other microcontroller interface?"
5v or 5v tolerant TTL level serial. 3.3V TTL serial if you must.
"* Finally, would people buy any of these? The price would be low. I estimate less than $65 (~£41) for the populated PCB and $35 (~£22) for the blank PCB + components.
If the video quality was good and it was easy to use.
"* I was also considering datalogging through an SD card. A 2GB SD card (about $3.99 on eBay) has at least 4 million x 512 byte sectors. Each sector could store a single datalogged point. That means, even if you are logging 25 times a second, you have 160,000 seconds (just over 44 hours) of recording!! Would people be interested in seeing this?
Last time I tried writing to an SD card using an Arduino, it was an exercise in frustration. If you can make the data logging (and reading back out on the ground) EASY, and multi-platform, you would add value.
I want to ask a few questions about where to go from now:
* Would people like to see a populated (i.e. no soldering required) PCB for sale? Is it worth me manufacturing and selling PCBs? I'm only a student, but the extra cash flow could really help!! Also, it would be a great way to see my project go somewhere.
* If people wanted to save a bit of money, would they like kit PCBs, with all the components supplied, but soldering and a steady hand required?
* Would you like buttons on the OSD module so menus and settings can be activated? Or would some RC channel have to be used?
* Sensors: Voltage, current are definite. How about RSSI? AHI? How much resolution? I was thinking two digits (like 7.32V), but three digits are definitely possible (7.323V.) It depends on the range used. Precision would depend on the voltage divider but no more than about ±1% (about what you would get out of a <$100 multimeter.)
* Would people mind an extra microcontroller? It would be dedicated to handling GPS and other sensors like magnetometers. It makes it less simple, but more versatile. It might even be an AVR (or be compatible with PIC or AVR, solder in your choice); the choice of micro is not too important here.
* How about a PC interface?
* Arduino or other microcontroller interface?
* Finally, would people buy any of these? The price would be low. I estimate less than $65 (~£41) for the populated PCB and $35 (~£22) for the blank PCB + components.
* I was also considering datalogging through an SD card. A 2GB SD card (about $3.99 on eBay) has at least 4 million x 512 byte sectors. Each sector could store a single datalogged point. That means, even if you are logging 25 times a second, you have 160,000 seconds (just over 44 hours) of recording!! Would people be interested in seeing this?
I have a basic HUD almost complete. Compass and airspeed indicator working. Flashing text working. Next step: altitude. Also, an artificial horizon.
http://code.google.com/p/super-osd/
(Software will be uploaded in 30 minutes, got to extract it from Win XP)
Here is a video of the OSD displaying a demo/about page: https://www.youtube.com/watch?v=RE18gHRUR40
-
1
-
2
of 2 Next