Description: Most FC these days have built in telemetry video overlay feature except PixHawk. It takes away one serial Port which is a bummer.
People buy Minimum OSD, vector list goes on. By incorporating OSD (telemetry overlay feature) inside Pixhawk hardware, all this revenue $$$ will go towards Pixhawk hardware developers.
As we are heading towards autonomous flying in the future, video telemetry overlay feature is critical to have. Also, it eliminates wiring headaches down the road, one less item to fail in mid flight.
First of all, there is no such thing as pixhawk platform. There is Ardupilot and flight controllers that support Ardupilot code.
There are many FC’s that have built in OSD and runs ardupilot software. The support for these FC’s OSD are already in the code.
For autonomous flying OSD is not really neccessary. It is good for hobbysts and FPV flyers, for any other use cases there is a full telemetry which transmits tenfold more data than an average osd can.
Even FPV flyers are moving to HD, FullHD digital video, where traditional analog OSD is not usefull anymore.
So the only relevant use case is for racers and they have their super integrated FC’s with OSD and Ardupilot support.
“There is no such thing as Pixhawk Platform”, now you really confusing me. So this web site https://pixhawk.org/ " The open standards for drone hardware" doesn’t define Pixhawk hardware is based on?
And to me ArduPilot is the software…so your comment has really confused me.
I also beg to disagree with you on your marketing analysis of Pixhawk “or” call it Ardupilot Hardware not having a built in OSD including platforms such as Pixhawk 2.1 a.k.a cube. a.k.a Orange, “or” PX4 etc. God knows who comes with up all these naming conventions.
I prefer Pxhawk over other FC’s for multiple reasons (History, comfort to use etc.). One commercial application we do is to provide cell tower inspections services. I run a company that builds Verizon and AT&T cell towers and installing 4G and now 5G antennas nationwide, besides catering to utility companies for inspections.
In the old days the technician would take 300 pictures of the job completion which you send to some back office engineer who evaluates the quality of work finds out that the guy missed few pics. Now the tech has to climb up the tower and take pics again.
The new model is that we provide live streaming of video either via a drone, or handled device. The live stream need lat and long data superimposed on the video and there is some other proprietary data we want to display down the road. Plus reduces the man power in the field to fly the UAV.
As the DJI platform is getting banned in the US (Typically used e.g. in this industry in the past) the demand for other reliable FCs such as Pixhawk for commercial application is growing.
We incorporated UAvionics ADS-B in Pixhawk 2.1 Orange, so why can’t we incorporate OSD data over lay? (required for many other applications and we are not talking hobbies here) One less device to fail mid air in my opinion and there are many other functionalities we can add in OSD overlay.
We are exploring few options without getting into too much details due to NDA issues with Nokia, Ericsson, Verizon and so on.
We do have a 4G streaming solution. I am working with a company to develop a 5G solution.
We also looked into, incorporating DJI Occusync with PixHawk and I have a thread going on with one guy in UK. So far, I can’t get it to work. DJI Occusync and Pixhawk
I also worked with another company in Europe who was developing 4K Video Tx solution with extremely low latency, Sorry to use the word “idiot”, but I told him he selected the wrong hardware platform (he didn’t use ASIC) for the development and at the end he pulled the plug on the project and now looking for a job. Rumor has it, DJI is working on an ASIC based Video TX solution. they have no competition at this point.
The question why I’m asking is because current one chip solution that possibly can be integrated is for analog SD video.
Doing a realtime HD video OSD is not a simple problem. Especially if your imaging device outputs compressed video stream (like most of the inspection cameras). You have to add osd content to the image BEFORE encoding. Which means that the OSD must be in the camera.
(Don’t forget that the latest DJI onboard osd was the iOSD mkII around 2013).
Instead of adding content to the video image, you have to add the data stream to the video stream and do the visualization on the ground end (just like DJI and others did). There are standards to do so (see KLV metadata or STANAG 4609, MISB 0601).
I am with the community and I have been contemplating about supporting “or” developing the next Gen FC for the community (better than Pix 2.1).
I have some design improvement ideas. As DJI getting kicked out, its time to provide an open source solution that all can benefit from. Enough corporate BS and monopoly games.
I fully agree with your analysis of technical issues around encoding OSD content on to the video stream. its a huge challenge as the technology evolves to high definition video streams.
Outside of PixHawk hardware, this is what we are developing. I will let the cat out of the bag
We are at the final stages of market testing a new Goggle. Supposed to be better or equal quality as DJI Goggles and with some unique twists. Its FPGA based and after market test, we may switch to ASIC design. Its almost ready. targeting 2021 GA.
The goggles will have e.g. one plug in option where user can super impose PixHawk or any other FC telemetry data or any other proprietary data on the display screen inside the Goggles. You buy the module of your choice so its not hard coded. Offers much greater flexibility as far as support for various telemetry protocols out there also will support custom applications for the military and other commercial sectors.
We are also developing modules for video reception and transmission. So 4G, 5G Tx and RX modules, analog video modules (Pick any from the market 5.8 Ghz) and right now bench testing HD video solutions we have designed ourselves.
The goggle main purpose is to provide unique and enhanced viewing experience. All other bells and whistles are plug and play modules. Like lego concept.
What is your experience with KLV meta data development? maybe you can talk to my lead Design Engineer when the time comes.
I would still like to see analog OSD inside Pixhawk. It will make my 19 year old very happy
I fully agree with this proposal. It has lots of use cases, even in autonomous flights (non amateur/hobbyst FPV flights) to the contrary of what Eosbandi is suggesting.
Adding a video overlay chip (analog and digital for HD streaming) would add a useul extra feature to the autopilot for a relative negligible cost (Pixhawk autopilots are priced in the 200-400 dollars range across the different major brands : mrobotics, Drotek, CUAV, Holybro, Proficnc, etc)
If you fly an ardupilot fc with a gcs, instead of video goggles, isnt that your osd?
Im lost, i thought an osd gave you telemetry data live to your goggles on top of your fpv.
Mp gives you a hud with all the osd information plus a moving map, plus so much more. And you can put the video link under the hud.
So why do they have to add an osd… its all there already?
There is some mistakes.
ArduPilot don’t do hardware but only software ! Some hardware partners could see this post but the team got no power on hardware…
From a software point of view, we already support some OSD chip directly from ArduPilot, you could find on our wiki the hardware that support the OSD feature.
Pixhawk is a trademark not a hardware type. Some vendor got permission to use pixhawk in their hardware name but now most are abandoning the pixhawk brand as it means noting … There is the original pixhawk 1 and all hardware after are different with different options. You could already find some hardware that implementation pixhawks standard with OSD
There is no such Pixhawk 2.1 a.k.a cube. a.k.a Orange … pixhawk 2.1 is the CubeBlack for Proficnc. He got right on the branding. The Cube Orange, and all others colors beside black, aren’t Pixhawk … they are Cube as they are from Proficnc and not Pixhawk brand… same for Durandal flight controller… that isn’t a pixhawk.
@Hugues I don’t know what professional application you are doing with autonomous drone, but video polluted with OSD isn’t great … having a telemetry system is far better and simplier on long distance. You can still do the sync between video and telemetry on the ground if you need to display thing on video …
One functionality does not exclude the usefulness of the other. Telemetry, GCS, display on telemetry on video on the reception side is not excluding the uses case of a video overlay onboard (think of the différences between video, radio control and telemetry bands/power/local régulations).
Khan - Thanks for the clarification. I understand ArduPilot is responsible for the software piece but I want to use you guys influence on the hardware team
I honestly think all these naming conventions are plain ridiculous. Some thought process seriously needs to be put in place going process. Anyone new trying to get in needs to take a history lesson first.
I was being sarcastic when I said , “Pixhawk 2.1 a.k.a cube. a.k.a Orange …”
Maybe I should put together a catchy song explaining the history of Ardupilot… lol
We loosely use the word OSD to confuse everyone :). I corrected my above post to avoid future confusion. What we meant that the FC such as Pixhawk that doesn’t have a built in video telemetry data overlay feature and requires an external telemetry data overlay device such as Minimum OSD which you connect externally.
The requested feature is to overcome using an external telemetry data overlay device. This way you plug in your onboard camera into Pixhawk, Pixhawk adds the telemetry data and encodes on to the video stream, then you connect your Video Tx to the FC and transmit the video stream back to the ground. Some MP/ArduPilot compatible FC’s have such feature except some who designed their hardware using open standard platform.
The feature is useful for those using Goggles, not laptop to fly the Plane/Quad etc.
If your Video camera and video TX are analog, then we just need a few dollar chip inside the Pixhawk FC to solve this problem and mission planner already have the features to support that.
If your video camera is HD, now that’s a whole different challenge. See Eosbandi and my comments above.
