OSD support #2210

Closed
hydra opened this Issue Jun 5, 2016 · 54 comments

Projects

None yet
@hydra
Contributor
hydra commented Jun 5, 2016 edited

This is a placeholder issue for discussion.

The intention is to add OSD support to Cleanflight.

Cleanflight is mainly targetted at the FPV and acro flying scene. Many FPV pilots need OSDs. The top four reasons are the following:

  1. battery status.
  2. flight time display.
  3. On-screen configuration of the FC.
  4. Callsign so spectators and see who is flying and for finding your own VTX channel.

Adding OSD support to cleanflight will let us build two types of system initially, and a 3rd later:

  1. FC
  2. OSD
  3. FC with built in OSD. (e.g. boards using MAX7456 chips, boards like the ImmersionRC Fusion and F4 boards like the BrainFPV)

It has long been noted by many pilots that the MinimOSD project, while very functional, is not a nice system to setup and configure. It also seems that the MinimOSD project is shunned by developers (compared to cleanflight, with over 1000 forks), I hear from various parties that it's for a few reasons: it's not nice to develop on atmel boards - debugging not as easy, hardware limitations, etc, etc.

Since the cleanflight codebase is quite mature and relatively re-usable it makes sense to use it, and the developer community, to bring about a new wave of OSD hardware and software.

This will bring the following benefits:

  1. more modular, isolated and re-usable code with fewer dependencies.
  2. open-source stm32 based OSD systems.
  3. more good deveopers helping progress OSD systems.
  4. configuration of OSDs via the cleanflight configurator.
  5. configuration of cleanflight via the OSD.
  6. further dissemination of the cleanflight brand via OSD branding.
  7. a shake-up in the OSD market - new and alternative hardware designs would be possible instead of just minimOSD boards.

I thought long and hard about having two different firmware codebases, but i feel integrating OSD code into the cleanflight firmware repo is the right answer, the primary reason is that if in another repo the code would have fewer eyes on it, fewer developers and a higher likelyhood of going stale.

I already have working F1 and F3 OSD prototype boards built and working. It's also equally possible to use the STM32F3DISCOVERY as an OSD development platform.

I am not currently in favour of a build system other than the one we have now. I also dismissed the the idea of separate library and firmware repos because of the overhead and complexity of pull requests and keeping things in sync. I am very open to discussion about further code reorganization and cleanups.

I'm looking forward to what the Cleanflight hardware and software community comes up with, i feel that this will make our hobby even more exciting!

I will be making the first PR for this after the release of CF 1.13.0.

@hydra hydra added this to the 1.14.0 milestone Jun 5, 2016
@hydra hydra self-assigned this Jun 5, 2016
This was referenced Jun 5, 2016
@JohnOCFII

I'd like to standardize on learning fewer thing well, then having to learn a little about many different things. Right now I use MinimOSD as it is quite popular, flexible, and inexpensive. The ability to have an OSD that you can configure through a Chrome App would be a great improvement.

As I have interested both in the existing CleanFlight features, as well as great interest in the iNav navigation features, I'd hope that any OSD you create would have the flexibility to handle the mapping and GPS data that is useful in that scenario. (See, that way I can stop dealing with ArduCopter and Pixhawk -- thus simplifying my RC world).

There are already a handful of simple OSD units out there. I'd hope the CleanFlight option would be a full-featured and flexible OSD.

And, of course, the cost would have to be pretty low to get much activity. The various minimOSD boards are under US$20. There are some wonderful OSDs out there, such as the BrainFPV you mentioned, but I would imagine the price has been a large impediment to greater adoption. I know it kept me from buying one.

Also, I'd hope than any efforts in the OSD arena don't negatively impact what I see as the more pressing desire: integration of iNav and BetaFlight features.

@hydra
Contributor
hydra commented Jun 5, 2016

@ShikOfTheRa you will definatly be interested in this. If you want development hardware just let me know your address.

@hydra
Contributor
hydra commented Jun 5, 2016 edited

@JohnOCFII Thanks for your feedback. Yes iNav and betaflight features are wanted. I made note of betaflight improvements and scheduled them for 1.14.0 in #2211. The iNav stuff is wanted too. I am keenly aware of the requirement for GPS improvements in cleanflight. Any thing that forces us to think harder about code modularisation/separation and re-use (such as OSD support) bodes well for the future.

