Developer

OSD with vector graphics compatible with MinimOSD

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

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

    • 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

      • Developer


        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. 

          • Developer

            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

    • This is just outstanding!
    • 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.

  • Very exciting project! I'll be watching closely with anticipation. Thank you.
  • 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.

This reply was deleted.

Activity

DIY Robocars via Twitter
RT @chr1sa: Donkeycar 4.4 released with tons of new features, including path learning (useful with GPS outdoors), better Web and Lidar supp…
Nov 27, 2022
DIY Robocars via Twitter
RT @NXP: We are already biting our nails in anticipation of the #NXPCupEMEA challenge! 😉 Did you know there are great cash prizes to be won…
Nov 24, 2022
DIY Robocars via Twitter
RT @gclue_akira: レースまであと3日。今回のコースは激ムズかも。あと一歩 #jetracer https://t.co/GKcEjImQ3t
Nov 24, 2022
DIY Robocars via Twitter
UC Berkeley's DIY robocar program https://roar.berkeley.edu/
Nov 24, 2022
DIY Robocars via Twitter
RT @chr1sa: The next @DIYRobocars autonomous car race at @circuitlaunch will be on Sat, Dec 10. Thrills, spills and a Brazilian BBQ. Fun…
Nov 24, 2022
DIY Robocars via Twitter
RT @arthiak_tc: Donkey car platform ... Still training uses behavioral cloning #TCXpo #diyrobocar @OttawaAVGroup https://t.co/PHBYwlFlnE
Nov 20, 2022
DIY Robocars via Twitter
RT @emurmur77: Points for style. @donkeycar racing in @diyrobocars at @UCSDJacobs thanks @chr1sa for taking the video. https://t.co/Y2hMyj1…
Nov 20, 2022
DIY Robocars via Twitter
RT @SmallpixelCar: Going to @diyrobocars race at @UCSDJacobs https://t.co/Rrf9vDJ8TJ
Nov 8, 2022
DIY Robocars via Twitter
RT @SmallpixelCar: Race @diyrobocars at @UCSDJacobs thanks @chr1sa for taking the video. https://t.co/kK686Hb9Ej
Nov 8, 2022
DIY Robocars via Twitter
RT @PiWarsRobotics: Presenting: the Hacky Racers Robotic Racing Series in collaboration with #PiWars. Find out more and register your inter…
Oct 23, 2022
DIY Robocars via Twitter
RT @Hacky_Racers: There will be three classes at this event: A4, A2, and Hacky Racer! A4 and A2 are based around UK paper sizing and existi…
Oct 23, 2022
DIY Robocars via Twitter
Oct 23, 2022
DIY Robocars via Twitter
Oct 19, 2022
DIY Robocars via Twitter
Oct 18, 2022
DIY Robocars via Twitter
RT @NeaveEng: Calling all UK based folks interested in @diyrobocars, @f1tenth, @donkey_car, and similar robot racing competitions! @hacky_r…
Oct 13, 2022
DIY Robocars via Twitter
RT @araffin2: 🏎️ After hours of video editing, I'm happy to share a best of my Twitch videos on learning to race with RL. 🏎️ Each part is…
Oct 13, 2022
More…