Hi,

Have been working on an OSD compatible with MinimOSD, but based on a STM32F4. The OSD can do vector graphics and also can send data to the ground station using the unused frames after the Vsync pulses ( like teletext).( I use this to send data to my antenna tracker.) The OSD is desigtned to be a drop in replacement for MinimOSD and accepts Mavlink data.  Also has 2 audio channels ( so can be used e.g fo vario) and various peripherals ( serial port, i2C, SPI and PWM capture etc,) broken out on headers.

Here is a video of the prototype working

regards

Andy

Views: 7173

Reply to This

Replies to This Discussion

Very nice to finally see something like this :) We'll be able to display much more data, in much more readable and intiutive way.

Well done.  Will this be a product for purchase ? , purchase PCB+get open source, or open all the way ?

Looking forward to it anyway.

I can imagine you'll listen on to I2C for smooth AHI.

BTW: for me, the most important part is the video processing onboard of UAV, because plain telemetry(with proper antennas) have longer range any time.

Very exciting project! I'll be watching closely with anticipation. Thank you.

Thanks for the feedback.

Yes, it is an Open Source project. I hope to put the source on my Github account soon.

As for the PCB, I would like to Open Source Hardware it, but with all its components being small smd, I dont see I would get too many takers for a kit. I would certainly welcome advice, links and ideas on how to get the board ( or rather a MK11 version) manufactured though as I am pretty clueless about that. I got the originals done at OSHPark and a very nice job too. They were populated by hand, but I dont recommend that unless you are a masochist :)

Before proceeding, I should provide some attributions. This is far from being all my own work. The driver code is based on work by Sami Korbonen who did a prototype using an STM32F4 for Openpilot. That code was then taken up by TauLabs and the BrainFPV project. Sami Korbonen in turn built on the work of Thomas Oldbury ( SuperOSD) mainly for the prototype display design.

The OSD was started because I wanted to use the video signal for sending telemetry data to my antenna tracker. I have been using the Frsky telemetry link and more recently FSK via a video audio channel, but the commercial antenna trackers are all moving to this method because (at least as teletext) it is meant to give better range.. see here for details

The processor used is the STM32F4. The OSD uses 2 bits per display pixel and is capable of outputting Black, Grey and White as well as transparent. The display can be interlaced or non-interlaced. The display size is adjustable within constraints. The size of a pixel in x is adjustable, by adjusting the pixel clock. The Hardware uses 2 SPI ports which are set up in slave mode so the MISO pins are outputs. The SPI's are both clocked by the same pixel clock. The SPI's are loaded by DMA and the data outputs are used to address a 4:1 analog multiplexer whose inputs are the display colours. The code departs from previous work AFAIK in using software to deduce the vsync pulse and odd/even frame. This was done to save money and board space on a dedicated sync sep IC, as I coulnt find any under SOIC8 size.

The board bases its I/O on the MinimOSD, so it's designed to be possible to replace MinimOSD with this board
without changing connectors. There are a couple of minor differences. The 6 pin header used on MinimOSD for the MAVlink Serial port has all the active pins of the MinimOSD but, on this board, the unused pins are used to provide a second bi-di serial port on which the Tx pin can be optionally inverted. (This is used in the prototype to send data down a FrSky Receiver telemetry link). Another difference is that the serial ports on the 6 pin header are completely electrically isolated from the rest of the board using the equivalent of an opto-isolator. This is done so that the video circuitry is insulated from the noise of the FC, servos etc and avoids "ground loops" which so often cause interference on the display. You need to provide 5v on this connection but this is available on the original comnnector so shouldnt cause major problems. Jumpers are provided so you can join the two parts if you wish... but not recommended!

At the other end of the pcb, as with MinimOSD, lies the video I/O, the pins are arranged as on MinimOSD, except that 2 extra audio outputs ( Left and right) are provided. These are connected via buffer amps and decouple caps to the STM32 DAC outputs. On the prototype the audio output is used to provide FSK telemetry data ( Though this is redundant with the new use of the video frame to convey data).