I'm sure that once the configurator can configure OSDs and people see it there will be more interest.

With regard to full-featured OSD support, we start simple and cheap and go from there. The point is we are actually starting! 😄

@tonofsteel

I have been following for awhile in background and I am very interested in contributing. Recently I have been looking to make an improved OSD and then this came up.
This sounds like the interest is in having the OSD directly as part of the hardware and software of CleanFlight / SPRacing? This sounds alright but personally I am biased towards having the hardware modular as well as the software. Make a really good flight controller that does flight control really well and an OSD that does OSD really well. Putting these together on the same micro will inevitably cause compromises to be made to both to accommodate is what i worry about.
But whatever direction this goes what do i need to work on now to help? Or what should I start looking into, the iNav / beta flight was brought up too.

-------- Original message --------
From: Dominic Clifton notifications@github.com
Date: 2016-06-05 7:47 AM (GMT-06:00)
To: cleanflight/cleanflight cleanflight@noreply.github.com
Subject: Re: [cleanflight/cleanflight] OSD support (#2210)

@JohnOFCII Thanks for your feedback. Yes iNav and betaflight features are wanted. I made note of betaflight improvements and scheduled them for 1.14.0 in #2211. The iNav stuff is wanted too. I am keenly aware of the requirement for GPS improvements in cleanflight. Any thing that forces us to think harder about code modularisation/separation and re-use (such as OSD support) bodes well for the future.

I'm sure that once the configurator can configure OSDs and people see it there will be more interest.

With regard to full-featured OSD support, we start simple and cheap and go from there. The point is we are actually starting! 😄


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#2210 (comment)

@ledvinap
Contributor
ledvinap commented Jun 5, 2016 edited

@hydra:
It may be much simpler if you reduce OSD to 'text display sink'. From point of firmware, it should be quite similar to OLED display / display over TX telemetry (and it may be implemented both as external module or internal code).

  • It should be connected either as telemetry - required code should be quite small, supporting telemetry on OLED may be nice bunus.
  • Or to menu system - which will be a bit complicated, the code is not that modular or clean now, but then we can support OLED/TX/OSD
@hydra
Contributor
hydra commented Jun 5, 2016 edited

@ledvinap that's similar to the aproach I want to take. yes the menus should work for oled/tx/osd. it's gonne be great!

@tonofsteel yes, separate to start with. and it's awesome to see that you have an interest in this. keep an eye out for the first PR's next week.

@tonofsteel

From what I understand i should get a f3 discovery and stlink in prep for dev / PRs? You mentioned you would send out a kit to existing devs, i am not existing and i don't mind buying my own, just need to figure out what to get. 

-------- Original message --------
From: Dominic Clifton notifications@github.com
Date: 2016-06-05 3:19 PM (GMT-06:00)
To: cleanflight/cleanflight cleanflight@noreply.github.com
Cc: tonofsteel tonofsteel@hotmail.com, Comment comment@noreply.github.com
Subject: Re: [cleanflight/cleanflight] OSD support (#2210)

@ledvinap that's similar to the aproach I want to take. yes the menus should work for oled/tx/osd. it's gonne be great!

@tonsofsteel yes, separate to start with. and it's awesome to see that you have an interest in this. keep an eye out for the first PR's next week.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

@hydra
Contributor
hydra commented Jun 5, 2016 edited

@tonofsteel an stm32discovery is a very handy board to have around generally. it has a built-in st-link board and a CPU with more output pins than on most FC's so you can hook them up to leds and scope inputs for additional debug information. if you're interested in helping out get one on order - they're cheap and will help get you started. I'll give more details of additional hardware required later this week.

@jflyper
Contributor
jflyper commented Jun 6, 2016

I have many questions, but the first and foremost question is

Will the new OSD hardware be open source?

Other questions and comments will follow...

@hydra
Contributor
hydra commented Jun 6, 2016

@jflyper Seriously Pro Racing (SP Racing) products - not open hardware. Development build hardware (for F3DISCOVERY) - yes. The same approach is taken with pretty much all existing cleanflight boards with the exception of the Sparky, CC3D and CJMCU. No schematics or gerbers are available for most of the supported boards (Naze32, Motolab, IRCFusion, Lux, etc) and in the cases where they are available they are for non-commercial use. I don't see this being an issue for anyone given the success of the cleanflight firmware and available hardware platforms.

Fire away with your other questions. Likely many will be answered when the first PR is ready.

@ledvinap
Contributor
ledvinap commented Jun 6, 2016

@hydra : Publishing schematics will help with development. And Chinese cloners need only weeks (and probably copy PCB layout directly), so hiding schematics doesn't even slow them ...

@hydra
Contributor
hydra commented Jun 6, 2016

@ledvinap I said 'yes' to stm32f3discovery schematics above. 😄

@jflyper
Contributor
jflyper commented Jun 7, 2016 edited

Development hardware would be super simple with proper F1/F3 board, 7456 BOB, half a dozen jumpers and a 1K pull up register; there is no schematic nor magic required. (Unless the SPROSD does not use the MAX and decide to go for the software way.)

[EDIT] MAX7456 has reached EOL. There seems to be some second source (AB7456?), but can't find details on the net.

@jflyper
Contributor
jflyper commented Jun 7, 2016

I agree with the vision on the need for a new OSD hardware and software support in CF. In fact, I have been doing some experiments in this field since MSP code separation work has started. The work included I2C/SPI connected OSD (which has reverted to I2C/SPI UART expanders), Scarab (MW) OSD running on Teensy 3.1 (uses Freescale MK20) and so on, so I believe I can contribute a little bit here.

Personally, I find it more challenging and interesting in a OSD integrated FC (the FC+OSD case above). There, we will be looking at interesting problems like how to schedule the SPI bus with possible DMA utilization for devices with different timing constraints and priorities (namely MAX and ACC/GYRO), possible new FC design with multiple SPI (and I2C also) buses and less UART and such.

I'm little bit concerned with having the repo for the SPROSD within the CF as we will be seeing more support questions.

@JohnOCFII

The integrated vs. non-integrated question is interesting. Ideally, both can be designed and supported. One the one hand, quads smaller than 250-class really benefit from fewer separate components due to lack of space. On the flip side, I'd hate to have to replace a consolidated (and expectedly more expensive) multi-function board if just one small piece (say, the MAX chip, or equivalent) fails. My first quad had as many discrete components as possible, but my more recent builds are re-integrating things because I need to save both space and weight.

@martinbudden
Contributor

Some thoughts:

  1. I think keeping the OSD code in the CF repo is the correct decision, at least initially. This will make development easier. Once the OSD is mature the idea of putting it in a separate repository should be revisited. Of course extra care needs to be taken to ensure good separation between the CF and OSD code.
  2. In terms of hardware, I think the "natural" place to integrate the OSD is the VTX, not the FC. This is especially true if the VTX supports software setting of the channel, since then the VTX needs to be connected to the FC anyway. Of course there are also advantages to integrating the VTX with the FC.
  3. In terms of schematics, I agree with @ledvinap : publishing them helps with development and doesn't make any difference to cloning. They can be published under a non-commercial license/copyright - that is the schematics can be published without making the OSD hardware open source.
@jflyper
Contributor
jflyper commented Jun 7, 2016

@martinbudden
I think the physical placement of components can be isolated from software, and it actually is where different vendors can compete with their original design philosophy and implementation.

I'm dreaming of a setup in which everything except serial RX is connected with I2C/SPI (may be a second i2C/SPI to avoid interfering with ACC/GYRO); OSD, VTX, GPS, Serial Expander, RGBLED, PWM Expander and so on.

@tannewt
Contributor
tannewt commented Jun 7, 2016

I think OSD support would be awesome. Doing away with the MAX chip would be even better because the legit ones are pricey.

@ShikOfTheRa

@hydra yep - definitely interested.
MWOSD I think still has a long future still, but a fresh start for CF is in desperate need to overcome the issues with the original hardware and software design intent.
I dont get too many new for extras now, but they are almost all based around... more config items available via OSD menu and cooler graphics...

Have your email somewhere on my old PC - I'll dig it out.

@hydra
Contributor
hydra commented Jun 7, 2016 edited

@martinbudden -

  1. yes, we can revisit down the line once we have a better view of the codebase and other factors that will surface for sure.
  2. yes, agreed. watch this space. 😄 See #1958 #1948 etc. The ideas would work for OSD/VTX and or FC/OSD/VTX.
  3. Yes, I and others can and likely will contribute to OSD hardware connected to an STM32F3DISCOVERY which people can use to base designs from.

@ShikOfTheRa Yes, menu code can be shared between the FC and OSD. The OSD will be able to ask the FC for a menu and just display it. See #2014. The OSD layout will be grid based but we can add code that displays items as we see fit, per OSD implementation.

I'm sure once we get a first cut we can refactor the hell out of it to make it do what we need and support a variety of hardware.

@tannewt Yes, the MAX7456 is a good starting point. There are other solutions which are pretty cheap such as the one used by the IRCFusion and BrainFPV. The main issue there however is RAM for the screen. The low end processors (F1) do not have enough and the higher end processors obviously just cost more. So legit MAX7456 + F1 works out about the same as F3/4 + custom video hardware.

People interested in alternative video outputs should check out the quantracker schematics, here:

https://github.com/kwikius/quantracker/tree/master/air/osd/hardware/64_pin_lite/air_osd_v2_1

The TauLabs source for the BrainFPV is also very interesting for those wanting to know how that hardware works (It uses a video sync seperator LMH1980 and some 100Mhz video op amps and a SPI output to generate signals).

The important parts of the BrainFPV source are here:
https://github.com/BrainFPV/TauLabs/tree/brain/flight/Modules/OnScreenDisplay
https://github.com/BrainFPV/TauLabs/tree/brain/flight/targets/brain
https://github.com/BrainFPV/TauLabs/blob/brain/flight/PiOS/STM32F4xx/pios_video.c

You can see that the system is quite demanding on the processor (two ISRs are called ~13k times/sec, for instance)

@tannewt
Contributor
tannewt commented Jun 7, 2016

@sheaivey may also be interested.

@hydra thanks for the links! Lots of food for thought.

@hydra hydra closed this Jun 10, 2016
@hydra hydra reopened this Jun 10, 2016
@hydra
Contributor
hydra commented Jun 12, 2016

#2226 is the first cut of code. Would love some feedback on the PR comments people!

@martinbudden
Contributor

Well, my first comment is that it is very difficult to give feedback on such a big PR (133 files changed!). There seem to be quite a few peripheral changes (ie changes to parameter groups, which caused a lot of files to change, changes to the scheduler, a new font etc). These peripheral cleanup changes may be important, but they make it hard to get to the meat of the matter. For future reference, for any enhancements you make, I'd like to see a first cut without the cleanup.

Having said that, I'll take a further look, but it may take some time...

@hydra
Contributor
hydra commented Jun 12, 2016

there was a lot of code reorganization required in order to build the target, most unavoidable. My first cut was to actually take the CF 1.12.0 codebase, delete everything flight related and go from there. 😄 #2226 keeps all the new code and fits it into the CF codebase so we can build one or the other.

There are no changes to PG code other than adding new parameter group IDs. Most of the major changes relate to relocating some of the MSP code. Other than that it was relatively trivial, it only took about 3 hours from starting with the CF1.13.0 codebase to getting something that would display stuff on-screen. Then it was a matter of updating the tests and adding the other new code back into the codebase. Over the last few days I then wrote all the code featured in the new commits such as features like font-upload procudure, vsync support, etc.

It came together pretty quickly, it's a testament to how re-usable the code in the codebase is, I can't thank you all enough for helping make things as great as they are!

@hydra hydra referenced this issue in savaga/betaflight-sirinfpv Jun 14, 2016
@savaga savaga SIRINFPV target initial code 8a93041
@hydra
Contributor
hydra commented Jun 15, 2016 edited

@ledvinap oh, with regards to existing PR's, most don't merge anyway because of the configuration storage changes in v1.13.0. Some of the bigger PR's (menu system) are in need of major cleanup anyway. EXTI stuff doesn't change that much since none of the drivers moved.

So that we don't have a buildup of new PR's targetting moved code I suggest that I cleanup the non-OSD code changes (very few) merge to master early next week. The OSD code is totally isolated, so even if it's less than idea we can still merge it and clean it up/replace it as we go - splitting the work as we see fit.

@zdar
zdar commented Jun 23, 2016 edited

I may be totaly wrong but what about support of cameras with digital interface? Something like OV7670. I know that they are normaly not in use for FPV as everebody uses analogue for latency and compatibility reasons but there could be some benefits:

  • interface is available on common processors
  • interface is resolution independent -> higher quality could be easily achived (just matter of processing power) - think of HD or stereo images
  • a lot of tricks could be done by the CPU on the image
  • no need for special analogue video signal input processing chip
  • they are cheap

Yes there are some cons:

  • video signal still needs to be generated somehow
  • processing has to be done on CPU - more horsepower needed
  • new cameras needed
  • possibly some lag from processing

Update: Think of Raspberry Zero + Camera solution which has all the goodies needed (camera interace, vidou out) and plenty of spare processign power

@hydra
Contributor
hydra commented Jun 29, 2016

@zdar in short yes. Though I've not investigated any time to research such solutions.

@dkisselev
Contributor

@hydra how are you wiring up the demo stmdiscovery board that you're sending out? Is there a doc/pinout somewhere?

@hydra
Contributor
hydra commented Jul 4, 2016 edited

@dkisselev I'm not sending out stm32discovery boards. I'm sending out my hand-built prototype boards. It's simple enough though, just look at the max7456 datasheet for an example. hook up OSD to an SPI port and hook up VSYNC and HSYNC and LOS to 3 GPIO pins. You can also hookup the RESET pin on the MAX7456 to the stm32 board to allow the stm32 to hard-reset the MAX7456. 8 pins total.

@ledvinap
Contributor
ledvinap commented Jul 5, 2016

@zdar: This is probably future of FPV, eventually even for racing: https://befinitiv.wordpress.com/wifibroadcast-analog-like-transmission-of-live-video-data/

I can't see any advantage using analog once signal is digitized frame by frame. And with strict 5GHz power limit for analog TX (20mW in Czech republic), WIFI is probably only cost-effective and legal way to get reasonable range.

@martinbudden
Contributor
martinbudden commented Jul 5, 2016 edited

@ledvinap , presumably DJI Lightbridge uses a similar technology

@zdar , a Raspberry Pi Zero is probably to big for many FPV racers, but a ESP8266 could be used, or an ESP32 when they become available.

@ledvinap
Contributor
ledvinap commented Jul 5, 2016

@martinbudden :
camera + Raspberry Pi Zero + USB wifi in air / Raspberry Pi 3 + multiple USB WIFI for diversity will cost considerably less then Lightbridge. Also 5GHz is easily possible.
And Lightbridge latecy is stated as 100ms - air only, without camera and display. befinitiv solution seems to be under 100ms total delay now, with good possibility for further improvement.

And there is also the opensource thing ...

It would be great if someone could create BCM2835 board directly adapted for FVP ...

@martinbudden
Contributor

@ledvinap , I'm not advocating the use of Lightbridge, just remarking that the technology is probably similar.

@hydra
Contributor
hydra commented Jul 6, 2016

OK, initial cut of OSD support is now merged. #2226.

Next up I will be looking at more display elements and configurator support. However I may add MSP support for PG's first and the update the configurator to use PG's for OSD configuration. I will sleep on it and review any comments before I start work on the next bit of work.

@orgua
orgua commented Jul 9, 2016

Offtopic / a little bit more to wifibroadcast: the first version of the Pi-Zero has no Camera interface. The Odroid-w is even smaller and lighter and has a wider voltage-input and even battery management. Unfortunately it is hard to get. The supported TP-Link TL-WN722n have a diversity switch and an external SMA-Port. With some tinkering you can get two external antennas.
My setup is running since last year and is in a small 70x40x20mm box. On the receiving end is a laptop and/or a patched Android-Phone with Google Cardboard for FPV. Digital 720p is awesome. Latency is about 60ms.

2016-07-09 13 33 28

2016-07-09 13 33 46

@bnn1044
bnn1044 commented Jul 13, 2016

I want to Start the pull request long time ago for the OSD support.
Hydra, I am interested in hardware platform design, and I am electrical engineer. Can you point me a way how to get closer to the cleanflight hardware design?

My email bnn1044@gmail.com. I hope I can help and contribute to the community.

thanks,

@hydra
Contributor
hydra commented Jul 18, 2016

@bnn1044 Hi, the hardware will be available soon. I have no prototypes left at the moment.

@hydra
Contributor
hydra commented Jul 18, 2016 edited

With regards to OSD code, I've been working on some changes to allow FC targets to be built with OSD support. The issue I am encountering is the source of the data for the OSD elements.

if the OSD wants to display the battery voltage, then it has to take the value from 'fcStatus.vbat' which is poplated from the result of an MSP command. If an FC with integrated OSD needs to display the same thing then could just access 'vbat' directly.

The situation is more complicated for things like flightmode flags which are packed into an MSP_STATUS response for OSD or available via FLIGHT_MODE macros in FC code.

I'm thinking the best solution is a common interface for both OSD and FC code and link in a specific implementation for both. I toyed with the idea of populating an fcStatus instance in the FC code but things like the flight modes complicate that somewhat.

I'll try and get some commits done today that at least allow the OSD in an FC to at least display something so that others can see the code too.

@hydra
Contributor
hydra commented Jul 21, 2016

Status update: Still working on the code, I've been prepping things on some development hardware here and have got everything to a working state. I've also received the SIRIN FPV board from @savaga which features a directly connected OSD. Lots of hardware related things have been taking a while but are now sorted so I can concentrate of making the prototype code work for standalone and integrated OSD systems again.

@bnn1044
bnn1044 commented Jul 21, 2016

Can you make some wiring diagram on the discovery F3? and make a target for it? I like to test the code also. Thanks. great job.

@hydra
Contributor
hydra commented Jul 21, 2016

yes, when I get a bit of spare time I'll get that target organized.

@gaelj
Contributor
gaelj commented Jul 21, 2016 edited

@hydra, the configurator hangs when connecting to the board you sent me. Lots of MSP timeouts (240, 116, 110, 101).
Also when I try to reflash it (SPRACINGF3OSD ?) the ports closes and refuses to open until I reboot it.
EDIT: This was juste due to Betaflight configurator running in the background and steeling the serial port when I triggered a reflash in Cleanflight configurator...

@jflyper
Contributor
jflyper commented Jul 24, 2016

I wish I can convert my SPRF3 with bad gyro to dev platform.

@hydra
Contributor
hydra commented Sep 3, 2016

@jflyper production boards should be available next week, after many many many delays.

@krzysztofmatula

@hydra, what exactly is going to be available - stackable PDB/OSD board for EVO, as seen in one of images on seriouslypro.com, or something else???

@ShikOfTheRa

Looking forward to these!

@hydra
Contributor
hydra commented Sep 7, 2016

@kylemanna yes.

@hydra
Contributor
hydra commented Sep 7, 2016

@ShikOfTheRa send me your address and I'll get one shipped to you.

@jflyper
Contributor
jflyper commented Sep 12, 2016

@hydra

production boards should be available next week, after many many many delays.

Yeah, saw the teaser(?) on seriouslypro.com. Look great :)

@ShikOfTheRa

@hydra - that would be fantastic. I'll drop you a mail.

@hydra
Contributor
hydra commented Sep 12, 2016 edited

ok, this is done. all the code is ready for the first production release.

Details:
http://seriouslypro.com/spracingf3osd

Purchase:
http://shop.seriouslypro.com/sp-racing-f3-osd-pdb

Enjoy!

I've also created a new issue in preparation for future OSD direction. Please see #2399.

@hydra
Contributor
hydra commented Sep 12, 2016

Thanks to everyone who has contributed to this, especially @ShikOfTheRa @savaga @nathantsoi @NightHawk32 @skaman82 @ledvinap and @martinbudden the MWOSD developers, anyone that ever made and posted anything on the internet regarding OSD systems, video systems, electronics engineering and code, and anyone else I missed. All a great help!

@hydra hydra closed this Sep 12, 2016
@kwikius
kwikius commented Oct 23, 2016 edited

@hydra I see you have referenced my OSD schematic. I'm pretty close to North London. Wonder if you want to meet up some time and discuss whether it is feasible to do a cleanflight version?

@hydra
Contributor
hydra commented Oct 30, 2016

@kwikius yes, I'll be back in London soon. Would be great to catch up. Please email me your contact details.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment