How interested would people be in a free, open source hardware/firmware graphical OSD?
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.
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.
Replies to This Discussion
-
Permalink Reply by Torin Segstro on -
Great idea. Also providing Ardupilot/APM shield versions would make it quite popular. Perhaps with an I2C interface?
-
ModeratorPermalink Reply by Alex on -
Yeah i think loads of ppl will be interested if you can manage to interface it with ardupilot as a shield or otherwise if the cost is right, similar to what rambizi OSD does right now
-
Permalink Reply by Thomas Oldbury on -
Thanks for the responses.
@Torin: The interface can be anything you like; it's an open source project. The dsPICs have support for I2C, so adding a simple byte level command interface is certainly something I will consider.
@Alex: The cost is right I think! In total it's cost me less than £10 (~$15) in parts to build. As it is open source anyone can build their own from my plans (which I'll have up in a few days after the pics and videos.)
-
Permalink Reply by Peter Seddon on -
If it is to be closely associated with the Ardu range of products could it be based on an Atmel processor?
Peter
-
Permalink Reply by Thomas Oldbury on
-
@Peter: At the moment, no. The dsPIC DSC was only chosen for four main reasons:
1.) I had a PICkit 2 so no need to invest in other programmers and equipment.
2.) The DSC has 16KB of SRAM. I don't know how many other Arduino processors have 16KB. This amount of memory is critical, because two copies of the video buffer must be stored.
3.) The DSC is 16-bit. Atmel do make 32-bit processors, but 16-bit is a good middle ground between full blown processor and tiny microcontroller, I think. Having a 16-bit address word allows for drawing more pixels at a time in optimised routines (for example, drawing a horizontal line, you can write up to 16 pixels at a time.) Also, the dsPIC architecture is very optimised for this kind of thing. For example, to set a pixel on, you can set a pixel on or off with an OR mask in one cycle: W5 = W5 | W2 operations and similar are all supported in single cycles.
5.) Microchip were very kind to send me two free chips because I asked them nicely and told them I was a student (which is correct.) This may well turn out to be my project for college; I'm doing electronics there.
Also, the code has already been written for the dsPIC (in assembly); it could be written for Atmel processors but I'd have to start from scratch and learn another assembly language.
-
Permalink Reply by Thomas Oldbury on
-
It seems I skipped a number, above it should go 1-4 not 1-3 and then 5. I'll have some pictures up soon and a video on YouTube hopefully (showing animations and how it can draw really fast.)
-
Permalink Reply by Thomas Oldbury on
-
Update:
Here is a video of the OSD displaying a demo/about page: http://www.youtube.com/watch?v=RE18gHRUR40
-
Permalink Reply by Dr Mike Black on -
Thomas,
Def up for that....was playing with a max ic yesterday having a think, but its sich low res...you seem to have cracked that..
keep us unformed..if you need help just ask,
Mike.
-
Permalink Reply by Thomas Oldbury on
-
The MAX7456 right? I had that as my backup plan, in case I couldn't get this OSD working. Maxim were incredibly kind to send me two free chips as part of my school project. They are nearly £18 each here, so that's a lot of money to spend on a chip that I might not even use! I'm glad I got this working because it opens up so much more possibilities.
Thanks for the offer of help. I will be preparing a source code release soon-ish. Once I get the major features working. Don't want to release a broken or incomplete product...
-
DeveloperPermalink Reply by John Arne Birkeland on -
I watched the demo video and the OSD graphics looked very nice. Much better then what the MAX is capable of. So good work! But.. :) The video looked a bit blurry (watched at 480p) and had a choppy frame rate. If this just the result of a cheap camera and low light, or does the OSD degrade the video when inserting graphics?
-
Permalink Reply by Thomas Oldbury on
-
Fear not, that's the result of a cheap TV card interlacing the video twice. I'll figure out a way to fix this (it might involve me getting another TV card, I have two going spare.) The frame rate is limited because the desktop I have is only a Pentium III and it supports about 20 fps recording from my TV card continuous. The only degradation is the slight dot crawl on the edges of the text, but this is unavoidable with composite signals.
-
Permalink Reply by Thomas Oldbury on
-
Google Code link to hardware + software:
http://code.google.com/p/super-osd/
(Software will be uploaded in 30 minutes, got to extract it from Win XP)
Social Networking
Top Content
Contests
Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.A list of all T3 contests is here.
Groups
-
ArduCopter User Group
1299 members
-
Documentation Editors
51 members
-
Melbourne
48 members
-
UK Ardupilot Group
111 members
-
Agricultural UAVs
137 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