The use of DMA coupled with the high performance of the STM32F4 means that there is ample processor
bandwidth available for other tasks. To that end all unused pins are broken out on headers.  As well as the above mentioned video, audio and serial port ports the following peripherals are also available as raw header pins.
 
 1 serial port ( so total 3)
 2 I2C ports
 1 SPI port
 6 Analog inputs
 4 pwm/capture/compare I/O
 1 CAN interface
 
 There are also various other general I/O for switches/LEDS etc.  In fact the  BrainFPV board uses the same MCU to power a complete FC, so I am sure this board will be able to do that too. One long term goal is a port of PixHawk/ APM to the board.

 Finally, as well as Display, the OSD is designed to act as either a Transmitter or Receiver of data, using unused  parts of the Video signal. The Data rate is adjustable. Currently using around 60k bits per sec ( ie continous throughput but much higher instantaneous bitrate at about 2 MHz in the video line), though it should be possible to go to nearly 3x that ( with possible a trade off between range and data rate), but it should be possible to send raw MAVLink (or any other) data at a a good rate through the link.
 
 Because it involves no extra hardware connectors antennas and cables, airborne or ground, the use of the video signal to convey data is very attractive, however for redundancy, on the prototype there are 3 simultaneous ways to communicate telemetry data; via the audio, the video and the RC link. You can add a further dedicated telemetry link too of course..
 
 During the design of the electonics, I have also tried to keep in the spirit of MinimOSD, so
 I have used a switching regulator to provide a 5V output, though I worked to an output of 200 mA only ( MinimOSD appears to be designed for 1A?) and also provided extra filtering at the inputs and outputs to pass EMC testing which is quite strict here in UK an also to avoid interference to the various other rf parts of the aircraft. Overall, I have worked to avoid too many expensive components to try to keep the costs down.
 
Software wise the main ingredient is the use of OpenRTOS, so it is relatively easy to provide your own custom tasks.

In order to customise the display I am looking at various options.  but initially the idea is to provide the declaration of an "OnDraw" function that you write your own implementation of ( or use one predone), but which insulates you entirely from having to worry about low level details of the Display driver.

There will be a suitable API eg to draw lines circles, text etc, as well as variables providing the system state , e.g battery level, yaw, pitch roll, gps etc etc. , which I am now working on. Currently you would write the function in C or C++, but another option is to enable scripting the OnDraw function using for example micropython.

I am also currently writing a PC app so that you can design fonts and bitmaps which can be uploaded to the board, in fact there is much work to do overall so from being a simple telemetry option for my tracker, the project has spiralled !

Anyway all comments, suggestions and ideas very welcome....

regards
Andy


 
 
 
 
 
 
 




to start manufacturing of custom boards, of decent quality (no manual soldering) you'll need some volume to make the set-up of manufacturing worth it.

I suggest you do a little more visual software demo, and got for a kickstarter to get the funding needed to start manufacturing.

My guess is that you will have very good response. this project is what's needed to finally get us something of RVOSD fidelity.

This is just outstanding!

I saw the BrainFPV video and was impressed with the OSD - I liked the vector graphics, the ability to mask an area, and the double buffering. Overall more flexible than any of the 7456 based designs. Would your s/w run (with reasonable adaptation) on the BrainFPV h/w until there is some way forward for a dedicated OSD? 

Andrew

+1 to crowdfunding


Using the BrainFPV hardware should be entirely possible, easier since the MCU is the same for both BrainFPV and my board. There are bound to be low level issues but I dont know those yet as the BrainFPV schematic isnt available AFAIK. However the interesting part to most would be the OSD Drawing API, which should hide all those details under an abstraction. The BrainFPV code and my code both use 2 buffers AFAIK. You are writing a new one as the hardware is rendering the old one. So I would sa...y yes, it  should be possible.

It should also be possible to Port APM to BrainFPV and or my board and get the OSD on top.. Dont see why not.


As to a suitable API. First choice is language. the OSD API I am writing is in C++11. The reason for this choice is that in C+ you can use operations on vectors  e.g addition, subtraction, multiplication by a scalar etc. This together with the other features of C++11 makes the code more compact and the source much easier to read in this application. It wont make some happy but it speeds stuff up. An alternative C API would prob be worth doing though...

