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
Replies
This is way cool. Vector is for sure the way to go. I like the STM32F4, too.
For the user programming interface you might want to have a quick look at the Decade Eng Bob-4 doc.
http://www.decadenet.com/
The graphics primitives are modeled on PostScript. See the Vector Graphics Commands section at:
http://www.decadenet.com/bob4/B4AppGuide.pdf
Here's an example I did that they link to:
https://www.youtube.com/watch?v=06lgzyAI164
Cheers,
Colin
Hi Colin,
The compass looks good. I decided to go down a similar road! The rotating compass is much more compact now using vector graphics than scrolling text horizontally, as well as being faster,easier and more intuitive to read, so clearly to me already a win for vector graphics. As for the language or commands in your link, I see no reason one couldnt put a parser in the code. Maybe being based on Postscript there is already one around for that task. Its a pretty flexible board with various peripherals available
I'm having a go at some proper documentation. It doesnt come easy but anyway, here is the start of it
Quantracker Air V1 OSD - getting started
regards
Andy
Looking good Andy. One thing scares me: you say "The Board is designed to be used with Ardupilot."
I'm going to be able to use it without an Ardupilot, right?
Thanks man,
Colin
Good point. I've edited the docs now to read "The initial board firmware is designed to be used with Ardupilot". also fixed some broken links.
Should probably document the low level API too, and separate that out so you can build your own higher level API if you wish..
Fun times ahead :)
regards
Andy
Better and better Andy.
C.
Hi Andy,
Very nice development, good to see that other STM32F4 based OSDs are starting to show up :). For prototype soldering, I recommend using a stencil (check out oshstencils.com) and a vacuum pen to place the components. I have been using a DIY vacuum pen, basically an old pen with a slightly bent solder paste needle at the front and some aquarium tube to make a vacuum using the mouth. It allows placing components very precisely; 0402 is no problem, the MPU-9250 (3x3mm QFN28) is a bit more tricky ;).
Anyways, I will keep watching your developments and best of luck with your project.
Martin
Hi Martin.. Thanks for dropping by :)
My main interest is in the Graphics API. Since this shouldnt be affected at all by the low level code, then I hope it will be easy to port the API for mine to BrainFPV Hardware and vice versa, so the outcome should be beneficial on all sides. :)
As to soldering, your vacuum pen sounds like a nice idea to try. Till now, my soldering equipment is just an Antex C15 soldering iron and fine solder wire, flux pen desoldering braid and tweezers! I will have to try a stencil and solder paste on the next board. I suppose then I will need other equipment.. a hot plate and a hot air soldering iron or something.
Anyway Here is my initial work on a PC app to create custom displays. A long way to go and I dont quite know how a lot of it will work, but anyway...
Once this is done, the next item on the list is an Open Source FPV OSD with Color !
regards
Andy
Just a heads up that the PCB is now also available as a shared project on OSHPark but bear in mind it does require quite good soldering skills, so not or the faint-hearted :)
There were several problems with the original sources and Kicad project, but I hope these have now been fixed.(Thanks Andrew Fernie).
The current state of the API is summarised here
The current implementation is here. The implementation is currently pretty simple. No optimisatison for horizontal and vertical lines for example, since, according to Knuth premature optimization is the root of all evil. The arc code is a bit messy but merely as I started from circle drawing code and tried to figure it from there. Anyway its the interface that is important at the moment :)
The API is designed with the idea (as it stands) to write some code that will either build into a shared library on your pc that can be called to draw the same image in a sim or to create the firmware for the real OSD. I hope at some stage that it will be possible to inject some real time stimulus ( e.g APM log files for example) into the PC version to test it out and give you a more realistic idea of the finished effect. Ideally once you are happy with the sim, you press a button to build the real firmware and upload it to the board. This is made easier by using gcc, the same compiler to generate the code in both cases. GCC - triumph of Open Source :)
Ive tried to keep the API simple. It turns out that (I think - ignoring optimisations) only the set_pixel_raw(Pos, color) and get_pixel_raw(pos) functions definitions are actually hardware dependent. That makes the "device" pretty simple to represent and new devices easy to cater for I hope ( e.g printers etc). Ther is a lot of stuff missing.. ellipse springs to mind. reversed text set_clip_rect etc.. so a fair bit to do.
Ive used functions only in the interface since I reckon its easier to future proof functions. Objects dont seem to future proof that well.
The hardest part of the interface seems to be to represent the aircraft part, since they are all different ( e.g electric need batteries, petrol needs gas, quadcopter v plane etc) I guess I should study how APM does it, but may have to cobble something temporary together to get a useful demo display! At the moment I'm just planning to use free functions for that too.. Will see how that goes..
Also, I hope that it will be easy to make a C API relatively simply.
So to sum up .. still beavering away and hope to have something useful running on the board before too long
regards
Andy
This is the hard part, isn't it? It's like you can't please everybody, on steroids.
For example for my rover I am for sure going to want on-screen graphical representation of Lidar-lite data. I might want to use the I2C interface, or I might want to use the PWM interface.
The guy next to me with a boat really, really wants a depth sounder display. Data might be Analog or UART, or maybe it's SPI. And so it goes.
Maybe if people could easily build and share their own graphics components we'd build up a library.
And then have some totally abstracted way of hooking it to an arbitrary input.
A general solution is tough, no question.
C.
Have been giving this some thought and tried making a graph, which is here.
Although it looks quite complex, I dont think its impossible to characterise a particular vehicle and you can specify more or less detail. (I havent joined all the dots and in practise you would only add the bits for that type of vehicle so it would look simpler
Source is attached (done using graphviz)
Anyway will continue to play around with it!
regards
Andy
vehicle_types.dot
-
1
-
2
-
3
-
4
-
5
of 5 Next