The most important primitive type for the OSD API after the builtin types is a 2D vector type , which I herafter call a 'vect2d' to distinguish it from the std::vector. The vect2d is a class template so you can have integer or floating point vectors ( or even indeed vect2d and a 3D version vect3d with physical length units if you wish, which comes in very useful in 3d dimensions. (See my quan library for more info about physical quantities)   Using the vect2d class, with its operations, dramatically reduces source code over simple use of int or float x,y values and ops. The source of the vect2d I use is in my quan library on github

In the OSD application I use the following typedef :

typedef quan::two_d::vect<int> pxp_t; // pxp for "pixel position"

The same type is also used to represent sizes. ( Without wanting to get bogged down, vectors work well enough for both uses)

typedef quan::two_d::vect<int> pxs_t ; // pixel size type

On the raw display the point [0,0] is at top left. After trying this for a while I eventually decided on a transform so that the point [0,0] is dead centre of the screen and y increases up. (x increases to the right as usual). The transform function is pretty simple and therefore is user definable if you dont like the default.

Also useful are boxes for drawing ,clipping  and finding the display limits etc

typedef quan::two_d::box<int> box_t;

angles ( both degrees, radians and others can be used and trig functions 'just work'[]

typedef quan::angle::deg angle_t;

Finally colours. One day it would be nice to do full colour but meanwhile its monochrome:

enum class colour_t{unknown,black,white, grey, transparent};

also bitmap_t representing bitmaps and font_t's representing fonts ( just an array of bitmaps indexed by character)

So far the following display drawing operations are available ( some params are in fact references/pointers.. ignored for clarity here):


void set_pixel(pxp_t px, colour_t c);
void set_pixel_raw(pxp_t px, colour c); // without the display transform
colour_t get_pixel( pxp_t pos);
void line(pxp_t from, pxp_t to, colour_t c);
void circle(pxp_t centre,int radius, int numsegments, colour_t c);
void arc(pxp_t centre, int radius, angle_t start_angle, angle_t end_angle, int numsegments, colour c);
void floodfill(pxp_t pos,colour c);
void rectangle(box_t box, colour c);
void bitmap(pxp_t pos, bitmap image);
void rotated_bitmap(pxp_t pos, bitmap image,pxp_t rotation_centre,angle_t angle);
void text(pxp_t pos,string str,font_t font);

void setclip(box_t box);

pxs_t get_display_size();



Currently the higher level API stuff exists as a sim ( in wxWigets in Linux) on my PC so I can work on the higher level stuff more easily, but I am pretty sure the code as written should port to the board quite simply.

I hope to put everything ( including the Schematics and PC sim) up on Github ASAP. Its just a question of adding acknowledgments checking copyrights etc to the sources, generally tidying up and getting around to it... However the plan is to Open Source the whole Kaboodle

The Kickstarter idea is interesting. I am looking at PCB manufacturers to see what sort of costs and scaling is required.

regards

Andy

If it goes Kickstarter, I am in. I am so tired of the limitations of the 7456 graphics, and your approach gets around that. There should be an opportunity for someone to come up with a product for sale.

Just interested in using it on the BrainFPV as that H/W is available now. Hopefully I can work out the low level issues by checking the source code. 

I certainly don't think it would be difficult undercutting Brain FPV on price. It Would be a diversion from my original purpose though which is to provide telemetry for my Antenna Tracker.

My hunch is it's going to happen one way or another. Kickstarter is one of various options.. Initially Since I am going to open source the board(EDIT boards.. hope to make a V2 soon), there will be hardware available to hackers shortly , (so I better get on and put it on Github and perhaps OSHPark for the hardware) If that takes off then larger scale manufacturing will surely follow...

regards

Andy

Hi again,

I'm pleased to announce that all the source for both software and hardware for the OSD is up on Github. Its all in my quantracker repository.

The firmware for the board is in https://github.com/kwikius/quantracker/tree/master/air/osd. To build the finished board firmware do  'make board_type4' in that directory. If you try the Makefile, I have no doubt there will be issues so please report and I'll try to fix. The schematic and pcb design which is done in KiCad is available in https://github.com/kwikius/quantracker/blob/master/air/osd/hardware...

If you are feeling adventurous you can send the board to OSHpark. The zip for the board shown is here

Please note there is very liitle of the higher level API yet, but the low level stuff is there. Also note that the board is a worki in progress as everything else. The finished board will have some changes, though this one works as drawn without any issues..


regards
Andy

Thank you Andy.

Ordered three PCB from OSHpark today. That part was painless - soldering those 0603 parts will be more of a challenge.

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service